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