引子
堆码堆了8年，历经五六个创业公司，经我手搭了五六个项目框架，开始的时候都当亲儿子看待。随着时间累积，是越看越不顺眼，越看不像亲生的，最后就到了看一眼就恶心的那种，俗称屎山代码。 这两年心态平和一些了。不是因为我的水平好了，而是被现实驯服了，咱也见过大公司的代码，大差不差，五六年的项目终是难逃一屎。下面就随便唠唠堆积如山的屎山代码的形成。
开发人员太low
第一点先喷人的问题，有的开发就是水平太差，会写业务，也知道处理并发，处理性能，但就是不爱封装，不考虑拓展性。下拉选项不用变量非要在模板里写死；很多公用的数组就是不写到公共字典里；用了n次的验证方法，格式化方法就是不放到一个模块里；消息提醒，弹窗，表格，间距重复写了一遍又一遍。
外包接手
咱不是说外包不好，只是从代码拓展性上来说，一般外包人员做的没有在班员工写得好。因为这里有一个客观原因，外包是“包活”，员工是“包天”，外包为了尽快交付项目拿到结款，是以功能完整交付为目的，不会过多考虑这个项目的后期。如果考虑了，也就意味着增加这一期的工作量，下一期项目不一定是交给自己，就有可能是给别人做嫁衣。而员工就不一样了，经验丰富的员工很多时候能预估到项目功能的走向，平时与产品在一起沟通也能了解项目的后期功能，为了自己方便就会提前铺垫。所以说想要长期迭代的项目最好是用员工，或者自己员工主导，外包辅助；也或者找个长期的外包，不要随便更换开发人员。
业务变更，向下兼容
随着客户增多，项目功能增多，有些业务也会变更。这就有一个麻烦事儿，属性多了甚至改了，为了兼容旧的业务就要写一些冗余的判断逻辑，而且可能要很多个地方都要写。越写越多直到写不动了，就要重新起个大版本给新客户。但是新版本里的冗余代码会清理掉吗，大概率是不会的。
新旧开发没有交接
旧的开发人员离职了，新的开发接手，但是两代开发没有交接，没有沟通。在写新功能的时候可能会有一些公共方法公共类的使用。这时候就会出现两个问题，一个是新开发不知道哪些方法写过了，哪些没写过，于是就会重新写一遍可能已经有的公共方法。在未来的某一天突然发现了那个公共方法已经没办法去掉了。还有一种情况是，即使知道某个功能用到的方法写过了，但是不能满足新业务。这时候有两种处理方式，一是更改旧方法，二是重新写方法。我相信开发人员为了安全都会自己重新写一遍，因为旧的代码不一定完全理解。我自己就见过很多这样的代码，看来看去都觉得不妥，明明很简单的业务偏偏写得很复杂，很繁琐，但是我又担心原来的开发人员有什么深意，不敢去改旧的。
优雅与资本的博弈
如果公司有项目经理，有产品经理，他们会去权衡甲方的需求与实现难度，和上下沟通，最后敲定方案。如果没有这些中间层，开发人员直接对接客户，或者开发人员直接对接老板。上层只是问一句“能不能实现”，“行还是不行”，以我多年的技术经验肯定是可以实现，但是要牺牲一些代码规范，甚至就是写一堆屎代码。开发人员可能只会回复一个“可以”。于是为了一个无关紧要的功能或样式，大概率出现一堆冗余代码。
结语
如果是技术的问题，反倒容易改变。但是很多时候都是客观原因，都是现实问题。公司是以盈利为目的，项目是以交付为目的，开发人员就是干活拿钱的，整个链条下来有谁会在意代码的优雅呢，所以一个项目发展多年以后，屎山是必然的。
再说点题外话，做开发这么多年确实有点消极了。以前以为有技术有想法能做出来个喜欢的东西。堆码多年才意识到“码农”的无奈。我们能做的也就是砖头垒成墙，不东倒西歪就不错了，至于它能阻挡多少风雨，它的风格漂亮不漂亮，它盖成的楼房能不能卖上好价钱，和搬砖头的关系不大。不过这些无所谓了，我喜欢敲代码就够了。为了写一个算法冥思苦想，为了实现一个样式辗转反侧，自己开心就好。
