程式設計師的“紀律性”

國慶節長假前後，我和很多業內外的朋友們展開了關於“碼農”的大討論，作為這些討論的延伸，一篇叫做《從“碼農”說起》的文章從腦海中輸出，最終展現在CSDN官網上。在文章中，我主張年輕的技術人們不應該接受社會輿論強加的“碼農”屬性，自己做有創造力的事情，要相信付出和智慧一定有回報。此文一出，得到了很多朋友的批評指正，令我頗為欣喜，因為有互動才會有頭腦風暴，進而產生更多的新想法。

回顧當時那場大討論，其中很多觀點其實值得深入探討，比如在討論中，一位名為“@不動如山_”的朋友是這麼說的：

對於軟體是不是勞動密集性產業，你認為怎樣合理是一回事，現實如何是另一回事。作為老程式設計師，老se，我參加過上千人的團隊協作，數年的開發週期。所有創造性的工作在預研階段就必須結束。一旦進入開發，就只有紀律，沒有創新。當然，個別高科技產品的原型軟體例外。

這席話給我很大觸動，因為它觸及了我進入IT行業之初時青澀經歷的回憶。

多年前我剛剛加入的團隊正在開發某個通訊裝置。有過開發通訊裝置的朋友們應該知道，其實嵌入式軟體開發的技術核心是事件排程，因為通訊裝置總是處在繁忙的交換和命令事件處置的狀態中，一個良好的事件排程機制是系統效能的靈魂，如果每次一個事件的到來都以新開一個執行緒的方式來應付，系統資源瞬間就會枯竭，裝置也就崩潰了。

當時我們採用的是一種叫做zebra的架構，這是一個面向交換的開源專案，甚至有點像一個使用者空間執行著的核心程式。

當時管理這個專案團隊的專案經理正好是一個完全沒有做過軟體開發的職業文案寫手，所以當主力開發人員把事件排程機制的框架整理完成之後，專案經理小眼滴溜溜一轉，說道：“現在架構已經完成，下面就是大家分工，把各自的功能框架填充好了，我看了一下，一共有19個模組，大家分一下，一個模組每人一週時間……”

這時一個資深的程式設計師打斷了他，資深程式設計師讓大家每個人把手頭做的東西做一下單元測試，聲稱下一週他會給我們一個好東西。

果然這位資深程式設計師拿出一週時間用指令碼寫成的工具，把所有原來的功能模組直接處理填充到zebra架構內。

每當我回憶這件事情的時候，想起外行專案經理的尷尬表情都會忍俊不禁。彼時的那位專案經理，其實也是一個年輕有為的人，但是對於軟體開發的特點的確缺乏瞭解，想當然地以為自己抓抓紀律性就行，大家按部就班、出工出力就好。可是要知道如果真的按照他的計劃，功能填充過程可能需要2-3個月，況且數百萬行規模的程式碼中隱藏的Bug又需要一個測試周期來捉蟲。

我把這個故事講給朋友們，有的朋友就問當時假如沒有這個用指令碼寫成的工具又當如何？我就會反問，那麼假如我們沒有找到zebra架構又當如何？難不成要我們幾個菜鳥來寫排程機嗎？軟體程式設計，是一個能走捷徑就一定要走捷徑的工作——有現成的可重用或者可借鑑的東西一定要重用和借鑑的，這樣工作水準和工作效率才可能有保證。有現成的東西不用，一定是萬不得已；推倒重來，則一定是出現了重大問題；動不動喜歡從頭再來的程式設計師，肯定是涉世未深、不得要領的門外漢。

我曾經將軟體工作比喻成人類這個物種的又一次進化過程，每次開發工作的成果都順理成章地成為以後階段專案的工具。既然學習製造和使用工具正是人和動物的區別，那麼在軟體工作領域，對走捷徑持懷疑態度，對借鑑現成成果持抗拒心理，反對寧可停下進度也要先創造工具的開發者或管理者，就如同軟體世界裡的大猩猩。

迷信“紀律性”的管理者，通常都以“戰鬥力”為口頭禪，可惜開發產品畢竟不是戰爭，軟體程式設計也不是你死我活的肉搏，軟體工作其實就是一次又一次把自己的好想法，好創意凝結在程式語言上的過程，好的程式碼精闢如詩歌一般，其簡練高效令人讀起來拍案叫絕；好的軟體架構巧奪天工，資源節約，魯棒性強，這些都是經過反覆思索和反覆斟酌的結果，這樣的工作狀態和“紀律性”、“團結就是力量”的狀態其實完全是南轅北轍。

軟體的靈魂是數學和邏輯，開發過程本身就是一種創造，一種與數學邏輯的對話。紀律性的靈魂是服從，是聽話，是個人意志服從集體意志，集體意志服從長官意志。這兩件事情的聯姻肯定不是自由戀愛，而是指腹為婚。

我覺得在團隊合作中，程式設計規範是極為必要的，用約定的程式設計規矩來撰寫程式是開發者應該共同維護的良好開發氛圍。但這就是所謂紀律的邊界了，紀律的覆蓋範圍，不應該逾越這個邊界。
這些年敏捷開發、結對程式設計等新興軟體開發模式的興起，從一個側面強化了我的這種認識，那就是：軟體工作的重要方式，就是創造一個可以醞釀好點子的環境，讓好想法源源不斷的產生出來，形成程式碼。軟體活動應該回歸本源，就是激發有創造力的人性。

按照這個思路，我常常建議一些嵌入式軟體工程師能夠在工作之餘學習一下Java，學習一下指令碼語言，Awk也行，TK也行，Perl也可以。很多人會很詫異，覺得自己面向硬體，甚至面向驅動，為什麼要學習那麼多表示層的東西？

我認為嵌入式系統軟體開發常常因為裝置處理能力以及開發環境限制只能使用程式導向的C，但是在軟體工具已經逐漸豐富起來的現在，底層程式碼是完全可以通過指令碼語言幫忙處理的，大量繁重的比對工作和程式碼遷移工作完全可以用指令碼來執行，高效而且準確。

單純從專案開發的效率來講，團隊裡面有這樣的軟體多面手，有能夠提出這樣想法的人，比一個外行領導者對於開發者紀律性的要求要有意義，也有效的多。

這又要說到我曾經參與的另一個專案，也是某一種通訊產品的開發工作。這一次是給裝置開發北向介面。所謂北向介面，實際上就是開放給管理系統的管理監督介面。我們當時採用的是MIB方案，以SNMPv2為介面規範。同樣的問題再次光臨：一個帶有龐大從屬終端數量的局端裝置，其MIB是非常複雜的，由於管理資料的節點已經細緻到每個終端下面的每個網口的出入口速率和VLAN之類的細節內容，所以資料管理異常繁瑣。

有了之前的經驗，這一次我們也都把眼光投向指令碼工具，果不其然，我們直接找到了一個開源專案，專門針對MIB開發了一套基於Perl指令碼的處理工具集，把這個工具集稍加調整，就能快速生成滿足MIB訪問要求的底層資料形態，並且生成的程式碼有良好的可維護性，冗餘度也在可接受的範圍內。

我印象非常深的是，在做完這個專案的慶功宴上，專案組的技術大牛，也就是之前說到的那位資深程式設計師曾有這麼一句感慨：“真正做可靠的嵌入式軟體開發，以後就應該是架構設計配合程式碼生成工具，資淺程式設計師的工作就是一邊做點小修小補，一邊學習架構，這樣利於成長，也對專案進展最有利。”此言聽聞已有將近8年，言猶在耳。

前面“@不動如山_”的那段話雖然出自一人之口，但是這樣的觀點，在國內卻絕不是少數，沒有程式設計背景的管理人員更是對這樣的觀點敞開懷抱，如獲至寶。很多國內的公司在軟體部門裡面都依然秉承著“人月”狀態，就是把員工人數和工作時間的乘積作為公司的生產力，然後把具體的工作按照“人月”或者“人日”乃至“人時”進行度量，進而把一項任務切分出去。看到這裡，讀過《人月神話》的朋友們應該都會會心一笑。

寫這篇文章，也主要是想對初入這個行業或者懷有志向即將進入這個行業的年輕技術者們說點我的心裡話：堆程式碼永遠不是軟體行業的核心競爭力，設計能力才是，儘管很多公司還以程式碼行數作為績效來考評；做一個聽話的孩子在這個行業裡也很難快速提升自我，因為創造力是要靠自己勉勵自己才能不斷展現的；安排很多人做重複體力活的規劃，其實是因為沒有人去嘗試創造便捷的工具，這樣的所謂的“紀律性”的團隊裡你肯定也學不到什麼東西。多問幾個為什麼、一定要這樣和為什麼不那樣，對一個年輕人，尤其對一個有技術追求的年輕人永遠有好處。