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