程式碼是敲出來的嗎？是批量生成出來的嗎？

　　No no no，程式碼是設計出來的！

　　如果說到程式碼生成器，大家可能會想到三層、動軟程式碼生成器、資料庫表等等。其一般的思路是，先有資料庫然後根據庫裡的表自動生成一系列的程式碼，包括實體類、持久化、業務層（空函式）、頁面程式碼等，還可以生成資料庫文件。這個確實很好很強大，可以免除程式設計師的機械式的敲程式碼的工作。

（“主要實現在對應資料庫中表的基類程式碼的自動生成，包括生成屬性、新增、修改、刪除、查詢、存在性、Model類構造等基礎程式碼片斷,支援不同3種架構程式碼生成，使程式設計師可以節省大量機械錄入的時間和重複勞動，而將精力集中於核心業務邏輯的開發。”

——摘自動軟官網的介紹　　）

　　但是我們都知道，表的設計是根據客戶的需求、業務邏輯、設計人員的專案經驗設計的，其中最主要的是要受到關係型資料庫自身的特點（所以nosql嘛）。表並不能完整體現業務需求，否則教會客戶使用企業管理器（資料庫的客戶端軟體）就可以了。直接把表交給客戶用，那是不行的，否則程式設計師就集體失業了。

　　總結一下，一般程式碼生成器的思路是：資料庫表——程式碼——文件。

　　而我這裡說的思路是完全相反的：文件——程式碼——資料庫——業務邏輯

　　一般我們做專案的順序是：調研，設計，編碼，測試，上線。其中設計階段要編寫大量的文件，比如功能說明，各種流程圖，領域設計，資料庫設計，原型圖等等。還要編制任務計劃，團隊分工合作。然後開始編碼。編碼的時候會發現，上一階段的各種文件只能看，對於要編寫的程式碼完全沒有直接作用，必須要程式設計師進行“翻譯”。把文件翻譯成程式碼——於是乎苦逼的碼農誕生了！

　　而實際情況是，專案緊任務重時間還短。怎麼辦呢？文件可以沒有或者後補，但是程式碼是不能沒有的，所以往往文件就被忽略甚至完全被幹掉了——這是文件和程式碼的矛盾點。

　　怎麼辦呢？犧牲文件？下面要介紹一把雙刃劍：可以讓文件成為程式碼的助力！可以把碼農從簡單、機械、重複中解脫出來，但是同時也意味著不會再有“碼農”這個崗位！

　　還要從剛進入的這家公司說起。公司主營各種企業管理的專案，採用ABP架構最為底層，然後又進一步封裝。

 　　簡單的說，用EF的code frist做實體類，然後生成資料庫，再根據業務需求設計Dto，有很多很多的Dto。頁面用angularjs做總控和表單，kendoui做列表。儲存部分至少定義一個介面，webapi部分也要定義一個介面。總之面向介面程式設計嘛。還有很多很多，逐步瞭解中。

　　對於新人來說，最大的問題就是——這都哪跟哪呀。有了code frist，也就沒有了資料庫文件。有一大堆dto，但是這些dto都是啥功能？點開挨個看吧。

　　看了兩週還是蒙登。如果有一系列的文件說明該多好？但是大家都知道，任務緊工期短，哪有時間弄文件？

 　　好了又繞回來了，如果我們設計的文件可以自動生成程式碼，是不是一切就都迎刃而解了呢？

　　資料庫角度：先設計資料庫文件，然後自動生成ef的code first 的實體類，然後用ef的資料庫遷移功能建立表。然後生成預設的介面定義。這個沒啥難度吧。

　　業務角度：設計功能模組、頁面，頁面裡面的資料列表、查詢、分頁、刪除、表單等，然後根據這些設計生成對應的Dto，以及相關的介面，還有頁面需要的程式碼。這樣程式碼和文件就都有了。

　　怎麼樣，一份設計實現兩種功能（文件和程式碼）。這時候基本功能就都出來了。然後在生成的程式碼基礎上做一些調整和優化，主要是頁面方面。

　　最後每個專案總會有些特殊的需求，我們就可以集中精力幹掉它們了，

　　對了，還可以生成測試用例，還有測試人員使用的測試平臺也可以結合起來。

　　現在您相信了吧：程式碼是設計出來的！