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