构建之法：第三次心得

Posted 2020-09-14

在之前一周学习过个人能力的发展的重要性以及软件工程师个人的成长之后，这一周我主要学习了团队之间的合作的重要性。具体就是学习了构建之法的第四章和第五章。

第四章

第四章，讲的是两人合作。在软件行业的逐步发展中，一个软件基本上一个人是完成不了的，软件都是在相互合作中完成的。

首先，代码除了要足够正确简洁外，还要清晰，让人一目了然。简单来说，代码风格的原则：简明，易读，无二义性。但是，最重要的代码设计规范还是程序设计、模块之间的关系。毕竟，一个软件的流行与否与它的性能与客户需求还是密不可分的。其次，在编写代码的时候，我们就要考虑到它之后可能出现的错误，修改错误，慢慢调试花费的时间会更长。在这之后，代码写完之后，就是需要同伴来给我们进行代码复审。代码复审的主要作用就是找出代码的错误，并且不断改进，然后团队之间相互传授经验。这是非常必要的。对我们亦或是团队的成长都有很大帮助。有的错误在这一次犯了之后，就要吸取经验教训，不能再犯第二次。复审不仅仅有代码复审，还有设计复审、设计计划复审和文档复审。在一个软件设计的最后过程就是结对编程，这是一个不断复审的过程，提高设计和编码质量，及时发现并解决问题，避免把问题拖到最后。

在以上这么多步骤中，两个人又或者是更多人没有默契是做不来的。团队也不会从一开始就合作默契，一定会有一些矛盾，但在不断的相处过程中，这些矛盾很有可能会变成坚不可摧的力量督促我们前进。在团队中，对于他人的错误，要及时给予指责，不能藏着掖着。最好能够在自己行动之前，考虑到他人的感受，不那么自私。这些因素都与个人性格有关，因此，在团队中，同样可以磨练我们的性格。

第五章

第五章，讲的主要是团队和流程。从第四章，我们可以看出，团队对我们有多重要，无论个人的能力有多强，不在集体中的话，也不能完全发挥出来。

首先，团队的定义就是团队成员有各自的分工，互相依赖合作，共同完成任务。软件团队有各种形式，适用于不同的人员和需求。基于直觉形成的团队模式未必是最合适的。而在书中提到了十几种模式：一窝蜂模式，主治医师模式，明星模式，社区模式，业余剧团模式，秘密团队，特工团队，交响乐团模式，爵士乐模式，功能团队模式，官僚模式。我们不必去一味迎合这些模式，需要根据自己团队的现状来决定自己团队的模式。

然后，最主要的是团队合作的流程。其中基础的流程是瀑布模型。在自己团队工作的时候，我们可以根据瀑布模型进行各种变形，调整到最适合我们的状态。当然还有其他流程，统一流程包括许多工作流和四个阶段。工作流：业务建模，需求，分析和设计，实现，测试，部署，配置和变更管理，项目管理以及环境。四个阶段：初始阶段，细化阶段，构造阶段，交付阶段。另外，还有老板驱动的流程以及渐行交付的流程。就是要不断地进行开发，发布，听取反馈还有根据反馈做改进等等。在自己团队没有什么明确的方向时，我们可以参考这些流程。如果有明确的目标，就要按照团队的需求，基于以上的流程，制定最适合自己的方案。

最后，我想每个团队都有自己的软件生命周期，我们需要在不同的阶段提高自己，提高团队，提高我们自己做制作的软件的水平和软件的质量。