文檔驅(qū)動式代碼設(shè)計器——代碼是設(shè)計出來的！

2016-10-22 10:07 by 金色海洋（jyk）陽光男孩, 497 閱讀, 3 評論, 收藏, 編輯

 

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

 

No no no，代碼是設(shè)計出來的！

 

如果說到代碼生成器，大家可能會想到三層、動軟代碼生成器、數(shù)據(jù)庫表等等。其一般的思路是，先有數(shù)據(jù)庫然后根據(jù)庫里的表自動生成一系列的代碼，包括實體類、持久化、業(yè)務(wù)層（空函數(shù)）、頁面代碼等，還可以生成數(shù)據(jù)庫文檔。這個確實很好很強大，可以免除程序員的機械式的敲代碼的工作。

 

（“主要實現(xiàn)在對應(yīng)數(shù)據(jù)庫中表的基類代碼的自動生成，包括生成屬性、添加、修改、刪除、查詢、存在性、Model類構(gòu)造等基礎(chǔ)代碼片斷,支持不同3種架構(gòu)代碼生成，使程序員可以節(jié)省大量機械錄入的時間和重復勞動，而將精力集中于核心業(yè)務(wù)邏輯的開發(fā)?！?

——摘自動軟官網(wǎng)的介紹　　）

 

但是我們都知道，表的設(shè)計是根據(jù)客戶的需求、業(yè)務(wù)邏輯、設(shè)計人員的項目經(jīng)驗設(shè)計的，其中最主要的是要受到關(guān)系型數(shù)據(jù)庫自身的特點（所以nosql嘛）。表并不能完整體現(xiàn)業(yè)務(wù)需求，否則教會客戶使用企業(yè)管理器（數(shù)據(jù)庫的客戶端軟件）就可以了。直接把表交給客戶用，那是不行的，否則程序員就集體失業(yè)了。

 

總結(jié)一下，一般代碼生成器的思路是：數(shù)據(jù)庫表——代碼——文檔。

 

而我這里說的思路是完全相反的：文檔——代碼——數(shù)據(jù)庫——業(yè)務(wù)邏輯

 

一般我們做項目的順序是：調(diào)研，設(shè)計，編碼，測試，上線。其中設(shè)計階段要編寫大量的文檔，比如功能說明，各種流程圖，領(lǐng)域設(shè)計，數(shù)據(jù)庫設(shè)計，原型圖等等。還要編制任務(wù)計劃，團隊分工合作。然后開始編碼。編碼的時候會發(fā)現(xiàn)，上一階段的各種文檔只能看，對于要編寫的代碼完全沒有直接作用，必須要程序員進行“翻譯”。把文檔翻譯成代碼——于是乎苦逼的碼農(nóng)誕生了！

 

而實際情況是，項目緊任務(wù)重時間還短。怎么辦呢？文檔可以沒有或者后補，但是代碼是不能沒有的，所以往往文檔就被忽略甚至完全被干掉了——這是文檔和代碼的矛盾點。

 

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

 

還要從剛進入的這家公司說起。公司主營各種企業(yè)管理的項目，采用ABP架構(gòu)最為底層，然后又進一步封裝。

 　　簡單的說，用EF的code frist做實體類，然后生成數(shù)據(jù)庫，再根據(jù)業(yè)務(wù)需求設(shè)計Dto，有很多很多的Dto。頁面用angularjs做總控和表單，kendoui做列表。存儲部分至少定義一個接口，webapi部分也要定義一個接口?？傊嫦蚪涌诰幊搪?。還有很多很多，逐步了解中。

 

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

 

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

 　　好了又繞回來了，如果我們設(shè)計的文檔可以自動生成代碼，是不是一切就都迎刃而解了呢？ <