在程序開發的世界裡，各路前輩們為了提高所謂的編碼速度，搞出了各式各樣的代碼生成器，來避免所謂的重複的人為機械地粘貼和複製代碼，以此來提高生產力。
早幾年前，我可能會認為這樣的做法真得有用，特別是在編碼速度上。是的，有時候代碼生成器是可以幫助我們開發者生成模板化的，規範化的，大批量的機器代碼。但許多人就將它當做了程序開發的利器，沒有代碼生成器完全沒法寫代碼了，也沒辦法工作了。
覺得自己會用幾款代碼生成器好像很牛的樣子。得意的在老闆們，或是不懂技術的技術經理們面前炫耀：「XXX們，你看我的工作效率多高，你們的需求，你們想要的功能我只需要簡單的代碼生成就可以快速地搞定。」。這種做法就好比別人把一頭宰好並切好的牛肉放到你面前，再問你：「把這些牛肉放進冰箱需要幾步？」
答案你也許知道了吧？沒錯，三步。1.打開冰箱門；2.放牛肉進冰箱；3.關上冰箱門很簡單是吧？那麼，如果別人給你的是一整頭牛，而不是切好的牛肉，再問讓你把這頭牛放進冰箱，你又怎麼辦呢？上面的這個案例其實與開發者（特別是初級開發者）使用代碼生成器有著同樣的道理。使用代碼生成器的時候，這生成器就好比切好的牛肉，開發者在使用時不關心代碼生成器的底層是如何封裝的，也不知道內部邏輯是如何處理的。就好比不知道也不用關心那頭牛是怎樣被宰的，如何解剖的一樣。庖丁解牛是怎麼來的？是屠夫們經過反覆的實踐，掌握了牛的結構、經絡之後達到的一種境界。在開發的世界裡也是同理。我見過不少開發者（絕大多數是.NET開發者，因為筆者主要專注.NET的開發）都是習慣並喜歡使用代碼生成器來生成項目，甚至整個解決方案都能為他們生成就最完美了。他們中有些人已經有5，6年或者7，8年的開發經驗，不再是初學者了，但卻還在用著傳統的某某的代碼生成器生成著傳統的三層架的解決方案，在前端UI代碼中充斥著各種DataTable和DataSet，各種if...else...邏輯判斷，各種SQL語句拼接。。。
不知道看到此處的你是否正經歷著相同的處境或者是經歷過相同的場景？
也許你說：」我不是這樣的開發者啊。「
那麼作為熱衷於開發的我感到很欣慰了，但這樣的朋友應該不在多數，不然國內的.NET開發環境不會成如今這個要死不活的樣。我的觀點準確嗎？
究其原因，不外乎是這樣的：
在早年前，很多接觸程序開發(本文主要是C#)的人中，都是看中網際網路的高薪而加入到開發者這個大軍中的，他們為的是錢途，而不是前途。他們不是真正意義上喜歡，或者說是熱愛編程。
他們的骨子裡或者根本就只是把程序開發當作多賺點錢的捷徑。
他們在想：」我就在程序界裡混幾年，等資歷老了，有個幾年的開發經驗或者是不停地跳槽，薪水自然就會不斷地往上漲。等混到了30歲，就有資格做高級工程師，做項目經理，做項目主管了。有沒有過硬的技術都不重要的。「
所以，如你，我，他所見到的如今的國內開發環境，真正熱愛編程這份事業的，願意深入研究技術的人很少，因為他們的目的根本不在於此。
他們只想通過簡單的代碼生成器來」賺快錢「，他們在編程界裡呆了幾年之後，還是不知道C#的面向對象編程思想，不知道泛型是什麼，更沒聽說過反射，委託，事件，不知道還有設計模式，領域驅動設計。。。反正他們就知道有個叫「代碼生成器」的東東。甚至還驚訝地問：」原來C#還有這麼些啊？「
試想一下，如果代碼生成器都能搞定我們的編程工作，那像Microsoft,Google,百度，阿里，騰訊等等這樣的以技術為驅動的科技公司為什麼不直接寫一堆代碼生成器就好了，何必每年養成千上萬的開發者呢？
再說得具體一些，比如我們使用某某代碼生成器來生成三層架構(這是很多C#初學者在入門或者開發生涯的前幾年中最熟悉的套路)，這個架構中包含三層：實體層，BLL，以及DAL。
隨著一個項目需求的不斷變更，你的數據表結構是不是也會變更。那麼，問題是不是來了，每次變更表結構，你是不是需要重新生成這三層的代碼，然後把原來的代碼替換掉。
如果你在這三層的任意一層中添加了自己的代碼，替換時是不是又會遇到問題呢？
那你有沒有想過，有沒有辦法能解決這些問題呢，而不是一味地抱著代碼生成器過日子。代碼變更完，對應修改UI中的邏輯判斷後就萬事大吉。
筆者描述了這麼多，想表達的是（特別是對於C#初學者來說）：剛入門或者初級階段，更多地要手寫代碼，多熟悉.NET Framework中的類庫，老是想著：「代碼生成器能幫我搞定的」是學不到真正的高級編程知識和技術的。
如果你執拗地喜歡利用傳統的代碼生成器去解決你項目中大部分工作，那麼恭喜你，你入錯行了，請趁早離開以免被坑得越來越深，因為你不熱愛這個事業，你遲早也會走的，這樣只會浪費你的寶貴的青春。
結束語
如果選擇了.NET這條路，請用心，認真對待，因為這是你的事業，你的付出也會得到回報。