對付時間不充足的專案的一些思路

氫氦發表於2019-07-25

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

客觀來說，時間不足，資源不足，是專案中的常見情況。有時是因為人的失誤造成的，有時是因為一些難以抵抗的因素。一味怨尤並不能解決問題。針對這個讓人印象深刻的失敗，我決定把作為開發者得到的一些經驗和反思記錄下來，當做教訓。

本文連結：https://www.cnblogs.com/hhelibeb/p/11247004.html

原創內容，轉載請註明

1，持續重構

每一次需求變更都有可能增加程式的複雜度，使設計變差。在時間不足的專案中，這種修改往往尤為頻繁，因為來自上游的需求很可能是在缺少足夠思考和溝通的情況下產生的。為了對抗這種趨勢，必須要時時依據最新的情況重新思考抽象，嘗試重構程式碼，以保證程式碼至少不向更糟糕的方向發展。

在這個專案中，我花了大力氣對一些核心邏輯進行封裝，並且在程式因為需求變化需要修改時不斷地嘗試重構，尋找更好的命名、對齊程式碼、拆分臃腫的類、去除重複程式碼。結果，在上線後這部分程式碼執行得相對良好，只有2個比較輕微的程式碼bug，都是上線前兩天的臨時改動造成的，忙碌導致的開發人員頭腦混亂是bug的主因，程式的設計本身還算過關。

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

能否持續重構是決定程式碼層面成敗的關鍵因素。有兩個原因決定了這點，

人會犯錯，也會學習，持續的重構可以幫助改成錯誤、提高自己。
需求會變，變化會破壞設計，導致程式出現不必要的複雜度，從而難以修改和維護。需要通過重構把被破壞了的設計改善，這樣才能保持良好的設計，避免因為額外複雜度導致開發時間更加緊張。

一個現實的問題是，時間不足的專案裡，可以用於重構的時間會更少，如果用於實現功能的時間都很少，還要怎樣重構程式碼呢？

在這方面，我的經驗是，

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

2，重視問題的處理順序

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

在專案問題逐漸被修復的過程中，一個參與專案較晚的同事問我：我曾經在反饋過一個測試中出現的bug，為什麼你們都忽略了？結果現在導致了很多問題。

我回憶了事情的經過，這個問題沒有引起重視的原因是多方面的，

該同事參與專案太晚，,對很多東西不清楚，之前提出了數個錯誤的問題，導致其它人對她的新發現信任度不高。
問題表現在外部系統，這使得大家對它的熱情很低。
時間緊迫，似乎有必要優先處理更明確的問題。

這三點都不無道理，但我們忽略了一個更重要的問題，那就是一旦這個問題確實存在，將造成嚴重的影響。相比之下，上面的三個理由都是相對主觀的理由，而僅僅是“可能造成嚴重後果”這一個理由，就應該足以引起大家的重視了。所以，在確定問題時，不應只按照“可能性”確定，也應按照結果的嚴重性確定。我想，在專案時間緊張，面臨大量需要處理的問題時，也許應該按照以下順序處理可能性和嚴重性不同的各種問題：