互聯網風口，程序員怎麼飛？

知識 09-28

互聯網的世界，風雲變幻，經歷著雷厲風行的洗牌，在這個快速迭代升級的風口上，創新成了幾乎所有互聯網企業的核心理念。而規範是需要一定的匠心去打造的，遷就規範，似乎就礙了創新，在技術日新月異、業務風口變換的今天，如何才能權衡好創新和匠心呢？

最近，阿里巴巴對外正式公開《阿里巴巴Java開發手冊》終極版。回望這些年，國內的代碼規範良莠不齊，通常都是各公司程序員基於個人開發過程中的經驗總結出來的，驗證不夠充分，涉獵不夠全面，描述不夠準確。行業代碼，可謂魚龍混雜，各有千秋，沒有統一的標準。《阿里巴巴Java開發手冊》對中小企業，乃至對行業都有著很強的借鑒作用。

Java工程師或許都經歷過這樣的場景：接手別人的代碼時，因為沒有注釋，變數名五花八門，模塊之間邏輯關係如麻，弄得滿頭霧水，一臉茫然，痛定思痛之後不得不推倒重來，這些都是不注重編程規範造成的，事倍功半。

那如何權衡時間成本與代碼規範？如何引領一名普通程序員走向優秀，進而邁向卓越？為此，InfoQ採訪了《阿里巴巴Java開發手冊》作者楊冠寶。另外，楊冠寶也將會在10月17日舉行的QCon全球軟體開發大會上分享相關話題，歡迎關注。

宜未雨而綢繆，毋臨渴而掘井

在阿里正式發布代碼規範之前，孤盡回憶，那些牽一髮而動全身的壞代碼例子：如表達刪除狀態的欄位名，非常多，像：delete/delete_flag/is_deleted，在數據分析時，總要小心翼翼，象文字遊戲。而0/1還是y/n來表示已刪除和未刪除，更是神坑，極易造成線上問題。再如，批量介面定義時，沒有介面保護很容易造成伺服器方內存耗盡，產生OOM等等。

孤盡認為，國內的開發者大多重技能，輕規範。此前有這麼一個段子，程序員A和B，A每天只寫100行代碼，字裡行間規範清晰，其餘大部分時間都在整理文檔，備註的非常詳細，B每天寫50000行代碼，卻很少寫注釋，天馬行空，為此還嘲笑A不夠高效。

隨著業務越來越複雜，客戶需求隨時可變，兩個人都開始組建團隊，這個時候，功夫不負苦心人，A之前的努力都派上了用場，B只能佩服加慚愧。

可見，編程規範，對於程序員而言，不是要靠強制約束，更關鍵的還是要讓其從認知，思想覺悟上提高，骨子裡意識到規範也是一種生產力。

原始社會的爭端，更多的是講究個人的蠻力，而三國時代的群雄並起，開始講究士兵的配合與團隊，而現代戰爭，海陸空、信息兵、工程兵，無不需要緊密配合。現在軟體發展到現在，只是造一句hello world走天下的時代，已經過去了，需要團隊緊密協作。

編程風格的不一致，明顯影響了團隊研發效能。有時候，團隊可以為沒有營養的介面定義方式，能夠吵上一天。公說公有理，婆說婆有理，重點是：最後沒有達成一致。編程規範就是極大的減少沒有營養的爭論，真正把時間放在需要解決的核心問題上。

程序員都是天生幻想創造個性化作品的藝術家，變著法子想著要如何與眾不同，最好代碼只有自己能夠看懂，只有自己能夠維護。但是個性化應盡量表現在代碼質量和演算法效率的提升上，而不是對於合作規範上糾纏不休的爭論。

再者，公司是請程序員來產出實際價值的，而不是經常消耗時間為TAB還是空格的事情爭得臉紅脖子粗的。有時候，就是一個規定，就像交規靠左行，還是右行一樣，大家這麼做了，協作效率自然就提升了，正所謂無規矩不成方圓，無規範難以協作。

簡單，適用的代碼規約背後，所傳遞的是技術上的追求卓越，協同合作的精神，是每個技術團隊不可缺失的重要利器。

領先半步，是基於行業背後的思考

以前阿里巴巴對外開放的是一些縱向領域的中間件產品，如dubbo/fastjson/jstorm等，這次《阿里巴巴Java開發手冊》的發布，也是第一次公開橫向標準類的技術成果。

孤盡坦言，在此之前，阿里內部的Java編程規範，各自為政，沒有權威的官方標準，痛定思痛的抉擇後，形成了內部稱為《集團開發規約》的寶典，經過脫敏後，對外發布《阿里巴巴Java開發手冊》。編程規範發布後，希望業界的代碼能夠規範化，提升業界整體溝通和研發效率。

據悉這本手冊歷時3年，融匯了近萬名開發者的智慧，幾乎 Java 日常開發中的方方面面都有所涉及。當談及是如何逐步接受實戰檢驗的？孤盡描述：

阿里巴巴推動中台化戰略，對於項目機動聯合的要求越來越高。而規範不一的痛楚，使大家意識到統一規範的緊迫性與必要性。以集團平台技術事業群為核心，以國際事業部的規範為藍本，進行大幅度修訂，多輪討論，投票，甚至是辯論，艱難地形成最後的統一規範。

首先，意識形態上統一，結合豐富的正反例，以及歷史數據分析，融合已有規範，取長補短，明確規範往前一步是生，退後一步是死的危機感；其次，成立集團專業委員會來負責內容的制定，成立宣傳推廣項目組定向推進宣傳工作，在過去一年中，幾乎是飽和式轟炸地宣傳方式，讓規範深入人心；最後，成立檢測項目組，如果自動化檢測，如果不符合，對不起，不能發布上線。

對外版本的更新上，從之前的周頻度，到後來的月頻度，現在以季度的時間維護來修訂，阿里巴巴有一個專門項目組來長久地維護《阿里巴巴Java開發手冊》的與時俱進。

終極版，只是PDF版本的終結，而不是《阿里巴巴Java開發手冊》的最後一版，未來會轉為線上維護，大家可以在線提交issue，允許企業和個人fork分支用以非商業化用途，提升團隊及個人的研發效能。

可見，紮根內部，立足行業，著眼未來，行業編碼規範化水平，可以幫助行業人員提高開發質量和效率、大大降低代碼維護成本。

不是一番寒徹骨，怎得梅花撲鼻香？

大家看到的都是蝴蝶飛舞的風光，而只有自己才明白破繭成蝶的痛苦。孤盡回憶了當時對內和對外遇到的最大挑戰：

對內而言，程序員的天性是自由的，沒有人願意被束縛。這個過程的意識碰撞，甚至是火星碰地球一樣，即使插件普及率接近八成，但是挑戰依然還存在，尤其是新入職的有經驗的社招開發同學。掃描自動化只是實現了30%的條目，有70%的條目是沒有落在自動化上，所以需要在意識上非常清楚地知道背後的邏輯。

對外，個別同學在論壇上表示了這是阿里巴巴KPI的產物，感覺阿里從KPI孵化出來，都是怪獸，其實不然，這是一種願意和技術情懷驅動。開放給業界，首先想到的是幫助到大家，一起提升程序員的幸福感。最大化地讓大家懂得規約背後的意義，及它的衍生價值。

健壯的代碼是經得起重複的修改和重構的

Java開發工程師都比較關心一個問題：代碼出現之前如何排除掉不給Bug出現的機會？孤盡給出了建議：

首先，定位問題比解決問題更加重要。解決問題，在計算機的世界裡，都是能夠找出方案的。無非是解決問題姿勢是否夠優雅，解決問題的時間長短，解決問題能否解決的同時，解決掉隱含的其他問題。

所以需要時時有異常分支流程的概念，清晰地知道這個世界上最強大的測試同學是用戶，他們的操作行為千奇古怪，儘可能把自己想成傻的不能再傻的用戶。曾經有一個故障，就是一個好奇的用戶簽名使用了：--&@# 這種奇怪的字元，結果被SQL注入，導致資料庫被批量更新。

聊聊《阿里巴巴Java開發手冊》細節

據悉，《阿里巴巴Java開發手冊》主要是面向Java開發群體，Java做為面向對象語言，在業界的生命力還是非常強大的，技術生態豐富，框架結構成熟，經歷了超高並發的「雙十一」實戰考驗，阿里想把多年的Java技術積累回饋給Java開發者社區。在裡面可以找到很多的技術規範、最佳實踐，避坑指南等。

其中引入了資料庫、安全、伺服器等知識。現代軟體行業的高速發展對於開發者的綜合素質要求越來越高，因為不僅是編程知識，其它維度的知識結構也會影響到軟體的最終交付質量。

比如：資料庫的表結構和索引設計缺陷可能帶來軟體上的架構缺陷或性能風險；工程結構混亂導致維護困難；沒有鑒權的漏洞代碼被黑客攻擊等等。

《阿里巴巴Java開發手冊》劃分為編程規約、異常日誌規約、單元測試、MySQL 規約、工程規約、安全規約六大塊。那麼衍生的問題是為什麼我們提到的這些看似與編碼毫無關係的內容？有人提問，僅安全規約如果擴展開來可以是上百頁的資料，不知道寫在其中的意義何在？

其實，主要關注的是與開發緊密相關的知識點，試問一個不知道水平許可權校驗的 Java 開發者，會是一個合格的程序員嗎？這本手冊不是提倡大家深究所有的知識點而成為安全專家、運維專家，而是關注在編碼相關的生態知識上。

約束力等級為何是三級？《阿里巴巴Java開發手冊》根據約束力強弱及故障敏感性，規約依次分為強制、推薦、參考三大類。

強制是一種指令型的，是協作的 Gap，或是故障的痛點；

而推薦，希望這樣做是一件好事，大家都這樣做，結構更清晰，協作更高效，但是不這樣做也不會死。

而參考分成兩種情況：第一種是無法用代碼量化的描述，提倡什麼什麼樣的做法，如索引的創建索引時，寧濫勿缺的錯誤做法；第二種是真心覺得或左或右都可以，只是有傾向於一種，這個自由度由開發者自己把握。

擴展的說明、正例、反例用來表達什麼？如果只是冷冰冰的條目，對於閱讀者理解成本和記憶成本都是很大的挑戰，《阿里巴巴Java開發手冊》希望閱讀者能夠非常舒心地看完整個文檔，掩卷遐思，亦有所得。

具體來說，「說明」是對內容做了引申和解釋，為求知其然；「正例」提倡什麼樣的編碼和實現方式，推薦做法的其中之一；「反例」說明需要提防的雷區，以及真實的錯誤案例，讓人知其不然。

千淘萬淘雖辛苦，吹盡狂沙始到金

每個人在未來的世界，最重要的不是做的多久，而是在於做的多好。其實久和好是兩個不同的概念，要想做的久，做法是不一樣的，要做的好，做法也不一樣，有時候活的久，不一定活得好，又要活得久，又要活得好，那是非常難的。但就是這丁點大的差距在時間維度上日積月累，導致了程序員之間的巨大差距。

有人說，Java程序員的日常是搬磚，那麼磚在哪裡，就是一個個鍵盤。除此之外，難免還要和產品汪、運營、無厘頭的用戶打交道。

都說普通程序員到優秀程序員的過程，無非就是量變到質變的過程。其實不然，代碼多少行才會產生質變，很難量化，但是如果沒有深度地思考，就是寫再多的代碼也是枉然。就像一個泥水工，如果沒有胸懷，沒有思考，永遠只是壘磚頭的。

而在這其中，一名普通的程序員和一名優秀的程序員就出現了，優秀是知道自己的差距在哪裡。一些剛入行兩三年的程序員，經常說這個我懂了，那個我懂了，感覺寫代碼很枯燥，我要轉型，要麼往產品方向，要麼向架構師方向，要麼向管理方向。其實這距離一位基本程序員的自我修養，還只是摸到邊。如果靜下來，抬頭仰望星空，發現優秀離自己兩萬里，而卓越更是無邊無際。

那一名優秀的程序員如何突破成為一名卓越的程序員呢？卓越是彌補了這些差距。

比如：

1）融會貫通技術知識體系;

2）品味編程語言的內在美，感悟語言哲學;

3）勇立新技術潮頭。

最後，突然發現，在計算機的世界裡，所謂的全才是不存在的。真正的卓越，往往是某個語言方向，某個領域方向上，持之以恆的追求與實踐，以及永不磨滅的熱愛。

Java開發中如何用工匠精神突破創新？

對於任何一個項目，從重要性上來說，分為核心業務、非核心業務。前者更重視產品文檔、技術方案、規範化編程。從需求時效上來說，分為臨時性需求、長遠型需求。臨時性需求，相對來說更加講究快速實現、快速迭代。而長遠型需求，一定要考慮到，可能由不同的人在不同的階段進行開發，這個時候的效率和質量就會受到很大的挑戰。

其實，任何事情，都是一個度的哲學問題。如果只寫文檔，代碼編寫效率低，不行；如果天馬行空，只寫代碼，不寫任何文檔和注釋，更不行，表面上詩意盎然，事實上是暗流涌動。這就需要權衡好代碼和文檔，兩者都要抓都要硬。

在Java開發過程中，代碼和文檔的完美結合，講究的就是匠心和創新，這是一種態度，更專註細節，力求完美。

匠心來自堅守，沉浸在一個行業打磨若干年，正是因為這種堅守才能洞察用戶需求，比消費者自己更了解他們之後，創新才會針對消費者的變化主動觸發，匠心恰恰是創新的前提和基礎。

企業需要匠心精神的沉澱，也需要創新方式的突破，匠心和創新是相輔相成，切莫對立地去思考。

受訪人簡介：楊冠寶，花名「孤盡」，取自：

1.）孤帆遠影碧空盡的縮寫。那樣的場景很蕭瑟，但也很安靜，很懷念，很感恩。佇立山頂之巔，遙望小帆遠遠淡去，一種感恩。

2.）獨孤九劍，破盡天下武學。

無論是前者，還是後者，一方面，說明內心篤定的自信。另一方面，學習有時候是孤獨的，成功有時候也是孤獨的。希望在孤獨的道路上，左手溫暖右手。有胸懷，有遠見，程序員不要固步自封。

精彩內容回顧請點擊

1.如何成為10x數據科學家

2.程序猿，你要先健康，然後再變得優秀

3.[圖文]什麼是真正的程序員，讀完淚奔……