1
westoy 2022-10-24 12:53:25 +08:00
所以行业最佳实践就包括了小 bug won't fix 以及只要程序能跑就不要动它啊
都不要说别人写的, 我自己写的, 业务复杂的, 隔了几个月没碰过的, 我都不会想再碰的 |
2
tool2d OP |
3
msg7086 2022-10-24 13:00:51 +08:00
应用最佳实践,合理拆分结构,加入适当的测试覆盖,写一些注释。
现在让我拿起我十五年前写的代码都不至于不想去碰。 |
4
edis0n0 2022-10-24 13:04:13 +08:00
没谁愿意接手维护 公司就不敢随意开除你
|
5
mxT52CRuqR6o5 2022-10-24 13:04:22 +08:00 2
我觉得和复杂简单没啥关系,关键要看代码怎么组织的,有些情况下可能就是简单不下来,但组织的好的话,可以把复杂难懂的东西局限在文件、函数内,不让复杂度难懂性扩散,不影响整体的可读可维护性
|
6
aecra1 2022-10-24 13:07:44 +08:00 via Android
复杂度不会消失只会转移
|
7
qiumaoyuan 2022-10-24 13:08:22 +08:00
你可能搞混了两个概念,业务逻辑的复杂度跟代码结构的复杂度是两回事。
|
8
kop1989smurf 2022-10-24 13:10:11 +08:00 3
大而全 ≠ 复杂 ≠ 耦合度爆表
首先,代码腐败是一定的。因为需求的变化,总会突破既有逻辑架构的限制。 团队下代码的结构设计统一就非常重要。优良的代码结构+高可读性,能够最大限度的降低代码腐败的速度。 其次,代码腐败是个“度”的问题,不是“是否”问题。 很多年头很长的项目,最终归宿都是彻底重制。而不是兼容性更新。 最后,“代码的生命力”,其实是一个不可控的伪命题。 因为最终的代码产出受非常多外力的作用。 比如开发的个人能力是否足以胜任、比如人力是否充沛,比如工期是否宽裕、比如需求调研是否明确、比如实现团队在整个项目中的地位(决定了需求的解决是否倾向于更好的技术方案)等等。 |
9
qiumaoyuan 2022-10-24 13:11:02 +08:00 1
之前写过点东西,欢迎讨论: https://www.zhihu.com/question/31049510/answer/115281860
|
10
ration 2022-10-24 13:11:26 +08:00 via Android
kiss
|
11
kop1989smurf 2022-10-24 13:12:13 +08:00
btw:楼主总喜好把一件事的某个片面现象,不加以作证和抽象,就假定为通解进行讨论,这并不是一个良好的习惯。
|
12
tool2d OP @aecra1 “复杂度不会消失只会转移”, 可以采用低纬度转向高维度的方法,把代码细节都隐藏起来。
比如你用汇编写程序,细节就特别多。而用高级语言实现相同的业务,由于细节都被编译器隐藏了,代码就非常简洁明了。 |
13
tool2d OP @kop1989smurf “最后,“代码的生命力”,其实是一个不可控的伪命题。”
你自己写的代码一般都是可控的,所谓不可控都是给自己找的理由。比如工期短,压力大,水平菜。 每到一个 milestore 后,把这几个月的写的代码回顾规整一下,部分重构,总是能焕发青春,让代码生命力更久。 |
14
tool2d OP JSX 能把语境抽象,真实的执行代码远不如看到的如此简单,又长又复杂。
但我发现一个很奇怪的现象,只有极少一部分人,会对自己写的语境进行抽象。 而恰恰只有这种抽象,才能缓解复杂度根本问题。 VUE 那么火,其中一部分原因,也归功于他自创了新语法,缩短了总代码量。代码量才是“复杂”最根本的因素。 |
15
likunyan 2022-10-24 14:06:41 +08:00
React 建议把东西都放在一起,HTML CSS JS ,这样单元可以非常细小。
|
16
xianyv 2022-10-24 14:12:57 +08:00
工期紧张的要死的时候,顺着往下写吧,管他复杂还是简单呢,后面能不能看懂都不知道了
|
17
fiypig 2022-10-24 14:15:40 +08:00
如果从 0 开始开发,我会规范一点,如果二次开发,我就管他的蛇皮代码,就是往下撸就对了
|
18
exonuclease 2022-10-24 14:41:54 +08:00
大公司都会遇到这种问题 上古代码扔不掉 服务太多依赖关系太复杂什么的 没什么好办法 一点点拆分和重写吧 当初定义的接口比较清晰的话就比较好弄 要是一堆黑魔法那就自求多福。。。
|
19
tianyou666shen 2022-10-24 14:50:06 +08:00
希望能写的越简单越好 不过有时候能力所限 复杂的业务写出来就会很复杂 木有办法咯
|
20
Leviathann 2022-10-24 15:21:58 +08:00
和业务同构
|
21
pein 2022-10-24 15:39:18 +08:00
从软件工程角度:隐藏复杂实现部分,运用设计模式,模块化解耦,逻辑清晰越容易看懂越好
从自身利益角度:能看懂的人越少越好,比如使用 C++模版再混合多种语言,增加不可替代性,否则随便招个新人就把你给优化了 |
22
zyxk 2022-10-24 23:20:32 +08:00
我总是想尽可能的简单, 总感觉 复杂一点, 程序就会运行很慢的感觉, 你们有这样吗?
|
23
jones2000 2022-10-25 01:34:17 +08:00
写程序是用来解决问题的, 就算代码再复杂,能解决问题, 给公司或客户带来高额的收益,基本这个团队里的人就很少流动,你想进去都难。
|
24
xqk111 2022-10-25 08:58:29 +08:00
代码越简单越好
|
25
zjj19950716 2022-10-25 10:04:03 +08:00
大道至简,no code no bug
|
26
wangtian2020 2022-10-25 11:19:36 +08:00
我前端能用 Array map filter 扩展运算符 可选链 一条龙一行解决的逻辑绝不拆开写
目标就是削减代码总行数,短小精悍绝不废话 能用箭头函数绝不多写一个“function” |
27
llsquaer 2022-10-25 13:17:03 +08:00
写了一段时间的 python 发现项目写大了..能用函数解决的就用函数,别想当然的再去搞一个 class 类..麻烦
|
28
AnroZ 2022-10-25 13:29:48 +08:00
给公司写的代码是用来(自己或他人)维护的,写简单点为佳。这里说的简单指 code 写得要通俗易读,而非功能简单。可以为一些性能放弃复杂语义写法。
|
29
luvxy 2022-10-25 14:01:28 +08:00
写复杂点对自己好 写简单对别人好
|
30
shellus 2022-10-25 15:12:30 +08:00 1
其实楼主这是很多个问题
1:写程序,到底把代码写复杂一点好,还是写简单一点好? 答案是肯定和绝对的:简单好,类比其他东西你就会明白了,例如科学研究,例如写文章,都是在试图将复杂的和困难的东西简单化,找出其最短路径,那就是成功,例如老师将复杂的道理浅显的讲给学生听,那就是一个好老师,例如将一些玄学的,自古以来没人能解释的清楚的现象用实验的方式重现并归纳其原理,那就是一个好的科学家。同样的,如果你将一个复杂的系统,用浅显易懂的代码实现了,那么你也会是一个好的程序员。 2:一个项目写久了,内部逻辑必然会变复杂。 大多数情况是这样的,为什么会写久了?因为业务逻辑不断变化,增加。所以对应的代码越来越多。 当然也有例外情况,例如 windows 的扫雷游戏,因为它的业务逻辑不会变化,如果你一直写它的代码,那么就不是对代码做加法,而是优化,优化必然会让代码变得更加可读。 3:而大部分码农最讨厌的一件事,就是继承别人的项目进行二次开发。所以除非继承代码是非常简单的,否则宁可弃用,完全自己从头写。 通常情况下是这样的,因为我们都不是神仙,都要吃饭拉屎,我为了吃饭而在公司拉的屎山,现在要你来清理的话,没有人会高兴得起来。 但是换个角度来看,其实大多数人都喜欢继承别人的代码来进行开发,例如什么呢?例如各种编程语言,各种开发框架,继承他们的代码来进行开发,我们往往不知不觉,享受其中,确忽略了这本质上也是在基于他们的代码进行后续开发,为什么就没有感到不开心,反而非常乐意呢?如果想明白了这个问题,我想你的继任者也会很高兴接手你的代码。 4:有时候我在思考,太过复杂的项目,最后是不是没谁愿意接手维护啊?只要能正常运行,保证不挂就行了。 是的,没有人想铲翻屎山,除非你想沾一身屎。 除非你有非常棒的项目管理能力,一边完成新任务,一边规划吃力不讨好容易导致业务故障的优化,但是绝大多数情况,这么优秀的人才,一般不会去接手屎山项目。 大多数普通人,还是继续吃饭和拉屎,写新需求,拿工资,往摇摇欲坠的项目中添加更多难以维护的代码。 引用一段笑话: "每一个程序员在他的职业生涯中某一天都会突然获得开示,这种开示在通常某一个夜晚悄然降临,有时是以图灵本人托梦的形式出现。这一开示的主要内容如下:程序员是真正理解思维和逻辑真谛的人。非程序员是被蒙蔽的无知者。每一个程序员对于世界上其他程序员有着不可推卸的责任。每一个程序员都必须尽力维护程序员这一高贵种族的延续,并保证世界的命运控制在程序员手中,既不被无知者淹没,也不被机器智能取代。完成这一使命的唯一方式,是保证稳定地出产低质量,难以理解,修改和维护的代码。每一个负责任的程序员,他每一年的产出,必须为另外三个程序员制造一年的就业机会。唯此,程序员一族可生生不息,整个 IT 行业欣欣向荣。图灵大神在冥冥中微笑,他的纸带机将嗒嗒作响,直至永恒。" |
31
anonymous2351d00 2022-10-26 17:20:41 +08:00
简单的代码做复杂的事儿最好
|