第四章 两人合作
关于合作中算法的使用
在第四章的叙述中，我们看到了代码的编写规范，代码的命名规范，我们还知道要写注释，要有良好的代码设计和错误处理。而这些都是我们在使用语言进行编辑中的问题。我们要阅读结队队友的代码，了解功能实现，明确函数意义。之后还要进行代码复审。
但是我们同时也知道，在代码实现的过程中，我们的分工是有侧重的。而同一个事情的完成是可以使用一些成型或自己的算法进行优化的。而如果我们在使用一个比较“复杂”（是指思想复杂而实现简单，例如dp，kmp，manacher算法等）的思想和算法时，这些算法可以大大优化代码的效率和质量。但是同时，这些代码会对队友阅读代码造成一定的难度。在长期的合作中会需要解释很多的代码思想。而有些比较难理解的东西可能会耗费队友很多的时间。这是长期训练算法和专精开发的人之间各有所长的一点。但是此时问题就出现了。
我们是否应该使用队友难以理解的算法对程序进行优化？如果使用了，是应该每次讲解给队友还是只说明算法功能？如果只说明功能，代码复审的时候是不是就又要一个人完成？如果因为麻烦而拒绝优化，是不是有违软件开发的思想理念 ，不能制作更优秀的程序服务大家？
在提出这个问题时，我已经先考虑了使结对对象完全了解算法的可能。因为身边一开始确实有很多在做算法的人，慢慢的又因为太难而放弃了，所以这个问题不是臆测而是通过实际情况而提出的。那么在我们先假定这个情况为既定事实的情况下，去考虑解决的办法。
结合提到过的单元测试的思路，已经书上本章讲到，一个模块只专注完成一件事并且做好。那么我的解决方法是，注释所有函数步骤的作用，参数调用和意义。然后两个人对这些函数单元进行统一测试，共同调试。而算法的使用者需要保证算法的正确性。要不然即便每个模块正确组合起来也没有用。
写在后面：我的结对搭档很好，对算法也很有兴趣。这些只是我在阅读过程中结合日常实际情况所提出的一点想法，并不是抱怨和吐槽，也愿意和大家讨论，为之后的实际开发做好预警和铺垫。
第十四章 质量保障
在软件质量保障工作的分工过程中，应该做到统一调配还是合作分工？
在书中多次提及软件质量保障（QA）和软件测试（Testing）。而且也论述了测试的角色是否应该被独立出来。问题四种也提到了“画地为牢的分工”。
在阅读了这么多的内容之后，我大概了解了，质量保障是一个，多阶段、多人合作，共同完成的一个事情。而在这个目标完成的过程中，不同的角色有不同的任务。那么这些任务是由一个boss专门指派，专人专项的负责呢？还是说由团队中的人进行讨论，认领工作分工，然后各自完成各自的项目。
前者由boss专门指派，可以很好的统一调度，考虑到每个人的特长专精已经能力差异，以任务式的方式去让各自完成。成体较为协调有力，但是可能不符合个人意愿，主动性较差。而对于后者，团队讨论认领分工可能会出现调度不均，考虑不周的情况。但是主动性强，对自我的认识更周到，但是也会因为团队的个人偏向性而漏掉某一部分的内容。相较之下两者兼顾可能是比较理想的状态。
我也针对这部分内容去百度和一些公司的网站上进行了查阅，但是并没有一个很明确的结果。可能在自己的实际行动中会去试验一下到底哪种会比较有效。
End
第十七章 人 绩效和职业道德
关于贡献与责任
书中讲定了团队原则、团队合作，讲了绩效评定、绩效管理。同时也根据书中的链接阅读了驱动与责任这篇文章。收益良多。
团队的风格决定团队的发展，兵熊熊一个，将熊熊一窝。一个“狼性"的团队有着他们的冲劲，一个“蜂性”的团队合作分工统筹有序，一个“羊性”的团队以无错稳定为目标，无过便是功。那么当我们在评价绩效的时候，贡献与责任之间的分配就成了一个问题。
狼性的团队，一股脑的冲劲，不怕错的勇气，他们有着很好的创新理念和创新意识，他们另辟蹊径有着创造无限可能的底气，但同时，冲的过头可能会造成种种难以弥补的错误和巨大的失败。而这种时候，是权衡责任，怕担责而选择“鸵鸟算法”，只愿意去维护那些“祖传代码”，无过便是功嘛。还是应该去冲冲冲，去创新创造，然后走错了弯路就再往回冲。
国人既讲究对错黑白，又讲究权衡和平衡。提出的很多问题既有对立面，又有平衡点。而倾向性是人皆有之，是个人的选择与追求。
End