一個較為失敗的專案覆盤

寫在前面

前一陣子部門啟動了一個新的專案叫做資源成本決策系統，到目前此專案已經基本上按照啟動前的規劃做的大差不差，但最近開會需要在這個專案中新增新的功能，這可真是要了命了，想想不管從資料庫上設計上，程式碼設計上可拓展性都比較差，專案換血勢在必行。昨天將專案開發的整個過程在腦海中過了一遍，總結出了幾點問題，或者是踩過的一些坑，在此記下以便更好的吸收這些教訓，為以後的道路添磚加瓦。
筆者自認為自己是一個文筆很差的人，因為從小學起我的語文就一直不好，尤其是寫作，想想當年寫作文為了將作文寫過800字的分界線，居然在每一個不是在行首結束的行中間故意寫錯一些字然後塗掉，強行將其拖到下一行結束。這是筆者第一次寫部落格，其實自己之前寫過不少東西因為措詞不夠嚴謹，或者說覺得寫出來的東西並沒有表達出自己想表達的內容都不好意思發到網上（這跟是否有人看沒有關係，就像你的一個作品，如果做的不好了大概也很少人願意拿出來），其實我覺得不少人都有這樣的心情，但是筆者認為還是應該多寫一些文章，不管寫出來的東西是否漂亮，對個人內化這些總結出來的東西是非常有幫助的，甚至可以拿出自己的東西向文筆比較好的朋友尋求建議，提高自己的寫作表達能力。

架構

其實這個專案我們專案組裡面並沒有專門的架構師做這個部分，關於專案資料流僅在我們幾個開發人員的腦海裡存在，筆者此前也沒有正式擔任專案架構的經驗，只在開發過程中修改過專案架構中不合理的地方。筆者部門採用的敏捷開發模式，這種快速迭代的專案開發模式，要求我們每週都會有可用時間量化考核的工作產出。因此我們每週的工作內容在前一週就已經制定好，但存在這樣的情況：沒有良好的專案架構和和專案的良好理解，你很難去評估你將要做的任務。
但為了工作產出，我們邁出了不太合適的第一步：在沒有專案結構，也不是很清楚事情未來會怎麼樣的情況下，草率的開始了專案開發。或許有人會問：沒有專案架構，你們是怎麼開發專案的。這裡筆者想替一些中小型公司，或者是做內部業務的部門說句公道話：這種事情真的很正常，不光是沒有架構圖，有些公司甚至專案原型都沒有，只靠著技術經理和幾個開發人員的口述就可以開始。
其實專案做到中期，筆者才感覺這個專案就像即將脫繮的野馬，已經有些不受控制了，後來根據已經完成的部分畫出了專案架構的草圖。但此時做這件事情還是有些晚，畫的過程中發現最初靠我們“口述”出來的專案設計有太多的缺陷和不合理的設計。
其實在專案開始之初，如果有條件的話，我們開發人員就應該和專案需求方和我們的需求分析師坐在一起開個會去討論一下實現需求的設計方式。因為需求分析師畢竟不是很懂技術，在需求，開發，需求分析三方的交流過程中會讓開發者更瞭解自己怎麼做和需求方的痛點的契合度更高。
因此在專案開發前，對專案整體的設計是不可或缺的，如果沒有人員流動，架構師讓開發者先理解專案架構也是非常有必要的。如果開發者不知道專案的整體結構，想要讓程式設計師有高價值和高效率的專案產出是可遇不可求的。
關鍵字如下：架構圖，理解專案整體結構。

開發者

作為這個專案的開發者，我大概對這一點很有發言權，對自己在開發中做的不足的地方大概總結如下：

藝術家的氣質

拋開這個專案不提，筆者認為一個有追求的開發者應該對自己的作品像一個藝術家一樣精雕細琢，這和專案是為公司做的還是為自己做的無關，這其實不管是對公司或者對個人的成長都是大有脾益的。其實在這個過程中大多數開發者都有這樣的能力，只是無法讓自己將自己全身心的投入給公司的專案，從而給自己設限，對自己的要求不是做一個優秀的產品，而只是完成工作。換句話說，很多人大概認為自己給公司的付出得不到回報也不會被公司看到。因此對待工作只是敷衍了事，而不是用心去做。
其實筆者認為這種心態在任何性質的工作中都是存在的。作為一個程式設計師，筆者認為做一個專案需要我們把它當作自己事情去做，不僅要讓自己的專案能夠完成功能，也要從細節上打磨自己的作品，敷衍自己的作品就是在敷衍作為開發者的水平。自私點來講，就算是哪一天你離開了自己所在的崗位，也至少讓自己配得上優秀二字。

軟體的熵

這個標題摘自《The Pragmatic Programmer》一書，熵的原意為：體系混亂程度的度量。最早在1947年薛定諤提出熵增的必然性。根據熱力學第二定律推論由以下結論

宇宙的能量保持不變，宇宙的熵將趨於極大值，伴隨著這一程序，宇宙進一步變化的能力越來越小，一切機械的、物理的、化學的、生命的等等多種多樣的運動逐漸全部轉化為熱運動，最終達到處處溫度相等的熱平衡狀態，這時一切變化都不會發生了，宇宙處於死寂的永恆狀態

在軟體開發中，當軟體的無序性增長時，我們稱之為“軟體腐爛”。我們姑且將低劣的設計，錯誤決策，或者一些糟糕的程式碼稱之為“Broken Window”。從熵的角度考慮，出現這些Broken Window是必然的，如果放任不管專案的愈發的趨於無序，因此在開發過程中必須儘可能的減少這些Broken Window的數量，最好是發現一個就修復一個，控制軟體的熵。關於軟體的熵《The Pragmatic Programmer》中一段比較好的描述如下：

我們看到過整潔，執行良好的系統，一旦窗戶開始破裂，就相當迅速的惡化。雖然還有一些其他因素能夠促使軟體腐爛，但與這些因素專案，對破窗戶的置之不理會更快的加速腐爛的程序。

重構

重構是一種防止程式設計逐漸腐敗變質的重要且有效的手段，經常重構會有助於維持住軟體優美的姿態，其實許多軟體的最初設計都是相當優秀的，只不過很多公司的人員流動大，一個專案換了N個開發者，每個人都上來抹兩下，專案很快就會失去它美麗的樣子。重構一種花費現在換取未來的做法，者無疑是會花時間和腦力的，但這是值得的，如果不及時對專案進行重構以維持專案的優雅，或許當下你的進展迅速，但隨著軟體腐爛程度的加重，很快就會讓你對系統的開發過程變得舉步維艱，除錯程式碼，理解系統會變得越來越花時間，甚至造成新的功能難以開發，一個簡單的拓展都要花費很長的時間。總之對專案的及時重構是一件低投入高回報的事情，筆者認為在《重構》一書中對重構帶來的好處描述的非常好，這裡結合筆者自己的理解將重構帶來的積極影響總結如下：
1. 重構會幫助程式碼維持優美的形態，保持專案良好的彈性
2. 重構會幫助你更好的理解專案
3. 重構會提升自己對專案設計的能力