首先，先說明一下「規劃專案結構」具體的工作內容是什麼。以二個常見的程式開發平台來說，不管是用 Visual Studio 來開發 .NET 的程式，還是用各種 IDE 來開發 Java 的程式，都會有一組用來輔助 IDE 進行程式專案管理的檔案、甚至會伴隨著一到數個特定的目錄結構。只不過，這些都不是這篇文章要涉及的部份。而是除了這些內容以外，由開發人員自行產生的檔案該如何妥適的進行分門別類的工作，就是這篇文章所提到「規劃專案結構」要主要工作內容。
對很多的從業人員來說，「規劃專案結構」可能是個無足輕重的工作項目，心裡會想：不就是開幾個目錄把檔案往裡面丟就完事了嗎？能編能跑才是王道！會這樣想，大部份應該都是以開發小型專案為主，所以好與不好的專案結構在效益上並沒有太大的差別。
舉個例子，如果你是網拍的賣家，打算做個小本生意，只有一人負責接單、發貨。貨品的種類和數量都不會很多的情況下，進來的貨可能就只是隨手扔在腳邊，不管怎麼堆只要有一套自己的邏輯就行了，不愁找不到貨。但是如果網拍的事業開始小有名氣了、要逐步地擴大規模，發貨的品項或數量都不再是一個人可以負荷得來時，就得要增加人手。一旦人手增加了，同樣的模式下問題就跟著出現。如果放任新加入的人隨個人喜好來擺放貨物、大家各做各的，要如何才能有效地掌握目前存貨的情形？況且人吃五穀雜糧哪有不生病，沒有統一的理貨方法，其他的人要如何接手？所以把例子的層級拉高來看，對於一個成熟的網購業者來說，倉儲就是一門學問，如何設計貨架以便分門別類地來存放貨品，是維持營運的重要環節。
同理可證，很多大型開發專案也都是由小系統開始，應該很少有人會聽到自己的老闆一照面就說：咱們來做個功能無敵豐富的系統唄！大部份應該都是：我有個想法，先做個小系統來看看市場的反應，如何？好吧，既然是個小系統，那開發就隨性一點，看起來有個樣子、功能正常就行了。
跟先前網拍的例子一樣，你怎麼知道你現在的小系統不會意外地發展成大系統？有些人也許會覺得：等到了適當的階段，再一次性地投入資源，進行重構就好啦！不要花時間在無謂的事情上。然而，系統的發展很多時候就像是溫水煮青蛙一般，等察覺到系統已經大到需要有一個較好的分類模式時，程式碼早就已經盤根錯節。在大部分的人都會有的因循苟且心態下，重構？別傻了，只要能夠如期交付工作就上天保祐了，哪有多餘的力氣去做吃力不討好的事。
好的專案結構也是工作品質指標其中一環，當程式碼依據著規則分門別類地放置，在後續的維護上自然會有一定程度的助益。不論是開發人員間工作上的指派、輪調，或是在降低新進人員的學習曲線上，都會比雜亂無章的專案結構要來得成本低。
另外一方面，在物件導向的原則之下，每一個類別的任務應該要儘可能的單純，其中的一個效果就是讓單元測試可以更容易地被開發。在測試程式的涵蓋率達到一定的程度，有自動化回歸測試的輔助，這時候談重構才會有足夠的利基。否則談到重構，最大的恐懼都是來自於對於系統穩定度的疑慮，在這種情況下自然不會有人甘冒風險去更動已經完成的部份。
這時合宜的結構規劃就可以輔助開發人員，做為類別內容是否過於複雜的衡量基準。如果每一個類別功能夠單純，則在分類上就會減少很多模稜兩可的情況出現。反之，則會因為類別負擔了多個任務，在分類上容易出現歧見，或是無法決定該放在哪一個分類之下。
所以古人說「慎始」，同時也說了「勿以惡小而為之」，養成良好的習慣是很重要的一件事。當你是架構師時「規劃專案結構」是你要思考的細節。就算是一人專案，也應該認真地考慮替自己設定一個可以因應系統擴大的準則，為未來承接更大的系統而做好準備。
對很多的從業人員來說，「規劃專案結構」可能是個無足輕重的工作項目，心裡會想：不就是開幾個目錄把檔案往裡面丟就完事了嗎？能編能跑才是王道！會這樣想，大部份應該都是以開發小型專案為主，所以好與不好的專案結構在效益上並沒有太大的差別。
舉個例子，如果你是網拍的賣家，打算做個小本生意，只有一人負責接單、發貨。貨品的種類和數量都不會很多的情況下，進來的貨可能就只是隨手扔在腳邊，不管怎麼堆只要有一套自己的邏輯就行了，不愁找不到貨。但是如果網拍的事業開始小有名氣了、要逐步地擴大規模，發貨的品項或數量都不再是一個人可以負荷得來時，就得要增加人手。一旦人手增加了，同樣的模式下問題就跟著出現。如果放任新加入的人隨個人喜好來擺放貨物、大家各做各的，要如何才能有效地掌握目前存貨的情形？況且人吃五穀雜糧哪有不生病，沒有統一的理貨方法，其他的人要如何接手？所以把例子的層級拉高來看，對於一個成熟的網購業者來說，倉儲就是一門學問，如何設計貨架以便分門別類地來存放貨品，是維持營運的重要環節。
同理可證，很多大型開發專案也都是由小系統開始，應該很少有人會聽到自己的老闆一照面就說：咱們來做個功能無敵豐富的系統唄！大部份應該都是：我有個想法，先做個小系統來看看市場的反應，如何？好吧，既然是個小系統，那開發就隨性一點，看起來有個樣子、功能正常就行了。
跟先前網拍的例子一樣，你怎麼知道你現在的小系統不會意外地發展成大系統？有些人也許會覺得：等到了適當的階段，再一次性地投入資源，進行重構就好啦！不要花時間在無謂的事情上。然而，系統的發展很多時候就像是溫水煮青蛙一般，等察覺到系統已經大到需要有一個較好的分類模式時，程式碼早就已經盤根錯節。在大部分的人都會有的因循苟且心態下，重構？別傻了，只要能夠如期交付工作就上天保祐了，哪有多餘的力氣去做吃力不討好的事。
好的專案結構也是工作品質指標其中一環，當程式碼依據著規則分門別類地放置，在後續的維護上自然會有一定程度的助益。不論是開發人員間工作上的指派、輪調，或是在降低新進人員的學習曲線上，都會比雜亂無章的專案結構要來得成本低。
另外一方面，在物件導向的原則之下，每一個類別的任務應該要儘可能的單純，其中的一個效果就是讓單元測試可以更容易地被開發。在測試程式的涵蓋率達到一定的程度，有自動化回歸測試的輔助，這時候談重構才會有足夠的利基。否則談到重構，最大的恐懼都是來自於對於系統穩定度的疑慮，在這種情況下自然不會有人甘冒風險去更動已經完成的部份。
這時合宜的結構規劃就可以輔助開發人員，做為類別內容是否過於複雜的衡量基準。如果每一個類別功能夠單純，則在分類上就會減少很多模稜兩可的情況出現。反之，則會因為類別負擔了多個任務，在分類上容易出現歧見，或是無法決定該放在哪一個分類之下。
所以古人說「慎始」，同時也說了「勿以惡小而為之」，養成良好的習慣是很重要的一件事。當你是架構師時「規劃專案結構」是你要思考的細節。就算是一人專案，也應該認真地考慮替自己設定一個可以因應系統擴大的準則，為未來承接更大的系統而做好準備。