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

[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]

和业务同构

[pein]

从软件工程角度：隐藏复杂实现部分，运用设计模式，模块化解耦，逻辑清晰越容易看懂越好
从自身利益角度：能看懂的人越少越好，比如使用 C++模版再混合多种语言，增加不可替代性，否则随便招个新人就把你给优化了

[zyxk]

我总是想尽可能的简单, 总感觉 复杂一点, 程序就会运行很慢的感觉, 你们有这样吗?

[jones2000]

写程序是用来解决问题的， 就算代码再复杂，能解决问题， 给公司或客户带来高额的收益，基本这个团队里的人就很少流动，你想进去都难。

[xqk111]

代码越简单越好

[zjj19950716]

大道至简，no code no bug

[wangtian2020]

我前端能用 Array map filter 扩展运算符 可选链 一条龙一行解决的逻辑绝不拆开写
目标就是削减代码总行数，短小精悍绝不废话
能用箭头函数绝不多写一个“function”

[llsquaer]

写了一段时间的 python 发现项目写大了..能用函数解决的就用函数,别想当然的再去搞一个 class 类..麻烦

[AnroZ]

给公司写的代码是用来（自己或他人）维护的，写简单点为佳。这里说的简单指 code 写得要通俗易读，而非功能简单。可以为一些性能放弃复杂语义写法。

[luvxy]

写复杂点对自己好 写简单对别人好

[shellus]

其实楼主这是很多个问题

1：写程序，到底把代码写复杂一点好，还是写简单一点好？
答案是肯定和绝对的：简单好，类比其他东西你就会明白了，例如科学研究，例如写文章，都是在试图将复杂的和困难的东西简单化，找出其最短路径，那就是成功，例如老师将复杂的道理浅显的讲给学生听，那就是一个好老师，例如将一些玄学的，自古以来没人能解释的清楚的现象用实验的方式重现并归纳其原理，那就是一个好的科学家。同样的，如果你将一个复杂的系统，用浅显易懂的代码实现了，那么你也会是一个好的程序员。


2：一个项目写久了，内部逻辑必然会变复杂。
大多数情况是这样的，为什么会写久了？因为业务逻辑不断变化，增加。所以对应的代码越来越多。
当然也有例外情况，例如 windows 的扫雷游戏，因为它的业务逻辑不会变化，如果你一直写它的代码，那么就不是对代码做加法，而是优化，优化必然会让代码变得更加可读。

3：而大部分码农最讨厌的一件事，就是继承别人的项目进行二次开发。所以除非继承代码是非常简单的，否则宁可弃用，完全自己从头写。
通常情况下是这样的，因为我们都不是神仙，都要吃饭拉屎，我为了吃饭而在公司拉的屎山，现在要你来清理的话，没有人会高兴得起来。
但是换个角度来看，其实大多数人都喜欢继承别人的代码来进行开发，例如什么呢？例如各种编程语言，各种开发框架，继承他们的代码来进行开发，我们往往不知不觉，享受其中，确忽略了这本质上也是在基于他们的代码进行后续开发，为什么就没有感到不开心，反而非常乐意呢？如果想明白了这个问题，我想你的继任者也会很高兴接手你的代码。


4：有时候我在思考，太过复杂的项目，最后是不是没谁愿意接手维护啊？只要能正常运行，保证不挂就行了。
是的，没有人想铲翻屎山，除非你想沾一身屎。
除非你有非常棒的项目管理能力，一边完成新任务，一边规划吃力不讨好容易导致业务故障的优化，但是绝大多数情况，这么优秀的人才，一般不会去接手屎山项目。
大多数普通人，还是继续吃饭和拉屎，写新需求，拿工资，往摇摇欲坠的项目中添加更多难以维护的代码。


引用一段笑话：
"每一个程序员在他的职业生涯中某一天都会突然获得开示，这种开示在通常某一个夜晚悄然降临，有时是以图灵本人托梦的形式出现。这一开示的主要内容如下：程序员是真正理解思维和逻辑真谛的人。非程序员是被蒙蔽的无知者。每一个程序员对于世界上其他程序员有着不可推卸的责任。每一个程序员都必须尽力维护程序员这一高贵种族的延续，并保证世界的命运控制在程序员手中，既不被无知者淹没，也不被机器智能取代。完成这一使命的唯一方式，是保证稳定地出产低质量，难以理解，修改和维护的代码。每一个负责任的程序员，他每一年的产出，必须为另外三个程序员制造一年的就业机会。唯此，程序员一族可生生不息，整个 IT 行业欣欣向荣。图灵大神在冥冥中微笑，他的纸带机将嗒嗒作响，直至永恒。"

[anonymous2351d00]

简单的代码做复杂的事儿最好