对于开发过程的关注源于先前一个失败的小项目。先前在学校学的关于软件工程的内容早就丢到JAVA国去了。一方面因为当时学的是传统的SE，讲的是瀑布模型等一些过时的东东，另一方面很少有实际的项目经验，主要精力放到学习语言技巧，系统领域的知识，没有对process予以过多的注意。在做这个小项目的时候也是如此。接到需求后花了一些时间分析了一下，然后开始编码，最后测试。在编码阶段发现先前的设计有问题，然后跑回去重新设计，再编码。到最后测试阶段发现在分析阶段对一些性能指标没有深入的研究，导致做出来的东西并不满足需要。这其实就是SE中所说的错误放大效应。一旦前面的有失误，一切就要推倒重来。

因为公司开始采用RUP来作为开发过程，所以针对上面的失误做了总结。

1. 首先是没有一个开发过程作为项目的指导
   在开发中没有明晰的milestone，一切都是在我的脑子里形成的。整个过程一团糟。

2. 分析和设计的内容没有经过审查
   也没有和内部团队成员沟通，就直接拿去编码了，导致后面才发现设计的不合理。这里我想提到XP的Four Value里的courage。有时候将自己设计的东西拿到众人面前评审，总有些胆怯的感觉，好象被脱光了衣服仍到大街上一样。：）要坦然面对自己的东西被批的体无完肤的确是需要勇气的。不过如果不通过复审，后期的开发可能给自己更多的尴尬。所以有积极，开放的心态是非常重要的。

3. 沟通的不足。
   在发现设计有问题后，并没有意识到可以去请教别人，而是一个人埋头苦想，到后来延期的时候不得不找同事来一起分析问题所在。也许有人说一个人思考是对的呀，这样提高才快，在经过适当的考虑后，还不能确定的东西就应该拿出来和人讨论，毕竟自己一个人的智力和经验有限，也许你冥思苦想的问题人家早就经历过并解决掉了。

4. OOAD/UML的关注。
   学习C++的时候，我在想一个好的C++程序应该是怎样的呢？不可否认，到目前为止，我还是拿C++来写过程化的东西，除了偶尔的用用继承，用用virtual function。当然对于C++这样MultiParadigm的程序语言来说也无不可。但是总觉得意难平。当然没有好的OOP功底，OOAD很难一窥门径。但不妨碍我们去了解，熟悉。而且对于UML的学习并不需要很多的经验。

5. 推荐好书

• Robert Martin “Agile Software Development”，正在看
• “Design Pattern Explained”
• “Applying UML & Patterns”
• “UML Distilled”
• “XP Explained”
  让我们一开始就看好书，一开始就走正确的路。