企業上雲？也許只差一個代碼生成器

甲方爸爸，大概你要的是代碼生成器吧？

一

1）

有一天，個人朋友Y童鞋分享了他正在作的一個內部開源項目，這個開源項目從外表上看，跟目前市場上那些代碼生成器本沒有特別大的區別，因此我興趣並不大。

在他給我介紹了一下具體需求以後，我才體會了他的意思，並提起了那麼一丟丟興趣。。

畢竟，聽起來有點「鬼扯」，爲啥？由於，他竟然試圖依靠這個項目來生成」單元測試「。。。。

他：定義好數據庫表和結構，而後就生成邏輯方法和代碼、以及界面，還同時把「單元測試」代碼給生成了，省得程序員要花時間去思考代碼邏輯之餘，還要想怎麼寫出可測試代碼。

我：這樣生成的代碼還有靈魂麼。。

他：有啊，編寫高可測試代碼，不就是我輩中人，這些有追求的碼農應該實現的目標麼？

我：這種模式怎麼越看越像埃裏克埃文斯大佬說的「Smart UI」模式啊。。

他：你倒這麼說，也有那麼一點點像。

2）

我：固然，可以生成單元測試倒也能夠。畢竟大部分單元測試看起來彷佛是如出一轍的。無外乎就是「 Arrange\Act\Assert」，AAA操做猛如虎，測試代碼一把梭。

他：我這個東西，生成的代碼，除了看起來提升了單元測試覆蓋率以外，其實，並不能提升代碼的質量。

我：是什麼逼得你要花時間去開發這樣的代碼生成器呢？

他：還不是被這班菜雞開發者們產出的劣質產品鬧騰的。我不是想着省測試的錢，又能提升產品的質量麼？就天然而然只能靠壓榨「程序員」來實現了。可是讓我來對這麼多人的代碼進行審查，仍是太難了。這不，用單元測試來操做，不就能夠了？

3）

我： 大家太難了。爲啥這麼趕啊？

他：這不是甲方爸爸要加需求，他說得卻是好：加需求也就幾行代碼，多簡單。可是咱們這邊，就得忙翻天，太特麼累了。

我：那能不能多招幾個測試？

他：端到端測試，只是看起來將缺陷扼殺在搖籃而已，實際上。。隱藏在冰山下的缺陷呢。。客戶就是小白鼠啊。再說，咱們如今家業過小，測試有兩個了，再招就請不起了。。功能是不能少的，bug是不能多的，我只能想一想單元測試這種辦法了。

我：好吧。。咱們也同樣。。

二

1）

以前有個朋友老張介紹了一個故事，彷彿跟這個有點相似。他有幸參與了一個交通訊息化的項目，這個項目的業主是國企單位，屬於「體制內」的企業。

在過去一波有一波的信息化發展過程當中，這些體制內的企業彷彿成爲了許多IT企業競相薅羊毛的對象。爲啥，國企項目多、錢也很多，關鍵是國企對軟件質量要求不高啊。

許多企業藉助國企項目，他們依託所謂「快速上線」的神器，將中華民族艱苦奮鬥的精神發揮到了極致，公司可以在最短的時間內，將本來停留在腦海裏的軟件，快速的轉化成爲實現，並部署到甲方爸爸的現場環境中。

至於軟件的質量、軟件的工程化水平，對不起，不重要？用戶體驗？性能？功能可用性？重要麼，不重要。先快速上線回款再說。因而，這些企業得到了業績的騰飛，老闆們賺得盆滿簸贏，好不自在。

並且老闆們還會吹：咱們公司最大的優勢，就是在逆境下生存的能力，可以在最短的時間消化需求，作出最符合客戶需求的軟件。

好吧，彷彿這也是軟件工程的一種方向？快速開發。。。。

2）

而後，有那麼幾年，市場忽然間就「作爛「了。
一方面，國家將投資方向重點放在了房地產領域，對信息化的投入也逐漸收緊了許多；
另一方面，企業過去匆忙上線了太多的軟件系統，不一樣軟件系統之間的對接溝通困難，操做過程缺少連貫性，使得基層員工開始抗拒這些」看似「可以帶來效率提高，卻容易出現各類質量問題致使本身過去幾天工做量返工的所謂」信息化「系統；
另外，你們也都很清楚，效率提高其實帶來的是」裁人「，首先被裁的...

總之，有那麼一段時間，國企對信息化是「棄若敝屣」的。

三

1）

但，隨着「互聯網」和「共享出行」的興起，又讓這個概念從新熱炒了起來。

老張他們公司也有幸接到了一個這樣的項目，公司仍是一家很是大的出租車公司，擁有二十多家子公司，員工超過2萬人。這個項目的目的是打通出租車和旅客的關係，藉助於手機實現快速出行，同時打通企業內部信息孤島，讓總公司領導可以第一時間看到各類數據的流轉狀況，爲創建科學決策提供依據。

老張被選爲這個項目的負責人。在項目啓動會上，他意氣風發，向業主和公司老闆們保證，將帶領公司團隊與甲方團隊一塊兒，以飽滿的姿態打響這場戰役，爲業主的業績騰飛貢獻本身的一份力量。

然而，但項目啓動後，他才深入的明白這到底是一個怎樣的坑。

2）

首先是業主關係，因爲業主是一家涉及大幾萬員工和二十幾家子公司的大型集團公司，須要梳理的業務表單很是複雜，業務流程和體系，遠比甲方爸爸預想的要複雜得多。

其次是開發週期短，不知從什麼時候起，國企對於軟件系統的印象就是「簡單、容易、很快就能實現」，彷彿一個需求只要說出來，這般不要命的程序員們就能很快的實現功能。當老張跟他們提到需求太多，根本作不完時，甲方爸爸甚至說：怎麼可能有作不出來的軟件系統，是否是你能力不行？

再次是外部系統多，因爲不一樣的子公司每每採購了不一樣的系統，要統一對接到一個系統 。

還有就是涉及的技術點多，須要在許多領域進行專門的技術攻關，因爲公司暫時缺少相關資源，使得開發過程屢屢收到阻塞。

2）

通過長達幾個月的需求調研，老張編寫了一份超過一千頁紙的需求規格說明書，並得到了業主的批准，但項目正式開始時，他卻只得到了短短半年的開發週期。此時，他手上可以調動的開發者資源，纔不過10餘人。

爲了幹完這個項目，他和項目團隊的成員不得不犧牲週末和假期，辛苦堅持了半年，才把項目功能都開發完，但在項目實施環節時，因爲子公司與總公司的意見不統一，根本用不起來。

最終，項目崩盤，公司倒閉，甲方將近一年的投入近乎白費。老張和項目團隊也白白辛苦了大半年，還得去勞動仲裁，找老闆討薪。

回顧這段時光時，老張說了一段話：

「企業信息服務化的項目，看起來合同工價很高，其實都是坑啊。有的業主，根本不懂什麼叫「合適的軟件」。

在互聯網如此發展的今天，這些業主，要的仍是「快速開發」。但凡想到什麼就往裏面加，程序員不猝死太難了。許多需求今天提，明天就要，可是用了一次呢這些功能就不用了，我根本不知道這些軟件，幹出來有什麼意義。

千萬別跟業主提敏捷，他們會在你的每一個迭代中塞根本幹不完的工做量；也不要提擁抱變化，他們變起臉來，本身都怕。」

四

仔細想一想，許多傳統企業領導想上雲、或轉型到互聯網，不就是這樣麼，恨不能一天就把項目幹完，幹完項目就「升官發財」，至於項目能不能用，誰知道呢。。

也許，他們要的並非軟件，而是一種「代碼生成器」。嗯，輸入「甲方爸爸的一萬種需求」，輸出「一個功能齊全、包容萬物、自由變化的軟件」。。

做爲有追求的碼農們，咱們能像Robert大叔在《代碼整潔之道-程序員的自我修養》一書中寫的方法：選擇「拒絕」麼。

額。。生存要緊。。偶爾吐吐槽，飯仍是得恰啊。