「提效」这个话题很大，涉及了很多方面，虽然会和技术等工具有关，但它们相对来说不是重要的，由参与活动的人的认知、意识及其所决定的行为更为重要！
在《反思软件开发：人为因素（上）》与《反思软件开发：人为因素（下）》中尝试阐述了「人」对「效率」的影响，本文和下两篇文章我将试图从「知识」的角度说明「效率」问题。
常见问题
我们在日常工作中遇到的问题很大程度是以分工协作及沟通交流为中心的——不仅是人与人之间，还包括人与机器之间和机器与机器之间。
业务支撑
在支撑业务功能时，前端是如何做的？
当今前端开发的主流做法就是在基础组件（顶多再加上所谓的「业务组件」）之上新建个相应业务功能的「页面组件」，一顿操作猛如虎之后，至少几百行代码出来了，如果布局和交互稍微复杂点，破千行轻轻松。
设计师和产品经理验收后很高兴，不仅还原度高，还没什么「八阿哥」。可过了几个月甚至一两年，在需要加点新功能或做些调整时，打开代码文件，傻眼了——
当时的业务逻辑是啥来着？这个地方当初为啥这么写？怎么一个小调整要改这么多地方？！这地方太复杂了，不敢改啊，改出问题又得背锅……
有经验的人都能看出问题主要出在哪，以及该如何避免，包括当初写下那些代码的人——
对代码和逻辑进行适当切割，拆分出文件；语义化命名，以将部分隐性知识显性化，并减少无意义注释；抽象出具备高内聚性和可复用性的模块；遵循各种「原则」，使用高大上的「模式」……
然而，真正有动力去做这些事情的人并不多，代码写得好又不会升职加薪，并且我们大部分人没有什么「正当理由」要求他人写出好代码——除非这成为带有行政属性的制度。
前端在业务支撑时的主流模式加上人的惰性，在人与机器的沟通交流中形成很大的障碍。
岗位职责
有些人对前端从业者抱有「不切实际」的期望和要求——前端应该懂业务——我觉得这很荒唐，这是他们的「幻想」。
当前一般意义上属于「前端」的工作有网站开发、函数库、组件库、CLI 工具、开发框架等专注于「前端」这个领域且与企业「业务」不相关的；与「业务」有所关联的，基本只有应用开发。
在以软件及服务为营生的企业中，涉及到「前端」的职业、岗位有前端工程师、前端负责人、全栈工程师、（Modern.js 所倡导的）应用开发者/产品开发者、业务架构师以及产品经理。其中，是「纯前端」（专注于「前端」这个领域）的只有前端工程师。
如果一个人，他的工作内容与职责不局限于「前端」，那他实际上不是一个前端工程师，并很大可能也不会自称为「前端工程师」；那些自称「前端工程师」且说自己「（要/该）懂业务」的人，极有可能是被动的——在应聘或被安排工作时如此要求，或者是为了 KPI 和升职加薪。
「前端」理应是做「业务无关」工作的「前端工程师」——以此为前提，前端专注于展示与交互，代码中不应有业务语义，与前端沟通时的语言也是业务无关的，转化为与展示、交互强相关的用语——从「前端」的世界中剥离一切「业务」强相关的事物。
但是，应用开发中一定会有业务相关的事物，该如何处理呢？
在用合适的架构和框架将业务语义的逻辑、状态等从 UI 组件中剥离出去之后，由非前端人员（通过 Handie 类的工具）去完成领域模型定义、业务相关的状态控制等。
「非前端人员」是指除做「业务无关」工作的「前端工程师」之外的人——前端负责人、全栈工程师、应用开发者/产品开发者、后端工程师、业务架构师、产品经理等。
那些对前端抱有「不切实际」的「幻想」的人，估计是认为这会提高协作效率或价值产出？他们应该是想多了……
当一个人对「业务」一知半解且有自己想法时，沟通协作中发生摩擦的概率和次数会更高，不仅不会提高价值产出，还会降低协作效率。这个人，无论是不是「前端」。
在这方面，「设计」与「前端」实则属于一类人——着眼于展示与交互，不需要去了解和背负「业务」上的事情。要求「前端」和「设计」去懂业务，从「人」的角度看，这也算是一种压迫行为。
测试左移
在软件开发流程中，「测试」是在「开发」之后的，也就是在功能开发完成后才进行功能上的测试。这样一来，只是程序单元上的问题还好说，但若是架构甚至是业务上有问题，返工的成本可就很大了。
为了尽早发现问题，并在没造成什么实际影响时解决掉，测试人员或行为需要介入到上游环节中，如测试人员参与需求评审、设计稿评审、软件设计评审，开发阶段进行单元测试等——这就是「测试左移」。
虽说这样在一定程度上能够达到预防的目的，但依然会存在信息同步上的问题——
在开发过程中发现了评审时没意识到的问题，与产品、设计私下沟通后做了修改，但没同步更新相关文档也没告知测试人员，这时就很容易会在不知情的情况下漏测，进而导致线上故障。
跨部门协作
总的来说，跨部门协作是很烦的事情，比同部门协作烦上几个等级。究其原因，就是人性导致的利益冲突，考虑更多的是自身利益，而非共同利益；并且思想狭隘、目光短浅，做一锤子买卖，而非长期合作。
一个比较普遍的问题就是——
业务部门在功能迭代时需要用到中台/平台部门的服务，倘如此时中台/平台部门的基础服务还不完善，无法「开箱即用」，那么就面临「业务方的个性化逻辑代码写到哪和谁维护」的选择：
- 各自部门的人在各自的代码仓库中开发调试各自的逻辑代码；
- 中台/平台部门在开发基础服务的同时，在业务部门的代码仓库里开发调试业务方的逻辑代码；
- 临时放在中台/平台部门的代码仓库里，基础服务完善后将业务方的逻辑代码迁出去；
- 写到中台/平台部门的代码仓库里，并且后期变动和维护也继续由中台/平台部门的人做。
正常情况下，无论如何不可能也不应该选最后一种，这是最基本的部门定位和职责划分问题。然而，也许也会存在比较无奈的情形，比如：当不够强势的中台/平台部门遇到比较无赖的业务部门时。
更糟糕的是，业务方的逻辑比较绕，开会讨论时已经各方自认为达成了共识，并按照自己的理解去开发了；但在测试时业务部门的人却说中台/平台部门的人实现得不对，业务逻辑有问题，甚至还推翻了之前开会讨论时所达成的共识……
由中台/平台部门去维护业务部门的逻辑代码，这本身就是一件很扯蛋的事情！这对中台/平台部门来说几乎是无利可图，反而容易惹得一身腥！
小结
本文述说了我们在日常工作中常会遇到的几类问题，并针对它们各自十分简单且浅显地表达了我的观点。
这几个问题虽然看起来五花八门，它们之间貌似没有什么关联，但正如文章的标题和开头说的一样——它们的背后都与「知识」有莫大关系！
具体是什么将在下篇文章中揭晓，在那之前各位有兴趣的话可以先想下～