程序員的“紀律性”
國慶節長假前后，我和很多業內外的朋友們展開了關于“碼農”的大討論，作為這些討論的延伸，一篇叫做《從“碼農”說起》 的文章從腦海中輸出，最終展現在 CSDN 官網上。在文章中，我主張年輕的技術人們不應該接受社會輿論強加的“碼農”屬性，自己做有創造力的事情，要相信付出和智慧一定有回報。此文一出，得到了很 多朋友的批評指正，令我頗為欣喜，因為有互動才會有頭腦風暴，進而產生更多的新想法。
回顧當時那場大討論，其中很多觀點其實值得深入探討，比如在討論中，一位名為“@不動如山_”的朋友是這么說的：
對于軟件是不是勞動密集性產業，你認為怎樣合理是一回事，現實如何是另一回事。作為老程序員，老 se，我參加過上千人的團隊協作，數年的開發周期。所有創造性的工作在預研階段就必須結束。一旦進入開發，就只有紀律，沒有創新。當然，個別高科技產品的原型軟件例外。
這席話給我很大觸動，因為它觸及了我進入 IT 行業之初時青澀經歷的回憶。
多年前我剛剛加入的團隊正在開發某個通信設備。有過開發通信設備的朋友們應該知道，其實嵌入式軟件開發的技術核心是事件調度，因為通信設備總是 處在繁忙的交換和命令事件處置的狀態中，一個良好的事件調度機制是系統性能的靈魂，如果每次一個事件的到來都以新開一個線程的方式來應付，系統資源瞬間就 會枯竭，設備也就崩潰了。
當時我們采用的是一種叫做 zebra 的架構，這是一個面向交換的開源項目，甚至有點像一個用戶空間運行著的內核程序。
當時管理這個項目團隊的項目經理正好是一個完全沒有做過軟件開發的職業文案寫手，所以當主力開發人員把事件調度機制的框架整理完成之后，項目經 理小眼滴溜溜一轉，說道：“現在架構已經完成，下面就是大家分工，把各自的功能框架填充好了，我看了一下，一共有 19 個模塊，大家分一下，一個模塊每人一周時間……”
這時一個資深的程序員打斷了他，資深程序員讓大家每個人把手頭做的東西做一下單元測試，聲稱下一周他會給我們一個好東西。
果然這位資深程序員拿出一周時間用腳本寫成的工具，把所有原來的功能模塊直接處理填充到 zebra 架構內。
每當我回憶這件事情的時候，想起外行項目經理的尷尬表情都會忍俊不禁。彼時的那位項目經理，其實也是一個年輕有為的人，但是對于軟件開發的特點 的確缺乏了解，想當然地以為自己抓抓紀律性就行，大家按部就班、出工出力就好。可是要知道如果真的按照他的計劃，功能填充過程可能需要2-3 個月，況且數百萬行規模的代碼中隱藏的 Bug 又需要一個測試周期來捉蟲。
我把這個故事講給朋友們，有的朋友就問當時假如沒有這個用腳本寫成的工具又當如何？我就會反問，那么假如我們沒有找到 zebra 架構又當如何？難不成要我們幾個菜鳥來寫調度機嗎？軟件編程，是一個能走捷徑就一定要走捷徑的工作——有現成的可重用或者可借鑒的東西一定要重用和借鑒 的，這樣工作水準和工作效率才可能有保證。有現成的東西不用，一定是萬不得已；推倒重來，則一定是出現了重大問題；動不動喜歡從頭再來的程序員，肯定是涉 世未深、不得要領的門外漢。
我曾經將軟件工作比喻成人類這個物種的又一次進化過程，每次開發工作的成果都順理成章地成為以后階段項目的工具。既然學習制造和使用工具正是人 和動物的區別，那么在軟件工作領域，對走捷徑持懷疑態度，對借鑒現成成果持抗拒心理，反對寧可停下進度也要先創造工具的開發者或管理者，就如同軟件世界里 的大猩猩。
迷信“紀律性”的管理者，通常都以“戰斗力”為口頭禪，可惜開發產品畢竟不是戰爭，軟件編程也不是你死我活的肉搏，軟件工作其實就是一次又一次 把自己的好想法，好創意凝結在編程語言上的過程，好的代碼精辟如詩歌一般，其簡練高效令人讀起來拍案叫絕；好的軟件架構巧奪天工，資源節約，魯棒性強，這 些都是經過反復思索和反復斟酌的結果，這樣的工作狀態和“紀律性”、“團結就是力量”的狀態其實完全是南轅北轍。
軟件的靈魂是數學和邏輯，開發過程本身就是一種創造，一種與數學邏輯的對話。紀律性的靈魂是服從，是聽話，是個人意志服從集體意志，集體意志服從長官意志。這兩件事情的聯姻肯定不是自由戀愛，而是指腹為婚。
我覺得在團隊合作中，編程規范是極為必要的，用約定的編程規矩來撰寫程序是開發者應該共同維護的良好開發氛圍。但這就是所謂紀律的邊界了，紀律的覆蓋范圍，不應該逾越這個邊界。
這些年敏捷開發、結對編程等新興軟件開發模式的興起，從一個側面強化了我的這種認識，那就是：軟件工作的重要方式，就是創造一個可以醞釀好點子的環境，讓好想法源源不斷的產生出來，形成代碼。軟件活動應該回歸本源，就是激發有創造力的人性。
按照這個思路，我常常建議一些嵌入式軟件工程師能夠在工作之余學習一下 Java，學習一下腳本語言，Awk 也行，TK 也行，Perl 也可以。很多人會很詫異，覺得自己面向硬件，甚至面向驅動，為什么要學習那么多表示層的東西？
我認為嵌入式系統軟件開發常常因為設備處理能力以及開發環境限制只能使用面向過程的C，但是在軟件工具已經逐漸豐富起來的現在，底層代碼是完全可以通過腳本語言幫忙處理的，大量繁重的比對工作和代碼遷移工作完全可以用腳本來執行，高效而且準確。
單純從項目開發的效率來講，團隊里面有這樣的軟件多面手，有能夠提出這樣想法的人，比一個外行領導者對于開發者紀律性的要求要有意義，也有效的多。
這又要說到我曾經參與的另一個項目，也是某一種通信產品的開發工作。這一次是給設備開發北向接口。所謂北向接口，實際上就是開放給管理系統的管 理監督接口。我們當時采用的是 MIB 方案，以 SNMPv2 為接口規范。同樣的問題再次光臨：一個帶有龐大從屬終端數量的局端設備，其 MIB 是非常復雜的，由于管理數據的節點已經細致到每個終端下面的每個網口的出入口速率和 VLAN 之類的細節內容，所以數據管理異常繁瑣。
有了之前的經驗，這一次我們也都把眼光投向腳本工具，果不其然，我們直接找到了一個開源項目，專門針對 MIB 開發了一套基于 Perl 腳本的處理工具集，把這個工具集稍加調整，就能快速生成滿足 MIB 訪問要求的底層數據形態，并且生成的代碼有良好的可維護性，冗余度也在可接受的范圍內。
我印象非常深的是，在做完這個項目的慶功宴上，項目組的技術大牛，也就是之前說到的那位資深程序員曾有這么一句感慨：“真正做可靠的嵌入式軟件 開發，以后就應該是架構設計配合代碼生成工具，資淺程序員的工作就是一邊做點小修小補，一邊學習架構，這樣利于成長，也對項目進展最有利。”此言聽聞已有 將近 8 年，言猶在耳。
前面“@不動如山_”的那段話雖然出自一人之口，但是這樣的觀點，在國內卻絕不是少數，沒有編程背景的管理人員更是對這樣的觀點敞開懷抱，如獲 至寶。很多國內的公司在軟件部門里面都依然秉承著“人月”狀態，就是把員工人數和工作時間的乘積作為公司的生產力，然后把具體的工作按照“人月”或者“人 日”乃至“人時”進行度量，進而把一項任務切分出去。看到這里，讀過《人月神話》的朋友們應該都會會心一笑。
寫這篇文章，也主要是想對初入這個行業或者懷有志向即將進入這個行業的年輕技術者們說點我的心里話：堆代碼永遠不是軟件行業的核心競爭力，設計 能力才是，盡管很多公司還以代碼行數作為績效來考評；做一個聽話的孩子在這個行業里也很難快速提升自我，因為創造力是要靠自己勉勵自己才能不斷展現的；安 排很多人做重復體力活的規劃，其實是因為沒有人去嘗試創造便捷的工具，這樣的所謂的“紀律性”的團隊里你肯定也學不到什么東西。多問幾個為什么、一定要這 樣和為什么不那樣，對一個年輕人，尤其對一個有技術追求的年輕人永遠有好處。
<span id="shareA4" class="fl">
</span>
</div>