在系統架構設計方面，源代碼是不可忽視的組成部分。中培偉業《詳細設計與系統架構》培訓專家賈老師指出，系統架構中的設計源代碼組織結構在設計過程中有很多需要注意的問題。

賈老師指出，在系統架構源代碼組織結構方面，我們有以下幾個方面的問題需要注意：

一、  開發可管理性

便于人員分工（模塊獨立性、開發工作的負載均衡、進度安排優化、預防人員流動對開發的影響：一個好的構架同時應有助于減少項目組的壓力和緊張，提高軟件開發效率）、利于配置管理、大小的合理性、適度復雜性；

1）便于人員分工－模塊獨立性、層次性

模塊獨立性、層次性是為了保證項目開發成員工作之間的相對獨立性，模塊聯結方式應該是縱向而不是橫向, 模塊之間應該是樹狀結構而不是網狀結構或交叉結構，這樣就可以把開發人員之間的通信、模塊開發制約關系減到最少。同時模塊獨立性也比較利于配置管理工作的進行。現在有越來越多的的軟件開發是在異地進行，一個開發組的成員可能在不同城市甚至在不同國家，因此便于異地開發的人員分工與配置管理的源代碼組織結構是非常必要的。

2）便于人員分工－開發工作的負載均衡

不僅僅是開發出來的軟件系統需要負載均衡，在開發過程中開發小組各成員之間工作任務的負載均衡也是非重要的。所謂工作任務的負載均衡就是通過合理的任務劃分按照開發人員特點進行分配任務，盡量讓項目組中的每個人每段時間都有用武之地。這就需要在構架設計時應當充分考慮項目組手頭的人力資源，在實現客戶需求的基礎上實現開發工作的負載均衡，以提高整體開發效率。

3）便于人員分工－進度安排優化；

進度安排優化的前提是模塊獨立性并搞清楚模塊開發的先后制約關系。利用工作分解結構對所有程序編碼工作進行分解，得到每一項工作的輸入、輸出、所需資源、持續時間、前期應完成的工作、完成后可以進行的工作。然后預估各模塊需要時間，分析各模塊的并行與串行（順序制約），繪制出網絡圖，找出影響整體進度的關鍵模塊，算出關鍵路徑，最后對網絡圖進行調整，以使進度安排最優化。

有個家喻戶曉的智力題叫烤肉片策略：約翰遜家戶外有一個可以同時烤兩塊肉片的烤肉架，烤每塊肉片的每一面需要10分鐘，現要烤三塊肉片給饑腸轆轆急不可耐的一家三口。問題是怎樣才能在最短的時間內烤完三片肉。一般的做法花20分鐘先烤完前兩片，再花20分鐘烤完第三片。有一種更好的方法可以節省10分鐘，大家想想。

4）便于人員分工－預防員工人員流動對開發的影響

人員流動在軟件行業是司空見慣的事情，已經是一個常見的風險。作為對這一風險的有效的防范對策之一，可以在構架設計中考慮到并預防員工人員流動對開發的影響。主要的思路還是在模塊的獨立性上（追求高內聚低耦合），組件化是目前流行的趨勢。

5）利于配置管理（獨立性、層次性）

利于配置管理與利于人員分工有一定的聯系。除了邏輯上的模塊組件要利于人員分工外，物理上的源代碼層次結構、目錄結構、各模塊所處源代碼文件的部署也應當利于人員分工和配置管理。（盡管現在配置管理工具有較強大的功能，但一個清楚的源碼分割和模塊分割是非常有好處的）。 

6）大小的合理性與適度復雜性

大小的合理性與適度復雜性可以使開發工作的負載均衡，便于進度的安排，也可以使系統在運行時減少不必要的內存資源浪費。對于代碼的可閱讀性和系統的可維護性也有一定的好處。另外，過大的模塊常常是系統分解不充分，而過小的模塊有可能降低模塊的獨立性，造成系統接口的復雜。

二、  可維護性

便于在系統出現故障時及時方便地找到產生故障的原因和源代碼位置，并能方便地進行局部修改、切割；（可維護性與運行可管理性不同）

三、  可擴充性：系統方案的升級、擴容、擴充性能

系統在建成后會有一段很長的運行周期，在該周期內，應用在不斷增加，應用的層次在不斷升級，因此采用的構架設計等方案因充分考慮升級、擴容、擴充的可行性和便利

四、  可移植性

不同客戶端、應用服務器、數據庫管理系統：如果潛在的客戶使用的客戶端可能使用不同的操作系統或瀏覽器，其可移植性必須考慮客戶端程序的可移植性，或盡量不使業務邏輯放在客戶端；數據處理的業務邏輯放在數據庫管理系統中會有較好的性能，但如果客戶群中不能確定使用的是同一種數據庫管理系統，則業務邏輯就不能數據庫管理系統中；

達到可移植性一定要注重標準化和開放性：只有廣泛采用遵循國際標準，開發出開放性強的產品，才可以保證各種類型的系統的充分互聯，從而使產品更具有市場競爭力，也為未來的系統移植和升級擴展提供了基礎。

五、  需求的符合性

從源代碼的組織結構看需求的符合型主要考慮針對用戶需求可能的變化的軟件代碼及構架的最小冗余（同時又要使得系統具有一定的可擴展性）。