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

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

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

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

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

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

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

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

复杂度不会消失只会转移

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

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

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

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

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

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

kiss

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

和业务同构

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

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

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

代码越简单越好

大道至简，no code no bug

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

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

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

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

其实楼主这是很多个问题

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


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

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


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


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

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