怎么避免自己写的代码变成屎山？
source link: https://www.v2ex.com/t/898413
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
 |
singerll 4 小时 2 分钟前 |
 |
salmon5 4 小时 1 分钟前 不做 KPI ，不领工资
|
 |
Kirdoyz 4 小时 1 分钟前 避免不了，多适应，习惯就好
|
 |
yytbob 4 小时 0 分钟前 很难，因为熵总是在增涨。
|
 |
god7d 4 小时 0 分钟前 技术层面
1.架构设计科学，有前瞻性 2.规范自己的代码习惯，写好注释（但不是滥用注释 项目层面 1.有一个不那么心急的老板或者领导 |
1 |
vevlins 3 小时 56 分钟前 1. 做需求硬气些
2. 在演化完全前撤离 |
 |
akakidz 3 小时 56 分钟前 赞同楼上，好的代码依赖于好的项目，如果你们的产品不断的推翻迭代，并且给的工期不够，发展成屎山是必然的
|
 |
fiypig 3 小时 56 分钟前 能跑就行，管他的
|
 |
coderxy 3 小时 54 分钟前 |
 |
lookStupiToForce 3 小时 54 分钟前 没有人可以永远当先知
所有人都是盲人摸象 所有人都只有有限理性 所以唯一的办法就是定期梳理业务，定期总结新方法、新框架，定期重构 |
 |
thulof 3 小时 47 分钟前 没办法，只能多写多看，不停的学习
|
 |
wu67 3 小时 47 分钟前 我同意重构, 但重构不应该是定期的, 应该是持续性的小范围重构.
重构本身不产生新功能、不完成新需求、不带来业务产出, 但却耗费开发人员大量精力, 你觉得项目周期允许你这么折腾? 这玩意只能夹在新功能开发期间不停的小范围进行, 看到有不够好的就及时调整. |
 |
llsquaer 3 小时 44 分钟前 个人觉得 写好注释 就可以避免一大片乱码
注释需要有 为什么有这段代码,适用范围和可能的意外 别嫌啰嗦, 回过头几个月看依然知道这个是干嘛的 |
 |
virus94 3 小时 44 分钟前 哈哈,每当我想避免屎山一样的代码时,项目总会加急的.
|
 |
LaGeNanRen 3 小时 43 分钟前 让你老板多花高于你两倍工资的钱，再招一个架构进来 ：D
|
 |
luzemin 3 小时 38 分钟前 持续重构，别无他法
|
 |
holy_sin 3 小时 36 分钟前 最基本的避免大类 大函数，估计可以消灭 90%的屎山了；而现实是老板觉得这些并没有收益，所以别做了，除非老板觉得有必要。
|
 |
kongkx 3 小时 33 分钟前 via iPhone |
 |
fkdog 3 小时 28 分钟前 哪怕你代码写的再好，屎山终归是我们最终的去路。
|
 |
luhe 3 小时 26 分钟前 跳槽去做新项目
|
 |
ytmsdy 3 小时 25 分钟前 一个类不要超过 300 行，一个文件不要超过 1000 行，按照功能点来规划具体代码，及时合并重复的功能代码。
只要一个函数同时在两个地方以上用到，那就把它单独拿出来。 及时删除不用的代码！ |
 |
xuelu520 3 小时 24 分钟前 避免不了，找其他人 review 代码+定期重构。
|
 |
itechnology 3 小时 24 分钟前 没办法的，因为经常会有工期给的不够或者临时要求改需求（曾经遇到过好几次在上线前一天要改需求的情况，而且有时候你还不能拒绝）的情况，这种情况下就避免不了代码变屎山。
|
 |
yfugibr 3 小时 24 分钟前 写完别看，只要你不知道它是屎山，它就不是
|
 |
FallenTy 3 小时 23 分钟前 无法避免，除非你的业务在写代码的那一刻就不变了
|
 |
abc635073826 3 小时 22 分钟前 不要给别人写代码
|
 |
wanguorui123 3 小时 14 分钟前 架构设计，重构，Review
|
 |
JackMi 3 小时 13 分钟前 公司的一堆屎山，同一个项目，同样的功能，归属于不同的模块，copy 一份过去，就算完成功能，真是日了狗了
|
 |
mmm159357456 3 小时 10 分钟前 屎山的最优解是丢给别人
|
 |
misttyw 3 小时 9 分钟前 开发的复杂度从来不会消失，只能转移，屎山同理
|
 |
rrZ2C 3 小时 8 分钟前 写个 3~4 年 差不多维护不下去的时候 果断跳槽
|
 |
lihengyu 3 小时 4 分钟前 |
 |
xuanbg 2 小时 54 分钟前 归根结底，只有三个办法：
1 、不写代码🐶 2 、做好设计，写出优雅的代码，且不再增加功能 3 、持续重构代码 其实，对于我这样的普通人，也只有第三个办法是可行的。老话说得好，“勤能补拙”。 |
 |
yousabuk 2 小时 50 分钟前 via iPhone 只有天天小重构，两天大重构能解。
今天看昨天写的是屎； 明天看今天写的是屎； 一周后觉得项目本身就是屎得把项目推翻…… |
 |
janxin 2 小时 44 分钟前 |
 |
qiumaoyuan 2 小时 38 分钟前 把这个问题归咎为业务需求的，能不能有点程序员的担当？
|
 |
fakeshadow 2 小时 38 分钟前 写自己经常用的
|
 |
justin2018 2 小时 37 分钟前 写屎山好呀 只有你能维护 其他人无法维护
|
 |
vazo 2 小时 34 分钟前 水平不够写好注释
|
 |
akira 2 小时 32 分钟前 如何避免自己写的代码变成屎山？ 首先你要自己写一大坨屎山
|
 |
estk 2 小时 32 分钟前 via Android 老板需求变化大对代码架构的影响也很大
这是商业规律，很难避免 推特员工被裁，屎山没人懂，不也又招回来了 |
 |
KENNHI 2 小时 31 分钟前 via Android 你今天写得很好，明天写得也不错，大后天一看成 shit 了，没办法的
|
 |
Crackers 2 小时 20 分钟前 1. checkstyle -> review -> refactor -> checkstyle -> review -> refactor -> ...
2. 多看优秀的开源代码，做做 issue 3. 不要“怕”看和改以前的代码 Go for it! (●'◡'●) |
 |
fate 2 小时 14 分钟前 珍惜每一次 CodeReview 和 Debug
|
 |
pkoukk 2 小时 12 分钟前 分层分层还是他娘的分层
虽然复杂度和新人上手难度随着业务唰唰往上涨 你可以说他是臃肿啰嗦，但你不能说它是屎山，他是可维护的，逻辑结构是清晰的 |
 |
chuanqirenwu 1 小时 55 分钟前 人只能利用规律，不能改变规律。
|
 |
kooze 1 小时 32 分钟前 干掉产品经理
|
 |
missdeer 1 小时 18 分钟前 |
 |
Track13 1 小时 15 分钟前 via Android 上午还是完美的，下午产品说这个功能要改，下班就要。
加班还是堆屎山? |
 |
meetyuan 1 小时 10 分钟前 via iPhone 说重构的人，究竟是有多闲？
|
 |
linshenqi 55 分钟前 吾日三省吾身
|
 |
MMMMMMMMMMMMMMMM 51 分钟前 看类型
1 、如果是商业代码，市场和需求永远在变，永远有你想不到的逻辑会从奇怪的地方插进来 2 、如果是兴趣代码，你能一直写下去说明一定有商业价值，然后 goto 1 、 |
 |
blankmiss 48 分钟前 能跑就行了 管什么 shit 不是 shit 的
|
 |
wanganjun 46 分钟前 以我写出两个小屎堆的经验看，除非有人来做整体规划，然后不断重构，不然把代码写成屎是必然的
|
 |
GreatAuk 33 分钟前 设计模式多看看
|
 |
wherewhale 29 分钟前 里的清就行
|
 |
tool2d 14 分钟前 和楼上一样，优先代码分层。
个人觉得按照调用频率，对逻辑代码分支进行分层，也是一个不错的选择。 比如你写了一个简单的调用框架代码，然后需要针对 N 个公司添加不同的逻辑代码。那么保证主框架不变的前提下，对每个公司都额外 HOOK 一部分特殊代码，也是不错的选择之一。 |
 |
liuidetmks 11 分钟前 3 天开需求会，1 天开发，1 天测试上线
很难～ |
 |
leafre 1 分钟前 不要动其他的史山
|
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK