构建之法阅读笔记03

　 接着读构建之法,感觉自己读的有点慢了,本来就不多的内容硬是拖到了现在。读到了两人合作这里，感觉现在的开发已经很少是单独完成的，最少也是两个人了。我们写代码不仅仅要让机器了解，更要让别人看得懂，让你的队友看得懂。这就需要代码规范。代码规范分为代码风格规范和代码设计规范。代码风格规范包括：缩进，行宽，{}的位置，分行，命名，大小写。其中我认为比较重要的有：每个语句只定义一个变量，做一个操作。即便IF和ELSE语句只有一句，也使用{}。在变量名中加入下划线表示作用域，如m_iAge。代码设计规范不光是程序书写的问题了，而且牵涉到程序设计，模块之间的关系，设计模式等等。一个函数只做一件事。按照public,protected,private顺序来说明类中的成员。在小型软件开发过程中，有一种模式叫做结对编程，在这种模式下，一对程序员一起完成设计，代码，测试，文档工作，由于每个工作都被两双眼睛看过，程序的初始质量取决于各方面水平较高的那一位，在整个开发过程中不断地进行着潜移默化的复审。一直以来我感觉自己都是太过随意了，认为对于程序来说，最主要的就是完成功能的实现，但是现在我发现，功能的话似乎并没有那么重要，当然我不是说否认功能它还是很重要的。我明白了软件还是服务于人的，用户才是上帝。对于第四章，我也只能草草的总结一下，而在第五章看了很多软件团队的模式，有主治医生模式，明星模式，社区模式等等。以及功能团队模式，有官僚模式。开发流程有写了再改模式等。但是，可能是我拜读不深吧，看完还是么能理清团队如何合作，团队里的每一个人负责什么。要一起写需求设计吗？还是一部分人负责？有没有具体的例子可以帮助理解呢。一个公司开发一个大项目，要如何才能让一个软件团队有条不紊等工作，他们之间如何分工，如何把所有人所负责的部分整合成一个项目？每一次的提到团队都是感觉口号很响亮，真到合作时，又都是漏洞百出，团队大阵总是自己破。软件工程确实是团队的活动，一个人要做一个大的项目真是太难了。

　　再到第六章的敏捷流程，感觉印象最深的就是scrum了，书中讲述了什么是scrum，老师也让我们亲身体验了一把，感觉就是很流于形式，可是又不能没有，一旦没有了规矩真是很容易就使得团队乱套，这真是管理层需要的东西。我想以后接触到时也不会再那么新鲜和烦躁，毕竟接触到了，学到了。