本次阅读内容为《构建之法》的三四五章。
这部分内容主要讲的是软件工程师的个人成长以及团队协作。
其中软件工程师的个人衡量与发展我觉得给每个软工人都指明了一个方向。每个软工人在软件工程师的路上都会经历初级、中级、高级阶段，晋升之道不仅仅在于技术的提升，更重在知识的积累，软件设计思想的积累，解决问题的经验的积累，而在这个积累的过程中，无时无刻不伴随着自我管理能力，表达交流能力，团结协作能力，任务执行力等等的发展，这些能力其实不仅仅是软件工程师，更是每一个职场工作人员晋升必须具备的品质。
说完了个人能力，下面再来说说团队协作。团队协作可以简单的分为二人合作和多人合作。
其中，二人合作，需要遵守严格的代码规范——简明、易读、无二义性，比如分行、命名、大小写、注释，这些看似简单的事情，其实是两人合作中很重要的模块。另外就是要注意代码复审，其实就是看是否在“代码规范”的框架内正确的解决了问题，而软件工程中最基本的复审手段，就是同伴复审。这个复审并不只是找出代码的错误，同时还要发现程序中的逻辑错误、算法错误以及潜在错误，也要发现一些可能需要改进的地方。双人开发中代码复审的过程也是一个传授经验、互相教育的过程。这也是一个对于个人的提高的机会。
然后就是多人合作——三人以上组。相比二人合作，多人合作能更好的促进设计质量和代码质量，高质量的产出同时也能带来更高的满足感。但是多人合作的难度比二人合作要难得多，不仅仅是因为软件团队的多模式难以抉择，任务分配不均，还很容易出现抱大腿的现象，而在大学的软件团队中，更多的就是主治医生模式和业余剧团模式，即，一个人干活其他人打酱油的模式。这样带来的弊端也是显而易见的，打酱油的人几乎没有什么提高不说，最终奖励的分配也成为了团队矛盾的导火索。有人说这种模式是不可避免的。
但是我想说的是，对于团队中的任何一个人，即便是打酱油的，也有其存在的意义。就算是打酱油，也要打出水平，打出存在感，软件开发不仅仅是开发，它还包含的设计、推广等一系列的工作，只有制定切合实际的计划和承诺，才能更好的完成团队任务。
对于我们自己的团队，在项目之初，出现的问题就是计划不够切合实际。比如我们团队的研究方向是基于深度学习的医学图像分割，但是在团队的第一次会议中，我们大多只是简单介绍了一下自己的能力，对于整个项目的方向，我们第一阶段确定的任务就是找论文，对于后续阶段，只有一个大致的说明——编码，并没有一个系统的、完善的计划，每个人也没有完善的分工，这对我们后续的工作造成了很大的影响，导致后期的时间规划几乎全部崩溃。
在新的团队或项目中，我会尽量让团队的每个成员都有自己的工作，切实体现团队的意义，同时做好前期计划，符合实际，尽量在后期不会有太大的变动，同时计划应该留出足够的时间随机应变，计划要具体到人周，每个成员还需要细化自己分配到的任务。