【日志归档】 06月, 2008
良好的编程习惯是成长的助推剂
近来看到、听到一些很小的问题，却导致了系统故障（甚至更严重的问题）。
- 案例1：等号（==）导致的损失
- 案例2：少传递一个参数导致的损失
- 案例3：默认返回结果的乐观，导致的损失
- 案例4：偶然停止的一个系统，导致系统停机
- 案例5：2个参数没有设置，导致外部系统故障的内部传递
- 案例6：大小写，导致某类业务失败
- 等等
事后看这些问题，发现都很简单，都是由于程序员的粗心导致的。或有有人会说，我们应当允许犯错误，我也是非常认可的，但对于一个企业来说却是非常可怕的，上百个程序员，每人都犯一次这类错误，恐怕企业会有些受不了。
如何规避这些问题哪？
- 制度保证
- 测试保证
- 程序员良好的编程习惯
通过下面几个例子，简单说明良好编程习惯对成长的助推作用。
首先，通过观察，发现上面所列的问题，都是一些编程习惯导致不是很好的人身上发生的。
其次，通过和一些同事交流，虽然他们自己没有遇到过这类问题，但良好的编程习惯帮助他们避免了这类问题以及克服了其它困难。
再次，同样一起进入公司的新毕业的学生，工作时间、加班时间也一样多，1年后，发展却非常不同。通过观察，我发现：排处天然因素，后天因素中很重要的一点就是良好的编程习惯帮助他们获得了成长。
良好的编成习惯包含很多方面，综合我身边这类人的特质，总结了下面几点：
- 坚决按照业界认可（或公司认可）的编程风格编写代码
- 开发、调试、测试过程中遇到的问题，不是简单的解决问题，而是进行深入的思考，挖掘现象背后的基础层面的东西
- 对于别人、外界出现的一些BUG，不是简单的听听即可，而是进行试验，思考
- 对于别人无法解决的BUG，总是尝试各类方法，不解决问题，决不罢休
- 不断总结-〉实践-〉再总结
SOA是可持续的战略，不是一次项目
常常听到如下关于SOA的说法：
- 我们完成了SOA化改造。
- 我们的SOA化，已近实现了80%。
- 这次项目是为了实现SOA化，因此要请有这方面经验的公司来实施。
- 从技术角度层面来说，我们达到了SOA化的目标。
- 这是我们最后一个SOA个项目
- 等等
如果这些话出自程序员，项目经理等人员，也是无所谓的；如果出自IT管理层的人员，哪就是一种可怕的想法了。因为他把SOA仅仅看作是一次项目了，而没有把它作为战略。这样的后果也是可以预见的，最终本次投资将会失败。
因此，建议那些准备实施SOA的公司，首先回答这个问题：SOA是贵公司的一个战略吗？
为什么要回答这个问题？
- 从SOA概念来看
- 从SOA目标来看
- 从IT管理角度来看
- 从系统分析角度来看
- 从技术特征来看
关于什么是SOA，我有几篇文章，可以参考（《这些都不是SOA》,《ESB产品升级准备：SOA、ESB、JBI、SCA、OSGI概念再学习、再理解》,《SOA，想说爱你不容易》）。丛概念上可以看出，SOA不少技术问题，它是一种思想，一种架构，因而不可能通过一个项目就把这种思想或架构完全实现；思想也是会发展得，今天的思想在明天或许就会不适应。
SOA的目标是解决业务敏捷性问题。如今，大环境复杂多变，任何一个公司都不敢说自己的业务就是这几个、自己的业务会一直不会变，很多企业，在很短的周期内，就会推出各类产品（特别是服务类企业，例如：银行、互联网企业等）。只有那些能够快速适应变化，主动寻求变化的企业才能够生存下来，发展起来，例如：会跳舞的大象IBM，IT行业最大的特色就是变化快、发展快，如果IBM的业务不能敏捷的适应这种变化，它还能跳舞吗？正因为IBM深刻理解了SOA的目标，因而它把SOA看作一种战略–可持续的战略。
对于IT主管，一定要确保本公司的IT战略是可持续的，不能今天一种想法，明天又看到什么好思想，就换了一种想法，或者换个主管，就彻底换了战略（这种做法，就像我们国内的城市建设，路总是修不好）。既然从一种思路切合到了SOA领域，那么再次切换的成本将会更高，也不可能多种思路同时进行（吃得多，嚼不烂）。此外，谁能保证一次项目就确保几年内业务变化的需要？从我们实施的经验来看，必须持续的进行SOA化，才能确保SOA持续的发挥效果。
每次项目都要进行系统分析，都是基于当前的业务进行，那么不可避免的就会有一些盲点（从认知的角度看，人不可能一次就抓住事物的本质，何况大多数系统分析员不具有这种能力）和不合理支出。这些问题，只有在实施后一段时间才能发现（我们自己的实践经验）；此外随着补丁的实施，原有的系统已经恶化，和最初的SOA化目标越来越远。此时，如果不能再次用SOA的思想重新审视系统，就将彻底失去了SOA带来的好处。
SOA非但不能让系统架构变得简单，反而变得复杂了（系统设计要求变高了、系统部署复杂了、发布复杂了、各类SOA相关技术的引入增加了对人员的要求），这也是为什么要引入SOA治理。从这一点来看，只有持续的SOA化，才能最终发挥SOA技术架构的好处。
再次提醒将要进行SOA化的朋友和已经进行了SOA化的朋友，把SOA当作贵公司的可持续的战略来看，而不要认为它紧紧是一次项目。
Java Enum小心使用，它可能增加系统耦合性
关于在SOA环境中使用Java Enum的一些经验已经在《服务化的行军中：Enum使用，快乐的痛苦》一文中进行了讲述。
随着项目的深入，在某些环节使用Enum的不爽之处，上升为一些设计方面的选择问题。
- Enum不适合作为通用类的属性来使用
- Enum不适合作为服务接口的参数来用
在我们的代码中，我看到如下一个情况，有关类：UserPrincipal，它被整个分布式系统中的所有系统共同使用，从包的放置位置：net.esbzone.comm.security就可以看出它的通用性。突然某天，看到有同学在这个类加入了一个Enum属性，这个Enum属性还是另外一个业务系统B内部定义的一个通用常量【这个常量的确很是通用，表示用户类型】。这个例子，首先导致UserPrincipal与业务系统B产生了紧耦合，间接导致所有系统与业务系统B产生了耦合；其次即使它定义在net.esbzone.comm.security包中，也间接导致UserPrincipal与具体业务产生了关联，会增强外部系统对Enum的耦合度，从而削弱了UserPrincipal的独立性；此外一旦Enum发生变化，所有依赖与它的业务系统都要发生变化，代码依赖级别的变化。
往往，Enum的业务语义太强，与场景的关联性太密切，一旦环境发生了变化，Enum的值就可能发生变化，从而导致使用它的业务域对象也可能要发生变化。
使用Enum作为通用类的属性，制约了该类的通用性。
【注意：】在封闭系统内部是非常适合使用Enum，它会增强代码的可读性，减少维护成本，降低风险。
首先是序列化的风险。
其次Enum增强了系统的耦合性，如果只是接口耦合，那么可以通过WS，HTTP POST等方式来降耦。如果使用了Enum之后，我们进一步增加了对Enum这种特殊类型的处理【大部分标准化协议和现代变成语言，都支持原子类型，对象类型，集合类型，但对Enum的支持却各有所不同】，这就增加了耦合性。此外，此时对于一个使用者要面对多个服务提供者的时候，如果遇到这种情况就会更加痛苦不堪。
再次，Enum在接口层使用，制约了扩展性。当增加一个新的业务常量时，需要修改Enum，此时它的WSDL文件也会发生变化【这点很头痛】，想到于修改了接口描述文件。
最后，我们从业务协议设计的角度来看，我们需要的只是原子数据类型，而不是Enum这么强的一个对象类型。
故事集合
六十八个超级经典MBA管理小故事
管理小故事精髓百例
让你受益匪浅的管理小故事20则
管理中的心理学
管理小故事100例
豪猪的距离–哲学小故事
翠絲特的小空間
SOA实践之：在程序层，面向服务的设计准则探讨
在面向OO领域有10几条设计准则，那么这些是否都能够延续到SOA领域的服务接口设计层哪？下面列出本人实践过程中，认为能够继续适用的一些原则：
- SRP 单一职责原则
就一个服务接口而言，应该仅有一个引起它变化的原因。
职责即为”变化的原因”. - ISP 接口隔离原则
不应该强迫客户依赖于他们不用的方法。接口属于客户，不属于他所在的类层次结构。
多个面向特定用户的接口胜于一个通用接口。 - REP 重用发布等价原则
重用的粒度就是发布的粒度. - ADP 无依赖原则
在包的依赖关系中不允许存在环.
细节不应该被依赖. - IDP(Interface Design Principle)接口设计原则
规划一个接口而不是实现一个接口。
-
其它一些可以参考的点：
- 放弃程序级别的OO概念。
- 业务的粒度就是接口方法的粒度。
- 接口方法尽可能简单、清晰、业务含义明确。
在实际应用中，按照这些准则，我总结了一些具体需要需要的点：《SOA实践之：在程序层，服务接口设计的一些准则》【对于这篇文档，会随着实践而不断补充】
