近年来我带队开发出的一坨屎山

前言、我花费一年时间带队开发出来一坨屎山。

有人说： 烂代码跟一坨屎一样，很多时候就是和一坨屎共处千万别深挖，说不定把哪里挖塌了把你埋了，扔一坨代码到屎山上，达到自己目的，能跑就行了，你还要搞清楚山上的屎哪一坨是谁拉的，拉的人吃了什么，就没什么意思了。
而这坨屎山却不是祖传的，而是我带队开发出来的。以下简称【我的屎山】。

一、目标

经过几个类似项目的经验积累，公司希望开发出一个可复用率较高的产品，用来给每一个项目来客制化的基础产品。

之前已经开发过一版，但其实是根据第一个项目定版，有很多考虑不周的地方，希望这次把这些问题改掉。

1、易用的脚手架

在产品中，要有相关的范例，可能用到的技术范例，新设备的可以使用范例代码。程序启动调试发布的已实践流程。

在项目定制化时，不再需要前期框架搭建，设计完成后能开发。不再需要对新技术调研能直接进入开发。

2、通用的标准化模块

在产品中，要有一些标准模块，这些模块是大部分项目都需要的。

在项目定制化时，希望只有一些小改动就可以实现客户的定制化。希望大部分代码可复用。

3、易上手的代码

希望新人经过简单的业务培训或技术培训，能快速上手修改代码，并完成定制化需求。

二、其他屎山出现的常见原因

参考别人的文章介绍的屎山出现的原因

1、程序员的技能水平。

很不幸,干这行,入门真不需要受多少教育,不客气地说,是个人培训培训就可以上岗了,这些从业人员能够把事情搞定,但是真没有意识做长远考虑,也没能力做长远考虑,写出来的当然是一坨一坨

我的屎山：很幸运，我们组的人员基本都是成手，并且开始之前，我们调研了前一版本出现的问题，并强调了所有需要注意的代码。

2、管理层的短视。

程序员的水平不高，好歹还可以通过培训，通过招募更强的程序员来弥补，但是，如果管理层想要的只有短期目标，“这个功能很简单，怎么实现我不管”，横批“明天上线”，哪怕是一群10x程序员也没法做出高质量的代码啊。管理层的短视，其实已经很难追责了，你可以因为一个管理者没有按期交付功能开除他，但还真很难因为他没有搞出可维护代码而开除他，没救了。

我的屎山：管理层目标很明确，希望产品可复用率高。

3、资本压力。

万恶之首，还是资本，资本想要规模，一声令下，就要公司扩招多一倍程序员，满足场面，招来这么多人又管不好，除了生产垃圾还能怎样；一旦资本寒冬，又是一声令下，裁员一半，大家都没心情过年，来年哪有人有心维护代码质量。

我的屎山：时间固定，第一版3个月，第二版加功能也3个月，第三版第四版要加的功能已经规划，并且有时间预期

三、我们的产品成为屎山的原因

1、我的能力不足

很遗憾我以前基本没带过队，虽然参加过几个从零开始的项目， 且也有意识的长远考虑问题，但实际上考虑不周全，遗留下很多未解之谜。在产品开发过程中我虽然经常参考其他人的意见，但是于事无补。

2、前期需求设计不足

我们的产品完成日期确实是固定的，但对功能的预估不足，需求设计人员只知道想要什么，前期没有努力完善需求，后期开发过程中发现很多情况不自恰，唯有现改代码逻辑。需求设计人员很理想化，希望做一个大而全的产品，所有情况全部实现，使用配置参数作为条件来区分以后产品在各个项目中的定制化，而实际实现中也真是这么做的，导致最后这种配置参数粗略估计超过1000个【if分支超过1000个】，有一些参数其实他自己都没有考虑清楚，这个参数的意义都无法仔细描述清晰。

而这些参数还不只是产品的系统参数，可能是某个逻辑结构的参数，类似mysql的排序规则，可以属于：库，表，字段。

mysql的系统参数也没超过1000个【SHOW VARIABLES 查询发现500多个系统参数】，并且在官方文档中对每一个环境变量都有具体的解释，而且每一个参数都有默认值。有使用范例，有参数选择分析。

而我们的产品大部分参数没有默认值，如果不配置一个具体的值，产品无法启动；并且参数也没有仔细考虑就直接怼上去了，后期出问题都找不到原由只能翻代码。

3、产品定位不准确

产品初期定位是希望项目的快速交付，但实际开发过程中需求设计人员一直在偏向实现需求，遇到分支不仔细考虑，直接加配置参数，从来不参考项目开发组的意见，导致最后项目开发组在使用过程中根本不用标准功能，改动稍微大一点就重写，基本没有表现出配置化的意义。整个产品成了一个黑盒子。

4、为了提高复用率不择手段

需求设计人员以为提高复用率就是把所有业务尽可能覆盖，在产品中把所有可能的情况都实现了，而实际项目中的情况千变万化根本做不到全覆盖，最后导致整个产品代码过于臃肿。

四、重构

有人说： 重构祖传代码就跟迁祖坟一样，稍有不慎就万劫不复

我们这个产品其实是第二次重构了，产品开始前，使用了半个月选定和搭建框架，写工具类，规范命名规则。

最后、结局

最后我们获得了一坨屎山，标准功能都好使，但在实际项目中，可复用率低于10%，大部分开发不想阅读我们像精密仪器一样的代码，只是使用我们的产品作为脚手架，使用其中的工具类，在项目中如果模块的功能差异只要超过30%就重新开发。因为阅读并修改产品的模块，还没有重写一个新模块快速。所谓的可配置成了一句笑话。
程序从头到尾都是我设计的，我了解几乎所有实现细节，但是在交付项目中，好多开发还是不想理解细节，为了速度重写功能，绕开那托屎山。虽然我自己总结出了我们的产品成为屎山的原因，但代价太惨痛了。