《Agile Principles, Patterns, and Practices in C#》(chap 1 - chap 10)读后感

近日开始读Bob大叔的《Agile Principles, Patterns, and Practices in C#》，到今天看了前10章，最大的感觉就是：代码、设计、架构都是根据需求变化而不断增长的。静态地、孤立地看代码、设计是没什么意义的。同样的代码、同样的设计在开始阶段可能是非常好的、足够用的、再过之就over-design的；但在两周之后、新需求增加之后再不调整就充满各种bad smells。

之前上过一个软件开发的培训，老师教我们软件开发的流程是拿到需求之后，先进行详细的OOA（面向对象分析）、OOD（面向对象设计），画出系统的Class diagram（类图）以及 sequence diagram；然后再找N多专家、架构师开会复审，根据反馈再进行修改、确认定稿；最后再依据最终稿实现。按照这个流程，理论上系统最终的架构、代码都应该相对漂亮、干净、易维护才对啊，可为什么到最后我们的代码还是让人觉得差、设计还是让人觉得乱呢？

其实，不能否认，经过仔细分析设计、专家评审通过的那些架构肯定是优雅漂亮能解决问题的。可是，它是针对当时的需求、当时设计人员对需求的理解而言的，它是静态的在那一点时的足够好。但是，它也存在不足。首先在没有实现、没有编码之前，设计人员不可能预见到所有的问题，所以前期的设计总是会存在一些没有考虑到的漏洞；其次专家们可能对该系统的了解可能还没有设计人员深，虽然他们功力深厚、经验丰富，但在这种情况下也只能是从大的方面帮设计人员把关，确保一些大的方面的架构、设计不出现偏差，至于细节上也不能面面俱到了。在这种情况下，设计人员开发时遇到那些没有预见的问题如果没有很好的重新设计（在时间的压迫下），而是凑合根据现有的设计实现它，那么，问题代码、问题设计就出现了。

敏捷开发和敏捷设计就可以很好的处理这个问题了。敏捷天生就是处理动态变化的。敏捷设计的观点是，需求来了之后，首先选出接下来两周你要做什么，然后对这些选出的工作进行简单的分析设计并开始编码，用简单且足够好的设计、编码来实现这些功能，并且用Unit Test来测试这些实现、来迫使你自己从一个用户的观点来看待这些实现是不是合理、时不时覆盖到各种情况。当Unit Test发现你之前没有预见到的情况时，更改你的代码和设计来实现它，并且重构你的代码和设计、保证他们还是足够好。用单元测试保证你高质量的进行增量是开发，用重构保证你代码设计总是足够好，用敏锐的嗅觉保证你及时重构。敏锐的嗅觉来源于对代码、设计的bad smells的熟悉和了解。

好的代码、好的设计是不断成长的，是需要不断维持的。一旦被程序员有意或无意的忽略，再想找回它们来就难了。