軟件的核心任務不外乎是收集和整理數據，然後以用戶需要的形式表現給他們而已，此外還有數據的存儲，數據的傳輸等外圍任務。
數據的收集，整理，表現，存儲和傳輸就是軟件的主要任務，它們也是程序員的主要工作內容，也是程序員編寫代碼的最終目的。
那麼該如何編寫代碼讓軟件完成它的主要任務呢？編寫代碼的過程是否有規律可循？編寫代碼需要注意那些方面的問題？本人想就這些問題羅列自己一些粗淺的看法，並大家進行一些探討。
一.軟件構建從需求開始
需求即用戶對軟件功能的描述，用戶通過需求告訴程序員他需要收集什麼數據，這些數據該怎麼處理，最後他希望看到什麼結果。需求中描述的場景和內容是軟件處理的核心領域，程序員需要通過代碼把它表現出來。
即使用戶是和你一樣的程序員，需求也不可能完善到直接指導編碼的地步，而且軟件的構建是一個“邪惡（Wicked）”的過程，也就是說某些問題在設計階段並不顯山露水，只有在構建過程中它們纔會逐漸暴露出來。這就要求程序員深入問題的領域，瞭解領域的相關知識，對領域做出合理的抽象，並在軟件構建過程中不斷完善它，直到完全實現用戶需求，具備現代軟件的八個主要特徵。
二.何謂領域和領域模型
領域即業務領域，是用戶進行業務活動的主要內容。一些領域是和現實世界中的實體對應的：如僱員管理系統中的僱員，圖書管理系統中的圖書，零售系統中的商品，而有些領域和現實世界中的虛擬實體相對應：如金融系統中的借貸關係，商務系統中的合同關係等。
軟件的主要任務是數據的收集，整理，表現，存儲和傳輸，而數據的基本單位就是領域模型。
領域模型是現實世界中的實體在代碼中的體現和合理抽象，它能表現出實體的基本信息。如果可以說軟件環境是現實業務活動在計算機世界的模擬的話，那領域模型就是現實實體在計算機世界的模擬。
三.軟件構建的核心是領域模型的建立
領域模型是軟件需要處理的數據的基本單元，只有建立起了領域模型，你才能知道軟件需要收集，整理，表現，存儲和傳輸的對象是什麼。
建立領域模型是軟件構建的核心環節，如果它沒有被合理抽象出來的話，軟件能提供的服務，數據的持久化和數據在軟件中的表現都是空中樓閣，因此我們可以說，從現實世界中的實體中抽象出合理的領域模型是軟件構建中提綱挈領的一個環節，這一步是軟件各個層次的基石，也是軟件構建的起點。
不建立領域模型並非一定不能造就出能運轉正常的軟件，所謂的表維護程序就是典型例子，它們由某些懶惰，愚蠢和無能的程序員造就，他們從來不去認真思考用戶究竟想知道什麼，程序究竟在處理什麼，而是翻譯堆砌代碼，僅僅讓它能跑出一個正確的結果而已，這樣的程序員永遠成爲不了優秀的程序員，他們生產出的代碼也是一堆有危害性的幾乎無法維護的垃圾，這堆垃圾將給公司和個人帶來潛在的危害，相對而言，對個人的危害性更大，有時甚至可以斷送一個程序員的職業生涯。
四.如何建立起領域模型
途徑一：分析業務中的業務流和業務規則,從中歸納出功能的基本單位,這個基本單位就是領域模型之一或領域模型的一部分.
途徑二：從原型界面中觀察顯示的數據,它們是領域模型的外在體現.
途徑三 ：從持久化介質中推導領域模型,如從數據庫的表結構和ER圖中推導領域模型.
途徑四：向領域專家問詢業務流程中的核心單元是什麼，甚至自己進入問題領域去學習探究。
途徑五：將不熟悉的領域和相似的自己熟悉的領域做對照，類比出領域模型。
途徑六：從已有的知識系統中學習，參考功能相似的軟件代碼，向優秀代碼學習。
五.如何完善領域模型
領域模型是經常發生相互聯繫的,上一步只是建立了孤立的,僅能表現單個領域對象信息的模型,要使它們豐富完善起來,需要做以下工作:
1) 從程序的功能角度入手,考慮需要幾個領域對象才能完成這個功能,再由此考慮領域對象之間的聯繫.這方面的典型例子是需要僱員類和資源類的協助,借貸關係才能完整的表現出來.
2) 從領域對象本身入手,考慮領域對象之間是否有級聯,回溯,包含等常見關係.如個人信息包含地址信息,公司類和僱員類的級聯關係,僱員類查找自己所屬公司的回溯關係等.
3) 從反持久化入手,考慮把一個領域對象從存儲介質中提取出來需要那些領域對象的幫助,這些領域對象是通過那種方式聯繫在一起的,這方面的典型例子是表之間的主鍵和外鍵,領域對象同樣也要具有相對應的成員變量.
六.領域對象設計完成之後
一旦領域對象設計完成,程序的設計工作就可以說完成了一大半,其餘工作都是圍繞領域對象來進行,這些工作有:
1) 從考慮怎麼爲領域對象服務入手,爲領域對象設計服務類,服務類的常用方法有添加,刪除,更新,查詢領域對象四種以及從ID取得一個領域對象,判斷持有某個ID的領域對象是否存在等.具體的操作實際上由服務類的持久層類成員完成,服務類實際上起到的是一個領域對象上下傳輸通道的作用.一般來說Service層的六大函數是add，delete，update ,search, hasId(String id), getById(String id)）再加上一些用於查詢的函數。
2) 考慮到實現服務類中要求的方法,設計持久層類,其中的成員函數基本是服務類的六大方法的具體化,持久層類實際上起到一個把領域對象存儲到持久介質中和從持久介質中取出領域對象的作用.如果持久層是關係型數據庫的話，還需要設計領域對象對應的表以及表之間的關係ER圖。
3) 從功能的角度設計控制層的函數和類,在這裏控制層類調用服務層類來操作領域對象,業務邏輯主要體現在這裏.
4) 從領域對象的輸入輸出和表現的角度設計各個表現層類.設計這一層類時應該從用戶立場考慮而不是從代碼編寫者的立場考慮,怎麼讓用戶感到直觀,方便,快捷就怎麼設計界面.
5) 在設計上述層次的同時,考慮到減少重複代碼,突出主幹代碼而設計實用層類,把共通的操作都歸納到一起,這樣既提高的代碼的清晰程序和可讀性,也使修改變得方便容易起來.
6) 如果有些變量在使用過程中是可能發生變化的,如數據庫的地址,業務中一些硬編碼信息等,這樣的量就不該硬編碼（Hard Code）在程序中,否則修改後還需要重新編譯,打包,發佈.而應該把這些量寫在XML形式的配置文件裏,在程序啓動時讀取.
七.軟件的六大層次
上頁的工作完成後,我們會得到以下六大層次:
1) Domain層
2) Service層(允許Control層訪問,能訪問Persistence層)
3) Persistence層(也稱爲DAO層,只允許Service層訪問)
4) Control層(訪問Service層和View層)
5) View層(僅被Control層訪問)
6) Util層
八.一定要限制各層之間的無規則通信
如果不規定各層之間的通信規則，那麼它們之間的通信將會肆意的發生，這將使軟件結構混亂直到不可收拾的地步。
在分層中，有一點特別重要，即不同層次之間相互通信的規則。如果所有的層次都能和其它層次通信，你就完全失去了把它們分開帶來的好處，應該通過限制層次之間的通信來讓每個層次更加有意義
九.逐步完善六大層次中類的各個具體函數
這一層的設計包括把每個類細分爲子程序。在上一步已經定義了其中一些子程序，這一步將使類更加細化豐富起來。
完整的定義出類內部的子程序，常常有助於更好的理解類的接口，反過來，這又有利於對類的接口進行進一步的修改。
將類分解爲子程序時：首先要想到這個類的基本功能和在類層次中的定位是什麼？其次要想到它被上級類調用的接口是什麼和它該怎麼調用下級類？再次要想到爲豐富這些接口類中還需要那些字段和方法？最後考慮是用返回值還是異常來控制程序流程。
十.繪出各層次類的靜態類圖
靜態類圖能幫助我們思考各類之間的關係和類內部的各函數,通過靜態類圖我們還能發現各類共通的接口,由此可以對已有的類進行進一步抽象和歸納.
十一.最後的步驟：子程序內部的設計
在子程序層次上進行設計就是爲每個子程序佈置詳細的功能。這裏的設計工作包括繪製流程圖，選擇算法，組織子程序內部的代碼塊，考慮和工具層類的調用關係以及最後用編程語言編寫代碼。
在書寫代碼時,可能會遇到複雜的處理,這時可以通過流程圖來理清思路，幫助思考.
十二.軟件的最終需要具備的現代軟件的八個典型特徵
最小的複雜度:整個系統可以分解爲簡單而易於理解的各個部分.
易於維護:程序有良好的可維護性.
鬆散耦合,通過應用類接口中的合理抽象,封裝性以及信息隱藏等原則,設計出相互關聯儘可能最少的類.
適應變化: 能在不改變系統基本構架的基礎上,適應未來的變化,有良好的擴展性,程序可擴展,可重用.
有明晰的層次,每層各司其職,有良好分工.
高扇入低扇出:系統很好的利用了較低層次上的工具類,重複代碼很少或沒有.
有良好的規範:無論多少人蔘與了項目,從代碼看來猶如出自一人之手.
使用標準技術.(以上八點來自<<代碼大全2>>)
軟件編寫完成後，可以自我審覈一下看看是否達到了這些特徵。