懂很多的工程师最恐怖

有些比较大型、而且有规划要进行客制销售的专案，它在程序工程上有几个阶段，首先是「确立技术可行性」，然後是「提出核心模组」，接着就是开始组成工程团队开始「应用模组陆续完成大型专案」。

既然有工程团队，自然不只一个工程师...领头的工程师自然是跟随着专案团队从「确立技术可行性」到「提出核心模组」步骤的那一位。
这样的工程师往往经过人资精挑细选，具有「最资深」「做过最多东西」「懂很多平台技术/工具技巧」的特质。
专案前两个步骤在他手中会进行的似乎非常顺利，看着用核心模组做出来的雏形，专案领导者（和大老板们）会开始构思着（幻想着）专案步上轨道後美好的画面.......

然後专案（工程品质）就垮了。

怎麽垮的？
对不懂技术的人来说，他们可能永远看不懂这个问题的全貌，就冒然下结论「一定是後续扩增的团队成员资格不符、能力不佳」。然後他们的解决方案可能是拉着那位核心工程师（可能加个薪、给个头衔跟大办公桌）要求这人一肩扛下重组工程团队的任务.......

然後专案（工程品质）就死了。

（有些时候，「为了拯救专案而做的事情，才是真正害死专案的症结。」有机会再深入讨论。）

事实上，这位工程师往往就是问题的症结。
因为这位工程师根本不懂「怎麽用平行的心态去跟别人合作」。
讲直白一点，「他在一开始用自己设计的核心模组做出雏形，但不表示这套核心模组可以交给其他工程师去进行其他专案。」

为什麽？
因为「设计核心模组」其实是门很抽象的、非技术性的学问，（就跟「如何让专案具有可维护性」一样，）但这位工程师正好只懂技术、正好只懂完成自己眼前看到的问题，给他越多权限、或越明确的认知「别人要跟随你的脚步做事」，他针对问题所完成的解决方案就越不可用。

听起来有点不可思议，可能同时违反了大家的经验与直觉。
用个直接的例子来说明吧......

这位工程师有天写了个函数A，为的是完成某项工程。

functionA(var a){
.......
}

但过了几天几个礼拜後，可能是工程内容改变，所以需要扩增函数A的内容，或是大家发现Bug，所以要进行修改并释出新的函数。
不管怎样，这其实都是很常见的事情。
结果大家会看到这位工程师针对函数A进行了以下的修改。

functionA(var a, var b){
........(完全没有针对当「b」无传入时设计该做什麽事情，就是真的只负责「扩充功能」「修正Bug」)
}

…………

没翻桌的人大概都不懂技术或不懂如何团队合作编写程序。

函数A可能已经释出在多个专案里使用了，而且每个专案都不只使用一次。
（我经历过最惨的例子是「每次点击任何功能」都会呼叫到这个函数A。）
忽然改写函数A的结构与使用方式，等於要专案工程师把已经完成的功能都修改过，甚至连已经通过测试的功能也要将测试结果作废。

有点经验或认知的工程师会将函数A这样进行修改........

functionA1(var a, var b){
........
}

functionA(var a){
var b = ....(初始化)
functionA1(a, b);
}

工程师会另外释出新版的函数A1，然後在函数A中呼叫函数A1，避免使用到函数A的地方都要进行大规模改写。

修改核心模组时不去想办法避免专案工程师要进行大规模改写，专案工程师往往就要自我毁灭式的加班。
如果连续发生这种事情，专案工程师的体力就会开始往下掉、工程品质与效率也会跟着往下掉，而且是恶性循环的幅度。

（这是很多Android专案垮掉的原因。因为Google的Android工程师们显然不懂这个道理。）

顺便一提。
这技巧看起来很简单，但真的很多工程师都不会。
而且是那些越积极吸收新技术、技术年会场场跑、各种新颖工具都能快速上手的工程师，往往不具备这些技巧。

很讽刺的是：他们很多是知道这个问题存在的。
只是因为没人在针对这些技巧举办年会，各种技术平台或工具平台往往也只专注在「SDK说明」或「工具使用技术说明」，所以这些工程师可能年资十年，但从不涉猎这方面的技巧....
（可能也遭遇过不只一次，但他们选择跟其他人一样把责任归咎给其他工程师，或是认为「这世界上一定有可以完美解决这个问题的工具」，然後转头去跳近无穷无尽的工具One Piece中...）

「喔！不就是彼德原理的活生生例子嘛～」不懂什麽是彼德原理？保重。