Category Archives: Architecture

几篇不错的virgo文档

On OSGi, Spring and Eclipse Virgo OSGi Debugging in Eclipse Virgo virgo的shell有两个,如果根据这篇文档没有找到对应的命令,那么应该是连错地方了。一个配在config目录下的osgi.console.telnet.properties里,还有一个配在repository/ext下。

Spring Integration – Quote Example理解

前两天看了一个关于Spring Integation的Webnar。感觉相当不错。Spring从最初的反转控制到现在做的如此之大确实让人感叹。Spring的那些人既能写代码,又能做这么好的演讲,另人佩服。 准备花段时间看一下,也把自己的理解记一下。 大致翻了一下Spring 参考文档 下载了并安装了Spring Tools Suite 下载了示例代码 解压示例代码,并在STS里以导入Maven工程方式导入。 Spring的依赖注入之后各个模块之间的关系不是特别直观了。完全依赖于对Spring配置文件的理解。Quote是一个非常简单的例子。 // Spring 依赖这些namespace来决定需要干什么 // 这是一个输入的通道,名字叫tickers。每300ms调用一次tickerStream的nextTicker函数 // 这是一个输出通道,名字叫quotes。 // 上面tickerStream bean // 一个quoteService bean。在上面的例子中只有输入和输出通道。QuoteService里定义的另外一组输入和输出。 QuoteService定义。 @MessageEndpoint public class QuoteService { // 输入通道是tickers,输出通道是quotes @ServiceActivator(inputChannel=”tickers”, outputChannel=”quotes”) public Quote lookupQuote(String ticker) { BigDecimal price = new BigDecimal(new Random().nextDouble() * 100); return new Quote(ticker, price.setScale(2, RoundingMode.HALF_EVEN)); } } Spring根据上面几个通道定义,将每一个输入和输出一相连,就形成了一个有机的链条。

也谈单元测试拯救了架构设计?

Honnix在blog里写了一篇”单元测试拯救了架构设计?” 我也有感而发, 谈谈自己对这方面的看法. 虽然我现在已经和架构设计逐渐偏离, 但是我对架构设计还是由衷的热爱. 首先关于什么是好的架构设计,什么是架构设计的水平? 我心中的评价标准为. 所以以我心中的标准, 架构设计的水平越高越好. 简洁明了 模块之间既相互独立又有机融合 初级程序员可以根据设计说明做具体的任务 大部分程序员能够明白架构设计理念. 而不是只有架构设计者 架构易于演进, 易于测试, 易于添加分析统计功能 把大部分异常处理当作正常流程处理 团队成员喜欢并乐于维护这个架构. 而不是架构只是架构设计者一个人的宝贝. 团队其他成员恨不得重写一个 关于如何做单元测试. 我认为那是一个度的问题. 从设计之初需要考虑如何做单元测试. 但是并不是把所有代码都写成可以做单元测试. 因为并不是所有的代码都适合做单元测试. 如果仅仅将单元测试作为一个唯一标准, 那么自然会导致需要各式各样的注入, 使整个结构异常难于理解. 所以在模块内部可以有一定的耦合性. 作为比单元测试层次更高一层的测试模块测试. 我认为这一个层次测试就需要更加解耦一些. 不能说只能整个系统集成时才能测试这个模块. 作为架构设计师, 中庸是最好的方式. 对任何东西都需要有一个平衡. 单元测试重要不重要, 是重要. 但是单元测试不是全部. 如果仅仅因为单元测试引入了太多的复杂性, 那还不如将这部分测试放到模块测试中去.

在中-国做软件架构设计

架构设计在整个软件设计中起到至关重要的作用。软件架构的好坏直接影响到软件是否成功。 一般组织结构中有架构师这个角色。比较通用一个迭代周期一般是这样的。 系统工程师分析客户需求。将需求形成User Story。 架构师分析所有重要的User Story,设计架构。如果User Story不清晰和系统工程师再沟通。 架构师将架构交到开发团队,由团队开发,并作单元测试。团队开发时发现架构某些地方不合适,和架构师沟通并调整架构。 测试团队进行功能测试和系统测试。有问题团队修改,有时候还要调整架构。 交付。 这个过程看起来还不错。而且这许多国-家也切实可行。但是在中-国却非常困难。不少地方团队成金字塔结构,上面决定怎么做下面就怎么做,当然做决定之前可能会有反馈。而国-内一般是一个纺椎形结构,当然我指的是技术,不是收入。这就形成了谁也不服谁的局面。而且为了和-谐,即使上面做决定之前和下面的人讨论了,下面人也一般也不会当面说出自己的想法,而只是在心里咕噜,那是什么狗屁东西。然后决定做了之后,自己想怎么做还是怎么做。在一个模块之内可能还会做出一个比外面还要复杂的架构出来。 再拿孩子作比喻。谁家的孩子最漂亮?当然是自己家的咯。别人的孩子看着顺眼就看,看不顺眼可以不看。那自己的孩子呢?再怎么不争气还得接着养不是。 所以,只要架构设计上有哪怕些许不好的地方,也很有可能会被扔掉。最后造成你设计你的架构,我写我的代码。 所以我觉得(实验过)在国-内应该换一种思路。架构师主要不做架构设计,而做架构设计引导。让软件架构变成每个团队成员自己的孩子。 在架构设计引导时,一般应由团队自己做决定。团队成员如果有不同的方案,而你却认为这个方案不可行。那就要从内心上说服团队成员。如果说服不了,那还是得按团队成员的方案来,即使会失败也还得这么做。

框架挑选想到框架设计

只要是稍微大一点的公司,内部总会有各种这样的平台。当然外部也会有各种各样的框架。具体使用什么样的框架?内部就会有各种各样的争论。我最近就听到一个关于框架挑选的争论。 公司内部有一个有几个产品使用的web框架C。框架C基于Struts开发。这时有一个新的应用也需要web开发。该框架的负责人A极力推框架C。而新应用的其中一个开发人员B极力反对,认为该框架太垃圾,不如直接使用Struts。其它的开发人员没有太强烈的意见。 这过程当中A列举了框架的很多优点。领导也要求B证明为什么能做好该新产品,做好的前提下能否有多少可能重用。 中间经历了相当长的时间。开始A占上风,B很无助。最后忽然B的方案被采纳,A很失望。 我作为外人对此次争论记一下看法。 我只是翻过用该框架写的东西,实在是不太能看的懂。当然这也由于我没有做过什么真正的web开发有关。只是听说有相当多的限制。 开发一个框架是相当难的,不是一般水平的人能开发好的。如果框架的架构师水平不是非常高,而给框架设了很多假设。那么该框架往往会给人很多限制的感觉。再加上有了框架之后,学习曲线会比重头写高很多。即使框架考虑了很多因素。但是这些因素大部分不是在开发之初能够感觉到的。这时候就会很多开发人员抵触了。 所以我认为框架应该尽量做薄,只做最通用的事情。其它的功能做成辅助库。让框架容易入手,给开发人员更多的控制权,是否使用其它功能由开发人员决定。

软件平台迁移

软件存在时间长了之后平台总会让人觉得落伍了。在各种力量的推动之下就会开始平台的迁移。但平台迁移到初衷到底是什么?是客户关心软件平台?是新软件平台可以提高业务的开发效率?还是纯粹的技术驱动? 经常会有人告诉我C++已经过时了,C++经常会有内存泄露,JAVA更时髦。内存泄露是C++的内建特性吗?JAVA就没有内存泄露吗?其实这完全是人们对C++理解不深入所造成的误解。C++只要遵循几个基本的准侧完全可以避免内存泄露,只有在性能非常关键的地方自己管理内存,并且谁分配谁释放,其它时候只要使用STL之类的标准库就可以了。JAVA如果用不好照样会有内存泄露,而且内存泄露会特别难找。几乎每种语言都有自己的优缺点,要不然早就灭亡了。C++的优点主要有二,一为内存和性能,二为行为可预知。JAVA最大的优点也有二,一为众多的开发类工具,二为众多的库。 那么从C++平台移植到JAVA平台有没有必要呢?那要看具体的目的了,而不是只是某些人觉得C++过时了。即使C,汇编在某些场合下也无法被替代,有他们各自的一块天地。其实客户才不关心最终是用什么语言实现。为了平台独立?C++也完全可以。为了开发效率?原来的平台都已经实现了,平台移植之后需要开发多少新功能才能达到平衡点。JAVA现在开发效率其实并不高,比JAVA开发效率高的语言多的是。 如果已经决定要移植平台了,那么怎么移植呢?重新实现一套?从外面引入一个平台?一步一步更新平台? 先说重新实现一套。如果让同样水平的另一拨人去完全重新开发,那么最后的水平也高不了多少。如果原来的那一拨人重新实现,那一拨人思维已经比较固化,实现的系统会比原来的好一些,所有的行为和原来差不多。最好是原来的那拨人,加上更高水平的新鲜血液,还得给足够的时间。 再说引入一个平台。引入的那个平台和原平台相比有多大的优势,有多少相似性。很多系统平台之是起支撑作用,更重要的业务逻辑。如果平台希望迁移,业务希望保留,大相似性就非常重要的。往往会决定移植后才觉得移植后的平台需要很多工作之后才能真正使用。 一步一步更新平台。这种策略比较稳,但是也就不会有很大的变化。 我经历的一个平台移植就是一个完全错误的决定。希望引入一个平台,平台迁移的目的没有考虑清楚,而且那个平台差距就比较大,而且当时决定所有的业务逻辑要在新平台重新写,导致了花了很多精力之后新平台还是不能使用。最终…

如何提高软件可用性

大家都知道软件可用性是一个软件成功的关键。微软成功的关键是可用性,苹果成功的关键是可用性,狗狗成功的关键还是可用性。 那么如何提高软件的可用性呢?用户根据什么来使用一个软件呢?那当然是软件使用文档了。一个软件如果软件文档很难编写,一个功能说明如果连设计人员都看不明白,那么软件的可用性就不咋的。所以应该边编写软件文档,边考虑可用性,再反过头来修改软件设计。 很多公司都有专门的文档编写人员。但是经常存在的问题是文档编写人员根本就不明白软件是怎么回事。更别说提出软件可用性的建议了。如果文档编写人员也能对系统相当熟悉当然最好了。但是术业有专攻,一般很难达到。即使能有这样的人,成本也不一样了。 所以我觉的软件文档应该由文档编写人员提供文档结构参考。设计软件设计人员负责编写。编写过程中如果发现难写一般会比较自然的考虑修改设计。文档初步编写完成之后再由文档编写人员润色。润色完了之后再由客户代表和系统测试人员测试文档是否描述清晰。

软件架构设计之性能设计

经常可以看到很多文章说性能调优不是最重要的,只有证明确实证明存在性能时才去调优。我想他们更多的是想强调不要太关注局部的性能调优。曾经听说过有人把x*10写成x

养孩子与软件架构设计

谁家的孩子长的最好看?如果有人这么问我,那我会毫无疑问的回答:“咱自己儿子”。我想很多人应该也是这样的,自己的孩子再怎么丑,在自己心目中那也是漂亮的。 中途领养了一个孩子,总会有各种不舒心的地方。老想着自己生一个会更好。 软件设计也是一样。通常软件都是由几个超强的人设计架构,然后交个一拨其它人去丰富完善。架构设计的再好,总有考虑不周到时候,不可能每个方面都非常完美。而且架构设计人员的潜在意图不可能100%的传递给后面的维护人员。而维护人员中也会有不少人做着做着就想,那玩意设计的啥吗!我要自己设计一个肯定比那个好的多。这就导致了一个孩子养到十四五岁之后,就有很多人又从头开始养还自己的孩子,到十四五岁后又有其它人开始这么干。导致这个孩子总是长的不那么好,软件总是不那么好。 这种情况在中国特别明显,谁也不服谁。在一些西方国家就比较好,有几个强人设计架构,其它人老老实实的根据这个思维做下去。这种潜在的思维几乎是不可能改变的。 那如何才能改变这种状况呢?让大家一起从头养这个孩子!而不是强人养一个孩子到中途把他再交给别人。由团队设计软件架构。 在一个团队中需要有一两个特别强的人。需要解决问题的能力特别强,设计架构的能力特别强,团队协作的能力特别强,激发团队氛围的能力特别强,最主要的是愿意与人分享的愿望特别强。解决问题的能力特别强,可以下面的成员能够佩服。设计架构的能力特别强,才能设计出好的架构。激发团队氛围的能力特别强,大家有激情才能做出好东西。团队协作的能力特别强,才能使团队往一个方向走。如果没有与人分享的愿望,老是害怕别人比自己强,那么一切都是白搭。 由团队领导开始构建一个想法,软件架构的大致思路。然后整个团队开始设计架构,从头来或者基于某个平台。在设计过程中团队领导需要不停的修正方向,指导软件架构设计中应该考虑到地方,说服团队成员按照那个方向走,如果说服不了,那最好的办法还是按照团队成员的想法先做,允许犯错误之后再来做修改。 这种团队往往特别难以建立。上面领导对团队领导信任都不够;团队领导不够强;团队成员已经老油条了;团队成员被其它事情拖住了;团队成员不停的换啊;团队之间不过默契啊;等等。建立团队比较好的办法就是由团队领导自己挑人,在团队建立之初先在一个比较隔离的环境里。