都是血淚，程式設計師傍身的生存法則（上）

筆者曲健，1024生人，天選程式設計師，漿糊人送外號“大爺Dà Yé”，目前在奧琪科技擔任首席架構師一職。

程式設計師生存法則Number One, 無出其右者，且不接受挑戰。

務必記住，程式設計師的第一武裝不是格子衫不是脫髮，是程式碼! 如果把程式碼比喻成人體，那麼邏輯(指令)是經脈，資料是氣血，而命名就是穴位。

大家想想在閱讀程式碼的時候，不管是變數名、方法名、類名還是系統名，都是用於輔助理解邏輯/功能的特別重要的標識。我可以負責任的說：程式設計師命名能力的高度基本決定了他/她未來的高度。命名絕不僅是名字本身，它更可對映出作者的思維框架、知識外延、邏輯推理、語言能力、創造力、想象力等等，所以是不是瞬間拔高了？

可以參見我之前關於取名技巧的一篇文章《IT範兒 | 你是個會取名兒的人麼？》

DàYé囉嗦

# 長點心好好補補英文，程式設計師閱讀各種英文文件需要詞彙量自不必說，如果你每次命名都需要翻譯軟體，不自知的取最生僻的那層含義，或者各種拼寫錯誤，往大了說特別容易引入BUG，往小了說實在丟人丟份。

# 同一程式碼塊/層級/工程中一定不要出現過於相似的名字。由於相似導致寫邏輯的時候把自己整亂的大有人在！每每評審看到這種程式碼吾必痛心疾首。

# 切不可文不對題，切不可“百轉千回”。何意？比如說判斷一個人是否是註冊會員，變數名被定義成了 notRegisteredUser，大家想想在寫各種if條件組合的邏輯判斷時會有多酸爽。

我經常跟團隊的人強調慢動手腦先行，可惜能領悟到精髓的人真心不多，其餘的通常會以專案進度為由，將“先碼起來”列為第一要務，殊不知災難就是這麼悄然來臨。

書法看筋骨，程式碼亦如此。

程式碼的“筋骨”無非就是分層、結構、邏輯、抽象、封裝、模式...曾經大行其道逢人必談，到現在感覺都沒什麼人提起了的GoF 23種設計模式，其實就提供了23種“筋骨”範例，大家依葫蘆畫瓢就行。

程式碼沒有編譯成機器碼之前，都是給人讀的。業界戲稱的衡量程式碼好壞的指標就是“閱讀該程式碼時說髒話的次數”，我們罵的通常就是程式碼“筋骨”。

要“想清楚”就是想辦法練好“筋骨”。TDD測試驅動模型的話，考慮應該怎麼設計邏輯控制？DDD領域建模的話，考慮應該怎麼建立領域實體？BDD老闆驅動的話，考慮迅速翻翻老闆以前寫過的程式碼、說過的話、下過的KPI，當然這是玩笑。

曾有多少次，我們懷著一顆要求完美的心，罵著前人寫的狗屎一樣的舊程式碼，不得不妥協著專案壓力，不斷降低著那條曾經的標準，敲出自我放逐的同樣狗屎一樣的新程式碼，附上那句可能永遠無法兌現的“以後重構”的承諾，最終進入一個不斷償還他人和自己技術債的死迴圈裡...

DàYé囉嗦

經典的《Java程式設計規範》裡開篇總則裡的“第一次就做對”，聽起來輕飄飄的一句話，背後深意滿滿。帶腦子有思考的編碼，想第一次能做對都不是那麼容易，別說沒動腦的了。這裡羅列一些身邊實際發生過的錯誤行為模式，供君一品：

# “初期沒多少資料量的，我迴圈著一條一條Insert沒什麼問題，等哪天資料量大了，我再考慮批次插入吧！” 請問批次插入很難麼？還需要以後？

# “這個程式碼是我從另一個專案裡複製過來的，他那邊執行的一直沒有什麼問題。” 然後某一天出現了記憶體洩漏，因為兩個專案的流量完全不對等，不求甚解不動腦，搬磚型碼農這裡體現的淋漓盡致。

# “為了測試環境方便聯調，易於排障，我每個關鍵點都列印了Info日誌。” 實際上列印的都是無腦的不攜帶任何引數線索的trans begin/trans end類日誌，在分散式日誌平臺裡看到的各種無法上下串聯的孤島日誌，我常常邊心疼著磁碟儲存和索引計算成本，邊碎碎念著這些系統真的可以做好線上運維排障麼？

# “某些邏輯點我hardcode了一些程式碼，用來觸發某些特殊邏輯分支方便測試，等上線的時候這些我都會刪掉。” 等真的上線了，這些hardcode被帶上去的不在少數。

# “系統有兜底的全域性異常攔截器，就算有些異常沒catch, 最終也會被攔截器包裝成標準報文返給前端的，所以有些類似空指標異常我就無視掉了。” 結果就是APP使用者不勝其煩的看到各種“系統未知異常”的彈窗。

# “Service層就是簡單的資料庫CRUD，Business層這麼多業務邏輯，保證資料一致那就讓事務的邊界擴大一些，直接把事務管理放到Business層不就完事了。” 結果就是事務裡面包裹了各種耗時資料IO、邏輯計算甚至更耗時的RPC呼叫，導致事務整個被拉長，資源被鎖住的時間也加長，最後就是各種阻塞直至雪崩。

東北大兄弟說：能動手就別BB。

程式設計師的基本工作除了前面說的動腦，緊接著就是動手了。這裡需要做一下澄清：基礎的編碼僅僅是動手能力的一部分，而真正的動手能力遠不僅於此。

身為一個程式設計師，可以搭建一個完整的網站，可以開發一個桌面效率工具，可以編寫一個Excel的VBA指令碼，可以根據官方文件部署和定製開源系統，可以根據API實現自動化偷懶...

以上才是我想說的動手能力。

大家都知道人和動物的區別是“使用工具”，而程式設計師群體是更加需要善用工具、甚至創造工具的一類人。當然不要本末倒置，使用工具不是目的只是手段，是為了提高效率、保證質量、降低成本等的手段。

DàYé囉嗦

# “程式碼的搬運(Copy&Paste)”絕對不是動手能力，“搜尋”卻是。因為優秀的程式設計師必然善用搜尋引擎、具備良好的搜尋技能。

參見我之前的一篇推文《技術人如何高效搜尋》

# 承認Copy&Paste是個偉大的發明，但是我還是建議能不用就不用，能手敲就手敲，除非是嚴重影響工作效率不得不C&P。歷史上由複製黏貼引起的BUG還小麼?

# 熟練IDE、作業系統、常用軟體的一些快捷鍵。不使用快捷鍵，就和手機不用手勢一樣。先不說了，WIN+L鎖屏，泡個程式設計師紅茶去。

程式設計師骨子裡的孤傲時常會把自己定位成一個問題終結者，提問題似乎與此格格不入。我到現在都沒太想明白這種孤傲源自於哪裡，也可能是知識工作者特有的清高。其實吧，大家日不離手的搜尋引擎，不就是一種另類的提問麼？

待續！！！

曲健，1024生人，天選程式設計師，漿糊人送外號“大爺Dà Yé”，

目前在奧琪科技擔任首席架構師一職。