引子
本章主要论述了在软件工程师角度上对个人能力的衡量，中间提到职业发展——个人能力发展，也给出几个例子说明了开发软件过程中陷入的思维误区。这里想把 《构建之法》 中学习到的内容做成读书笔记,以供日后结队、团队作业参考。
个人能力的衡量与发展
软件系统的绝大部分模块都是由个人开发或维护的。——(Page 47)
书中这句话让我十分不解，既然绝大部分模块都是个人开发或维护的，那团队中的其他人还需要做些什么呢？(老板发工资养活一大帮不干活的？)，如何在团队中角色的划分如何算合理呢？
-
解决第一个问题之前可以先关注下第二个问题，首先，团队中各个角色考虑问题、需求的出发点很难做到全部相同，但是最终团队当中每一个人的工作质量均影响着软件的开发。如果说完全把团队中工作均分，不一定能够展现出团队中个人的创造性，反而会拖慢软件发布的进程。打个比方说去超市买菜，就一定要细化分成一个人推车、一个人选购商品、一个人付钱...等等这样吗？
-
但是，我的意思并不是不需模块化开发工作，我认为团队中每个人的代码量、工作量或多或少都有差异，不必只是形式化的划分工作，可以适当强调团队中的个人的能力。比如说，团队中维护和开发这两项工作的耦合度要适当高一些，维护工作本身已经不易，更何况是维护其他人的代码更加是一件效率很低的事情了。
-
再回到第一个问题上，如上所述，团队中每个人的工作量或多或少都有些差异，仔细琢磨也发现单单个人的开发和维护是不足以完成一个软件系统的，甚至都很难完成需求——其他例如测试、项目管理等功能依旧很重要。
-
下图是amazon关于测试工程师和软件工程师的任职资格。(上方为测试工程师、下方为软件工程师)
-
参考自 amazonjobs
-
如图所示，我们平时认为不重要的测试工程师反而却需要更长时间的工作经验，完全不输于我们固以为的团队核心——软件开发。
-
所以综上所述，团队中其他的工作很多——测试、项目管理...每一件工作的工作量可能有差异，但都存在其价值。我想这样的思路也能在应用到结对作业甚至是团队作业上，更好地权衡团队发展与个人的能力。
软件工程师的思维误区
这一小节提到了很多软件开发中容易陷入的思维误区，我认为其中不分主次，想解决所有依赖问题这个误区也较适合在当前团队作业进行的前夕尽可能理解更深一些。
不分主次，想解决所有依赖问题：过于积极，想马上动手修复所有主要和次要的依赖问题，然后就可以“完美地”达成最初设定的目标，而不是根据现有条件找到一个“足够好”的方案。
- “一次性解决所有依赖问题，剩下只需按部就班完成各种模块”这样的蓝图固然很美好，但是大部分情况由于各模块实现上的不确定性、技术能力限制等原因使得我们付诸蓝图到实践显得有些无力。
- 而立足于现有条件来寻找一个“足够好”的方案则更有点像一种贪心算法，通过不断选择当前的局部最优来达到去全局最优。不过我个人认为有关贪心算法的一些限制也同样适用于跨越当前思维误区的方法——选择的贪心策略必须具备无后效性，即某个状态以前的过程不会影响以后的状态，只与当前状态有关。 如果当前认为的“足够好”的解决方案会影响后续软件的维护，则这种方案在实施上就需要多加考量。
那么问题来了，如何选择足够好的方案呢？方案决定的方向的重要性又如何呢？
爱丽丝向猫咪问路，
“那全看你打算上哪儿去了。”猫说。
“我上哪儿倒不在乎——”爱丽丝说。
“那走哪条路也就无所谓了。”猫说。———《爱丽丝梦游仙境》
- “足够好” 的解决方案有很多，但是我认为如何在这些方案中做出选择比提出这些方案来得难的多。软件开发团队中，包括PM都可能因为想弄清楚所有方案的每个细节实现而陷入《构建之法》中提到的分析麻痹误区，导致忽视部分方案的可塑性或是潜在隐患。
- 我也思考过如何避免这样的思维误区——逐步分解要解决的问题细化至一个个小问题，再逐个选取最优的解决方案，这种解决方案下也可能出现选取方案不佳的情况，但是对整体的团队项目来说影响已经减小了许多，也方便在后续进行修改。
结语
- 在本章中作者花了很多笔墨来叙述团队中个人力量与团队间的衡量，也给出了团队中的角色应尽的职责。我认为在当前团队作业开始之前能够明确自身在团队中的定位和职责是十分重要的事情。
- 而书中关于职业发展中的投身的事业、理想的呼唤云云感觉至少相对于我来说显得过于抽象缥缈了一些，不过对于职业有着认真的态度是十分可取的。
