2017/1/30

為什麼應該要做好專案結構的規畫

首先,先說明一下「規劃專案結構」具體的工作內容是什麼。以二個常見的程式開發平台來說,不管是用 Visual Studio 來開發 .NET 的程式,還是用各種 IDE 來開發 Java 的程式,都會有一組用來輔助 IDE 進行程式專案管理的檔案、甚至會伴隨著一到數個特定的目錄結構。只不過,這些都不是這篇文章要涉及的部份。而是除了這些內容以外,由開發人員自行產生的檔案該如何妥適的進行分門別類的工作,就是這篇文章所提到「規劃專案結構」要主要工作內容。

對很多的從業人員來說,「規劃專案結構」可能是個無足輕重的工作項目,心裡會想:不就是開幾個目錄把檔案往裡面丟就完事了嗎?能編能跑才是王道!會這樣想,大部份應該都是以開發小型專案為主,所以好與不好的專案結構在效益上並沒有太大的差別。

舉個例子,如果你是網拍的賣家,打算做個小本生意,只有一人負責接單、發貨。貨品的種類和數量都不會很多的情況下,進來的貨可能就只是隨手扔在腳邊,不管怎麼堆只要有一套自己的邏輯就行了,不愁找不到貨。但是如果網拍的事業開始小有名氣了、要逐步地擴大規模,發貨的品項或數量都不再是一個人可以負荷得來時,就得要增加人手。一旦人手增加了,同樣的模式下問題就跟著出現。如果放任新加入的人隨個人喜好來擺放貨物、大家各做各的,要如何才能有效地掌握目前存貨的情形?況且人吃五穀雜糧哪有不生病,沒有統一的理貨方法,其他的人要如何接手?所以把例子的層級拉高來看,對於一個成熟的網購業者來說,倉儲就是一門學問,如何設計貨架以便分門別類地來存放貨品,是維持營運的重要環節。

同理可證,很多大型開發專案也都是由小系統開始,應該很少有人會聽到自己的老闆一照面就說:咱們來做個功能無敵豐富的系統唄!大部份應該都是:我有個想法,先做個小系統來看看市場的反應,如何?好吧,既然是個小系統,那開發就隨性一點,看起來有個樣子、功能正常就行了。

跟先前網拍的例子一樣,你怎麼知道你現在的小系統不會意外地發展成大系統?有些人也許會覺得:等到了適當的階段,再一次性地投入資源,進行重構就好啦!不要花時間在無謂的事情上。然而,系統的發展很多時候就像是溫水煮青蛙一般,等察覺到系統已經大到需要有一個較好的分類模式時,程式碼早就已經盤根錯節。在大部分的人都會有的因循苟且心態下,重構?別傻了,只要能夠如期交付工作就上天保祐了,哪有多餘的力氣去做吃力不討好的事。

好的專案結構也是工作品質指標其中一環,當程式碼依據著規則分門別類地放置,在後續的維護上自然會有一定程度的助益。不論是開發人員間工作上的指派、輪調,或是在降低新進人員的學習曲線上,都會比雜亂無章的專案結構要來得成本低。

另外一方面,在物件導向的原則之下,每一個類別的任務應該要儘可能的單純,其中的一個效果就是讓單元測試可以更容易地被開發。在測試程式的涵蓋率達到一定的程度,有自動化回歸測試的輔助,這時候談重構才會有足夠的利基。否則談到重構,最大的恐懼都是來自於對於系統穩定度的疑慮,在這種情況下自然不會有人甘冒風險去更動已經完成的部份。

這時合宜的結構規劃就可以輔助開發人員,做為類別內容是否過於複雜的衡量基準。如果每一個類別功能夠單純,則在分類上就會減少很多模稜兩可的情況出現。反之,則會因為類別負擔了多個任務,在分類上容易出現歧見,或是無法決定該放在哪一個分類之下。

所以古人說「慎始」,同時也說了「勿以惡小而為之」,養成良好的習慣是很重要的一件事。當你是架構師時「規劃專案結構」是你要思考的細節。就算是一人專案,也應該認真地考慮替自己設定一個可以因應系統擴大的準則,為未來承接更大的系統而做好準備。