案例一
大概在2014年，我在某公司开发一款持续集成方面的软件，叫openCI。它需要集成（请求）Jenkins、GitLab、Sonarqube等第三方软件，又或被这些第三方软件请求（Webhook）。
在我加入团队时，我发现团队成员经常要重启这些第三方软件。每次重启前，还会贴心地在IM群里通知一下，避免影响其他开发人员。但是并不是每个人都能及时留意到IM群里消息，以至于影响到一些需要长运的测试。
是的。每次第三方软件的重启，团队的工作效率都会被中断一次。而且，如果有人不小心“搞坏”这些第三软件系统时，整个团队似乎都无法工作了。
我是一个脾气暴躁的人，无法忍受这种低效。所以，就考虑如何每个人自己搭建一套第三方软件。想到了Vagrant。当时使用Vagrant搭建开发环境的人还非常的少。而无意间，又了解到Docker。就这样，当我需要集成到Jenkins时，我就会使用Docker在本地启动一个Jenkins实例。
这个案例的低效在于开发人员依赖于一个唯一的、脆弱的、不确定性很大的开发环境。
案例二
案例二是我工作几年后，来到一个采用事业部编制方式的大型企业。进入之后，发现当一个需求涉及两个事业部时，计划 server 端由 A 事业部开发，client 端由 B 事业部开发。
在总体上线时间不变的情况下，A 事业部（server端）要求占用90%的开发时间，只留给 B 事业部（client端）10%的时间。他们为此吵了起来。
当时我很好奇，为什么不可以同时开发？大家一起把接口定义出来，然后同时开发不就行了。后来，我才知道原来，client端的开发人员的开发习惯是：一定要server开发好，能真正请求了才能开始开发。而server端的开发员需要开发完成后，才能交给client测试。
案例二的低效在于开发人员之间本来只需要依赖一个协议，却要依赖于整个实现。
P.S. 我常常在团队中推gRPC的原因就是慢慢改掉团队成员之间的依赖实现的问题。
案例三
最近几年，使用Kubernetes的企业越来越多。刚开始使用时，开发人员懵了。因为本地开发环境无法轻松地连接Kubernetes中的Redis、MySQL了。怎么办呢？他们一般是在企业内网找一台server，自己手工搭建Redis、MySQL等。然后本地开发环境连到这个集成开发环境。这其实和案例一是一样的低效。
案例四
现在公有云的使用普遍了，比如Elasticsearch这样产品，更多时候会选择云产品。开发人员经常会找到运维人员：你能不能给我开一个公网，我们本地开发需要连接上这个Elasticsearch。
总结
还有很多案例，我就不一一列举了。这里我只针对这些事实进行讨论，而不是针对个人。
小结一下，这些案例的共性就是：开发人员开发时，一定要“连”上某个开发环境才能进行开发。
我们可以看出开发人员越多，管理熵就越大。管理熵越大，团队效率就越低。
如何破局？这些年，我也观察到，大多数人的解决方案就是找运维再建立一套开发环境。这能解决问题吗？在我个人看来，这就是俄罗斯套娃，一套不够，再建一套。直到维护N套开发环境的成本大于团队的开发成本。另，如果套到极限，不就是人手一套吗。
而我的个人解决方案是：
•改掉开发人员的面向实现的开发习惯，改成面向接口的方式•建立开发人员写单元测试的好习惯
遗憾的是，这个解决方案通常会被pass掉。答案是开发人员能力不足。
面对这样的回答，我思考过很长时间。这是很大的话题，不是本文的内容。
最后，作为个人，只能依靠自己影响力去影响别人了。
欢迎关注 持续交付实践指南 公众号
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/70960.html
