文檔驅動式代碼設計器——代碼是設計出來的！

 

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

 

　　No no no，代碼是設計出來的！

 

　　若是說到代碼生成器，你們可能會想到三層、動軟代碼生成器、數據庫表等等。其通常的思路是，先有數據庫而後根據庫裏的表自動生成一系列的代碼，包括實體類、持久化、業務層（空函數）、頁面代碼等，還能夠生成數據庫文檔。這個確實很好很強大，能夠免除程序員的機械式的敲代碼的工做。

 

（「主要實如今對應數據庫中表的基類代碼的自動生成，包括生成屬性、添加、修改、刪除、查詢、存在性、Model類構造等基礎代碼片段,支持不一樣3種架構代碼生成，使程序員能夠節省大量機械錄入的時間和重複勞動，而將精力集中於核心業務邏輯的開發。」

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

 

　　可是咱們都知道，表的設計是根據客戶的需求、業務邏輯、設計人員的項目經驗設計的，其中最主要的是要受到關係型數據庫自身的特色（因此nosql嘛）。表並不能完總體現業務需求，不然教會客戶使用企業管理器（數據庫的客戶端軟件）就能夠了。直接把表交給客戶用，那是不行的，不然程序員就集體失業了。

 

　　總結一下，通常代碼生成器的思路是：數據庫表——代碼——文檔。

 

　　而我這裏說的思路是徹底相反的：文檔——代碼——數據庫——業務邏輯

 

　　通常咱們作項目的順序是：調研，設計，編碼，測試，上線。其中設計階段要編寫大量的文檔，好比功能說明，各類流程圖，領域設計，數據庫設計，原型圖等等。還要編制任務計劃，團隊分工合做。而後開始編碼。編碼的時候會發現，上一階段的各類文檔只能看，對於要編寫的代碼徹底沒有直接做用，必需要程序員進行「翻譯」。把文檔翻譯成代碼——因而乎苦逼的碼農誕生了！

 

　　而實際狀況是，項目緊任務重時間還短。怎麼辦呢？文檔能夠沒有或者後補，可是代碼是不能沒有的，因此每每文檔就被忽略甚至徹底被幹掉了——這是文檔和代碼的矛盾點。

 

　　怎麼辦呢？犧牲文檔？下面要介紹一把雙刃劍：可讓文檔成爲代碼的助力！能夠把碼農從簡單、機械、重複中解脫出來，可是同時也意味着不會再有「碼農」這個崗位！

 

　　還要從剛進入的這家公司提及。公司主營各類企業管理的項目，採用ABP架構最爲底層，而後又進一步封裝。

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

 

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

 

　　看了兩週仍是蒙登。若是有一系列的文檔說明該多好？可是你們都知道，任務緊工期短，哪有時間弄文檔？

 　　好了又繞回來了，若是咱們設計的文檔能夠自動生成代碼，是否是一切就都迎刃而解了呢？

 

　　數據庫角度：先設計數據庫文檔，而後自動生成ef的code first 的實體類，而後用ef的數據庫遷移功能創建表。而後生成默認的接口定義。這個沒啥難度吧。

 

　　業務角度：設計功能模塊、頁面，頁面裏面的數據列表、查詢、分頁、刪除、表單等，而後根據這些設計生成對應的Dto，以及相關的接口，還有頁面須要的代碼。這樣代碼和文檔就都有了。

 

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

 

　　最後每一個項目總會有些特殊的需求，咱們就能夠集中精力幹掉它們了，

 

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

 

　　如今您相信了吧：代碼是設計出來的！