《构建之法》阅读笔记2
之前在老师要求下阅读了《构建之法》在第五章的团队和流程中，团队有共同的特点：团队有一致的集体目标，团队要一起完成目标。一个团队的成员不一定要同时工作，团队成员有各自的分工，互相依赖合作，共同完成任务。在开发、运营、维护软件的过程中有很多技术、做法、习惯和思想。软件工程把这些相关的技术和过程统一到一个体系中，叫“软件开发流程”，软件开发流程的目的是为了提高软件开发、运营和维护的效率，以及提升用户满意度、软件的可靠性和可维护性。要完成一个复杂的软件项目，团队的各种成员要在不同阶段做不同的事情。
1、团队的模式：
一窝蜂模式：最无章法，效率最低，是比较娱乐的方式。
主治医师模式、明星模式：两种方法类似，都是偏向以一个人为主，其他人为辅的开发模式，当然后者更甚。这就有些偏于个人的利益了，而非团队的利益最大化了。（软件工程就应该是团队活动，偏于团队）
社区模式：这一类，在网上多见，不只是软件工程项目，其他偏向民间网络社区的活动，多以这种方式运行。是一种兴趣的聚集地。
业余剧团模式：学生实践项目或培训项目中多见。
秘密团队：秘密状态开发，内部有极大的自由。
特工团队：专门处理棘手且紧迫性的问题。
交响乐团模式、爵士乐模式：两种模式有点对立了。前者功能齐全，众多大型软件公司就采用的这种方式，后者灵活富有创意。各有优势，也各有劣势。
功能团队模式：有点像业余剧团模式，有着不同能力的人，扮演着不同的角色，来共同实现功能。小组内交流频繁，效率高。
官僚模式：带有领导和被领导的关系，过于形式。
其中有讲到写了再改模式，我就觉得自己就是这个样子。“只用一次”、“看过了就扔”，要用的时候，再去看看整体架构，改改内容。
下面的瀑布模型，就像UML那样复杂。大体流程能够理解，就是感觉过于遵循这个流程，似乎有些死板。后期的瀑布模型的变形，为的就是解决各种不同的问题。
流程的运用，规范工程的运作，至少能免除上面那种 写了再改模式，对于提高效率，灵活改进程序有很大的帮助。所以，自己的那种 写了再改模式，还是不必提倡了，考虑久远些，是对自己的帮助。