然而，大师写软件就不需要，随手写一下，就感觉无法超越。他们对于算法的深度领悟能力远超普通人。以前我一直不太愿意加太多细节，写一段新代码容易，维护一段老代码可就难多了。但是嘛，不加细节，程序就会显得粗燥，缺乏必要的打磨精炼，也很难得到用户的赏识。问题又来了，没有一个好的框架前提下，使劲的堆代码量，一不小心又容易写成屎山，真难。

能跑就行了

你说的细节是什么？

你说的细节是注释的话，那当然得写。写成屎山是水平问题和加不加注释没关系，当然加了注释的写成屎山以后拆起来更方便点。

我和代码，一个能跑就行

遇到屎山挪走了一块，注释没删，落在了下面的山上，百思不得其解，翻 commit 才明白一开始是两个方法长得像，但是内容不同

有些框架定位就是小而美，加了一大堆代码细节后，代码量上去后，总觉得有点格格不入。一是后期没人愿意接手维护，二是和框架本身定位背道而驰。当然我是愿意用工匠精神慢慢打磨，但是不是每一个项目都可以这样处理。

真正的高手可以在屎山里畅游（

工作写屎山是没问题的， 代码并不是写的越优雅越好（除个人项目和外国公司），在国内你不写屎山，每天优化代码，老板看你工作不饱和，分分钟把你开了，为了生活必须写的乱七八糟才能维持自己的工作岗位

我遇到的三种级别最低级是因为技术不行，没有能力长久的独立维护一个项目（比如三五年甚至更长），所以他们的代码都是多人合作写出来的，这就不可避免的导致理念不合、设计考虑不周全、各自理解对不上，出来的代码就没那么漂亮中级的人可以长久的独立维护项目，但是他们的代码往往只有自己看得懂，每次有一些改动的话都是大段大段的删掉重写，外面的人看起来不知这里为何删掉，那里为何加了一点，因为这些改动是整体的，思路只有作者本人看的懂，但是厉害的是偏偏就能跑起来，感觉不可思议，不过普通人是达不到的最厉害的人，不仅可以长久独立维护，而且架构也足够好，改动的时候只需要改很少的地方，而且外人看起来也能看的懂、能试着改。

而且写的屎山别人无法维护或者维护成本高，改的慢。你来改的快，增加了自己的不可替代性，老板求着你来改😀

罗永浩举图片：又不是不能用。

所谓注释，也是一把双刃剑。改了代码不改注释的大有人在。

很大取决于团队内的整体水平，如果个人写的太好其他的人又差不多，实际上反而可能增加代码维护的成本。如果写的太差那么也是显而易见，需要学习其他人的代码。多人维护感觉是无法很好体现个人水平的，相反个人维护也不知道什么是好代码，从其他项目中学习，感觉思想上的提升才能提升整体的代码架构水平

你怎么知道我正在经历相同的事

是的，一定要展示自己的不可替代性😀

只要系統有一定年頭 屎山都是不可避免的

话说看完有突然冒出两个想法，最厉害的人，写的非常不错，大部分程序员都能或者愿意仔细阅读每处的设计，并遵循规范进行扩展，达到可持续维护的项目。但是场景 1. 部分人不知道之前的人是大佬，一看这个 sum 函数，这人搞啥，不就是个加法，传两个参数相加不就完了，怎么下面还有这么多 typeof 检查，各种异常提示，删了，这明显计算总和的表格都是数字（殊不知，后端的屎山可能有时候返回空字符串，有时候返回 null ），结果起初有值的时候，删除后的精简代码，运行正常，若干日后，坏了，删减代码的人早就跑路了，与此同时许多这样的人参与了，于是厉害的人变成屎山，后面又来了个厉害的人，说，这个之前的厉害的人真垃圾，写的什么狗屎代码（虽然可以追溯 git ，但是有时候，一套长期维护的代码，比如管理系统，可能被另一个人复制开一个新项目，这样 git 记录就无法追溯了。）场景 2. 本来就是一坨屎，很厉害的人，废了九牛二虎之力，经过了忙里抽闲的自我牺牲精神，将部分代码优化，整理。但是领导看到，这个非常厉害的人也不行嘛，整天不知道搞啥，跟他一块写屎山的人，效率比他高多了，大概评估起来一样工作量的任务，另一个人，3 填写完了，这个厉害的大佬工资比他高，咋还写了一周，看来不行啊。久而久之，厉害的人发现，自己写的再好，可维护性再强，结果只要他写的功能，其他人（参考场景 1 ）继续开发一段时间，还是成了屎山。既然都是屎山，那就秉持又不是不能用好了。结果，非常厉害的人写的东西最后还是变成屎山，其次，非常厉害的人也变成屎山创造者了。除非团队有非常好的管理 leader ，每个成员觉悟都能相对一致的高度。但是在我看来，后者是非常难得的，大部分成了前者的结局。。。

＃17 是这样的，所以后面两种人，一般是项目的主力开发，某些地方有不可替代的作用，也可以参考开源项目的缔造者等，总之不会是商业项目的基层螺丝钉

用户的赏识？

只需要团队，坚守一个明确的公共编码规则+测试代码，就不会有很多屎山的问题。现实情况是很多人偷懒，临时方案，催命上线以及不屑测试。需求多变其实也不是屎山的主要因素。