對付時間不充足的項目的一些思路

最近參與了一個十分倉促的SAP項目，不管是需求收集、功能設計、程序實現、測試、用戶培訓，幾乎每一個環節都有不小的疏漏。最終匆忙上線，天然也致使了悲劇性的結果：上線次日就發現了幾百個訂單錯誤，用戶的投訴紛至沓來，後續又持續地產生其它錯誤和誤解。在接下來的一週裏面，項目相關人幾乎天天都要加班到深夜，並且天天中午都要上線一個「十分重要」的補丁，來解決前一天發現的問題...在六七天的努力事後，風波總算漸漸平息。

客觀來講，時間不足，資源不足，是項目中的常見狀況。有時是由於人的失誤形成的，有時是由於一些難以抵抗的因素。一味怨尤並不能解決問題。針對這個讓人印象深入的失敗，我決定把做爲開發者獲得的一些經驗和反思記錄下來，當作教訓。

本文連接：http://www.javashuo.com/article/p-wwiwdnac-er.html 

原創內容，轉載請註明

1，持續重構

每一次需求變動都有可能增長程序的複雜度，使設計變差。在時間不足的項目中，這種修改每每尤其頻繁，由於來自上游的需求極可能是在缺乏足夠思考和溝通的狀況下產生的。爲了對抗這種趨勢，必需要時時依據最新的狀況從新思考抽象，嘗試重構代碼，以保證代碼至少不向更糟糕的方向發展。

在這個項目中，我花了大力氣對一些核心邏輯進行封裝，而且在程序由於需求變化須要修改時不斷地嘗試重構，尋找更好的命名、對齊代碼、拆分臃腫的類、去除重複代碼。結果，在上線後這部分代碼運行得相對良好，只有2個比較輕微的代碼bug，都是上線前兩天的臨時改動形成的，忙碌致使的開發人員頭腦混亂是bug的主因，程序的設計自己還算過關。此外，雖然上線後產生了一些緊急的需求變化，但由於相關程序的可讀性較好，耦合度不高，程序層面的變動就獲得了快速、有效的實現。

但在有一個「不過重要」的批處理程序發生了嚴重的翻車事故。早先，咱們對這個程序的指望是用來處理一些數量極爲有限的「例外」訂單，它出場的次數不會不少，即使有bug，影響範圍也應當十分有限。因爲我自信在上面的核心邏輯的實現中已經取得了成功，傲慢和焦躁的我只是草草寫完了這個程序，對後續的需求變化，也只是簡單地找到看起來正確的程序位置，註釋重寫幾行代碼，或者插入若干if-else之類的語句，並無關心重構問題。可上線以後，實際狀況很糟糕。因爲需求溝通的失誤，「例外」訂單的數量大大超出預期，批處理程序沒有正確地處理異常，反而由於程序bug形成了進一步的異常。經過對它的檢查，我發現，這個短短几百行的程序中包含多個低級錯誤，各類if-else的交織遠比本身當初想象中的要複雜...我不得不把這個程序改了又改，修改屢次以後才勉強保證它能正常運做。這即是不重構的惡果。若是有足夠的重構的話，問題也許早就暴露了——或者即使不暴露，也會很容易地被修復。

可否持續重構是決定代碼層面成敗的關鍵因素。有兩個緣由決定了這點，

1. 人會犯錯，也會學習，持續的重構能夠幫助改爲錯誤、提升本身。
2. 需求會變，變化會破壞設計，致使程序出現沒必要要的複雜度，從而難以修改和維護。須要經過重構把被破壞了的設計改善，這樣才能保持良好的設計，避免由於額外複雜度致使開發時間更加緊張。

一個現實的問題是，時間不足的項目裏，能夠用於重構的時間會更少，若是用於實現功能的時間都不多，還要怎樣重構代碼呢？

在這方面，個人經驗是，

1. 時間不足的項目每每有管理不善的因素，而管理不善，一般意味着各個過程的銜接可能會有問題。工做銜接上的問題會形成溝通不足和低效等負面影響，但也極可能會在某些階段讓開發者有一些空閒時間。抓緊利用這些時間重構吧！
2. 好的抽象是重構的基礎，在對代碼實際重構前，心中首先要有個好的抽象，而抽象是不包含不少具體細節的，這意味着開發者不必定要面對代碼才能思考重構，理論上，吃飯、走路、洗澡的時候也能夠進行相關思考。固然，前提是開發者確實還要有精力作多餘的思考。

2，重視問題的處理順序

讓咱們感到很遺憾的一個狀況是，有好幾個重要問題其實在上線前就已經被部分同事想到/發現了，但因爲各類緣由，它們都沒有引發足夠的重視。

在項目問題逐漸被修復的過程當中，一個參與項目較晚的同事問我：我曾經在反饋過一個測試中出現的bug，爲何大家都忽略了？結果如今致使了不少問題。

我回憶了事情的通過，這個問題沒有引發重視的緣由是多方面的，

1. 該同事參與項目太晚，,對不少東西不清楚，以前提出了數個錯誤的問題，致使其它人對她的新發現信任度不高。
2. 問題表如今外部系統，這使得你們對它的熱情很低。
3. 時間緊迫，彷佛有必要優先處理更明確的問題。

這三點都不無道理，但咱們忽略了一個更重要的問題，那就是一旦這個問題確實存在，將形成嚴重的影響。相比之下，上面的三個理由都是相對主觀的理由，而僅僅是「可能形成嚴重後果」這一個理由，就應該足以引發你們的重視了。因此，在肯定問題時，不該只按照「可能性」肯定，也應按照結果的嚴重性肯定。我想，在項目時間緊張，面臨大量須要處理的問題時，也許應該按照如下順序處理可能性和嚴重性不一樣的各類問題：

1. 肯定的、後果嚴重的：最優先處理，對其進行修復。
2. 不肯定的、後果嚴重的：次優先處理，對其進行調查。
3. 肯定的、後果輕微的：延後處理，對其進行修復。
4. 不肯定的、後果輕微的：延後處理，對其進行調查，或忽略。

下圖是我畫的一個問題管理象限圖：

 

3，保持樂觀

在進度的重壓下，保持樂觀的心態十分重要。我是容易長吁短嘆的類型，可是我發現一些優秀的同事每每更能苦中做樂，在你們疲憊不堪的時候想出不少笑話，讓你們稍稍變得開心和放鬆起來。這在無形當中給了你們不少幫助，值得我學習。

困難總會過去，保持樂觀，也許能幫助咱們更好地度過難關。

總結

用三句話來總結三段內容，

1. 經過持續的重構，不斷消解額外的複雜度，保持健康的代碼設計。
2. 按合理的順序調查和解決問題，準確肯定真正重要的問題，讓時間花費更有「性價比」。
3. 樂觀，堅持。

 

參考文章：

時間「四象限」法