如何避免屎山代码，理论上可行的思路

[taogen]

如何避免屎山代码

1. 减少屎山代码产生的可能。实行单元测试和代码审查。但时间成本提高了。
2. 减少产生屎山代码的人。多招高级工程师，不招初级工程师。但人力成本提高了。

[Sfilata]

排工期不断重构，叫团队一起评审。这个东西没有时间就是无解。

[tianmalj0613]

屎山代码也是 trade-off 的结果。比较大部分公司都选择了商业扩张优先于工程文化

[DinnyXu]

这个“屎山”定义是什么？ 有待商榷......
目前我认为的屎山有以下几点：
1：代码不够简洁，有违代码简洁之道，简单的功能写的太复杂，看似各种容错，其实是各种漏洞
2：代码没有承上启下，不要写一些重复的东西，重复造轮子很蠢，很难维护
3：基于第二点，如果代码复用性差，维护起来成本就会增高，而且老人一走，新人维护简直是火葬场，也就成为了新人眼中的屎山
4：代码整体设计，这个是基于前 3 点，我个人认为一个项目应该有若干个版本，例如 1.0 、2.0 、3.0.....版本的升级维护，每一次的升级都是为了更好的优化代码，而不是堆屎山


还有你说的第二点：减少产生屎山代码的人。多招高级工程师，不招初级工程师。但人力成本提高了。多招高级工程师，简直是个伪命题，高级不代表能解决屎山的问题，架构都不一定能解决，因为每个公司对高级的定义是不一样的，普通公司的高级也就是大公司的中级，我这样说你能明白的吧...至少我身边有一些高级，我没觉得他写的代码不是屎山

[crazytudou]

接手过这种项目，那真是上班都没心情，一打开项目心里就开骂。全是一些刚毕业或毕业一两年的人开发的，也没人审代码，真是不爆错就行，业务逻辑都走不通。
想杜绝屎山，那就从根上解决，出高价钱招人，要不然什么鬼方法都没用，因为那些人写代码就是这样的风格

[AyaseEri]

2
你要减少产生屎山代码的人，需要多招高级产品经理，而不是工程师。

[tt67wq]

不要尝试消灭屎山

[tool2d]

最佳解决办法，把菜鸟同事换掉，但这通常是不太可能的。

退而求其次，那就是鼓励多写函数式编程，减少变量依赖。再用自研工具去合理管理代码。

屎主一般有两点特种，1 代码量太多，2 耦合性过强。针对性解决就好。

[Biggoldfish]

1. 难道没有写 unit test 并经过的 code review 的代码能被 merge ？

[yaphets666]

主要是工期问题，需求问题，成本问题。技术问题不是问题

[Rooger]

提高人员的水平，但是首先提高自己的水平，同时也要清楚有些东西绝没有想象的那么简单，最近看了几本书，推荐给大家。
《人月神话》-- 往已经延期的项目中增加人力是无效的。虽然有一部分论点有些过时，但是其强调的大多观点目前仍适用，依然强烈推荐。
《代码整洁之道》-- 如何写出 Clean Code ，也就是屎山的对立面。
作者的精彩演讲视频： <amp-youtube data-videoid="7EmboKQH8lM" layout="responsive" width="480" height="270"></amp-youtube>&t=539s
《软件设计的哲学》-- 如何控制复杂性，如何设计
作者的 Google talks 视频： <amp-youtube data-videoid="bmSAYlu0NcY" layout="responsive" width="480" height="270"></amp-youtube>&t=313s
该书 github 的翻译版本有些问题，由于时间问题，我只修正了从十二章开始的内容： https://github.com/luojiego/A-Philosophy-of-Software-Design-zh

[Acoolda]

无法杜绝，因为在今天你看一起来十分不合理的设计，说不定就是当时写的时候因为种种因素导致只能这么设计的，有时候很无奈。

[Jammar]

除了你自己没有人关心你的代码是不是屎山,能赚钱的代码就是好代码

[jamosLi]

绝大多数屎山不是开发堆的，是产品脑抽造成的。

代码精简不等于非屎山代码，精简的代码可能比屎山还恶心，

[taogen]

@yaphets666 #29
技术问题和工期问题，需求问题，成本问题一样，都是重要的。
现在假设工期给的是充足的，需求也是很合理的，成本也是允许提高的，但没有单元测试和代码审查等机制，让刚毕业的人来写代码，你认为代码会不会成为屎山呢？
人是有惰性的，除非已经养成了好的编码习惯或者强制要求编码规范，否则很难主动去写好代码。

[bk201]

从大环境开始吧，大环境浮躁，喜欢年轻人加班干。

[cubecube]

拉屎的是人。要么限制提交（手段很多），治标不治本
要么搞定人的问题

[taogen]

@taogen #34 让刚毕业的或者技术很一般的人来写代码（修改）

[PythonYXY]

问题大部分在需求端

[whileFalse]

@8355 跟人有关系，但即使有足够经验的开发也扛不住瞎几把改需求以及排期不够重构的情况。

[LXGMAX]

工程师的角度来讲，给足够的时间去研究代码效率和架构、自身向高水平看起就有可能
反之前期正在形成体系的时候各种赶，后期修补的方式，屎山就越来越高
而现实更多的是后者