共计 2652 个字符，预计需要花费 7 分钟才能阅读完成。
「提效」这个话题很大，波及了很多方面，尽管会和技术等工具无关，但它们相对来说不是重要的，由参加流动的人的认知、意识及其所决定的行为更为重要！
在《反思软件开发：人为因素（上）》与《反思软件开发：人为因素（下）》中尝试论述了「人」对「效率」的影响，本文和下两篇文章我将试图从「常识」的角度阐明「效率」问题。
常见问题
咱们在日常工作中遇到的问题很大水平是以分工协作及沟通交流为核心的——不仅是人与人之间，还包含人与机器之间和机器与机器之间。
业务撑持
在撑持业务性能时，前端是如何做的？
当今前端开发的支流做法就是在根底组件（顶多再加上所谓的「业务组件」）之上新建个相应业务性能的「页面组件」，一顿操作猛如虎之后，至多几百行代码进去了，如果布局和交互略微简单点，破千行微微松。
设计师和产品经理验收后很快乐，不仅还原度高，还没什么「八阿哥」。可过了几个月甚至一两年，在须要加点新性能或做些调整时，关上代码文件，傻眼了——
过后的业务逻辑是啥来着？这个中央当初为啥这么写？怎么一个小调整要改这么多中央？！这中央太简单了，不敢改啊，改出问题又得背锅……
有教训的人都能看出问题次要出在哪，以及该如何防止，包含当初写下那些代码的人——
对代码和逻辑进行适当切割，拆分出文件；语义化命名，以将局部隐性常识显性化，并缩小无意义正文；形象出具备高内聚性和可复用性的模块；遵循各种「准则」，应用高大上的「模式」……
然而，真正有能源去做这些事件的人并不多，代码写得好又不会升职加薪，并且咱们大部分人没有什么「正当理由」要求别人写出好代码——除非这成为带有行政属性的制度。
前端在业务撑持时的支流模式加上人的惰性，在人与机器的沟通交流中造成很大的阻碍。
岗位职责
有些人对前端从业者抱有「不切实际」的冀望和要求——前端应该懂业务——我感觉这很荒谬，这是他们的「空想」。
以后个别意义上属于「前端」的工作有网站开发、函数库、组件库、CLI 工具、开发框架等专一于「前端」这个畛域且与企业「业务」不相干的；与「业务」有所关联的，根本只有利用开发。
在以软件及服务为谋生的企业中，波及到「前端」的职业、岗位有前端工程师、前端负责人、全栈工程师、（Modern.js 所提倡的）利用开发者 / 产品开发者、业务架构师以及产品经理。其中，是「纯前端」（专一于「前端」这个畛域）的只有前端工程师。
如果一个人，他的工作内容与职责不局限于「前端」，那他实际上不是一个前端工程师，并很大可能也不会自称为「前端工程师」；那些自称「前端工程师」且说本人「（要 / 该）懂业务」的人，极有可能是被动的——在应聘或被安顿工作时如此要求，或者是为了 KPI 和升职加薪。
「前端」理当是做「业务无关」工作的「前端工程师」——以此为前提，前端专一于展现与交互，代码中不应有业务语义，与前端沟通时的语言也是业务无关的，转化为与展现、交互强相干的用语——从「前端」的世界中剥离所有「业务」强相干的事物。
然而，利用开发中肯定会有业务相干的事物，该如何解决呢？
在用适合的架构和框架将业务语义的逻辑、状态等从 UI 组件中剥离进来之后，由非前端人员（通过 Handie 类的工具）去实现畛域模型定义、业务相干的状态管制等。
「非前端人员」是指除做「业务无关」工作的「前端工程师」之外的人——前端负责人、全栈工程师、利用开发者 / 产品开发者、后端工程师、业务架构师、产品经理等。
那些对前端抱有「不切实际」的「空想」的人，预计是认为这会进步合作效率或价值产出？他们应该是想多了……
当一个人对「业务」只知其一; 不知其二且有本人想法时，沟通合作中产生摩擦的概率和次数会更高，不仅不会进步价值产出，还会升高合作效率。这个人，无论是不是「前端」。
在这方面，「设计」与「前端」实则属于一类人——着眼于展现与交互，不须要去理解和背负「业务」上的事件。要求「前端」和「设计」去懂业务，从「人」的角度看，这也算是一种压迫行为。
测试左移
在软件开发流程中，「测试」是在「开发」之后的，也就是在性能开发实现后才进行性能上的测试。这样一来，只是程序单元上的问题还好说，但若是架构甚至是业务上有问题，返工的老本可就很大了。
为了尽早发现问题，并在没造成什么理论影响时解决掉，测试人员或行为须要染指到上游环节中，如测试人员参加需要评审、设计稿评审、软件设计评审，开发阶段进行单元测试等——这就是「测试左移」。
虽说这样在肯定水平上可能达到预防的目标，但仍然会存在信息同步上的问题——
在开发过程中发现了评审时没意识到的问题，与产品、设计私下沟通后做了批改，但没同步更新相干文档也没告知测试人员，这时就很容易会在不知情的状况下漏测，进而导致线上故障。
跨部门合作
总的来说，跨部门合作是很烦的事件，比同部门合作烦上几个等级。究其原因，就是兽性导致的利益冲突，思考更多的是本身利益，而非共同利益；并且思维狭窄、目光短浅，做一锤子买卖，而非长期单干。
一个比拟广泛的问题就是——
业务部门在性能迭代时须要用到中台 / 平台部门的服务，倘如此时中台 / 平台部门的根底服务还不欠缺，无奈「开箱即用」，那么就面临「业务方的个性化逻辑代码写到哪和谁保护」的抉择：
- 各自部门的人在各自的代码仓库中开发调试各自的逻辑代码；
- 中台 / 平台部门在开发根底服务的同时，在业务部门的代码仓库里开发调试业务方的逻辑代码；
- 长期放在中台 / 平台部门的代码仓库里，根底服务欠缺后将业务方的逻辑代码迁出去；
- 写到中台 / 平台部门的代码仓库里，并且前期变动和保护也持续由中台 / 平台部门的人做。
失常状况下，无论如何不可能也不应该选最初一种，这是最根本的部门定位和职责划分问题。然而，兴许也会存在比拟无奈的情景，比方：当不够强势的中台 / 平台部门遇到比拟无赖的业务部门时。
更蹩脚的是，业务方的逻辑比拟绕，开会讨论时曾经各方自认为达成了共识，并依照本人的了解去开发了；但在测试时业务部门的人却说中台 / 平台部门的人实现得不对，业务逻辑有问题，甚至还颠覆了之前开会讨论时所达成的共识……
由中台 / 平台部门去保护业务部门的逻辑代码，这自身就是一件很扯蛋的事件！这对中台 / 平台部门来说简直是无利可图，反而容易惹得一身腥！
小结
本文述说了咱们在日常工作中常会遇到的几类问题，并针对它们各自非常简略且通俗地表白了我的观点。
这几个问题尽管看起来形形色色，它们之间貌似没有什么关联，但正如文章的题目和结尾说的一样——它们的背地都与「常识」有莫大关系！
具体是什么将在下篇文章中揭晓，在那之前各位有趣味的话能够先想下～😁
本文其余浏览地址：集体网站|微信公众号
