我们系统当前的开发现状：
- 基础架构较简陋，导致系统整体的扩展性可维护性较差，因陋就简是开发资源不充足时的无奈之举。
- 基础业务设计有较多的不合理性，业务模型和业务功能适配度不高，导致代码复杂度增高，可理解性较差，耦合性很高，扩展性较差，开发效率降低，系统的演进基本只能靠代码叠代码的方式，即使做了一定的重构，如果重构的不彻底，仍然会回到混沌的状态。
- 客户一部分定制化功能和通用功能纠缠在一起难解难分，增加整个系统的复杂度，需要正确的支持客户定制化，让系统更简洁更具备可理解性。这一点导致系统可维护性较差，但bug产生率并不高。
- 新人较多，任务也多，老人忙着赶任务，新人也忙着赶任务，老人没有时间带新人，新人全靠个人技术能力和一知半解的业务能力在现有代码上填补叠加。
- 部分代码可读性较差，缺少一些高质量的基础类，界面的操作性友好性、部分业务的前后交互性也都属于因陋就简。
- 做不到精益求精，开发人员只求完成任务，我们基本上也是根据功能性指标来评价其完成度，忽略掉非功能性指标对后续功能演进质量的影响。非功能性指标完成度不高的功能，如果叠加任务排期人员的错觉以及后续开发人员凑合凑合也能用的心态，大概率会造成后续功能演进时开发效率下降和bug产生率增高。
以上导致的后果就是，实现越多新的业务功能，代码耦合性越高，一个简单的改动可能就会引发不少的问题，软件的稳定性和可维护性越差，测试需要的时间越长，软件质量只能努力维持在特定的水准。
解决思路：
- 夯实基础，软件基础质量决定了整体质量的上限，这一点需要靠重构逐步将原有的基础改造和替换。
- 从业务变化承载能力入手，找出混沌度较高的业务优先进行重构，加强复用性和扩展性，确保新的变化既能复用已有逻辑，又有充分的自治能力，减少开发阻抗，提升开发效率。新的业务变化进入系统后需要扭曲附和已有业务，是我们需要重点解决的问题，这会导致开发效率不高而bug率较高。
- 要稳住，不要着急赶任务赶进度，又快又好只是理想状态，软件质量取决于充分的设计和工时，打破时间和质量的平衡点以后，开发速度越快，软件质量衰减的也越快。
- 充分考虑业务模块解耦，充分理解面向对象设计原则，并在程序设计中遵循和实践，在设计上充分考虑可维护性、可扩展性、可测试性等非功能性指标。
- 设计决定了质量的下限，开发人员的实现决定了质量的上限，一个大的功能完成后，开发人员会对整个功能的理解把控有更深层次的升华，更容易复盘出他当前的实现是否有更佳的方式，应该和开发人员充分沟通，尽可能给予其打磨提升软件质量的机会。
- 彻底重构以后，随着业务功能的增加变更，代码仍然会走向腐烂，需要提前进行分析估测，防微杜渐，给予开发人员一定的自由时间进行重新设计和构建，保证软件高质量演进。
- 形成一个完整的需求、设计、测试、实施文档库，并保持及时更新，让知识集中沉淀在文档中而不是分散于团队成员的头脑中。
- 参考敏捷开发模式，但非墨守成规，需应时而变，比如这个版本迭代周期是三周，下个版本迭代周期变为四周，这都未尝不可，因为敏捷开发有一个原则就是拥抱变化，如果一个迭代未能体现出敏捷开发的优点就可以做相应的调整变化。总体来说，敏捷开发并非全是好处，也需要衡量其得失所在。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！