軟體工程中設計與編碼

 

GF常說我吃家裡飯操別人的心。

父親常被母親這樣“罵”，這是我家的宿命。

以前都是一個人開發，從有想法，到最後發布到網上。

而且都是一些很小的工具軟體，因此，沒有體會到設計的重要性。

由於喜歡編程，在這方面的文章看得自然多一些，知道有種說法是：軟體工程70%的設計，寫代碼只佔30%。

最近，由於5個人在開發一個小項目，前期只有幾個頁面，由於涉及到後期的東西，為了後期考慮，將業務層寫得很複雜，將現實中的事物基本是一對一的映射成類/集等。

其實幾個頁面，一個人幾下搞定，但是為什麼，我們目前還沒有完成呢？

不是專案經理沒努力，也不是成員們偷懶。

那誰來承擔責任呢？

這不是問題，誰承擔責任，對以後的項目有好處嗎？沒有！

找到導致此情況的原因，並在以後的項目中避免再犯此錯。

設計！！

是設計！

在我僅參加的一次項目會議上，記得已經有人提出了問題，是那種由感而發的問題，感覺到有某個地方有點不正常。

的確，他感覺到了，並提出了－－“設計稍顯粗糙”。

現在，我們為此付出代價了，周一應該測試的，可我們周末加2天班，仍然沒有看到曙光！

今天周二了，曙光在哪裡，我仍沒看到。

那這麼久，我們在作了什嗎？

專案經理，是最累的，大家都看得到。

可以說“頭髮都想白了”，這話來形容，太貼切了。

其他4人呢？

在內耗！注意在這裡“內耗”是中性的意思。非貶非褒！

由於沒有細緻的設計階段應該出來的文檔，成員們只有事無具細都找專案經理交流。

你想，換誰，再好的脾氣，再好的涵養也會瘋狂的。

4個人，每人一天問N個問題。N>20。而被問的這個人，不是專門解答問題的，他還在“想白頭髮”的在思考，如何設計。

他此時會是多少進程在同時運行，還不斷有4個無規律的中斷事件進來發出請求。電腦都要死機，何況是人。

在這種情況下，設計出來的東西，當然不算好，分配任務也不會很合適。

於是成員們，會花很多的時間來猜測和尋找，自己需要的資料，從哪個類，用哪個方法取出來。如果有一點不清楚，先自己想（都不忍心再去打擾專案經理），花了N多時間，沒解決，然後，再去找專案經理。

即使這樣，進展也很緩慢。品質也不高。而每個人都覺得很艱難。

正好，這樣惡性迴圈，進展慢，時間緊，“頭髮白”想出來的，業務層設計，注釋和說明就盡量的少了，節省時間嘛。導致，其他人看不明白，又不好意思頻繁地去刺激老大，只有自己想，實在想不出再去刺激老大一下。

如果遇上老大在苦想階段，這交流效果肯定不好，兩個人說了半天，都還不知道對方的意思。

好了，不再嘮叨這沒有詳細設計就開工的負面情況了。

如果！我們來總結一下，加上如果。至少今後，可以按“如果”來作作。我在此只是設想一下，如前所述，我一個人開發慣了。並沒有團隊開發的經驗。如有不對之處，還請指證。

一個項目，不論大小，只要不是一個人開發，就需要每個參與者都對此項目很瞭解，特別是要瞭解“它”是如何設計的。哪個類，哪個方法，是作什麼的。這個是起碼的要求。

但是在缺乏設計文檔的情況下，一邊開發，一邊定義類，介面，而以時間緊為由，沒有寫清楚，這定義的這些東西是作什麼的？怎麼用？

那別人會花更多的時間來猜測這個東西是作什麼的，怎麼用？浪費的時間，比別人自己從資料庫寫到表現層更多。

在設計階段，我們幾個開發人員一起，進行N次討論（或稱會議吧），作什麼呢？

從用例討論到抽象，從介面層的按鈕的放置到資料表的欄位定義。並形成文檔。

文檔細緻到有每個類及類應該有的屬性，方法。

這樣每個方法返回什麼，實現什麼功能，都確定好了。

而且有一個好處是：避免了在始真正寫代碼時，發現這也缺一點，那也不合適，這樣調整起來，會發現，改了這裡一個問題，那裡又出了更多問題。

這樣會將前期的設計搞得面目全非－－－（套用一句話，真的會“連他媽都不認識”）。

如果設計時，大家一起討論並一起將這些細緻到類和介面及其目標和參數，如果有不妥的地方，會在下一次討論時，大家一起修正。

修本文檔和在實際開發中修正代碼容易不是一點兩點，對吧。

到這裡，我們就可以真正的實現設計70%（大家在一起討論，氣氛很好，不會緊張和覺得打擾到對方）。

在編碼的時，可以從文檔中依葫蘆畫瓢，輕鬆簡單，不會再頻繁地去打擾其他成員的思路。

編碼真就成了一個體力活了，不會常常看到扣破腦袋的情形了。有的只是邊聽音樂，邊優雅的敲擊鍵盤。

於是一個項目就在輕鬆團結的背景下完成了。