Luna说 | 软件开发思考
0. 前言
最近花了比较多的时间在研究一个工作相关的问题上，在研究问题的过程中，有一些思考和感悟。
1. 发现问题
我在管理团队、观察团队卡点的时候，发现了一个问题。
简单来说，我们公司有很多客户，每个客户有不同的配置文件，我带的团队开发的是一个客户配置和管理的工具，每两周出一个版本。
但我发现，出版本的时候我们并没有同步更新所有客户的配置，也就是说，客户生产环境的版本和工具所生成的配置版本没有同步。
目前的业务模型是，只有当我们做这个客户的需求时，才更新一次配置，但假如好几个月都没有更新，开发团队和测试团队就要花大量的时间来修复跟当前客户需求无关的问题。
2. 这是个问题吗？
既然这个问题是我自己想出来的，那么我就要定义问题，以及「我希望实现的目标是什么」。
我开始找团队里面的程序员讨论这个问题，但首先遇到的瓶颈是——很多人都觉得这不是个问题。
有人说，这个问题可以通过单元测试解决。
我想了想，觉得单元测试无法解决客户配置没有按时更新的问题。
找几个人聊完以后，我逐渐明确了我的目标：我的目标是让每个客户的配置都能和当前工具的版本同步。
3. 如何解决这个问题？
具体要怎么做呢？我给出了方案：
- 开发一个命令行工具，这个命令可以自动生成所有客户的配置；
- 每个程序员都可以在本地跑这个工具，作为提交代码的前置步骤，确保新的改动不会影响到现有客户的配置；
- 生成配置后，把新配置跟生产环境的配置进行比对，如果有改动，就回归测试改动相关的内容，改动测试结束后，把工具版本和客户配置一起部署到生产环境；
也就是说，每次出工具版本，所有客户的配置都会更新，包括客户的网站版本也要一起更新到最新版。
4. 解决这个问题的好处
这个工具能帮助我们减少客户维护的成本，我们可以进行批量更新，而不是每个客户的单独更新，公司也可以用更少的资源支持更多的客户。
另外，程序员在做改动的时候，对自己的代码质量也更有信心，大家更有动力去做大的改动和代码重构，而不是总担心自己的代码会无意中把某个客户搞崩。
PS：有这样的想法，主要是因为我之前学了一些 DevOps 相关的知识，能从另一个角度来看问题。
5. 如何获取支持
为了拿到「buy in」，我首先手动把当前所有客户的配置用最新的工具版本生成了一遍，在生成配置的过程中，我发现了各种各样的奇怪问题，每当发现一个问题，我就会创建一个工作任务，跟团队讨论这个问题，让大家意识到，客户配置跟工具版本不同步真的有很大的隐患。
我大概花了 2-3 周的时间，把所有的客户配置都审核了一遍，然后我把工作任务的依赖关系都加了进去（比如更新 A 客户的配置需要完成任务 1 和 2）。
我做完审核之后，跟测试部门的老大打了招呼，说我们要回归测试所有的客户，确保配置是最新的。测试部门也表示支持。
然后我把这些客户的回归测试 bug 修复任务分配给了我的团队成员，也就是说，每个人都要参与到「把客户配置更新到最新版本」这个目标中。
我跟大家强调，这个任务跟「还掉技术债」是密切相关的，所以不能轻视。如果这次更新做完了以后，我们再把命令行工具跟版本更新周期结合起来，以后大家就不需要考虑客户版本跟工具版本不同步的问题了。
同时，我也积极争取了上级的同意，告诉他们我这次手动更新配置花了很多时间检查代码，发现了各种问题，我们如果要支持更多的客户使用这个工具，就必须把批量更新这件事情做好。
6. 正式开工
有了解决问题的思路 + 团队共识之后，我自己动手开始做这个任务。
刚开始看代码的时候，发现了各种障碍，因为之前我们的工具没有考虑到整合所有客户配置这个需求，所以在设计层面需要讨论方案，看怎么做比较好。
为了快速出原型，我先写了一堆『渣代码』，让命令行能够按照我的需求跑起来，输出我想要的文件目录结构，然后我把需要讨论的一些点都列了出来，找了个单独的时间跟上级开会，确定最终的方案。
7. 一些思考
今年我想主攻技术这块，所以最近看的一些书也跟技术领导力、系统设计相关。
比如《Staff Engineer》这本书提到了：
- Staff Engineer 的主要任务是发现别人无法发现的问题，并且能够帮助整个团队提高技术能力；
- Staff Engineer 需要有高维度的思考能力，要帮助团队避免「local maximum mindset」（就是每个团队按照自己的利益最大化来做事，没有考虑到全局）；
还有《Head First Object Oriented Analysis & Design》这本书，给出了系统设计的三步法：
- Make sure your software does what the customer wants it to do. 解决客户需求（让程序的功能符合客户要求）
- Apply basic OO principles to add flexibility. 通过使用一些基本的面向对象设计原则来增强程序的灵活度。
- Strive for a maintainable, reusable design. 通过使用 design pattern 来增强程序的可维护性和复用性。
8. 结语
现在我工作中一个重要的任务就是「技术决策的沟通」。
比如：程序员 A 告诉我，TA 发现这个程序有 xx 问题。
然后我需要听懂 TA 在说什么（对系统有足够的了解），并且「通过提问来收集信息」。
假如信息不足，我需要鼓励团队成员独立做一些前期调查和研究，并且写出可能的解决方案。
有了问题 + 解决方案后，我要加入自己的思考，跟上级进行沟通，确定最终的方案。
最终方案通过书面形式写出来之后，程序员可以开工。
程序员开工的时候遇到了问题，有些我可以帮忙解决/给出方向，有些则需要继续求助他人。
在多次重复这个流程的实践中，我对系统的了解程度更深了，能帮助解决的问题也更多了，跟上下级的沟通也更加顺畅了。
不过，最有效的学习方式还是自己动手去做一些任务，所以我每周尽量保证自己有一天的时间是不开会的，能集中注意力去写点代码。
大家周末愉快~
Talk to Luna
Support Luna
