怎么避免自己写的代码变成屎山？

代码

变成

避免

屎

118 条回复 • 2022-11-30 10:30:32 +08:00

1 2

❮

❯

1

singerll

2022-11-28 10:12:14 +08:00

8

不写代码

2

salmon5

2022-11-28 10:12:44 +08:00

1

不做 KPI ，不领工资

3

Kirdoyz

2022-11-28 10:13:22 +08:00

避免不了，多适应，习惯就好

4

yytbob

2022-11-28 10:13:40 +08:00

很难，因为熵总是在增涨。

5

god7d

2022-11-28 10:14:28 +08:00

3

技术层面

1.架构设计科学，有前瞻性

2.规范自己的代码习惯，写好注释（但不是滥用注释

项目层面

1.有一个不那么心急的老板或者领导

6

vevlins

2022-11-28 10:17:34 +08:00

1. 做需求硬气些
2. 在演化完全前撤离

7

akakidz

2022-11-28 10:17:35 +08:00

1

赞同楼上，好的代码依赖于好的项目，如果你们的产品不断的推翻迭代，并且给的工期不够，发展成屎山是必然的

8

fiypig

2022-11-28 10:17:52 +08:00

能跑就行，管他的

9

raysonx

2022-11-28 10:18:00 +08:00

3

https://github.com/kelseyhightower/nocode

10

coderxy

2022-11-28 10:20:10 +08:00

定期重构

11

lookStupiToForce

2022-11-28 10:20:13 +08:00

7

没有人可以永远当先知
所有人都是盲人摸象
所有人都只有有限理性

所以唯一的办法就是定期梳理业务，定期总结新方法、新框架，定期重构

12

leonshaw

2022-11-28 10:25:44 +08:00

@lookStupiToForce 只开新坑，定期跑路

13

thulof

2022-11-28 10:27:05 +08:00

没办法，只能多写多看，不停的学习

14

wu67

2022-11-28 10:27:19 +08:00

1

我同意重构, 但重构不应该是定期的, 应该是持续性的小范围重构.

重构本身不产生新功能、不完成新需求、不带来业务产出, 但却耗费开发人员大量精力, 你觉得项目周期允许你这么折腾?
这玩意只能夹在新功能开发期间不停的小范围进行, 看到有不够好的就及时调整.

15

llsquaer

2022-11-28 10:30:11 +08:00

个人觉得写好注释就可以避免一大片乱码

注释需要有为什么有这段代码,适用范围和可能的意外

别嫌啰嗦, 回过头几个月看依然知道这个是干嘛的

16

virus94

2022-11-28 10:30:27 +08:00

哈哈,每当我想避免屎山一样的代码时,项目总会加急的.

17

LaGeNanRen

2022-11-28 10:30:41 +08:00

让你老板多花高于你两倍工资的钱，再招一个架构进来：D

18

luzemin

2022-11-28 10:36:02 +08:00

持续重构，别无他法

19

holy_sin

2022-11-28 10:38:15 +08:00

最基本的避免大类大函数，估计可以消灭 90%的屎山了；而现实是老板觉得这些并没有收益，所以别做了，除非老板觉得有必要。

20

kongkx

2022-11-28 10:41:14 +08:00 via iPhone

轮回

21

fkdog

2022-11-28 10:46:31 +08:00

哪怕你代码写的再好，屎山终归是我们最终的去路。

22

luhe

2022-11-28 10:48:04 +08:00

跳槽去做新项目

23

ytmsdy

2022-11-28 10:49:20 +08:00

一个类不要超过 300 行，一个文件不要超过 1000 行，按照功能点来规划具体代码，及时合并重复的功能代码。
只要一个函数同时在两个地方以上用到，那就把它单独拿出来。
及时删除不用的代码！

24

xuelu520

2022-11-28 10:50:01 +08:00

避免不了，找其他人 review 代码+定期重构。

25

itechnology

2022-11-28 10:50:08 +08:00

没办法的，因为经常会有工期给的不够或者临时要求改需求（曾经遇到过好几次在上线前一天要改需求的情况，而且有时候你还不能拒绝）的情况，这种情况下就避免不了代码变屎山。

26

yfugibr

2022-11-28 10:50:10 +08:00

写完别看，只要你不知道它是屎山，它就不是

27

FallenTy

2022-11-28 10:51:01 +08:00

无法避免，除非你的业务在写代码的那一刻就不变了

28

abc635073826

2022-11-28 10:52:10 +08:00

不要给别人写代码

29

wanguorui123

2022-11-28 11:00:26 +08:00

架构设计，重构，Review

30

JackMi

2022-11-28 11:00:57 +08:00

公司的一堆屎山，同一个项目，同样的功能，归属于不同的模块，copy 一份过去，就算完成功能，真是日了狗了

31

qiumaoyuan

2022-11-28 11:02:19 +08:00

https://www.zhihu.com/question/31049510/answer/115281860

一句话就是：防微杜渐。

然后，你要有防微杜渐的能力。

32

mmm159357456

2022-11-28 11:04:22 +08:00

屎山的最优解是丢给别人

33

misttyw

2022-11-28 11:04:44 +08:00

开发的复杂度从来不会消失，只能转移，屎山同理

34

rrZ2C

2022-11-28 11:05:58 +08:00

写个 3~4 年差不多维护不下去的时候果断跳槽

35

lihengyu

2022-11-28 11:10:15 +08:00

持续重构

36

xuanbg

2022-11-28 11:19:43 +08:00

归根结底，只有三个办法：
1 、不写代码🐶
2 、做好设计，写出优雅的代码，且不再增加功能
3 、持续重构代码

其实，对于我这样的普通人，也只有第三个办法是可行的。老话说得好，“勤能补拙”。

37

yousabuk

2022-11-28 11:24:24 +08:00 via iPhone

只有天天小重构，两天大重构能解。

今天看昨天写的是屎；
明天看今天写的是屎；

一周后觉得项目本身就是屎得把项目推翻……

38

janxin

2022-11-28 11:30:21 +08:00

不写代码

39

qiumaoyuan

2022-11-28 11:35:32 +08:00

把这个问题归咎为业务需求的，能不能有点程序员的担当？

40

fakeshadow

2022-11-28 11:35:44 +08:00

写自己经常用的

41

justin2018

2022-11-28 11:37:28 +08:00

写屎山好呀只有你能维护其他人无法维护

42

vazo

2022-11-28 11:40:00 +08:00

水平不够写好注释

43

akira

2022-11-28 11:41:55 +08:00

如何避免自己写的代码变成屎山？首先你要自己写一大坨屎山

44

estk

2022-11-28 11:42:20 +08:00 via Android

老板需求变化大对代码架构的影响也很大
这是商业规律，很难避免
推特员工被裁，屎山没人懂，不也又招回来了

45

KENNHI

2022-11-28 11:42:36 +08:00 via Android

你今天写得很好，明天写得也不错，大后天一看成 shit 了，没办法的

46

Crackers

2022-11-28 11:53:33 +08:00

1. checkstyle -> review -> refactor -> checkstyle -> review -> refactor -> ...
2. 多看优秀的开源代码，做做 issue
3. 不要“怕”看和改以前的代码
Go for it! (●'◡'●)

47

fate

2022-11-28 12:00:13 +08:00

珍惜每一次 CodeReview 和 Debug

48

pkoukk

2022-11-28 12:01:33 +08:00

分层分层还是他娘的分层
虽然复杂度和新人上手难度随着业务唰唰往上涨
你可以说他是臃肿啰嗦，但你不能说它是屎山，他是可维护的，逻辑结构是清晰的

49

chuanqirenwu

2022-11-28 12:19:04 +08:00

人只能利用规律，不能改变规律。

50

kooze

2022-11-28 12:42:31 +08:00

干掉产品经理

51

missdeer

2022-11-28 12:56:26 +08:00

经常重构

52

Track13

2022-11-28 12:59:29 +08:00 via Android

1

上午还是完美的，下午产品说这个功能要改，下班就要。
加班还是堆屎山?

53

meetyuan

2022-11-28 13:04:01 +08:00 via iPhone

说重构的人，究竟是有多闲？

54

linshenqi

2022-11-28 13:18:33 +08:00

吾日三省吾身

55

MMMMMMMMMMMMMMMM

2022-11-28 13:22:42 +08:00

看类型

1 、如果是商业代码，市场和需求永远在变，永远有你想不到的逻辑会从奇怪的地方插进来

2 、如果是兴趣代码，你能一直写下去说明一定有商业价值，然后 goto 1 、

56

blankmiss

2022-11-28 13:25:53 +08:00

能跑就行了管什么 shit 不是 shit 的

57

wanganjun

2022-11-28 13:28:21 +08:00

以我写出两个小屎堆的经验看，除非有人来做整体规划，然后不断重构，不然把代码写成屎是必然的

58

GreatAuk

2022-11-28 13:41:27 +08:00

设计模式多看看

59

wherewhale

2022-11-28 13:44:36 +08:00

里的清就行

60

tool2d

2022-11-28 14:00:04 +08:00

和楼上一样，优先代码分层。

个人觉得按照调用频率，对逻辑代码分支进行分层，也是一个不错的选择。

比如你写了一个简单的调用框架代码，然后需要针对 N 个公司添加不同的逻辑代码。那么保证主框架不变的前提下，对每个公司都额外 HOOK 一部分特殊代码，也是不错的选择之一。

61

liuidetmks

2022-11-28 14:03:09 +08:00

3 天开需求会，1 天开发，1 天测试上线
很难～

62

leafre

2022-11-28 14:13:12 +08:00

不要动其他的史山

63

Daniel17

2022-11-28 14:16:58 +08:00

一直重构

64

mawenjian

2022-11-28 14:19:12 +08:00

领域驱动设计，面向对象编程，多用设计模式，合理划分类间职责。

根据个人经验，使用面向过程写的代码，最后变成屎山基本是必然的。

65

anonymous2351d00

2022-11-28 14:26:47 +08:00

重构

66

yeyu123

2022-11-28 14:43:48 +08:00

一直重构

67

lilyok1234

2022-11-28 14:43:50 +08:00

写这么好干嘛，工作这么多年发现写的好的 bug 少，绩效差。写的烂 bug 多，绩效好。又不是不能用

68

eason1874

2022-11-28 14:47:02 +08:00

变成屎山是必然的，就像你不断往家里塞东西，东西多到超出原先的承载能力了，原先再整齐的房子也会变得很乱，除非重构，也就是每隔一段时间换一个房子，重新收纳

69

yxzblue

2022-11-28 15:18:02 +08:00

为什么有人可以在屎一样混乱的几千行代码里加功能？不重构能驾驭屎山吗？
https://www.zhihu.com/question/497344549/answer/2215116962

70

daokedao

2022-11-28 15:20:05 +08:00

高手都是拉完屎就换地方，去开辟新的项目（屎山）

71

ruoxie

2022-11-28 15:26:29 +08:00

分层

72

xumng123

2022-11-28 15:28:55 +08:00 via iPhone

避免不了

73

aliveyang

2022-11-28 16:04:24 +08:00

只要不再屎上堆屎，屎永远都不会堆成山

74

fournoas

2022-11-28 16:12:54 +08:00

只要坑挖得深，山就堆不起来

75

1vonzhang

2022-11-28 16:35:49 +08:00

3

我读书的时候也思考过这个问题，那时候太 naive ，觉得水平够高就可以不写屎山了。现在工作了几年，有了一些新的心得：

0. 核心是要认识到，你以为的需求，你设想的发展方向，你预先做的架构和设计，都会不可避免的朝着你意想不到的方向发展。特别是会发展好多年的软件。

1. 高内聚，低耦合是避免屎山的真理。永远把功能最小模块化，并设计出好的 API ，是面对改变得心应手的关键。具体怎么分割、怎么设计 API ，是需要一定功底的。

2. 像楼上很多朋友说的，重构不可避免，不要害怕重构，也不要为了重构而重构。过度重构和过度设计是一样的，都是在把路提前铺好，导致以后修路只能缝缝补补。我做的最多的重构，是在进行稍微大一点的改动之前，把一个部分拆成好几个模块，然后对每个小部分独立的进行修改。

3. 模块化的东西不要考虑 context 。某一个部分可能只是为了某一个应用场景写的，但是设计的时候要把模块独立考虑，而不是从外部看这个模块会被怎么用到。这样一来可以保证低耦合，二来可以在之后有不同使用场景时，不需要各种补丁代码。

76

zjj19950716

2022-11-28 16:54:38 +08:00

主动或者被动得吃了太多泻药，不搞屎山难不成大活人还要被屎憋死吗？所以正视屎山，屎崩的时候没有一坨翔是无辜的。

77

BrightLiao

2022-11-28 16:55:06 +08:00

一旦你看你的代码快要变成山了，就得考虑是不是代码垒得太高了。拆分成两座或更多的土丘是大多数人的选择。

考虑：
- 从技术上看，有没有模块是非常复杂的，但是是独立的。如有，拆出去，专门给某个人或团队维护。
- 从业务上看，有没有两个业务本来就是相关性很低的，考虑拆分为不同的项目，交给不同的人维护。

现在大家在谈微服务，其实就是谈拆分，如何避免一个项目内的东西过于复杂。

78

pC0oc4EbCSsJUy4W

2022-11-28 16:55:25 +08:00

周期重构

79

nicebird

2022-11-28 17:05:53 +08:00

基本做不到。人如果被放到被不能胜任的位置，代码复杂度 hold 不住的话，就走向屎山。

80

likunyan

2022-11-28 17:06:34 +08:00

我的代码我一直觉得它是 shit ，但是我技术又没办法达到改成别人的样子，所以呢？

81

sparkpark

2022-11-28 17:23:04 +08:00

The best way to write secure and reliable applications. Write nothing; deploy nowhere.
https://github.com/kelseyhightower/nocode

82

montaro2017

2022-11-28 17:35:02 +08:00

任何代码的尽头都是屎山，你写得再好只不过能延缓它变成屎山的过程
所以不写出屎山的方式是，不写代码

83

loryyang

2022-11-28 19:18:21 +08:00

其实就一点，你需要时间来重构
说实话，一般公司里面，哪有时间，也只有真的有追求的人，愿意放弃自己的休息时间来实现自己的坚持
不过真的大项目，重构还有另外一个更大的困难：你不敢改，怕出事，这个基本就很难了

84

YVAN7123

2022-11-28 19:23:56 +08:00

提升自己换公司

85

gdgoldlion

2022-11-28 20:10:17 +08:00

换个好公司
如果公司代码天生就烂，你是改变不了什么的
顶多屎上雕花

86

hxysnail

2022-11-28 20:56:25 +08:00

很意外，看到很多人说代码屎山避免不了；也很高兴看到不少人提到一些不错的建议

其实，我自己的亲身体会时，合理的组织结构，还是会起到很积极的作用的。只是这需要功底，也需要花多一些时间。但是说实话，很多人达不到这样的功底，包括我自己。
有时一些简单的组织逻辑第一次写都没有梳理清楚，然后某天突然想明白了，去重构。或者某天发现自己在一个不合理的结构上消耗太多精力，才想方设法去做一些优化。
但是最可怕的事情就是没有意识到问题，如果不能意识到代码屎山带来的破坏性，不能意识到良好结构带来的好处，那结果就是在错误的路上越走越远。

还有通常在多人协作的项目，存在三个和尚没水喝的问题。你花精力去思考怎么设计得更合理，更稳定，更能适应未来可能的变化，但其他人都是胡乱堆砌，只刷 KPI 到点下班，那你一定会心里不平衡，可能也跟着堆屎山了。上面提到开新坑，定期跑路的，有一个算一个都是自私的人。如果接盘的人可以选择不接，然后你就跑不了路，我想可能又会有所不同。
从这个角度看，想要战胜人类与生俱来的自私，团队定期复盘代码设计质量可能也很重要。

87

crazyweeds

2022-11-28 21:04:35 +08:00

说点实在的就是：持续 Code Review 、持续重构，不放过任何一个螺丝钉。还有关键的一点，代码能简单写就绝不绕弯子，保持极高的可读性，可降低后续重构代码的时间和精力成本。
但是，悲催的是，会导致一个问题，你大概率会变成强伯症，别人代码只要略微不讲究，你就会很难受。

88

emma3

2022-11-28 21:06:29 +08:00

你不建屎山，在你跑路后，你的后继者们同样会建个屎上。

89

aaa5838769

2022-11-28 21:40:22 +08:00

一直重构

90

achira

2022-11-28 22:02:11 +08:00

如果做不到降低效率，那就只有如上所述的定期重构了
当然至少还可以注释写得尽可能详细一点写出为什么要这样

91

MEIerer

2022-11-28 22:07:46 +08:00 via Android

多写纯函数算一个

92

Pangurban

2022-11-28 22:12:19 +08:00

1. 根据业务特点做合理的抽象。
2. 除了了解基本的锁以外，了解一两种并发模型（例如纯函数式编程，Actor 模型）
并发读写、事务性都不简单，当代码不小心引入它们的时候要引起警觉。
3. 善用语言的特性，例如 Scala 的类型检查，Option ，Try 和 Pattern Match ，少用 Null 和 AsInstanceOf 。
争取编译通过即无 Bug 。（业务逻辑上的问题除外）
4. 强迫症。（会很累）