这是一个创建于 402 天前的主题，其中的信息可能已经有所发展或是发生改变。
然而，大师写软件就不需要，随手写一下，就感觉无法超越。他们对于算法的深度领悟能力远超普通人。
以前我一直不太愿意加太多细节，写一段新代码容易，维护一段老代码可就难多了。
但是嘛，不加细节，程序就会显得粗燥，缺乏必要的打磨精炼，也很难得到用户的赏识。
问题又来了，没有一个好的框架前提下，使劲的堆代码量，一不小心又容易写成屎山，真难。
以前我一直不太愿意加太多细节，写一段新代码容易，维护一段老代码可就难多了。
但是嘛，不加细节，程序就会显得粗燥，缺乏必要的打磨精炼，也很难得到用户的赏识。
问题又来了，没有一个好的框架前提下，使劲的堆代码量，一不小心又容易写成屎山，真难。
 |
1
SomeBodsy 2023-11-20 09:33:21 +08:00
能跑就行了
|
 |
2
zhazi 2023-11-20 09:35:57 +08:00  2
你说的细节是什么？
|
 |
3
HojiOShi 2023-11-20 09:43:29 +08:00
你说的细节是注释的话，那当然得写。写成屎山是水平问题和加不加注释没关系，当然加了注释的写成屎山以后拆起来更方便点。
|
 |
4
cz5424 2023-11-20 09:44:56 +08:00 via iPhone
我和代码，一个能跑就行
|
 |
5
winterbells 2023-11-20 09:48:17 +08:00 1
@HojiOShi 遇到屎山挪走了一块，注释没删，落在了下面的山上，百思不得其解，翻 commit 才明白一开始是两个方法长得像，但是内容不同
|
 |
6
tool2d OP @HojiOShi 有些框架定位就是小而美，加了一大堆代码细节后，代码量上去后，总觉得有点格格不入。
一是后期没人愿意接手维护，二是和框架本身定位背道而驰。 当然我是愿意用工匠精神慢慢打磨，但是不是每一个项目都可以这样处理。 |
 |
7
hamkido2000 2023-11-20 09:51:41 +08:00
真正的高手可以在屎山里畅游（
|
 |
8
HongXinss 2023-11-20 09:52:08 +08:00 3
工作写屎山是没问题的， 代码并不是写的越优雅越好（除个人项目和外国公司），在国内你不写屎山，每天优化代码，老板看你工作不饱和，分分钟把你开了，为了生活必须写的乱七八糟才能维持自己的工作岗位
|
 |
9
janus77 2023-11-20 10:13:40 +08:00
我遇到的三种级别
最低级是因为技术不行，没有能力长久的独立维护一个项目（比如三五年甚至更长），所以他们的代码都是多人合作写出来的，这就不可避免的导致理念不合、设计考虑不周全、各自理解对不上，出来的代码就没那么漂亮 中级的人可以长久的独立维护项目，但是他们的代码往往只有自己看得懂，每次有一些改动的话都是大段大段的删掉重写，外面的人看起来不知这里为何删掉，那里为何加了一点，因为这些改动是整体的，思路只有作者本人看的懂，但是厉害的是偏偏就能跑起来，感觉不可思议，不过普通人是达不到的 最厉害的人，不仅可以长久独立维护，而且架构也足够好，改动的时候只需要改很少的地方，而且外人看起来也能看的懂、能试着改。 |
 |
11
dif 2023-11-20 10:30:11 +08:00
罗永浩举图片：又不是不能用。
|
 |
13
blankqwq 2023-11-20 10:36:25 +08:00
很大取决于团队内的整体水平，如果个人写的太好其他的人又差不多，实际上反而可能增加代码维护的成本。
如果写的太差那么也是显而易见，需要学习其他人的代码。 多人维护感觉是无法很好体现个人水平的，相反个人维护也不知道什么是好代码，从其他项目中学习，感觉思想上的提升才能提升整体的代码架构水平 |
 |
14
MRG0 2023-11-20 11:04:09 +08:00
你怎么知道我正在经历相同的事
|
 |
16
roundgis 2023-11-20 11:49:15 +08:00 via Android
只要系統有一定年頭 屎山都是不可避免的
|
 |
17
kingterrors 2023-11-20 14:43:26 +08:00 1
@janus77
话说看完有突然冒出两个想法， 最厉害的人，写的非常不错，大部分程序员都能或者愿意仔细阅读每处的设计，并遵循规范进行扩展，达到可持续维护的项目。 但是 场景 1. 部分人不知道之前的人是大佬，一看这个 sum 函数，这人搞啥，不就是个加法，传两个参数相加不就完了，怎么下面还有这么多 typeof 检查，各种异常提示，删了，这明显计算总和的表格都是数字（殊不知，后端的屎山可能有时候返回空字符串，有时候返回 null ），结果起初有值的时候，删除后的精简代码，运行正常，若干日后，坏了，删减代码的人早就跑路了，与此同时许多这样的人参与了，于是厉害的人变成屎山，后面又来了个厉害的人，说，这个之前的厉害的人真垃圾，写的什么狗屎代码（虽然可以追溯 git ，但是有时候，一套长期维护的代码，比如管理系统，可能被另一个人复制开一个新项目，这样 git 记录就无法追溯了。） 场景 2. 本来就是一坨屎，很厉害的人，废了九牛二虎之力，经过了忙里抽闲的自我牺牲精神，将部分代码优化，整理。但是领导看到，这个非常厉害的人也不行嘛，整天不知道搞啥，跟他一块写屎山的人，效率比他高多了，大概评估起来一样工作量的任务，另一个人，3 填写完了，这个厉害的大佬工资比他高，咋还写了一周，看来不行啊。久而久之，厉害的人发现，自己写的再好，可维护性再强，结果只要他写的功能，其他人（参考场景 1 ）继续开发一段时间，还是成了屎山。既然都是屎山，那就秉持又不是不能用好了。 结果，非常厉害的人写的东西最后还是变成屎山，其次，非常厉害的人也变成屎山创造者了。 除非团队有非常好的管理 leader ，每个成员觉悟都能相对一致的高度。但是在我看来，后者是非常难得的，大部分成了前者的结局。。。  |
|
18
janus77 2023-11-20 15:41:17 +08:00
@kingterrors #17 是这样的，所以后面两种人，一般是项目的主力开发，某些地方有不可替代的作用，也可以参考开源项目的缔造者等，总之不会是商业项目的基层螺丝钉
|
 |
19
duck2u 2023-11-20 15:53:29 +08:00
用户的赏识？
|
 |
20
Acoolda 2023-11-21 10:03:34 +08:00
只需要团队，坚守一个明确的公共编码规则+测试代码，就不会有很多屎山的问题。现实情况是很多人偷懒，临时方案，催命上线以及不屑测试。需求多变其实也不是屎山的主要因素。
|
 |
22
GeekGao 2023-11-21 13:50:11 +08:00
每写下一行代码都是在熵增。所以，代码多代码必然结果就是屎山
|
|
23
tool2d OP |
|
25
tool2d OP |
Select Language