在学习了构建之法第四章，第五章之后，写一下我的感想。
代码规范一直是我们在学习过程中一个老生常谈的话题。专业技能过硬与否只是一方面，代码规范同样也是一个举足轻重的方面。比如最开始的注释，在我们写一些很短的代码十几行，几十行代码的时候，如果不写注释，说白了，那么短的代码，谁都能找得到。但是，万一代码量上了三位数呢。几百行的代码，找那么一个错误，难度可是不小。再加点难度，四位数，五位数，甚至做项目的时候呢。没有注释，八成项目经理都不要你了。
代码规范有很多方面，处了注释，还有缩进，行宽，括号，分行，命名，下划线以及大小写这些。虽说每个人都有自己的风格这么一说，但是坚决要避免抽象派，也就是那些没什么规则的乱写。就拿命名来说吧，函数命名一般意义上是要求要和函数的内容或者功能有关。如果说要拿自己的喜欢的某样东西，或者人来命名，那就太不专业了。
代码规范做到之后，接下来要注意错误处理，这项工作要占到超过一半的时间。在构建函数的过程中，也要注意一些规范。最后要进行的就是代码复审，也就是在代码规范的框架内，所做的程序能否正确的实现要求。
处理好了代码规范，就该结对编程了。两个成员慢慢付出自己的努力，互相帮助，互相磨合，创造出结对的作品。
第五章是团队的话题。团队一直是一个不可或缺的话题，球场上，网游中，甚至考试场上，逃课时都有着若干团队。个人离开团队无法健康成长团队离开个人就不是团队了。在我们软件工程的学习，开发中，团队是一个非常重要的内容。结对开发，结组开发，我们都已经经历过了。有些项目靠一个人的能力，思想无法做到尽善尽美，甚至无法完成。
团队意味着几个分工明确的成员共同为一个目标努力着。首先我们要有一个核心，主导着整个团队的运行。其他人都围绕着这个核心，就像手术中的主治医生那样。确立了团队与核心，就该确立开发流程了，是写了再改模式，还是直接分析，设计，实现，销售，维护流水线的瀑布模型。但是，写了再改有很多的缺点，相比而言，瀑布模型的话，走两遍之后，在此基础上加以改进，就能相对成功了。瀑布模型的两个模型，生鱼片模型，子瀑布模型，各有优缺点。生鱼片模型要求技术区别迥异，而子瀑布模型则难度较大。总之，我们要能够实现项目，就要好好地在团队中贡献自己的力量，使团队朝着正确的方向前进。
现在我们的团队---菜鸟小分队每个成员都在朝着设计的方向做我们的项目，希望通过构建之法的学习，能让我们团队的成果更加出色。