写程序，到底把代码写复杂一点好，还是写简单一点好？

[tool2d]

一个项目写久了，内部逻辑必然会变复杂。

而大部分码农最讨厌的一件事，就是继承别人的项目进行二次开发。

所以除非继承代码是非常简单的，否则宁可弃用，完全自己从头写。

有时候我在思考，太过复杂的项目，最后是不是没谁愿意接手维护啊？只要能正常运行，保证不挂就行了。

[westoy]

所以行业最佳实践就包括了小 bug won't fix 以及只要程序能跑就不要动它啊

都不要说别人写的， 我自己写的， 业务复杂的， 隔了几个月没碰过的， 我都不会想再碰的

[tool2d]

@westoy 那就很矛盾啊，自己写的代码都不愿意去碰，是不是从开始，就不应该写大而全的项目？

也许应该学 npm ，项目分成无数个小包，小模块，再组合在一起，代码才有生命力。

[msg7086]

应用最佳实践，合理拆分结构，加入适当的测试覆盖，写一些注释。
现在让我拿起我十五年前写的代码都不至于不想去碰。

[edis0n0]

没谁愿意接手维护 公司就不敢随意开除你

[mxT52CRuqR6o5]

我觉得和复杂简单没啥关系，关键要看代码怎么组织的，有些情况下可能就是简单不下来，但组织的好的话，可以把复杂难懂的东西局限在文件、函数内，不让复杂度难懂性扩散，不影响整体的可读可维护性

[aecra1]

复杂度不会消失只会转移

[qiumaoyuan]

你可能搞混了两个概念，业务逻辑的复杂度跟代码结构的复杂度是两回事。

[kop1989smurf]

大而全 ≠ 复杂 ≠ 耦合度爆表

首先，代码腐败是一定的。因为需求的变化，总会突破既有逻辑架构的限制。
团队下代码的结构设计统一就非常重要。优良的代码结构+高可读性，能够最大限度的降低代码腐败的速度。

其次，代码腐败是个“度”的问题，不是“是否”问题。
很多年头很长的项目，最终归宿都是彻底重制。而不是兼容性更新。

最后，“代码的生命力”，其实是一个不可控的伪命题。
因为最终的代码产出受非常多外力的作用。
比如开发的个人能力是否足以胜任、比如人力是否充沛，比如工期是否宽裕、比如需求调研是否明确、比如实现团队在整个项目中的地位（决定了需求的解决是否倾向于更好的技术方案）等等。

[qiumaoyuan]

之前写过点东西，欢迎讨论： https://www.zhihu.com/question/31049510/answer/115281860

[ration]

kiss

[kop1989smurf]

btw:楼主总喜好把一件事的某个片面现象，不加以作证和抽象，就假定为通解进行讨论，这并不是一个良好的习惯。

[tool2d]

@aecra1 “复杂度不会消失只会转移”， 可以采用低纬度转向高维度的方法，把代码细节都隐藏起来。

比如你用汇编写程序，细节就特别多。而用高级语言实现相同的业务，由于细节都被编译器隐藏了，代码就非常简洁明了。

[tool2d]

@kop1989smurf “最后，“代码的生命力”，其实是一个不可控的伪命题。”

你自己写的代码一般都是可控的，所谓不可控都是给自己找的理由。比如工期短，压力大，水平菜。

每到一个 milestore 后，把这几个月的写的代码回顾规整一下，部分重构，总是能焕发青春，让代码生命力更久。

[tool2d]

JSX 能把语境抽象，真实的执行代码远不如看到的如此简单，又长又复杂。

但我发现一个很奇怪的现象，只有极少一部分人，会对自己写的语境进行抽象。

而恰恰只有这种抽象，才能缓解复杂度根本问题。

VUE 那么火，其中一部分原因，也归功于他自创了新语法，缩短了总代码量。代码量才是“复杂”最根本的因素。

[QKgf555H87Fp0cth]

React 建议把东西都放在一起，HTML CSS JS ，这样单元可以非常细小。

[xianyv]

工期紧张的要死的时候,顺着往下写吧,管他复杂还是简单呢,后面能不能看懂都不知道了

[fiypig]

如果从 0 开始开发，我会规范一点，如果二次开发，我就管他的蛇皮代码，就是往下撸就对了

[exonuclease]

大公司都会遇到这种问题 上古代码扔不掉 服务太多依赖关系太复杂什么的 没什么好办法 一点点拆分和重写吧 当初定义的接口比较清晰的话就比较好弄 要是一堆黑魔法那就自求多福。。。

[tianyou666shen]

希望能写的越简单越好 不过有时候能力所限 复杂的业务写出来就会很复杂 木有办法咯

[Leviathann]

和业务同构