为了让工程提速，我们制造了规则。
为了让工程提速，我们漠视了规则。
本文给新踏上开发之路的朋友，1~3年左右开发经验的朋友可以看看，虽然这不是实打实的开发技能，但这却是我这数年开发的实际心得，您看完了，或许会有所收获，也可能会莞尔一笑，不过无论如何，肯定都不算是耽误您人生中的些许时光。
正文
在早期单打独斗的时候，从来没有在意规则，一个人想怎么写就怎么写。
不过为了让未来的自己读代码没那么累，于是我开始在代码中写入注释，并且开始了简单的语义化，不再简单使用a,b,c,d这种临时变量。
这是最开始的简单规则，一直到团队开发的时候，我开发人生中第一套规则才开始正式诞生。
而数年之后，我为公司打造了一套低代码工具，将工程化发挥到了极致。
遥遥回想过往，简直感觉一切简直是不可思议。
开发规则
在早年前后端分离的思潮刚刚诞生的时候，我入职的前端开发团队大约两人左右，那时后端也仅一人。
很多时候商量着来，就能完成。
而后来，随着业务量的增加，前后端数量开始增加，三人以上的前端团队，对接三人以上的后端，在没有统一规则的指导下，开发进度一言难尽。
大部分的时间，前后端为了对接接口而费劲了心思。
情景复盘
三个人的后端，写出了三种风格的接口，大小写不统一，中英文混写，接口传参方式混乱，传参方式不同，且接口变动频繁导致前端根本无法稳定对接。
大家可能不能想象，那我就说一点，增删改查这一套流程中，有人同样一个字段居然写出了四种命名，有的是拼音，有的是小驼峰的单词，有的是大驼峰的单词，有的还用下划线方式命名，传参的code甚至都能出现字符串和数字两种类型，判定接口成功的code：200，20000，且这个过程中还有两种类型。
后端一团乱麻，而前端也没好到哪里去。
样式写法混乱，不用公用样式，非要自己改权重，写入样式覆盖公用样式。
接口写入方式不同，明明有着开源框架的标准方式，却偏偏要自己手动引入axios写接口，导致api接口文件非常不便管理。
而且，当时那个时间大约是2019年，那时候，前后端分离方式的思潮还很新，部分前端依旧是习惯于Jquery操作Dom的写法，然后你可以在vue的项目中看到有人引入了Jquery的在线链接，然后在框架内写代码操作表格。
这种思潮时至今日我居然还能在部分新手代码中遇到，有些时候我甚至可以在vue3中看到Jquery操作表格的代码，我也是不得不感叹，世界真是太大了，大到会发生任何不可思议的事。
整理问题
毫无疑问，不规范的问题极大拖累了开发速度，我们两周后复盘了一下，近乎7成以上的事件浪费在这种毫无意义的调试上。
我们当时在做的是一个系统的翻新，之所以接口会出现频繁变动，是因为大多数后端对业务不熟悉，进而导致接口频繁变动，而我们需要快速翻新出成果。
为了追求快，我们放弃了规则，这是管理上的隐患。
公司当时用的是非常好上手的Vue2，写过Vue2的朋友大概率应该知道，这是一个非常好上手的新手框架，但是我们那时候简直能用出一坨屎。
我将这个开发过程中犯的毛病整理一下，权当一篇避雷指南了。
如果您现在的项目中中了以下几条，那您就必须要反思一下，您做项目到底将多少精力花在这些无意义的调试上了？
- 管理上追求快，不做标准要求，按照要求的时间点开始倒排开发日期，导致开发无限期加班，精力极大程度的消耗在对接空耗上了
- UI风格不统一确定，很多时候出成品，经常会有样式上的变动
- 前后端不做业务交流，双方都在一次会议之后，简单确认了任务，就毫无修正的朝着各自以为的目标推进
- 后端接口标准不统一，数种不同风格的接口导致前端难以适配，即便写统一处理字段的方法也没法讲中文字段转换成英文字段，这极大的拖累的开发进度
- 前后端未约定联调标准，导致传参方式适配难度极大，后端成功与失败的code都不统一，有的后端甚至不写接口报错捕获，所有的传参结果都是成功
- 前端未使用公用样式，导致样式管理极度混乱，无法统一修改部分公用样式
- 前端技术栈不统一，有人在项目中使用JQuery，加重了调试的心智负担
- 前端语义化命名不明显，在样式中多处使用
L1，R1，T1，B1这类风格，scss样式嵌套加深之后，阅读极为困难，变量中更是重量级，基本上不用ES6，狂用ES5的写法，几乎不用ES6的新特性来处理数组，导致代码阅读极为困难 - 前端代码风格不同，导致不同格式化的代码风格经常冲突
- 前端不用VueX存储的公共数据来读取一些数据字典，反而每次都要请求一次接口去读数据，每次页面都要拉取很多接口
- 没有公共工具方法库，所有人判空，取整，时间格式化都是按照自己的想法来，八仙过海，各显神通
综上，这是开发中问题，至于发布测试等方面的问题，这里先按住不表，因为后续更是重量级。
由于以上的问题，我们开发页面过程极度缓慢，翻新进度简直慢的发指。
四个简单的增删改查页面，前端后端6人，每天工作12小时以上，而且是时刻有交流条件的情况下，大家根本不交流。
然后，居然在一周内没有完成两个单表的增删改查。
而后续一个复杂的多字段表单，更是整整耗时一周，才勉强调通，且不能保证全流程完全走通。
是的，这就是我们的开发进度，6个人，做成这样，肉眼可见的丢人，但这就是那时的开发进度。
我们放弃了规矩，但是我们并未追求到进度。
在复数人员的开发情况下，一个混沌的开发体系，进度便是如此的可笑。
解决方法
幸亏管理也算是技术出身，且技术功底扎实，简单的商量之后，我们制定了以下的简单方案
- 后端接口由管理负责，定好统一格式，后端全员按照接口格式开发
- 在正式确认业务之前，前后端都要过一遍业务，彼此确认业务的大致流程，同时后端在没有给定正式业务之前，要先给出确定字段的接口，便于双方确认（那时候我们还不会Mock数据）
- 制定统一风格，由管理人员确定一套风格，然后开发出最初的模板，之后尽可能使用
element-ui框架来实现功能，避免前端使用自己手写的样式覆盖，如果一定要调整全局样式，那么需要报备，除非必须要求改动，否则就放弃修改 - 技术栈统一，放弃JQuery，全面拥抱Vue2的写法，每晚定期进行代码审查（草草检查，主要确认没有jquery）
- 公共接口抽离，将一些公用方法抽离出来，如上传，部分复杂的业务数据字典，
- 公共方法本地化封装，将一些判空之类的方法写在工具类中，省去每人手写工具方法的时间
- 命名语义化，尽可能减少无意义的变量命名
- 代码格式化插件统一，开发工具统一，保证所有人调试起来方便（笔者并不太会用webstorm的格式化，当时也没时间去研究，只能禁了那位组员的webstorm，让他用vscode）
经过这些小手段，效果立竿见影。
开发进度确实有了些许提升，但是页面功能的稳定性显而易见的上升，同时每人的工作量大幅下降，勉强可以8点下班，至少不用彻夜彻夜的加班了（在这之前巅峰时间甚至能达到每天14小时以上的工作强度）。
可能大家会觉得，这并未提升多少，但是于那时的我们来说，在这之前，团队几乎是肉眼可见要崩塌，所有人都不觉得这样的团队能做成这个项目。
但是这些简单的规定做下来之后，虽然强度还在，但是工作目标至少可以量化了，同时任务终于可以拆解了，不再是将所有人都堆在任务中。
而团队工程化的路，就是从那时候开始的。
运维发布
因为团队一开始并不大，所以很多时候都是开发运维一把抓，然后在这个过程中，又诞生了一堆混乱至极的问题。
情景复盘
那时，我们用的仍然是SVN进行版本管理，相对于git的分布式版本管理，SVN的集中管理有个弱势点，那就是版本管控必须要将代码文件提交到中心服务器。
而这就有个隐患，如果有人没有将自己的逻辑走完，那么为了版本管控，他也只能将代码提交到SVN，而客户几乎每天都会过来看一下进度。
如果有经验的人，想必此时已经发现哪里有隐患了。
因为有人会将未完成的功能提交到线上，那么发布到线上的时候，碰到演示这种未完成的功能时候，免不了会被客户一顿痛批。
部分公司为了解决这种问题，会选择再买个服务器，做一个测试版本，但我们当时是内网开发，客户表示只有这一个服务器，然后结果就很尴尬了。
这个过程，开发流程管理也很混乱，客户会经常在我们开发过程中插入一些新的要求，导致我们项目需求翻新的进度极度拖延。
整理问题
在我们刚解决了开发上的规范问题之后，我们就遇到了这种运维及需求沟通的问题上的问题。
需求混乱
- 翻新需求不明确，做无用功，很多旧版本的功能，在旧版时候明确不用了，但是项目Leader没有细细筛过需要翻新的功能，导致经常做了无用功
- 客户需求不评审，因为客户可以直接到现场催稿，导致经常会插入一些客户优先的功能，延误了正常工期排序
- 对业务不熟悉，导致返工。这个是最常见的事情，很多时候，我们评审业务，项目Leader没有说明白业务，进而导致开发者对业务的理解南辕北辙，不停翻新做无用功。
针对这些问题，我们项目Leader只能将自己从开发序列中抽离，自己去整理业务对接客户。
因为他最懂这块的业务，所以只有他自己可以去，他将需求承接完成后，顶住客户的需求压力，按照排期给我们捋顺业务和开发进度。
之后，由他来作为团队大核，指导对业务不熟悉的我们，由我们负责具体的开发内容。
这之后的效果，也算是立竿见影，虽然项目Leader不用实际开发了，但我们的进度却并未落下，甚至质量再次提升，做无用功的情况越来越少，随着大家对业务的逐渐熟悉，所有人甚至可以对业务中不合理的地方及时预警。
混乱发布
这是在需求没有整理之前的情况，我们的发布突出一个随心所欲，几乎所有小团队中能犯的错，我们这里都犯过。
- 版本不指定，我们没有既定的版本，只是按照大致的感觉和客户的催命程度来发布，这时候我们和上版本相比有了什么进步只有项目Leader知道
- 功能不自测，因为经常翻新，为了追求演示效果，我们经常赶时间发布，这导致演示的时候经常翻车
- 人员不指定，所有人都可以发布，然后我们经常在发布的时候撞车（趁没有测出BUG悄悄发布，小团队这种事想必很多）
- 项目现场不指定，当时翻新的这个项目部分源码涉及到另一个项目现场，手动发布必然会有失误，经常忘记改配置，导致项目现场读取的内容错乱
- 日期不指定，因为没有固定的发布时间，所以客户经常回来催我们（后来由项目Leader去抗这个压力了）
综上，我们提出了一系列的解决方案。
- 定好版本发布规则，确认需求后，固化发布日期。除非客户强烈要求，否则不会加入新功能排期，按照周为单位进行迭代。
- 指定专门的运维人员，其他人不能碰发布服务器
- 前端开发打包版本插件，让代码可以根据时间自动生成版本，并抽离配置，减少手动发包导致项目现场错配的问题
- 安排运维人员书写运维文档，保证客户和开发人员都能明白我们要改什么，接下来要做什么
提速方向
讲到这里，时间基本上挺接近现在了，我这里没有接触过更高标准的团队，但是就我打听的情况来看，大厂似乎也将工程化的流程走到顶点了。
我在面试过程中，发现很多团队实际上基本就是前者的形态了，很少有进入到这一步的，以下提到的这些需求，几乎是只有大型团队才会出现的需求。
这一步几乎是工程化的高标准状态了，大多数草创的开发团队，甚至是一些较为成熟的团队，他们几乎没有到这一步的意识和需求。
到了这一步，公司业务几乎固定，因为业务线的固定，也逐渐衍生出产品化的概念，自然也就有了产品迭代的需求。
于是，工程提速的玩法再次发生了改变。
- 自动化发布
- 代码管控，自动生成发布日志
- 组件库
- 工具包
- 脚手架
- 前后端约定统一，技术栈固化
集成以上方式之后，便有了终极形态，低代码。
在那时，我们几乎可以将一个两月交付的项目在一周内迭代出原型，供客户参考，然后在那基础上修改。
同时极大程度节约人力，不过受限于篇幅，这里就不展开说了，后续会随着自己的要求，逐步解释我们项目中为什么进行这些操作。
结语
开发规则的诞生，是一个几乎必然的过程，人人都在骂这种制度化，但是一旦走向了大型团队化，我们又不可避免的制度化。
有些时候，人真是有趣，讨厌一件事，理解一件事，融入一件事，成为这件事。
制度化，团队化，似乎是人类群体的必然性，这种过程似乎是大型团队的必然答案，也是一种趋同进化的趋势。
当然，扯远了，我们仅仅说的是工程，一个工程想要做的正常，并非一定要上大型工程的规则。
最后，给自己的掘金引个流：工程提速，规则的意义 - 掘金 (juejin.cn)。
希望大家能关注我，多多点赞，谢谢！
参考
无