当你和他们讨论分支策略如何制定，二进制文件不能提交gitlab代码仓库，依赖如何管理的时候，反而感觉“很无力”。
什么是软件的工程化介绍软件的工程化，首先要从代码说起。程序员写完的代码，不是说能直接运行的，不管是编译型，还是非编译型语言，几乎都包含如下步骤：
•准备代码•下载依赖•编译（编译型时间更长）•打包如果是部署，大体包含如下步骤：
上面已经是比较简化的提炼过程，看似确实好像没什么大不了的，常有程序员不屑地说：我在本地电脑就一个脚本，就可以把上面步骤全部搞定可是，如果把以下因素放大倍数，或者引入更多不确定因素呢？
•写代码的是几十人，上百人呢？•集成多份不同业务代码•交付的流程更长，参与角色更多•依赖很多，三方的，二方的•语言技术栈更多•要求配置更灵活•要求快速回滚
还有更多意外因素？
•专门负责构建的机器挂了呢？•写脚本那个哥们走了•更新代码的凭证用的离职那个人的•包不小心丢了上述意外情况，你能多久恢复，并且保证原样如初？
软件工程化解决的是团队协同，不是个人的问题写个shell脚本只是解决了你个人的问题，它并不没有解决软件团队的问题，充其量只是自嗨，对于团队和组织的可持续发展没有任何价值，甚至是"一坨屎"，后面还要找人擦屁股。如果第二个人依然这样，前赴后继，最后这坨屎会越来越“糟糕”，就变成了”技术债务“。
研发人员的不屑就像当年在汽车厂里手工造车的工人，看不上流水线生产汽车。手工造车可能还被视为“纯手工定制”，软件的“手工造轮子”能比得上吗，能有chatgpt造的好？
（此处已添加书籍卡片，请到今日头条客户端查看）
软件行业的先贤们，一致在试图解决复杂的软件问题，从单体到微服务，从虚拟化到容器化，目的就是要解决“依赖”和“标准化”问题。
而现实中，不管是管理，还是技术可能在都做着“逆解耦/降低依赖”和"反标准化"的事情。
软件工程的平台化解决了企业软件研发活动的可持续化什么是研发活动的可持续化？最近头条热点就是”东方甄选小作文事件“，其实这个就是”标准化“和”个性IP化“的冲突，如果企业的某个活动全靠某个人，他离开就受到了影响，我想这是所有企业不愿看到的。
就如同代码一样，如果某个持续交付的业务具备很多个性化，逻辑异常复杂，到处是if/else, 字符串截取，一会儿从这里拉点依赖，一会儿又和另外其他部分做个奇怪的集成，更别提这里面有多少坑了。
作为基础设施，持续交付流程的个性化，给团队和企业带来的就是不确定和风险，离开他今天就不能上线了，排除错误大半天，不知道哪里莫名其妙多个文件，少个文件。
个人认为，软件工程的平台化，是可以帮助企业实现研发活动可持续化的重要基石，这是软件企业的生产线，生命线，但是往往忽视了这个基石。
image.png
如何实现软件工程的平台化？1.首先必须坚持”标准化“这个原则和方针，一切有违”标准化“的行为统统干掉2.”标准化“不是一夜间就标准化的，识别优先级，考虑性价比3.”标准“是逐步演化的，让子弹多飞一会儿，找到属于自己特色的”标准化“4.团队培养”工程化“意识，特别是基础平台团队要带好头，基础设施决定上层建筑5.工程化需要一个人知识面非常的广，要懂多种语言、多种构建工具、多种部署工具、多种监控方式，深刻理解研发活动，试着寻找这样的人才6.不要盲目自动化，提起自动化好像感觉效率一下子起飞了，殊不知”盲目无脑的自动化“反而会”阻碍标准化“，纯属是自嗨，甚至饮鸩止渴。之前有篇文章《你以为搞个流水线每天跑，团队就在使用CI/CD实践了？》[1]，我就提过类似观点。
References[1] 《你以为搞个流水线每天跑，团队就在使用CI/CD实践了？》: https://www.yuque.com/binowen/blog/fk2h1h0089bt2il8
