以前在培训的时候，有位老师跟我们说，与其把需求定的太大最后做不完，不如把它定的小一点最后完成它。结果等进了公司在程序开发中，发现我们更多时候并不是不想把它定小点，而是实际情况逼着我们必须把它做大，做完善。这个时候会感觉到处处掣肘，很是郁闷。
经过一段时间的项目开发，总结一番之后，提出一个猜想，不知道是否可以算作经验。但是还是写下来防止忘记。
在我们的开发初期，我们肯定要就我们的系统做一番设计，设计的时候担心这担心那，仿佛要作出一个完美地方案才肯罢休，可最后还是按照担心的方式做的，可以说有很多时间在瞎操心。更多有建设性的提议是在系统做到一半的时候，有一些功能已经确定的时候才提出的。这也许就是迭代模型产生的原因吧。
我猜测一个好一点的开发方式应该是，就某一个功能模块，进行尽量少的细节分析，通过集思广益总结出一个比较完善的的方案来。当这个方案确定之后，我们就把它当成是一个完美地方案，完美的，绝对不再去想它有什么问题。大家都知道，不可能存在什么完美地东西，那么这个所谓完美地方案一定有这样那样的问题，当问题出现的时候，解决它。但是如果不确定方案，问题永远不会出现，直到按方案制作的成品做出为止，既然问题不可避免，既然方案不可能完美，那么晚出现就不如早出现的好。问题出现的越早，那么解决问题的日子就越早。
至于这些问题，我分析，其实不外乎三种：
1.效率问题
2.垃圾问题（或者说资源占耗问题）
3.方案中每一个子模块的耦合问题。
我觉得，这三个问题中，前两个完全不应该通过修改方案改变，因为方案不管怎么定，都会出现这两个问题，索性我们不处理它，等他出现了问题的时候再做外围的处理机制，比如多线程，比如分布式计算，比如垃圾回收，比如资源管理。而这些处理机制跟我们的系统是松耦合的，完全可以根据需求的变化而独自演化。
唯独第三个问题，耦合度问题才是我们真正需要担心的问题，既然已经是一套方案了，那么里面的东西大多是紧耦合的。如何脱藕？谁该脱藕？要知道耦合度问题解决不好会让系统的性能下降或者可扩展性降低。不管那一个都不是我们愿意见到的。作为一个普通人，真的去做抽象分析说实话是得不偿失的事情，不如仔细看看设计模式的书，看看我们的系统里面哪里有符合条件的情况出现，这时，利用GOF设计模式。这样既可以减少我们进行原创设计时的错误又可以轻易提高系统的可扩展性也就是所谓的降低了风险。当这些模式都不足以满足我们的需求的时候，我们才真正的需要去抽象进行原创式的分析。到时就要注意诸如依赖倒转，里氏代换，迪米特法则，接口隔离等OOD的原则了。
|