提高软件开发效率哪有那么容易？都是陷阱。是为了减少浪费吗？基于现状分析各个环节的浪费，避免浪费，能否达到提高效率的目的？这可能不正确，这取决于目的是什么。可能的目的有以下三种：降低总成本：可能人少了，但是开发时间长了。提高总吞吐量：通过堆叠更多的人，在相同的开发时间内，可以交付更多的业务价值。减少延迟：通过堆叠越来越多的人，你不在乎有多少浪费，只要你能快速响应市场，你就可以有所作为，当谈到提高上下文效率时，它的目的可能是不同的。比如前段时间非常火爆的买菜业务，大家一致选择越堆越多的人，目的是减少延误，用一种不计较投资的方式来做。如果为了省几个P5的工资，把开诚的上线推迟一个月，丢掉市场，实在不划算。即使当我们谈论提高效率时，我们也意味着消除浪费。如上图所示，我标记了6个可能产生浪费的环节。下面一一说说各个环节产生的浪费。存在了这么久也在情理之中，想要“提高效率”也不是那么容易的。不是每条路都走不通，而是没有低垂的果实，有坑。1.产品经理/UI设计师与开发人员之间的交接是浪费。很多人看到产品经理要写PRD稿，然后开发人员翻译。UI设计师需要绘制UI草稿，然后前端开发需要相应还原UI。如果能减少这个交接环节产生的浪费，让PRD稿和UI稿直接进入下一个环节，岂不妙哉。走这条路的陷阱是什么？PRD稿和UI稿的意义在于减少返工。如果没有前面的流程，让客户直接用一个需求的词来连接开发。那是很有可能做到的，而且这不是客户想要的。这个时候修改代码比修改PRD稿和UI稿的成本要高很多。所以PRD稿和UI稿的好处就是可以改的很快，对可运行代码没有那么多要求，可以很随意。如果要求PRD稿和UI稿可以直接翻译执行，需要添加语法和语义规则。这可能会损害“低成本、可修改、可讨论”的优势。产品经理和UI设计师将花费更多时间使输出符合规范，而不是花费更多时间与客户讨论和修改。2.开源库和框架提供的可重用代码太少。做了很多中后端项目，还是有很多重复的代码。这种浪费意味着开发人员重用的库和框架非常低级和基础。数据结构，RPC通信这些东西。做了几个项目之后，我会得出一个想法，我是一个CRUD男孩，我觉得一直重复它不是一个选项。如果能产生几个开源的库和框架，那岂不是造福于人类？走这条路的陷阱是什么？开发商不能反向约束客户需求。任何两个客户端，甚至CRUD，都会有不同的细微差别。比如列表/详情是上下左右，弹框，还是跳页？是列表分页还是无限下拉，带过滤还是搜索？开源库之所以都是那些基本的东西，是因为这些东西有很多共同点。稍微靠近用户的一侧，就会有很多花样。那么第二种可能的思路是满足80%的需求，让开发者传参数、传回调、写补丁、写DSL来满足剩下的20%。那些开源库的作者之所以没有这样做，是因为他们愚蠢（划掉），也是因为我有更好的代码生成/组件插件技术/xxx这条路可能会遇到什么坑？不讨论有没有什么牛逼的技术可以大大提升定制现有代码的体验，我个人的经验是没有这种技术，无论运行时还是编译时，能力基本相当。即使有这样的技术，一方面，写20%的人至少要知道80%是什么。他需要知道现有的库和框架提供了什么以及需求是什么，然后比较这20%。然后你需要知道如何在指定的库和框架上编写20%。没有两个框架提供相同的扩展方法，每个框架都有自己独特的实现方式。20世纪80年代，流行元件市场的传奇。把业务组件写好，然后卖钱。但从历史的角度来看，组件市场的最终形态是最大的同性交友社区github。复用代码最好的方法就是使用主义，直接fork一份，根据别人的代码进行修改。什么参数化、插件、回调都没有直接改源码那么直接，好用。3.现有代码的认知负担太大，新人接手需要很长时间。反馈周期很长，无法快速修改和快速迭代。观察人们如何阅读代码和修改代码，不难得出这两个主要的浪费点。CognitiveLoadFeedbackCycleCognitiveLoad：代码阅读复杂，难以理解。一段代码要交给另一个人来写，他要花很长时间才能达到你以前的水平。即使按照ProgrammingasTheoryBuilding，也没有人能达到与作者相同的理解水平。理解一段代码的最好方法可能就是重写它。走这条路的陷阱是什么？有人建议我们需要使用事件溯源。也有人提出，不行，我们应该是Reactive。有些人还建议我们应该有一个结构化状态机。每个人都会提出他们自己所谓的最低“认知负荷”的版本。但坑的是每个人的思维习惯和过往经历都不一样。不是所有的GUI都必须是React，而是Reactive。有些人和一些项目可能直接用jQuery修改DOM是“低认知负荷”的解决方案。有句话叫Simplev.s.Easy，就是一个解决方案可能是Simple，但是因为不是代码读者熟悉的模式（比如HaskellDoApplicative），所以对他来说并不Easy。被推测和揣测过的编程范式就那么几种。如果一个人比其他人强大得多，那么世界早就统一了。没有什么未知的逻辑表达式还没有被发现，早就被枚举出来了。反馈周期：很多人也看到修改GUI代码需要很长时间才能知道修改后的效果如何。如果所见即所得，反馈周期可以大大缩短，同一时间内可以进行更多的修改。同样，如果无法在本地获取生产环境数据，无法运行完整的代码，则需要上线或提交到特殊环境后才能运行，同样会导致反馈周期过长。如果可以减少认知负荷并缩短反馈周期，那不是很好吗？走这条路的陷阱是什么？编程语言太多了，运行时平台每年都在变，框架和库也在变。这些缩短反馈周期的工具和技术在很大程度上取决于项目使用的编程语言、运行时平台、框架和库。甚至有可能侵入业务代码的逻辑代码编写。你可以在Python中使用viztracer，PHP中有吗，Closure中有吗？Html+Vue搭建Vite难度大，迭代速度快。明天业务改用微信小程序，以前的技术就不用了。4、同事之间的沟通成本很高，开会浪费时间。大型软件不是一个人可以完成的。与同事合作需要沟通和开会。如果每个人都可以负责一个独立的模块，模块之间松散耦合并且各自做自己的事情，那不是很好吗？编译时，将模块代码链接在一起，成为同一个可执行文件，在线运行。走这条路的陷阱是什么？产品经理不知道你是怎么拆分模块的。产品经理看到的是这里有一个接口，谁来负责这个接口，我跟谁谈需求。产品经理看到有一个按钮可以点击，谁来处理这个按钮的点击，我应该和谁谈需求。但需求往往是“集成需求”，即一个模块处理不了。比如订单详情页，需要各种数据。如果这些数据都在同一个模块中，就达不到拆分开发的目的。如果分散到不同的业务模块中，则必须在界面上进行整合。如果出现问题，还有谁应该负责？谁来检查错误？谁将发布新代码？别人改的代码需要合并到一起。你敢上网吗？5、一个需求需要多个微服务一起修改。联调和线上部署一定要慎重，慢慢实现前面提到的不是拆微服务，只是拆分代码模块。微服务不浪费吗？微服务一多，人们就开始问为什么要拆掉那么多微服务。做一个需求，要改那么多微服务，不仅要联调，还要改上线时的顺序依赖。只要暴露了一个微服务接口，就不能下载，天知道哪里有引用。一个团队能完全搞定一个需求，那该有多好。要么是单体，真香。要么拆分不合理，需要DDD来指导微服务的边界划分。走这条路的陷阱是什么？没有所谓的“一个要求”。需求的粒度是人为限制的，可粗可细。一个团队不可能实现一个需求，因为这个需求没有严格定义。同时，业务创新往往是破坏性的，即将之前没有整合关系的事物进行整合，将之前没有联系的事物联系起来。无论怎么调整，都无法避免球队之间的配合。那么总可以把微服务结合起来，减少微服务之间的PublicAPI。比如让前端和后端同时发布，这样就不用考虑后端API的兼容性了。合并B端和C端，这样就不用考虑B端不升级，C端兼容的问题了。走这条路的陷阱是什么？很多运行时平台无法实现前后端同步发布。比如iOS需要审核，需要用户手动确认升级。也有可能安卓没有热更新技术。所以客户端要兼容老版本，添加的字段不能删除。B端和C端合并，server端可能没有。但是客户端的合并，无论是同一个web域名还是同一个微信小程序appid，都可能会引起产品经理的强烈抗议。人们习惯于为不同角色的用户提供独立的终端。6.终端用户知道自己要什么，他们会处理Excel，所以我们也可以做类似Excel的软件，避免因需求排程造成的浪费。很多软件都会提供类似流程图的界面，这样用户就可以去进行一些流程修改或者创建一个新的自动化流程来减少人工的重复劳动。也可能会提供一些填写数学公式的地方，供用户填写推广规则。还有一些营销页面构建工具可以让用户直接在页面上拖放他们想要的东西，比如Photoshop。走这条路的陷阱是什么？如果用户能够100%满足任何自定义需求，那么这些“自定义功能”一定等同于专业程序员使用的工具。这些让用户表达需求的接口，往往开发起来非常困难，需要大量的成本。而且它不一定会产生与成本相当的收益。在一些996国家，人们可能会觉得让别人来做会更快。另一个陷阱是用户只是用户，因为他们的工作不是“软件开发”。如果让用户自定义很多逻辑，工作量可能会大到造成“全职工作”。这时候，用户就不是所谓的“用户”了。它只是另一群全职开发人员，他们拥有所谓的“构建工具”并以蹩脚的方式编写代码。最大的陷阱在于过分吹嘘这种面向最终用户的定制能力，吹嘘颠覆行业的是xxx。快速定制的前提是需求固定。只要需求超出了原有配置能力的范围，就需要引入大量的“定制”。这些定制，无论是用c#写局部方法，还是用蓝图拖拽流程图，关键都在于“量”。只要定制量上来，量变就会引起质变。因此，前提必须是减少需求，而不是满足所有需求，才能实现效率提升。那些对需求限制保持沉默，只吹嘘10倍效率提升的人都是骗子。收益总是被高估，成本也总是被高估。在各种提高效率的努力中，可以看到三种常见现象。人们总是很乐观。这种效率提升方法实施后，可以直接10xwow。人们总是低估了替换现有成熟解决方案、模型和框架的成本。这种成本投入，上半年可能完全是负输出。只有达到一定的积累之后，才会开始超越原来的经验。不管用哪一种思路来提高效率，大家都会说自己做的是“lowcode”
