今日一搏：开发效率 Vs. 可维护性
今天一名研发骨干反馈新架构降低了开发效率。这是研发内部组织管理常见的问题，我认为是一件好事。团队最可怕的是一潭死水，表面波澜不惊，暗地耍性使拌。有不同的声音，用理性的方式讨论、沟通、协商、解决，激发了团队成员的思考，让所有人受益。
召集了小组讨论，矛盾的核心是：效率、质量、可维护性之间的平衡。
产品前期为了快速MVP，不太注重代码质量和可维护性。当完成MVP并开始正式产品迭代后，代码质量问题逐渐显现，开发人员疲于解决各种bug，再加上客户需求的不断变化，前期引入的代码自动化工具的灵活性问题显现，开发人员为适配业务，增添了大量业务代码，但缺少必要的规范，导致可维护性变低，进一步影响了代码质量。
进入产品需求稳定期后，需求的真实性和范围经过反复验证而沉淀，且明确了产品的商业策略，系统的架构才能真正稳定下来，如果架构有缺陷，可启动局部重构，核心思想是系统架构是否能承载下一阶段业务特性而不发生大的变动。并且需加强可维护性，持续提升代码质量。没有问题并不是真的没有问题，只是暂时还没发现。墨菲定律在系统开发中可谓是真理一般的存在。技术债是永远还不完的，只可能趋近完成，产品也好项目也好，都有时间和资源的限定。
所以没有最好的策略，只有在一定阶段最优的策略，脱离了当前实际情况谈最优是没有任何意义的。
而研发小伙伴既要坚持也要开放，技术的更新速度超出想象的快，但一些本质和基础的知识，如设计模式，多年未变。
管理好比钟摆，时而左，时而右，没有一刻停摆。真停摆时，钟就坏了。
