把代码写得简单易懂到底好不好？

[nomemo]

最近我喜欢把那些逻辑复杂的大块难懂的代码不再称作垃圾，倒喜欢叫做方法原型或者脑中原始方法的直接映射。也正是因为这样，开始整理那些方法原型，进行拆分与细化。复杂逻辑写得越来越简单易懂。

虽然同事也会说代码漂亮，但就越来越感觉自己容易被人取代

正好，上周有个同事因为家里有事回家一周，他手上的工作就完全停止，因为他大量的代码与功能实现都还是代码原型。

我上周工作了七天，昨天休息了一天，结果别人拿着我的代码就能改。

略微有些想法，跟V友分享一下

感谢各位V友的热情回复，回复中有很多很好的建议，学习了

之前写这个问题的时候自己有几个点没想太清楚，并不是说我不想把代码写好。

后来看到V友的回复 有几个点确实是我一开始想说没说清楚的。


如：
61楼说的，我是优币，不想被劣币驱逐

52楼所说，我也不想成为别人的垫脚石

32楼所说，有这个想法的一个诱因，印象深刻

17楼所说，其实这并不是一个态度问题，我只是想让自己能有口饱饭吃

[adoyle]

今天刚看到这篇文章
https://www.thc.org/root/phun/unmaintain.html

[Loop680]

@PrideChung 任天堂的产品，从GBA到GBASP,再到最后的GBM，东西就是那么个东西，只是体型上越来越小，这不算是客观条件做不到吧，只是不愿意一次发布出最终版而已啊。

[xjtlujoe]

大道至简

[xdeng]

这是什么心态=。=

[PrideChung]

@Loop680 你不想想这么多代产品中间隔了几年，摩尔定律起了多大作用。正常的产品迭代跟主动压箱底不是一个概念。

[shoumu]

你的核心竞争力不仅仅是你的代码

[kaizixyz]

如何写出无法维护的代码 http://www.csdn.net/article/2011-06-03/299247
哈哈啊哈哈~

[clino]

@kaizixyz 我刚看到一篇 http://blog.jobbole.com/80241/
看来最近这种话题挺火热的哈...

[sampeng]

不知道LZ在什么公司。。。你的leader要是做到这个份上，真是讽刺。
手下能把代码写的大家都能接手，都能看懂，都能解bug的能力，十个人里面不出一二。

其实从国内大环境来看，每个人水平真差不多。这不是嘲讽，是显示。你不会，我会。这种绝对的存在是不可能的。我不会，给我个google，马上搞定行不行？我会，你不会，你自行研究也能搞定行不行。真的很少具体的实现体现出一个程序员的能力来。都是干活而已。。

那程序员能力提现在哪？就是lz说的这种代码的掌握能力，态度，工作热情等等软实力。这种东西才是leader最关心的。。。招来的基本水平差不了太多的。但软实力没有，当leader好累的。。。

[tony1016]

必须好啊，同样的回掉函数，swift可以把闭包进化成这样，你说好不好：


进化前
func backwards(s1: String, s2: String) -> Bool {
return s1 > s2
}
var reversed = sort(names, backwards)


进化后
reversed = sort(names, >)

[miniwade514]

必须好。
1. 后来的新人在维护你的这个项目时更轻松，不需要你花很多时间指导。
2. 所以你有更多时间投入到新的项目、更有价值的项目中。

[tabris17]

@tony1016 不好，最烦这种语法糖

[zxhfirefox]

我觉得把接口定得简单易懂就好了，具体实现，可以复杂一些，木哈哈

[nomemo]

@tony1016 我也不喜欢这种过分简写，有点类似于抖机灵。。

[fwolf]

各位，试着把自己放在 leader 的位置上，再来看看这个问题？

[sgissb1]

@nomemo 现实就是现实没办法。不可以取代的人也就那么两种，要么极其牛逼的，要么极其差的。
我看你貌似工作也有很长段时间了，对付这种问题应该不难啊

[nomemo]

@sgissb1

以前公司小，又是在实习，在创业期间没那么多感受。真正开始成为一份职业的时候倒也才几个月，不能在像学生一样玩耍和不在乎咯~

[razrlele]

最近看见一句话，并且也打算被这句话影响一生：

To code to progress.

楼主可看后自行感受。

[tony1016]

其实代码的平均bug数量，和代码行数息息相关，因此，我认为，如果能简化的写法，对于减少bug是有很大帮助的

reversed = sort(names, >)这种写法，你总不会再出翔了吧

[nomemo]

@tony1016 其实为了照顾水平不同的同事，应该还是少用一些语法技巧，减少他们的阅读难度

[kenshin]

代码都是给人（Developer）看的吧，所以肯定要以看懂为目的性，所以才有那么多的编码规约。

- 如果你写的代码只是少数人看的话，只要这几个人达成了默契，那么就算是写成天书也没问题。（即便写的不好，大不了，另外的人，吼一嗓子，然后你可以过去帮他解答...）

- 如果你写的代码需要持久、多人反复的迭代和更新。如果你写成天书，完全有可能会造成，其它人无法读懂，最糟的情况是需要重写；最好的情况也只能不理会这块逻辑，编写另外的代码来维护这块无法看到的代码。（出来混，迟早要还技术债务的...）

一个良性，条理/逻辑清晰、易读的代码，其实是衡量一个人编程水平的标准。（我尤其讨厌，卖弄自己『本事』，把代码写的超复杂的人...）

[JamesRuan]

我虽然码的代码不多，但是有个现象：那些所谓的代码原型，如果一个星期没碰，我自己看懂都很难了。

所以，哪怕是为了自己，也要不断地把代码整理成最优美的样子。