先说下个人”暴论“，肯定是简单好。
为什么这么说，我们先从事物的本质来看。任何学术研究，科普文章，都是试图将一件复杂或困难的事情简单化。复杂的知识点通俗易懂得讲给学生听，你就是一位好老师了。同样复杂的系统功能，用浅显易懂的代码实现，你就是一位好的程序员。
这会儿肯定有同学会问了，“我司有个老员工，整个项目只有他一个人能看懂，能修改，别人根本没办法下手”。 这种已经发生的，不在咱们的讨论范围内。不过我们可以讨论一下，为什么项目会变得这么复杂。大概有以下几种原因
1、可能项目人员参差不齐，可能从需求侧就是有问题的。毕竟很多产品经理，在设计功能的时候，并不会考虑功能以后的扩展性。甚至，是直接借鉴友商的升级，稍加改改。
2、程序员的能力有限，或者说，在写代码的时候，并不会考虑扩展性，功能上线了，能跑就行，后续有问题，直接在代码上打补丁。函数的入参由一两个，变成多个，执行逻辑，变成if，else 各种堆叠。
代码之所以写成这样，是因为从代码层面来说，没有一个即时的负反馈，刚开始没人会意识到，这是一个问题，但是随着产品功能的迭代，慢慢才会被人发现，可能是已经无法维护了，或出现bug无法修复了，拆东墙补西墙。这个时候，可能最初开发功能的程序员都已经跑路了。他们没有意识到“防微杜渐”才是解决这类问题的根本手段。所以为了防范这类问题，市面上有很多软件工程，设计模式，代码规范之类的基础思想（这块咱们后面也可以展开聊一下）。
3、在有限的工期下，为了快速迭代，只能保交付，牺牲一部分质量。但如果一直牺牲质量，慢慢技术债会越积越多，代码腐坏，最终形成不可维护的项目。
但是，”代码的生命力“是一个不可控的伪命题。很多年头很长的项目，最终的归宿是彻底重制，而不是迭代更新。可能从公司层面来说，高层决定换一个产品或者系统。
复杂度不会消失只会转移
说回程序员本身。个人认为优秀的实用型程序员的职业素养之一，就是不断在有限的开发时间和优雅的代码实现之间找到一个平衡点。你可以用各种设计模式，基础思想，但你得找好平衡点。三天后有个功能需紧急交付，你给我整DDD，六边形架构，那人家可能觉得你不靠谱。