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

[qinrui]

[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]

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

[aaa5838769]

一直重构

[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]

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