鄭昀 創建於2015/2/27 最后更新於2015/3/25
關鍵詞： 哲學、規則、套路、傳承
本文檔適用人員：廣義的技術人員
提綱：
- Don't make me think
- If it hurts, do it more and often
- 這個世界從來沒有什么救世主
- 沒有苦勞，只有功勞
一，Don't make me think
大家都知道，技術人員從事的是創造性工作，加之是單核處理器，我們的上下文切換非常困難，被打斷后從新進入“神游”狀態往往需要十幾分鍾。尤其是研發經理，承擔更多的責任，線上線下的問題都要照顧到，還要解答內外的各種咨詢，工作時間碎片化嚴重。我們（包括系統）給出的信息，一定要足夠簡練，一目了然，讓人很容易克服焦躁情緒，啪啪地就處理了，或者啪啪地二次分發出去。 不要用無用的信息折磨這些人。
其次，技術人員是“世界”的構建者，不得不做大量瑣碎且枯燥的工作，其中，相當大比例的工作是重復性的，如修改配置文件適配不同環境，如打包。
重復的工作一方面容易出錯，尤其是在通宵上線時，另一方面消磨人的耐心和斗志。 我在《職場培訓第五期：職場的真相》中講過解題思路：『要摒棄單純依靠員工之間互相提醒、依靠個人認真細致來規避相同錯誤的固有思路，鐵打營盤流水兵，靠人終歸是靠不住的，最好靠遵循規則的機器』。
王淮在《以 Facebook 為案例剖析科技公司應有的工具文化》一文中談及，基本理念就是凡是被很多人不斷重復的好習慣，要將其自動化，綁定到工具之中，以"Don't make me think"的方式來推廣最佳實踐（best practice）。
基於以上原因，我們認為，凡是被不斷重復的過程，將其工具化，綁定到自動化流程之中，減少不必要的心智負擔。
這也就是過去幾年里我們一季季地推進持續集成（Continuous Integration，CI）的原因，把我們的經驗教訓變成可重復的規則，融入工具中，融入自動化流程中，而不是一代一代口口相傳。
好了，在舉具體的例子之前，讓我們大聲讀出這幾條 Slogan：
- Don't make me think!
- 減少不必要的心智負擔！
實例一：
Exception 日志分析郵件是我們非常重要的工具，是我們的寶貴財富。每天凌晨 Python 腳本定時分析各個工程的 Exception 日志，按異常類型歸類，用郵件 Push 到研發經理桌面上，它充分體現了我們的哲學： 自動化是王道。
但如果看到郵件內容后，研發經理仍需要費一番功夫才能搞明白這是什么異常，而我們往往沒有足夠的時間，我們就會嫌麻煩，就會下意識地放過這個 Exception，甚至不再看日志分析郵件和報警郵件，那么“Exception 日清日結”就會淪為一句空話，等攢到每天數以千計 Exception 時已經失去了清理的欲望。
我們都知道，電商的購買流程每增加一個交互環節，就多了一道門檻，用戶最終成單轉化率=流量入口UV數×步驟1轉化率×步驟2轉化率×步驟三轉化率×……，同樣道理，我們要盡量把條理清晰、一目了然的報警郵件和 Exception 日志分析郵件推到大家面前， 操作越少越好，我是在幫你，不是給你找麻煩。
實例二：
Yahoo! 的 Combo Handler 的出現就符合本哲學，阿里還因此出了一款插件 nginx_concat_module。前端工程師可以發布便於閱讀的原版 JavaScript 和 CSS 文件，只要模板文件里做一個特殊聲明，多個文件就能通過服務器端的插件合並且壓縮，配好之后從此不需要再考慮 Minimize HTTP Requests、壓縮和混淆了。
實例三：
頁面上所引用的 CSS 背景圖片可能需要做到 CSS Sprite 圖里，然后在 CSS 里寫偏移量，每增加一個 CSS 背景圖片，這些操作都要來一遍。
也許這是不必要的心智負擔，因為機器可以自動做。假如我們引入 Gulp，就可以自顧自地在指定 folder 里放一張張 CSS 背景圖片，CSS 里寫好聲明，然后讓 Gulp 這個前端構建工具自己把 folder 下的背景圖片合並為一張大的 CSS Sprite 圖片，並且它自己修改 CSS 里的背景圖片地址和偏移量聲明，不需要為此每次費心費力。
二，If it hurts, do it more and often
我們不能死於聽天由命和漫不經心。
工程師為什么會聽天由命？
- 因為線上日志里的異常實在是太多了，處理不過來。
- 因為異常太多了，淹沒了致命異常，以至於服務掛得死死的才發現問題已經存在N久了。
- 因為明天就要提測了，代碼合並沖突還有幾千個。
- 每到常規版本提測時就心里打鼓，合並個代碼都得預留兩天時間。
- 因為畫時序圖好煩，所以復雜系統的數據流轉靠“心算”、靠文字描述。
- 人腦容易有思維死角，一個考慮不到，系統就防不住並發提交和重復提交。
- ……
因為已然集腋成裘，所以做事前我們各種糾結和抵觸，於是找各種理由拖延。
怎么辦？
我在《職業化的7個細節》里講到， 如果一件事做起來很煩，那就把它拆成很多塊兒，每天做一點，每次做一點。
實例一：
以代碼合並為例，如果每天早上到公司后，從開發主線合到自己的私有分支上，每天都做，那么等你向測試分支提測時，合並沖突是不是就少很多？
實例二：
如果你覺得畫時序圖（或泳道圖）麻煩，要么是你不會用 visio，要么是你想不清楚調用時序。你應該立即從手頭的功能開始畫時序圖，多練習，以后畫時序圖、業務流程圖只是分分鍾的事兒。用 excel 也能做泳道圖啊。
很多工程師覺得寫設計文檔好煩，不開設計評審會的話就不寫。我是這么做的：
- 我動手做一個系統，肯定已經大致想清楚了對象的定義、大致的設計模式；
- 也就有了一大堆的類文件（空的）以及目錄結構；
- 每個類文件我都先寫類功能定義、處理流程、數據類型定義，blabla 一大堆注釋。反正寫代碼之前也得想明白這些事兒，那就直接寫成注釋；
- 最后，把這些注釋摘出來，配上各種圖，一篇設計文檔就搞定了。
所以我從來不會為寫概要設計和詳細設計煩心。
三，這個世界從來沒有什么救世主
這個哲學我過去幾年里一而再再而三地講。在《職業培訓第五期：職場的真相》中，我說：
過去幾年里，我們深深地體會到，從來就沒有什么救世主，要創造人類的幸福全靠我們自己，不要指望有什么人能救我們，只能絞盡腦汁闖陣。
為什么？
技術團隊是互聯網公司里最認真最專業最實操最靠譜的一群人，如果我們凡事都要指望別人給我們解決方案和思路，指望別人比我們更認真，那這個公司就危在旦夕了。
所以，我在2012年的飛行研討會上拋出兩個 Slogan：
- 拋掉幻想，勇敢面對！
- 直面白刃戰！
實例一：
飛行研討會上我說：
遇到問題，立刻跟進去Debug
——主管不能僅僅說一些似是而非的官話套話
——主管要投入白刃戰
————我黨向來是副職打仗下到主攻第一線
————縱隊副司令到主攻師，副連長打仗帶尖刀排
——圍觀不能救中國
主管都不出手，指望工程師救你啊？
實例二：
對歷史因果關系、系統調用、業務邏輯和數據流轉，甚至系統里的臟數據，最了解的人莫過於我們。怎么可能指望上游部門有一個人橫空出世，洞悉所有細節，告訴我們該如何設計和實施呢？
是你的終歸是你的，躲不過去的。
基於這個哲學，我們衍生出兩個 Slogan：
- 不要等死！
- 向前邁半步對接！
四，沒有苦勞，只有功勞
早年間，侯小強曾經說過： 如果你在職場，需要有三個好習慣，1，能馬上做的事情馬上做。2，每個事情要有始有終。3，要有這個習慣思維，沒有苦勞，只有功勞。但如果沒有極其努力，通常也不會有功勞。
延續着這個思維，我們過去幾年里反復強調：沒有結果就沒有意義。不要期望公司因為你和小伙伴們有苦勞而寬容你們沒有產出，這是一個商業公司。
實例一：
一些內部研發課題，由於不像主站那樣直面消費者的壓力，所以工程師會做得比較粗糙。就算功能 okay 了，但總缺少一股精細范兒， 讓我們這些老手渾身難受，遲遲不能投入商業應用。這就屬於典型的“沒有結果”，沒有在指定時間到達指定戰場。
實例二：
以下幾個征兆會被我判定為“只有苦勞，沒有功勞”：
- 如果沒有結合前面幾個哲學，沒有定期審視自己的工作，沒有找出痛點並用工具解決痛點，而是低水平重復再重復。累是很累，加班也加了。
- 同樣的錯誤一而再再而三地犯，技術團隊因此忙於四處救火，料理臟數據。
以上就是窩窩這四年來總結的研發哲學。我認為，我們團隊應該把這些理念結結實實地變成新老員工的“本能”，用哲學來指導我們的行事方式，保證不管我們換了多少人，始終能前后一致。對現代中國曾經有一個說法“每隔十年亂一次”，Why？大抵是十年后掌權的那幫人，不記得十年前發生過什么，傳承都丟了，躊躇滿志，滿懷熱情再錯一遍。
-over-
職業培訓系列：
第一次培訓：2013年，職業化包含的六個行為模式
第二次培訓：2013年，職業化的七個細節
第三次培訓：2013年，大項目爆漿處理模式
第四次培訓：2013年，職場(潛)規則
第五次培訓：2014年，職場的真相
……
第十次培訓：2015年，窩窩研發哲學
