代碼是敲出來的嗎？是批量生成出來的嗎？ No no no，代碼是設計出來的！ 如果說到代碼生成器，大家可能會想到三層、動軟代碼生成器、資料庫表等等。其一般的思路是，先有資料庫然後根據庫里的表自動生成一系列的代碼，包括實體類、持久化、業務層（空函數）、頁面代碼等，還可以生成資料庫文檔。這個確實很好很強 ...
代碼是敲出來的嗎？是批量生成出來的嗎？
No no no，代碼是設計出來的！
如果說到代碼生成器，大家可能會想到三層、動軟代碼生成器、資料庫表等等。其一般的思路是，先有資料庫然後根據庫里的表自動生成一系列的代碼，包括實體類、持久化、業務層（空函數）、頁面代碼等，還可以生成資料庫文檔。這個確實很好很強大，可以免除程式員的機械式的敲代碼的工作。
（“主要實現在對應資料庫中表的基類代碼的自動生成，包括生成屬性、添加、修改、刪除、查詢、存在性、Model類構造等基礎代碼片斷,支持不同3種架構代碼生成，使程式員可以節省大量機械錄入的時間和重覆勞動，而將精力集中於核心業務邏輯的開發。”
——摘自動軟官網的介紹 ）
但是我們都知道，表的設計是根據客戶的需求、業務邏輯、設計人員的項目經驗設計的，其中最主要的是要受到關係型資料庫自身的特點（所以nosql嘛）。表並不能完整體現業務需求，否則教會客戶使用企業管理器（資料庫的客戶端軟體）就可以了。直接把表交給客戶用，那是不行的，否則程式員就集體失業了。
總結一下，一般代碼生成器的思路是：資料庫表——代碼——文檔。
而我這裡說的思路是完全相反的：文檔——代碼——資料庫——業務邏輯
一般我們做項目的順序是：調研，設計，編碼，測試，上線。其中設計階段要編寫大量的文檔，比如功能說明，各種流程圖，領域設計，資料庫設計，原型圖等等。還要編製任務計劃，團隊分工合作。然後開始編碼。編碼的時候會發現，上一階段的各種文檔只能看，對於要編寫的代碼完全沒有直接作用，必須要程式員進行“翻譯”。把文檔翻譯成代碼——於是乎苦逼的碼農誕生了！
而實際情況是，項目緊任務重時間還短。怎麼辦呢？文檔可以沒有或者後補，但是代碼是不能沒有的，所以往往文檔就被忽略甚至完全被幹掉了——這是文檔和代碼的矛盾點。
怎麼辦呢？犧牲文檔？下麵要介紹一把雙刃劍：可以讓文檔成為代碼的助力！可以把碼農從簡單、機械、重覆中解脫出來，但是同時也意味著不會再有“碼農”這個崗位！
還要從剛進入的這家公司說起。公司主營各種企業管理的項目，採用ABP架構最為底層，然後又進一步封裝。
簡單的說，用EF的code frist做實體類，然後生成資料庫，再根據業務需求設計Dto，有很多很多的Dto。頁面用angularjs做總控和表單，kendoui做列表。存儲部分至少定義一個介面，webapi部分也要定義一個介面。總之面向介面編程嘛。還有很多很多，逐步瞭解中。
對於新人來說，最大的問題就是——這都哪跟哪呀。有了code frist，也就沒有了資料庫文檔。有一大堆dto，但是這些dto都是啥功能？點開挨個看吧。
看了兩周還是蒙登。如果有一系列的文檔說明該多好？但是大家都知道，任務緊工期短，哪有時間弄文檔？
好了又繞回來了，如果我們設計的文檔可以自動生成代碼，是不是一切就都迎刃而解了呢？
資料庫角度：先設計資料庫文檔，然後自動生成ef的code first 的實體類，然後用ef的資料庫遷移功能建立表。然後生成預設的介面定義。這個沒啥難度吧。
業務角度：設計功能模塊、頁面，頁面裡面的數據列表、查詢、分頁、刪除、表單等，然後根據這些設計生成對應的Dto，以及相關的介面，還有頁面需要的代碼。這樣代碼和文檔就都有了。
怎麼樣，一份設計實現兩種功能（文檔和代碼）。這時候基本功能就都出來了。然後在生成的代碼基礎上做一些調整和優化，主要是頁面方面。
最後每個項目總會有些特殊的需求，我們就可以集中精力幹掉它們了，
對了，還可以生成測試用例，還有測試人員使用的測試平臺也可以結合起來。
現在您相信了吧：代碼是設計出來的！
