前言、我花費一年時間帶隊開發出來一坨屎山。
有人說： 爛代碼跟一坨屎一樣，很多時候就是和一坨屎共處千萬別深挖，說不定把哪里挖塌了把你埋了，扔一坨代碼到屎山上，達到自己目的，能跑就行了，你還要搞清楚山上的屎哪一坨是誰拉的，拉的人吃了什么，就沒什么意思了。
而這坨屎山卻不是祖傳的，而是我帶隊開發出來的。以下簡稱【我的屎山】。
一、目標
經過幾個類似項目的經驗積累，公司希望開發出一個可復用率較高的產品，用來給每一個項目來客制化的基礎產品。
之前已經開發過一版，但其實是根據第一個項目定版，有很多考慮不周的地方，希望這次把這些問題改掉。
1、易用的腳手架
在產品中，要有相關的范例，可能用到的技術范例，新設備的可以使用范例代碼。程序啟動調試發布的已實踐流程。
在項目定制化時，不再需要前期框架搭建，設計完成后能開發。不再需要對新技術調研能直接進入開發。
2、通用的標准化模塊
在產品中，要有一些標准模塊，這些模塊是大部分項目都需要的。
在項目定制化時，希望只有一些小改動就可以實現客戶的定制化。希望大部分代碼可復用。
3、易上手的代碼
希望新人經過簡單的業務培訓或技術培訓，能快速上手修改代碼，並完成定制化需求。
二、其他屎山出現的常見原因
參考別人的文章介紹的屎山出現的原因
1、程序員的技能水平。
很不幸,干這行,入門真不需要受多少教育,不客氣地說,是個人培訓培訓就可以上崗了,這些從業人員能夠把事情搞定,但是真沒有意識做長遠考慮,也沒能力做長遠考慮,寫出來的當然是一坨一坨
我的屎山：很幸運，我們組的人員基本都是成手，並且開始之前，我們調研了前一版本出現的問題，並強調了所有需要注意的代碼。
2、管理層的短視。
程序員的水平不高，好歹還可以通過培訓，通過招募更強的程序員來彌補，但是，如果管理層想要的只有短期目標，“這個功能很簡單，怎么實現我不管”，橫批“明天上線”，哪怕是一群10x程序員也沒法做出高質量的代碼啊。管理層的短視，其實已經很難追責了，你可以因為一個管理者沒有按期交付功能開除他，但還真很難因為他沒有搞出可維護代碼而開除他，沒救了。
我的屎山：管理層目標很明確，希望產品可復用率高。
3、資本壓力。
萬惡之首，還是資本，資本想要規模，一聲令下，就要公司擴招多一倍程序員，滿足場面，招來這么多人又管不好，除了生產垃圾還能怎樣；一旦資本寒冬，又是一聲令下，裁員一半，大家都沒心情過年，來年哪有人有心維護代碼質量。
我的屎山：時間固定，第一版3個月，第二版加功能也3個月，第三版第四版要加的功能已經規划，並且有時間預期
三、我們的產品成為屎山的原因
1、我的能力不足
很遺憾我以前基本沒帶過隊，雖然參加過幾個從零開始的項目， 且也有意識的長遠考慮問題，但實際上考慮不周全，遺留下很多未解之謎。在產品開發過程中我雖然經常參考其他人的意見，但是於事無補。
2、前期需求設計不足
我們的產品完成日期確實是固定的，但對功能的預估不足，需求設計人員只知道想要什么，前期沒有努力完善需求，后期開發過程中發現很多情況不自恰，唯有現改代碼邏輯。需求設計人員很理想化，希望做一個大而全的產品，所有情況全部實現，使用配置參數作為條件來區分以后產品在各個項目中的定制化，而實際實現中也真是這么做的，導致最后這種配置參數粗略估計超過1000個【if分支超過1000個】，有一些參數其實他自己都沒有考慮清楚，這個參數的意義都無法仔細描述清晰。
而這些參數還不只是產品的系統參數，可能是某個邏輯結構的參數，類似mysql的排序規則，可以屬於：庫，表，字段。
mysql的系統參數也沒超過1000個【SHOW VARIABLES 查詢發現500多個系統參數】，並且在官方文檔中對每一個環境變量都有具體的解釋，而且每一個參數都有默認值。有使用范例，有參數選擇分析。
而我們的產品大部分參數沒有默認值，如果不配置一個具體的值，產品無法啟動；並且參數也沒有仔細考慮就直接懟上去了，后期出問題都找不到原由只能翻代碼。
3、產品定位不准確
產品初期定位是希望項目的快速交付，但實際開發過程中需求設計人員一直在偏向實現需求，遇到分支不仔細考慮，直接加配置參數，從來不參考項目開發組的意見，導致最后項目開發組在使用過程中根本不用標准功能，改動稍微大一點就重寫，基本沒有表現出配置化的意義。整個產品成了一個黑盒子。
4、為了提高復用率不擇手段
需求設計人員以為提高復用率就是把所有業務盡可能覆蓋，在產品中把所有可能的情況都實現了，而實際項目中的情況千變萬化根本做不到全覆蓋，最后導致整個產品代碼過於臃腫。
四、重構
有人說： 重構祖傳代碼就跟遷祖墳一樣，稍有不慎就萬劫不復
我們這個產品其實是第二次重構了，產品開始前，使用了半個月選定和搭建框架，寫工具類，規范命名規則。
最后、結局
最后我們獲得了一坨屎山，標准功能都好使，但在實際項目中，可復用率低於10%，大部分開發不想閱讀我們像精密儀器一樣的代碼，只是使用我們的產品作為腳手架，使用其中的工具類，在項目中如果模塊的功能差異只要超過30%就重新開發。因為閱讀並修改產品的模塊，還沒有重寫一個新模塊快速。所謂的可配置成了一句笑話。
程序從頭到尾都是我設計的，我了解幾乎所有實現細節，但是在交付項目中，好多開發還是不想理解細節，為了速度重寫功能，繞開那托屎山。雖然我自己總結出了我們的產品成為屎山的原因，但代價太慘痛了。