项目开发：就好像是一个取得真理的一个过程。
   在开始“没有人”会知道什么是对的，什么是错的。所谓的客户（中世纪教会的教徒），告诉你月亮是“热胀冷缩”造成的“阴晴圆缺”。
   在初期你敢于否定“热胀冷缩”原理？或者说根本就是认为月亮是受“热胀冷缩”原理影响的。
  
   那好，下面我们根据月亮圆缺原理，写个统计温度与月亮亮度报表。


   客户自己想要的东西也是一个认知的过程。编码要在开始就要确定是在一个不稳定的环境（即使错了我也能容易修改，这是软件最有价值的地方）。

对于这些理解为项目的可变性总结出的一些见解：
   1.尽量明确各层使用框架。这样能统一技术，明确编码风格，统一存放，查找地址。这样就能很好的 定位要修改文件的物理地址和 尽量不与个人技术有关 。
   2.尽量明确各种动作的命名规范。这样不但能很好的使用 aop ，而且为修改提供了 逻辑地址查找提供便利。
   3.减少个人英雄主义。由于某些个人原因，引入与项目不兼容的技术，这是很危险的。只有这为“英雄”能修改的后果很严重。
   4.编码中对“可预见性”的代码结构适应，扩展接口预留。月亮缺失可能不是“热胀冷缩”引起的怎么办（当然也是最难做到）这只要编码想到可能就有“可变性”就要有好的相应对策，比如：公司鼓励程序员的为“可变性预留接口”，当然最好也注意下预留接口的 规范 。

评论：

2008-08-06 10:03 by zhuxing

“编码中对“可预见性”的代码结构适应，扩展接口预留”
个人觉得这种事情在编码之前还是预先想一点的，至少从整体系统或者重点模块的层面上大致想一下，否则，完全推迟到编码时候再去做，那就有点悬了。除非项目组确实有几个老道的高手，否则......就有点困难了

2008-08-06 10:11 by 冬日的阳光

“编码中对“可预见性”的代码结构适应，扩展接口预留”
这个东西与经验的关系太大,属于不可控的方面,最好项目中有负责整体框架的人或者小组来决定这些事情而不是由某个开发人员来决定

来自：http://www.blogjava.net/Good-Game/archive/2008/08/05/220229.html

分类： 项目管理 管理工具 软件工程