早在本科阶段，一直对团队编程存在误区。四到六人小组，有时候个别人已经确定将来不做计算机这行，干脆放手不管。有的人基本功太差，讲解的功夫都比设计的时间长。剩下三三两两生力军，也大多各干各的，感觉团队这个词在刚接触编程的我们身上渐行渐远。看了几章书中的内容后，才对真正的“工程”有了一定的认识。

　　首先说说团队，书中说，两个工程师在一起，做的最多的事情就是“看代码”，每个人看“别人的代码”，并发表意见。

　　第一个重点是看，为什么看别人的代码那么费劲，自己写的代码别人也看不下去，长篇的函数、指令，一句注释没写不说，代码的换行、空格乱七八糟，一眼望去简直是车祸现场。大学算法的老师说，我看你们一次作业能头疼一周，为什么代码写出来那么难看。因为初学编程的我们从来是把程序能否运行摆在第一位，程序够不够规范，算法的排列，函数的起名等等，都影响到一个算法是否易读。

　　第二个重点是发表意见，为什么之前的团队合作都变成单枪匹马，那时候最常说的一句话是我写完再跟你说，等到“看”的这一步时，一整篇程序拍在对方面前，最直接的反应是你都写完了我还看啥。而对于中大型的软件项目，一个人编写往往写到猴年马月，因此小组之间的配合至关重要，我们需要了解的是，怎么在他人编程的时候交换双方的思想，把更好的结局方法在讨论的过程中挖掘出来，而不是自己埋头苦干发现工作量的重复或者意见上的不统一。

　　其次说说个人，说是其次，个人能力在小组中的地位也至关重要，如果自己能力与他人差距过大，何谈合作。谁也不愿意和一个只会拖后腿的人结伴编程，这样效率甚至不如自己个人编程。然而，算法可以讲，思想可以讲，代码却要自己一行一行的录入，只有自己脚踏实地的写一遍，才能说这是自己的代码。

　　一个合格的软件工程师，至少要能做到以下几点：

　　1.能够有效的和其他队员交流。2.按时交付任务。3.接受团队赋予的角色并按角色要求工作。4.全力投入团队。5.按照团队流程工作。6.做好准备、理性工作等等……

　　本书看了不到五分之一，对软件工程的了解与之前已经截然不同，对现在的我来说，更多的精力要放在自我能力的提高上，这样在日后开展小组项目时，才能更好的完成团队的任务。

读《构建之法》有感