软件开发的流程不只是团队的流程，而且还包括个人的流程。而且对于问题的观点看法每个人也是有不同的理解，所以团队中出现不同意见的冲突是在所难免的。一个好的团队流程能把冲突的积极方面释放出来，而避免消极方面。书中用了足球队来比喻团队开发，每个人都有自己负责的那部分，还要有与其他角色合作的部分，这样才能开发出一款产品。篮球队员可以根据上场次数、场上时间、命中率等来证明自己的能力，软件工程师可以根据做了多大的项目，产品的质量等来证明自己。初级工程师如何让成长？①.积累软件开发相关的知识，提升技术技能；②.积累问题领域的知识和经验；③.对通用的软件设计思想和软件工程思想的理解；④.提升职业技能（自我管理的能力、表达和交流的能力、与人合作的能力、按质按量完成任务的执行力）；⑤.实际成果，你的产品的用户评价、市场占有率如何。
有个案例是程序员小飞在快要完成任务的时候发现了自己设计中的弱点，但如果更改的话就会耗费额外的时间，不能按时提交，同事、老板也会看不起他。如果按照原计划进行，后期团队就会花更多的时间来完善，但那时就不是他个人问题了。如果我是小飞，我会现在就改变思路来做，既然有了更好的思路就应该马上改正过来，这样对后期来说就会轻松很多，不论是时间还是经历，如果是后期再去添加修改的话，那你就需要从头在捋一遍你的思路。而且如果你的作品能带给他们惊喜，老板同事是不会看不起你的，只会更加的尊敬你。
第四章--两人的合作
代码主要是给人看的，所以在写代码时要规范原则：简明，易读，无二义性。代码要有相应的缩进，要用括号来表逻辑的优先级，变量要用简单的英文单词及注意大小写，注释也是代码必不可少的一部分。当你的代码写完之后还要进行代码复审，最好复审的形式就是同伴复审。如果是自己复审的话，很容易受到先入为主的观念影响，自己找不到问题所在；如果是团队复审的话，比较麻烦的，因为需要找到所有人都空闲的时间出来。在我们平时课上的一些测试，自己写完后，老师也会要求我们进行同桌复审，我觉得这是很有效的检查错误的一种形式。
两人的合作不同的阶段（萌芽阶段、磨合阶段、规范阶段、创造阶段、解题阶段）有不同的技巧。对于同伴不注意代码规范而按照自己的习惯去写代码，你可以合理的指出他的错误，但是要注意技巧，否则很可能造成你们之间的不愉快，要让他从心里的去改变这种习惯而不是只靠批评指责。
个人感受：我写的代码基本上都会有缩进，因为这样“美观”，可读性好。“一坨”的代码真的让我没有心情去看它。我之前做的练习中，没有同伴复审的环节，写完程序后都是自己进行测试，导致的结果就是自己测试无bug，但到老师检查时就会出现一个又一个的错误。今后会找个搭档，每次程序写完后，我们两个相互给对方的程序进行测试。