在有复杂功能且持续迭代过程中的工程，如何保持架构简洁、代码可读性等？

本人非专业程序员，但是也接过一些前辈写的项目，有的还是残废半成品。

个人的想法是多写文档吧，而且程序员不喜欢写文档，最好把这个作为单独的工作职责派给其他员工。
在有完整文档的情况下，思路应该会清晰很多。
另外，用新的语法糖重构……

想要一直可读性高，怕是还得要重构才能实现吧。

从顶层讲，需要有人写设计架构，写每个 feature 的目的和实现方式，并且需要有人维护文档的实时性。

从底层讲，每一次变更都需要走 PR ，需要有人 review ，PR 需要写明白变更的原因和细节方便追溯。

但实际上上面两个绝大部分项目一个都做不到。

大型项目要控制复杂度，重点还是要做好模块边界划分，不要奢望能够把所有模块的业务都理解清清楚。
做一个需求的时候，要想清楚每个模块在这个需求里承担的职责是什么，然后把职责对应的实现落实到各个模块内，这个过程有时候会需要借助各种设计模式。
提高模块的内聚性的好处在于，当你在阅读一段代码时，你只需要把当前模块的上下文装进脑子里，降低心智负担。对于模块的维护者来说，如果某个外部模块的概念和流程扩散到自己的模块内，当你维护自己模块时，还得带上它的代码，而你对它可能并不熟悉，这种时候就容易改出 BUG 。

持续重构

设计先行，设计必须从长远的目光来看。如果有些业务属性加入注定会对代码造成质量影响的建议 battle 一下，尽量保证代码的优雅。有些业务加进来后，新的设计会对老的设计进行优化，这个时候要记得进行老模块的重构，这样才会保证代码的整洁优雅。如果团队的其他开发进行代码提交的时候一定要 review ，不注意的话 shit 会越加越多

微服务，从业务角度划分领域。但不要搞 DDD 的什么聚合根、仓储的那套玩意，太复杂。越复杂的代码越容易腐化。

最终，腐化的代码必须通过重构进行净化。不然，就会慢慢地积屎成山。

写代码之前多思考，一旦有 bad smell 立刻做调整，不然就会变成一坨💩山

https://www.zhihu.com/question/31049510/answer/115281860

欢迎讨论。

推荐这本书《软件设计》，我正在用微信读书读这本书，很多困惑都能帮你解开
https://book.douban.com/subject/35966115/

- 持续演进的架构。这表示定期就需要重构一部分旧的架构以优雅支持新的功能
- 完善的文档。具有一定复杂度的项目必须要维护足够清晰的开发说明文档，对于核心维护者和新人都是极大利好的
- 充足的人员。显然，仅靠少数几位核心维护者是无法完成上面两个目标的，项目要持续迭代，必须招入充足的维护人员

摘抄一下书中的观点：软件解决的是现实世界的复杂问题，现实世界有多复杂，软件就有可能多复杂。

保持开发人员稳定。不要开发换了一拔又一拔就行了。

@gowk #11 深以为然

企业项目最终的归宿都是 shi 山，因为团队的人员是流动的。

几年前我会觉得过程管理会有效果，现在我只会说重构重构重构

明确告诉你，保持不了，复杂度上升，就表示它简洁不了

时间、质量和成本不能兼得。要保证质量好，时间也合理（不快不慢），因此需要提高一些成本。

1. 招优秀的人。2. 规范的开发流程和制度。3. 给合理的开发时间。

模块化拆分任务提高内聚性让任务并行执行各司其职，代码更清晰。
统一编码规范便于维护和阅读。

不定期重构，清理技术债务。

非必要不更改框架内核。魔改会引入潜在的风险，我见过把一个框架内核改掉限制了只有新增、更改和删除记录才能使用否则无法提交和回滚导致无法正常写出优雅的代码。

减少人员流动，在职越久对项目越熟悉能写出高质量的代码，别整末位淘汰、人才九宫格这些没用的玩意儿害人害己。

优化需求，明确需求的边界。我见过最有印象的是 CRM 做成 CRM+财务系统+中台，边界不清晰的奇葩需求流入系统一定不符合业务需要理应被丢弃和转化。

保持可持续工作节奏，给予恰当合理的开发时间。

关注交付正确的内容而不是尽可能多的交付。

代码规范 + 技术方案评审 + CR

我这边一般是分为模块，保持一个模块只做一件事。更新功能的时候更新相关模块，可以避免主代码渐渐变成一坨的情况。

更新”热插拔“模块比换整个代码好。

> 参考 nginx 实现不同功能(waf 等等)插入对应的 so 库。而不是污染整个代码。