我經歷過最混亂的一個項目

初入項目

我加入這個團隊的時候，據說作的工做將會是如今很是熱門的「大數據」、「雲計算」，是某個行業基於雲的解決方案，初看上去彷佛是一份十分有前途的工做。這個團隊的工程代碼已經開發了好幾年，我當時想，必定會有很多能學習的技術吧。

然而當開始看到團隊的入門文檔的時候，我仍是很吃驚的，由於上面羅列的技術框架，已是很是久遠、過期的框架（再次說明面試的時候，問公司如今所用技術的重要性）。好比，用的Java版本是6，版本控制用的是CVS，顯示層框架新老代碼混合不一樣框架在用，有struts1和servlet，其餘的還有低版本的EJB和低版本的JPA、Velocity、Hessian。不過我對部分框架並非太瞭解，因此也沒有太多偏見，仍然是對這個項目抱着很多但願。

工做剛開始的時候，發現他們的代碼有一種說不出的混亂的感受。一個功能並無一個清晰的入口，有些是struts1，有些是servlet，有些又直接是Velocity混合着業務邏輯，代碼並無一個統一的風格，都是混亂的放在一塊兒。有些功能幾乎如出一轍，只是展現菜單名字不一樣，結果相同的代碼又分散到幾個地方，每次改動，須要幾個地方同時改動，否則就會有功能不正常。仔細查看以後，又發現每一個實體類的字段都沒有註釋，數據庫裏也沒有列註釋，更沒有專門的文檔來講明每一個字段的意思，每一個不一樣實體的字段表示的意思都存在不一樣開發人員的腦海裏。

而後我想着把整個系統的流程弄清楚，再花些時間整理一下字段的意思，應該會比較好理解這些代碼，或許能進行一次重構。但以後我發現，團隊裏沒有一個開發人員能解釋清楚工程的整個流程和結構，也沒有人知道哪些部分是正在使用，哪些部分是已經被廢棄的。你們都只知道本身開發的那部分代碼，但沒人瞭解整個系統，也沒有關於這個系統的文檔說明，甚至表示同一個意思的字段，先後都是不一樣的。

思考

我認爲這個系統發展如此混亂有必定的客觀因素。開發團隊人數不多，但新功能交付，BUG修改這些壓力都很大，公司的財務上也有很大問題，因此開發人員被迫天天加班，快速響應需求，修改BUG，快速交付，只能把代碼隨意疊加，只要功能不出大問題就交付。

雖然剛纔說到版本有CVS作控制，但那只是後臺的一部分代碼，前端的代碼所有提交到老闆（技術出身）開發的一個雲開發平臺上，不一樣項目共用同一個前端頁面代碼。但若是一個項目的頁面代碼被修改，那麼只會對這個項目生效，從而知足不一樣客戶的個性化需求。但有時候完成一個功能須要修改不一樣的頁面，這個開發平臺只能控制單個文件的版本歷史，而不能控制全部完成這個功能所修改的文件。這樣形成的結果是，客戶一看這個功能，發現實際上並不須要，想變回原來的樣子，這時候回退就變得十分困難。

還有一點在於，客戶的個性化需求絕大多數不只僅在於頁面樣式，還有不少業務邏輯，特別是每一個客戶須要展現的報表都是不一樣的。這個狀況仍是規定不能更改後臺代碼，只能寫在前端的Velocity裏，包括SQL。想到這裏，已經以爲是個噩夢了，但還有更可怕的。

對於這些前端代碼的編輯所有基於網頁編輯器，而這個網頁編輯器只有語法高亮功能……Java自己是強類型的語言，在Velocity裏寫業務邏輯，沒有IDE的編譯檢查，還得時時刻刻注意數據類型，否則賦值、轉換之類的無效根本不知道到底什麼狀況。甚至代碼超過幾百行時，編輯還會感受十分明顯的卡頓。其實我不是很懂以前的開發人員是怎麼堅持下來的……

代碼之外的思考

需求：

每當客戶提交一個新需求的時候，沒有人把控需求，常常形成完成這個需求以後，客戶一看說不須要，立刻又得修改回原來的樣子，形成太多太多的無用功。

員工：

老員工天天都在抱怨很累、每天加班，不過令我意外的是他們的士氣十分高漲，常常加班到凌晨甚至通宵。但編程這種工做，長時間的工做並不必定會換來對等的成果，有很多研究都證明了這個觀點。但在公司財務緊張，又須要招攬新客戶的狀況下，我也並無什麼好的想法，或許公司也有本身的無奈吧。

 

---

 

PS.以後公司要求執行傳說中的9 11 6，雖然公司十分近，就3分鐘的路程，可是我仍是離開了，接受不了如此強度的工做和畫餅的承諾。後來也沒關注，不知道這個公司發展得怎麼樣。