再2025年的Qcon大会上，听到一句话：从事软件开发这么多年，“高内聚，低耦合”这个原则，几乎没有变过。而且，几乎所有的开发原则都是围绕着这句话展开的。
我感觉很有道理。所谓“高内聚”，就是把功能相同、相似的代码封装在一起，方便复用、统一管理、统一阅览。所谓“低耦合”，就是把不同的功能拆分成一个个的模块或者分层，并且让不同模块之间通过特定的接口建立交互和依赖，减少耦合度，尽量一个模块的改动，不影响另一个模块的使用，另一个模块只需要依赖本模块暴露的接口即可。
其实，开闭原则，就是高内聚低耦合的提现。对扩展开放，对修改关闭。应用这个原则的设计模式比如 策略模式，模板模式，责任链模式，装饰者模式等。
我觉得，写代码就像穿衣服、言谈举止一样，每个人都有自己的品味。都可以吃得饱，穿得暖。不过有的让人看着舒服，用起来也舒服。有的则不然，难受至极。其实面向对象开发的原则就那么几个：减少重复，增加复用，开闭原则，高内聚低耦合，封装性，以及一些场景的设计模式，比如：工厂，单例，构造者，装饰者，责任链等。 可是为什么有的人还是会写屎山一样的代码呢？
一般来说有下面几种原因：
- 时间紧，任务重。来不及好好思考和设计。 其实这种情况，我遇到类似情况一般应对策略是先实现，然后紧接着进行类、方法的拆分。一般如果功能实现了，做拆分、合并、抽象操作，不会太慢。
- 没有良好的开发意识。这种其实是最难解决的。最难的就是把你脑子里的东西塞给另一个人。除了常规性的codeReview，培训，我没有很好的办法。还有就是在招聘环节做好把关，把风险控制在面试环节。
- 开始系统简单，采用这种架构没有问题。随着系统迭代发展，逐步复杂。而一开始定下的框架也逐渐不适用。有点像清水煮青蛙，最终达到不可收拾，难以维护的状态。尤其是在大型系统、长期更新迭代维护的系统。这种情况，我一般的应对策略就是及时止损。当发现要重复的时候、发现if else超过3个的时候、发现类行数超过500行的时候、发现有任何风险和维护性问题的时候，及时发起技术优化和重构。避免不适用框架越走越远，越来越难以重构。
- 已接手过来就是一个烂摊子。这个时候，一般不建议过早做大规模重构。一般来说：先跟着需求迭代，把需求相关的代码逐步做优化、重构；没有需求的时候，逐步分层、分模块做重构、迁移。小不快跑，细水长流。再不了解系统的情况下，贸然做重构，一是可能很多坑点、背景不清楚，容易采坑。二是你新的设计方案可能也不够符合系统的现状。
要成为一个优秀的开发工程师、架构工程师、专家工程师。不是一蹴而就的。而是通过持续学习、精进的精神，不断探索、优化的行为，严于律己的态度，慢慢积累出来的。多读书，多思考，多实践，多沟通，多分享，多整理，多总结。相信，每个人都可以成为一个优秀的软件工程专家。
