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

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

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

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

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

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

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

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

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

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

附註

新開了一個架構師的文集，未來打算在這個文集裡不定期地放一些在擔任架構師時的工作經驗或心得，有興趣的朋友可以關注、期待一下。