一胖
后端curd选手
获得徽章 6
赞了这篇沸点
几乎所有程序员都会拥有在屎山中作业的经历，并且所有有此经历的人基本上都会关切地问候一下写下这些代码的人
我曾经和很多人一样，一边骂一边暗自笃定，我是绝不可能写出这种代码的，但随着接触的项目多了之后，我终于明白，每个人都极可能是屎山的贡献者
业务屎山的存在是不可避免的，这跟写代码的人的水平和修养无关，大部分人都觉得自己是不会写出屎山的，并且可能也真的在努力写好代码，但实际上到了最后，终将变成自己讨厌的人
在项目初始阶段，还可以凭借着强硬的技术水平，保证整个系统处于所谓的“优雅”状态，但随着业务的快速迭代，参与的人数越来越多，这种初期建构起来的壁垒不堪一击
可能你认为你自己的水平很高，但你无法保证团队内所有人的水平都和你不相上下，参差不齐的团队水平是一件非常常见的事情
退一步，就算你拼尽全力保证进来的人都具备很高的技术水准，结果可能会更麻烦，因为技术是没有统一答案的，你觉得你的设计、架构好，但你怎么保证别人也觉得你的好，他完全可能觉得另外一种好，并且水平越高的人就越会有一种固执的自视清高，他不认可你，自然就不会遵守你的规则
再退一步，你拼劲全力保证团队内的人都具备很好的技术水平和修养，并且说服了所有人都认可你的思想，但这个时候业务方来了一个需求，众所周知，发展中的业务不可能是一成不变的，可以说是五花八门，甚至做着做着自己否定自己， 很可能有一个需求只要做了，就会对你的架构造成破坏，你做不做？
一个不做，两个三个五个呢？你都不做，那你的价值是什么，业务要你干什么？
技术是为业务所服务的，而不是用来体现你自身代码水平的，这种天然存在的优先级就决定了技术在绝大多数情况下需要向业务妥协
所以你不得不做，但只要你做了，根据破窗理论，你的所谓设计自此将不可避免地开始加速“堕落”，最终变成传说中的屎山，而 git 忠实地记录下了你对这座屎山所有的贡献
绝大部分的项目都避免不了成为屎山的结局（除非创业未半而中道崩殂，但这种更惨），但并不代表我们就应当自暴自弃顺其自然了，我们要做不是避免屎山的出现，因为大概率是避免不了的，我们应当为它们的出现提前做好规划，预留充足的空间，让屎山的艰难险阻仅流于表面，而保证内核的一如初心
屎山是不优雅的，但可以是可维护的，可以存在大量的反设计业务逻辑和 hack 代码，但不应当在里面尽情地挖坑，可以让人全神应对，但不应当让人头破血流
我曾经和很多人一样，一边骂一边暗自笃定，我是绝不可能写出这种代码的，但随着接触的项目多了之后，我终于明白，每个人都极可能是屎山的贡献者
业务屎山的存在是不可避免的，这跟写代码的人的水平和修养无关，大部分人都觉得自己是不会写出屎山的，并且可能也真的在努力写好代码，但实际上到了最后，终将变成自己讨厌的人
在项目初始阶段，还可以凭借着强硬的技术水平，保证整个系统处于所谓的“优雅”状态，但随着业务的快速迭代，参与的人数越来越多，这种初期建构起来的壁垒不堪一击
可能你认为你自己的水平很高，但你无法保证团队内所有人的水平都和你不相上下，参差不齐的团队水平是一件非常常见的事情
退一步，就算你拼尽全力保证进来的人都具备很高的技术水准，结果可能会更麻烦，因为技术是没有统一答案的，你觉得你的设计、架构好，但你怎么保证别人也觉得你的好，他完全可能觉得另外一种好，并且水平越高的人就越会有一种固执的自视清高，他不认可你，自然就不会遵守你的规则
再退一步，你拼劲全力保证团队内的人都具备很好的技术水平和修养，并且说服了所有人都认可你的思想，但这个时候业务方来了一个需求，众所周知，发展中的业务不可能是一成不变的，可以说是五花八门，甚至做着做着自己否定自己， 很可能有一个需求只要做了，就会对你的架构造成破坏，你做不做？
一个不做，两个三个五个呢？你都不做，那你的价值是什么，业务要你干什么？
技术是为业务所服务的，而不是用来体现你自身代码水平的，这种天然存在的优先级就决定了技术在绝大多数情况下需要向业务妥协
所以你不得不做，但只要你做了，根据破窗理论，你的所谓设计自此将不可避免地开始加速“堕落”，最终变成传说中的屎山，而 git 忠实地记录下了你对这座屎山所有的贡献
绝大部分的项目都避免不了成为屎山的结局（除非创业未半而中道崩殂，但这种更惨），但并不代表我们就应当自暴自弃顺其自然了，我们要做不是避免屎山的出现，因为大概率是避免不了的，我们应当为它们的出现提前做好规划，预留充足的空间，让屎山的艰难险阻仅流于表面，而保证内核的一如初心
屎山是不优雅的，但可以是可维护的，可以存在大量的反设计业务逻辑和 hack 代码，但不应当在里面尽情地挖坑，可以让人全神应对，但不应当让人头破血流
展开
4
21
