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

[singerll]

不写代码

[salmon5]

不做 KPI ，不领工资

[Kirdoyz]

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

[yytbob]

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

[god7d]

技术层面

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

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

项目层面

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

[vevlins]

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

[akakidz]

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

[fiypig]

能跑就行，管他的

[raysonx]

https://github.com/kelseyhightower/nocode

[coderxy]

定期重构

[lookStupiToForce]

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

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

[leonshaw]

@lookStupiToForce 只开新坑，定期跑路

[thulof]

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

[wu67]

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

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

[llsquaer]

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

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

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

[virus94]

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

[LaGeNanRen]

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

[luzemin]

持续重构，别无他法

[holy_sin]

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

[kongkx]

轮回

[fkdog]

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

[pikaconan]

跳槽去做新项目

[ytmsdy]

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

[xuelu520]

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

[itechnology]

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

[yfugibr]

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

[FallenTy]

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

[abc635073826]

不要给别人写代码

[wanguorui123]

架构设计，重构，Review

[JackMi]

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

[qiumaoyuan]

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

一句话就是：防微杜渐。

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

[MasterofNone]

屎山的最优解是丢给别人

[misttyw]

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

[rrZ2C]

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

[maybe0410]

持续重构

[xuanbg]

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

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

[yousabuk]

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

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

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

[janxin]

不写代码

[qiumaoyuan]

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

[fakeshadow]

写自己经常用的

[justin2018]

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

[vazo]

水平不够写好注释

[akira]

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

[estk]

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

[KENNHI]

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

[Crackers]

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

[fate]

珍惜每一次 CodeReview 和 Debug

[pkoukk]

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

[chuanqirenwu]

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

[kooze]

干掉产品经理

[missdeer]

经常重构

[bgm004]

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

[dreamererer]

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

[linshenqi]

吾日三省吾身

[MMMMMMMMMMMMMMMM]

看类型

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

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

[blankmiss]

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

[wanganjun]

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

[GreatAuk]

设计模式多看看

[wherewhale]

里的清就行

[tool2d]

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

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

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

[liuidetmks]

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

[leafre]

不要动其他的史山

[Daniel17]

一直重构

[mawenjian]

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

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

[anonymous2351d00]

重构

[yeyu123]

一直重构

[lilyok1234]

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

[eason1874]

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

[yxzblue]

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

[daokedao]

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

[ruoxie]

分层

[xumng123]

避免不了

[aliveyang]

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

[fournoas]

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

[1vonzhang]

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

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

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

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

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

[zjj19950716]

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

[BrightLiao]

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

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

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

[pC0oc4EbCSsJUy4W]

周期重构

[nicebird]

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

[QKgf555H87Fp0cth]

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

[sparkpark]

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

[montaro2017]

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

[loryyang]

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

[YVAN7123]

提升自己 换公司

[gdgoldlion]

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

[hxysnail]

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

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

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

[crazyweeds]

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

[emma3]

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

[MilkShake]

一直重构

[achira]

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

[MEIerer]

多写纯函数算一个

[Pangurban]

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

[tuutoo]

不断提升自己写代码的能力，写出屎山代码的根本原因就是能力不行。

[mowen1992]

经常重构呗，谁也不是一下子就能写出好代码的，不断对需求深入了解，学习尝试不同的解决问题的方法，才能写出最好的代码

[myd]

持续重构

[xy90321]

小而美的前提是小… 但是小的一般都不赚钱，除了 infra… 所以… 就是理想和面包二选一的问题

[gdyong]

凡事都有两面，屎山让你饱受批评，却能让你不怕被炒，长年累月待下去🐶

[honghaoz]

别急功近利，给自己写。

[theprimone]

《代码整洁之道》
《重构：改善既有代码的设计》

[07ly]

自己的个人项目：做好功能设计，完善代码注释，积极更新文档，持续进行重构
公司的项目：管他干嘛，能跑就行，没两天就推倒重做了。领导自己都想不明白干嘛，还要快速上线，谁有空给他好好设计