甲方爸爸，大概你要的是程式碼生成器吧？
一
1）
有一天，我的朋友Y童鞋分享了他正在做的一個內部開源專案，這個開源專案從外表上看，跟目前市場上那些程式碼生成器本沒有特別大的區別，所以我興趣並不大。
在他給我介紹了一下具體需求之後，我才體會了他的意思，並提起了那麼一丟丟興趣。。
畢竟，聽起來有點“鬼扯”，為啥？因為，他居然試圖依靠這個專案來生成”單元測試“。。。。
他：定義好資料庫表和結構，然後就生成邏輯方法和程式碼、以及介面，還同時把“單元測試”程式碼給生成了，免得程式設計師要花時間去思考程式碼邏輯之餘，還要想怎麼寫出可測試程式碼。
我：這樣生成的程式碼還有靈魂麼。。
他：有啊，編寫高可測試程式碼，不就是我輩中人，這些有追求的碼農應該實現的目標麼？
我：這種模式怎麼越看越像埃裡克埃文斯大佬說的“Smart UI”模式啊。。
他：你倒這麼說，也有那麼一點點像。
2）
我：當然，能夠生成單元測試倒也可以。畢竟大部分單元測試看起來似乎是一模一樣的。無外乎就是“ Arrange\Act\Assert”，AAA操作猛如虎，測試程式碼一把梭。
他：我這個東西，生成的程式碼，除了看起來提高了單元測試覆蓋率之外，其實，並不能提高程式碼的質量。
我：是什麼逼得你要花時間去開發這樣的程式碼生成器呢？
他：還不是被這班菜雞開發者們產出的劣質產品鬧騰的。我不是想著省測試的錢，又能提高產品的質量麼？就自然而然只能靠壓榨“程式設計師”來實現了。但是讓我來對這麼多人的程式碼進行審查，還是太難了。這不，用單元測試來操作，不就可以了？
3）
我： 你們太難了。為啥這麼趕啊？
他：這不是甲方爸爸要加需求，他說得倒是好：加需求也就幾行程式碼，多簡單。但是我們這邊，就得忙翻天，太特麼累了。
我：那能不能多招幾個測試？
他：端到端測試，只是看起來將缺陷扼殺在搖籃而已，實際上。。隱藏在冰山下的缺陷呢。。客戶就是小白鼠啊。再說，我們現在家業太小，測試有兩個了，再招就請不起了。。功能是不能少的，bug是不能多的，我只能想想單元測試這種辦法了。
我：好吧。。我們也一樣。。
二
1）
之前有個朋友老張介紹了一個故事，彷彿跟這個有點類似。他有幸參與了一個交通訊息化的專案，這個專案的業主是國企單位，屬於“體制內”的企業。
在過去一波有一波的資訊化發展過程中，這些體制內的企業彷彿成為了許多IT企業競相薅羊毛的物件。為啥，國企專案多、錢也不少，關鍵是國企對軟體質量要求不高啊。
許多企業藉助國企專案，他們依託所謂“快速上線”的神器，將中華民族艱苦奮鬥的精神發揮到了極致，公司能夠在最短的時間內，將原本停留在腦海裡的軟體，快速的轉化成為實現，並部署到甲方爸爸的現場環境中。
至於軟體的質量、軟體的工程化水平，對不起，不重要？使用者體驗？效能？功能可用性？重要麼，不重要。先快速上線回款再說。於是，這些企業獲得了業績的騰飛，老闆們賺得盆滿簸贏，好不自在。
而且老闆們還會吹：我們公司最大的優點，就是在逆境下生存的能力，能夠在最短的時間消化需求，做出最符合客戶需求的軟體。
好吧，彷彿這也是軟體工程的一種方向？快速開發。。。。
2）
然後，有那麼幾年，市場突然間就“做爛“了。
一方面，國家將投資方向重點放在了房地產領域，對資訊化的投入也逐漸收緊了許多；
另外一方面，企業過去匆忙上線了太多的軟體系統，不同軟體系統之間的對接溝通困難，操作過程缺乏連貫性，使得基層員工開始抗拒這些”看似“能夠帶來效率提升，卻容易出現各種質量問題導致自己過去幾天工作量返工的所謂”資訊化“系統；
另外，大家也都很清楚，效率提升其實帶來的是”裁員“，首先被裁的...
總之，有那麼一段時間，國企對資訊化是“棄若敝屣”的。
三
1）
但，隨著“網際網路”和“共享出行”的興起，又讓這個概念重新熱炒了起來。
老張他們公司也有幸接到了一個這樣的專案，公司還是一家非常大的計程車公司，擁有二十多家子公司，員工超過2萬人。這個專案的目的是打通計程車和旅客的關係，藉助於手機實現快速出行，同時打通企業內部資訊孤島，讓總公司領導能夠第一時間看到各種資料的流轉情況，為建立科學決策提供依據。
老張被選為這個專案的負責人。在專案啟動會上，他意氣風發，向業主和公司老闆們保證，將帶領公司團隊與甲方團隊一起，以飽滿的姿態打響這場戰役，為業主的業績騰飛貢獻自己的一份力量。
然而，但專案啟動後，他才深刻的明白這究竟是一個怎樣的坑。
2）
首先是業主關係，由於業主是一家涉及大幾萬員工和二十幾家子公司的大型集團公司，需要梳理的業務表單非常複雜，業務流程和體系，遠比甲方爸爸預想的要複雜得多。
其次是開發週期短，不知從何時起，國企對於軟體系統的印象就是“簡單、容易、很快就能實現”，彷彿一個需求只要說出來，這般不要命的程式設計師們就能很快的實現功能。當老張跟他們提到需求太多，根本做不完時，甲方爸爸甚至說：怎麼可能有做不出來的軟體系統，是不是你能力不行？
再次是外部系統多，由於不同的子公司往往採購了不同的系統，要統一對接到一個系統 。
還有就是涉及的技術點多，需要在許多領域進行專門的技術攻關，由於公司暫時缺乏相關資源，使得開發過程屢屢收到阻塞。
2）
經過長達幾個月的需求調研，老張編寫了一份超過一千頁紙的需求規格說明書，並獲得了業主的批准，但專案正式開始時，他卻只獲得了短短半年的開發週期。此時，他手上能夠調動的開發者資源，才不過10餘人。
為了幹完這個專案，他和專案團隊的成員不得不犧牲週末和假期，辛苦堅持了半年，才把專案功能都開發完，但在專案實施環節時，由於子公司與總公司的意見不統一，根本用不起來。
最終，專案崩盤，公司倒閉，甲方將近一年的投入近乎白費。老張和專案團隊也白白辛苦了大半年，還得去勞動仲裁，找老闆討薪。
回顧這段時光時，老張說了一段話：
“企業資訊服務化的專案，看起來合同工價很高，其實都是坑啊。有的業主，根本不懂什麼叫“合適的軟體”。
在網際網路如此發展的今天，這些業主，要的還是“快速開發”。但凡想到什麼就往裡面加，程式設計師不猝死太難了。許多需求今天提，明天就要，但是用了一次呢這些功能就不用了，我根本不知道這些軟體，幹出來有什麼意義。
千萬別跟業主提敏捷，他們會在你的每個迭代中塞根本幹不完的工作量；也不要提擁抱變化，他們變起臉來，自己都怕。”
四
仔細想想，許多傳統企業領導想上雲、或轉型到網際網路，不就是這樣麼，恨不能一天就把專案幹完，幹完專案就“升官發財”，至於專案能不能用，誰知道呢。。
也許，他們要的並不是軟體，而是一種“程式碼生成器”。嗯，輸入“甲方爸爸的一萬種需求”，輸出“一個功能齊全、包容萬物、自由變化的軟體”。。
作為有追求的碼農們，我們能像Robert大叔在《程式碼整潔之道-程式設計師的自我修養》一書中寫的方法：選擇“拒絕”麼。
額。。生存要緊。。偶爾吐吐槽，飯還是得恰啊。