这是一个创建于 306 天前的主题，其中的信息可能已经有所发展或是发生改变。
一般一个长期维护的中大型工程，最开始成型仅包含核心功能时，比较容易保持简洁。不过随着功能迭代，为满足各种细节需求，代码中不可避免地会增加很多流程与新概念，代码读起来会不流畅，一旦不控制好，最终很容易就变成屎山。
一个例子是，leveldb 的源码读起来很顺畅，从 leveldb 演化的 rocksdb ，目前已经是个变成庞然大物，虽然大体代码架构也很清晰，但由于支持的功能多、复杂度高，代码中相对会很多噪音，读起来相对不是那么流畅。
复杂度必然会影响可读性，那控制不变成屎山就很重要，大家对这方面有什么经验分享吗？
一个例子是，leveldb 的源码读起来很顺畅，从 leveldb 演化的 rocksdb ，目前已经是个变成庞然大物，虽然大体代码架构也很清晰，但由于支持的功能多、复杂度高，代码中相对会很多噪音，读起来相对不是那么流畅。
复杂度必然会影响可读性，那控制不变成屎山就很重要，大家对这方面有什么经验分享吗？
 |
1
NewYear 306 天前  1
本人非专业程序员，但是也接过一些前辈写的项目，有的还是残废半成品。
个人的想法是多写文档吧，而且程序员不喜欢写文档，最好把这个作为单独的工作职责派给其他员工。 在有完整文档的情况下，思路应该会清晰很多。 另外，用新的语法糖重构…… 想要一直可读性高，怕是还得要重构才能实现吧。 |
 |
2
mooyo 306 天前 1
从顶层讲，需要有人写设计架构，写每个 feature 的目的和实现方式，并且需要有人维护文档的实时性。
从底层讲，每一次变更都需要走 PR ，需要有人 review ，PR 需要写明白变更的原因和细节方便追溯。 但实际上上面两个绝大部分项目一个都做不到。 |
 |
3
Orenoid 306 天前 1
大型项目要控制复杂度，重点还是要做好模块边界划分，不要奢望能够把所有模块的业务都理解清清楚。
做一个需求的时候，要想清楚每个模块在这个需求里承担的职责是什么，然后把职责对应的实现落实到各个模块内，这个过程有时候会需要借助各种设计模式。 提高模块的内聚性的好处在于，当你在阅读一段代码时，你只需要把当前模块的上下文装进脑子里，降低心智负担。对于模块的维护者来说，如果某个外部模块的概念和流程扩散到自己的模块内，当你维护自己模块时，还得带上它的代码，而你对它可能并不熟悉，这种时候就容易改出 BUG 。 |
 |
4
xujinkai 306 天前 via Android 1
持续重构
|
 |
5
ghost024 306 天前
设计先行，设计必须从长远的目光来看。如果有些业务属性加入注定会对代码造成质量影响的建议 battle 一下，尽量保证代码的优雅。有些业务加进来后，新的设计会对老的设计进行优化，这个时候要记得进行老模块的重构，这样才会保证代码的整洁优雅。如果团队的其他开发进行代码提交的时候一定要 review ，不注意的话 shit 会越加越多
|
 |
6
xuanbg 306 天前
微服务，从业务角度划分领域。但不要搞 DDD 的什么聚合根、仓储的那套玩意，太复杂。越复杂的代码越容易腐化。
最终，腐化的代码必须通过重构进行净化。不然，就会慢慢地积屎成山。 |
 |
7
lstz 306 天前 via iPhone
写代码之前多思考，一旦有 bad smell 立刻做调整，不然就会变成一坨💩山
|
 |
8
duron600 306 天前 1
|
 |
9
gowk 306 天前 1
推荐这本书《软件设计》，我正在用微信读书读这本书，很多困惑都能帮你解开
https://book.douban.com/subject/35966115/ |
 |
10
lasuar 306 天前 1
- 持续演进的架构。这表示定期就需要重构一部分旧的架构以优雅支持新的功能
- 完善的文档。具有一定复杂度的项目必须要维护足够清晰的开发说明文档，对于核心维护者和新人都是极大利好的 - 充足的人员。显然，仅靠少数几位核心维护者是无法完成上面两个目标的，项目要持续迭代，必须招入充足的维护人员 |
|
11
gowk 306 天前
摘抄一下书中的观点：软件解决的是现实世界的复杂问题，现实世界有多复杂，软件就有可能多复杂。
|
 |
12
angryfish 306 天前
保持开发人员稳定。不要开发换了一拔又一拔就行了。
|
 |
14
pengtdyd 306 天前
企业项目最终的归宿都是 shi 山，因为团队的人员是流动的。
|
 |
15
Hstar 306 天前
几年前我会觉得过程管理会有效果，现在我只会说重构重构重构
|
 |
16
lloovve 306 天前 via iPhone
明确告诉你，保持不了，复杂度上升，就表示它简洁不了
|
 |
17
taogen 306 天前
时间、质量和成本不能兼得。要保证质量好，时间也合理（不快不慢），因此需要提高一些成本。
1. 招优秀的人。2. 规范的开发流程和制度。3. 给合理的开发时间。 |
 |
18
zhanshen1614 306 天前 2
模块化拆分任务提高内聚性让任务并行执行各司其职，代码更清晰。
统一编码规范便于维护和阅读。 不定期重构，清理技术债务。 非必要不更改框架内核。魔改会引入潜在的风险，我见过把一个框架内核改掉限制了只有新增、更改和删除记录才能使用否则无法提交和回滚导致无法正常写出优雅的代码。 减少人员流动，在职越久对项目越熟悉能写出高质量的代码，别整末位淘汰、人才九宫格这些没用的玩意儿害人害己。 优化需求，明确需求的边界。我见过最有印象的是 CRM 做成 CRM+财务系统+中台，边界不清晰的奇葩需求流入系统一定不符合业务需要理应被丢弃和转化。 保持可持续工作节奏，给予恰当合理的开发时间。 关注交付正确的内容而不是尽可能多的交付。 |
 |
19
Helsing 306 天前 via iPhone
代码规范 + 技术方案评审 + CR
|
 |
20
huahsiung 306 天前 1
我这边一般是分为模块，保持一个模块只做一件事。更新功能的时候更新相关模块，可以避免主代码渐渐变成一坨的情况。
更新”热插拔“模块比换整个代码好。 > 参考 nginx 实现不同功能(waf 等等)插入对应的 so 库。而不是污染整个代码。 |
 |
21
xsen 305 天前 1
需要人搞卫生（维护）
需要人天天清理，不然再底层设计、再多人，早晚都会成屎山 这个与你房子多大、住的人多优秀无关 |
 |
22
lujiaxing 305 天前
没有可能.
只要你们公司存在人员流动, 功能更迭, 代码的腐化就是不可避免的. 任何的规范和制度都只不过是延缓其发生而已, 不可能避免. 很多很多的功能其实开发的时候, 功能描述里说的可能只是一个很简单的需求, 但是实际上开发的时候, 隐藏在里面的逻辑却可能是相当复杂的. 而这种复杂并不是一句两句话能说得清的. 而一旦编写这种复杂业务逻辑代码的人离职, 这段代码很可能就会变得难以维护. 就算是留下交接文档, 这种编写于几年前的复杂业务逻辑代码, 当事人也不一定会记得当时的逻辑细节. 更何况很多情况下人员并不是主动离职而是被辞退/优化掉的, 这种更是连交接的过程都不会有. 这种过程多来几次, 你的代码就基本没法儿看了. |
 |
23
sampeng 305 天前
持续重构。没有第二条路。其他都是扯蛋。如果没有投入持续重构，动不动就是，这个功能稳定了，不能动，代码不能改。吧啦吧啦。。这必定成为一个新的 shit 山
|
 |
24
WashFreshFresh 305 天前
全都自己写
|
Select Language