程式設計師的那些反模式

有雞湯就有反雞湯，有模式就有反模式。

今天，我們來談一談程式設計師的行為中的那些反模式，涉及程式設計師的日常工作和學習的各個方面。

這些反行為模式，並不針對某些特定的個人。如果你不幸中招，千萬不要懊惱，因為這實在太正常不過了，很多反模式的坑我也是親身踩過的^-^

稍微修改幾行程式碼就除錯

對所有程式設計師來說，這個行為有一點心理上的原因：工程師都喜歡在做完一點修改之後，立即看到它的效果。這是一種誘惑。

除此之外，這種做法一般多見於新手。

新手對於敲下的每一行程式碼都不太有確信的把握，因此需要依靠高密度的除錯來一步步確認。當一個老手在專案中首次使用一個新的技術時，情況也與此類似。

但是，不得不說，這種做法是低效的。

• 首先，稍微大一點的專案，手動除錯一遍都會比較花時間。
• 更重要的是，不停地中止編碼工作來進行除錯，很容易打斷思路，甚至漏掉一些關鍵流程。

更好一點的方式是：動手編碼之前，提前想好一個完整功能或模組的關鍵邏輯，然後一口氣敲完所有程式碼，最後一次性除錯所有case。如果有自動化測試+Daily Build系統，一定要充分利用。

當然有時候難免會碰到不太確認的技術點，這時如果可能的話，更好的方式是單獨搭建一個輕量級的、便於除錯和驗證的工程，來把模糊的技術點系統地摸索一遍。

通過設定眾多斷點的方式來學習新專案

對於剛剛入職一家新公司的程式設計師來說，首先要做的一件事也許就是學習和熟悉新的專案工程了。於是我們經常看到類似如下的一幕：

通過設定大量的斷點，來弄懂程式的執行流程，這種做法對於小專案來說，其實是沒有什麼問題的。但對於複雜的大型專案，容易使人陷入細節，造成“一葉障目，不見泰山”的後果。

而且，在那些大量使用非同步和多執行緒的工程中，斷點除錯和真實執行的時候往往存在差異。特別是對於一個公司新人來說，這有可能導致他對專案程式碼的片面理解，甚至誤解。

對個人來說，這種做法也容易養成一種“不除錯就看不懂程式碼”的習慣。這是一種不太有益的依賴症。要知道，相對於我們將要閱讀的程式碼，我們能親自除錯的機會少之又少。

我的觀點是：斷點除錯是個很不錯的工具，但如果把它作為新人學習新專案的主要途徑，那麼一定要警惕它所帶來的弊端。

只依賴百度來搜尋技術問題

程式設計師應該使用谷歌還是百度，已經有太多人討論過了。我覺得在這裡不需要再次強調它們在搜尋技術問題方面的區別了。

一般來說，即使你由於環境所限用不了谷歌的話，用一用bing.com的英文版，也是比百度更好的一個選擇。

但這裡需要說明的一點是，搜尋技術問題，並不是說用百度就肯定得不到好結果。其實，當你想搜尋某個固定用法的相關程式碼參考一下的時候，百度是能很快速地滿足你的要求的。但是一定要記住，搜到的程式碼不要直接拿來就用，一定要從Spec和API Reference的層面找到使用的依據（Spec的概念參見我的另一篇文章《技術的正宗與野路子》）。

不經意間使用翻譯外掛

當你訪問英文網站的時候，你的瀏覽器是否會彈出類似這樣的“翻譯工具欄”？

這是現代瀏覽器智慧化的一個體現。但是，對於程式設計師閱讀技術文章來說，還是原汁原味的英文文件表達得更準確。

所以，如果你的瀏覽器有這樣一個翻譯工具欄，那麼想辦法卸掉它或關閉它。

閱讀英文技術文件，其實對英語基礎的要求並不太高。英文技術文件，所涉及到的詞彙量很有限，而且一般句式比較簡單。之所以有人感到困難，很多時候是一種耐心的缺乏或心理的恐懼。

對於我們團隊內的每個人，我都會這樣告訴他：閱讀英文技術文件的能力，是一個must；否則，你在技術的路上就很難突破。

先實現簡單的，其它後面再說

我們總是習慣從擅長的事情出發來決定行為。當一個專案中出現一些複雜的、超出常規的部分時，很多人的選擇是先把簡單的部分做完，複雜的部分最後再說。

“最後再說”的意思是，等到專案的後期再來考慮它。這其實是在逃避和擱置矛盾。

從另一個層面來說，這也是人們趨利避害的一種本能。一種鴕鳥心態。

到那時有可能已經臨近專案截止日期，人們更沒有足夠的耐心來設想解決方案，而最終只能求助於一些折中，比如降低產品要求。

在比較壞的情況下，還可能出現由於關鍵細節沒有在開始討論清楚，從而最後推翻整個設計的情況。

所以，在專案開始之初，就要優先把那些看似複雜的、有可能超出掌控的產品技術點討論清楚。實際上，能否把最複雜多變的東西在一開始就考慮清楚，反映了一個團隊的綜合水平。

IDE裡看不到依賴工程的原始碼

我在另一篇文章《技術的正宗與野路子》中已經提到過這個問題。這裡我再展開講一下。

不管是出於提升自身的目的，還是由於工作需要，我們都需要閱讀一些優秀的開源原始碼。實際上，閱讀開源的程式碼未必非要找一個完整的開源工程，從頭到尾地去讀。應該從日常工作需要的SDK原始碼入手，積少成多。

每個程式設計師，不管他是用什麼語言來編寫程式，一般來說都要依賴某個語言的SDK，而且通常它們都是開源的。比如Java的JDK，比如C++的STL，再比如Android SDK。一定要把你的開發環境設定成一點選某個呼叫的方法就能跳轉進原始碼實現。只有這樣，你才能把平常開發的時間利用起來，隨時隨刻都點過去閱讀原始碼。

有時候我發現某些工程師用的IDE很高階，各種快捷鍵用得也很溜，但就是點選不到原始碼，這讓人很難理解。在這種情況下程式設計，我會感覺自己像是被蒙上了眼睛一樣。

當然有些程式設計師面對的是一個閉源的系統，比如iOS程式設計師，似乎這個方法不太適用。不過閉源的SDK通常註釋寫得比較詳細，至少通過IDE把每個呼叫的註釋都仔細讀懂。況且，現在iOS上的Swift的SDK不是也開源了嘛。

IDE裡一點選就看到依賴工程的原始碼，這個習慣不僅適用於閱讀開原始碼，也適用於在一個大公司內呼叫其它團隊提供的介面的時候。在任何公司和組織內部，不斷加深對於周邊系統的理解，不斷擴大你的知識邊界，永遠都是讓你從眾人中脫穎而出的有效途徑。

懶得閱讀前人的程式碼，因為它們太爛

當我們有了一點工作經驗之後，我們總是會抱怨工程中前人留下的程式碼太爛，總有一種推翻重寫的衝動。

很多時候，前人留下的程式碼質量如何，剛接觸專案的人是會產生錯誤印象的。但是，我們要知道，之前的程式碼作者掌握的資訊可能比我們目前看到的要多，我們現在考慮到的和沒考慮到的，可能作者都已經考慮過了。

更何況，編碼猶如創作，有人說好就有人說不好。就像最近新獲雨果獎的《北京摺疊》，有些人覺得是中國科幻的進步，而另一些人則認為這不是一部成熟的作品。作為一名科幻迷，我也在朋友圈裡對它進行了批評。對於一部原創作品來說，雖然每個人有堅持自己看法的權利，但我們應該理解，爭議是會始終存在的。

因此，對前人留下的東西，首先應保持敬畏，這樣才有可能去了解它。

即使是前人的程式碼真的很爛，那麼我們在重構之前也應該徹底讀通它，以保證在進行程式碼結構升級的時候不至於丟掉邏輯。

要知道，讀懂別人的程式碼，是一種更高的能力。

一有問題就找Leader提問

愛問問題，通常被認為是一種美德。

但有一種情況，卻可以被認為是懶於思考或不得要領的表現。

假設你的Leader交給你一個任務：研究某項新技術，並把它用到專案中。很快，你就碰到一個解決不了的障礙。然後你去找Leader請教。

結果，你的Leader在瞭解完你的問題之後，反問了你一些問題，比如：“如果換另外一種使用方式會怎麼樣呢？”，或者，“文件裡提到的這個概念，好像跟另一個問題有關，它是什麼意思呢？”，再或者，“這個問題到底是怎樣產生的呢？它的底層原理你瞭解過沒有呢？”

這時如果你的回答是“不知道，我還沒來得及看”，恐怕你的Leader就會在心裡把“不善思考”的帽子扣在你頭上了。

這裡其實有點像個陷阱。如果你的Leader問的這些問題你都能回答下來，那其實你多半已經能解決原來的問題了。

所以，在把你的問題拋給你的Leader之前，要確保你已經充分探索了所有可能性，最好已經有了一些解決思路，只是需要你的Leader來幫你做一些權衡，到底選擇哪一條思路。

輕易說不可能實現

產品同學們經常會找程式設計師確認一些想法的可行性，類似下面的對話：

產品同學： 這個地方的資料能否換成像XX軟體那樣的展示形式呢？
程式設計師： 不可能。我們服務端的資料儲存格式根本不是那樣設計的。
產品同學： 那這裡的互動能改一改嗎？讓使用者更方便操作一些。
程式設計師： 不能。我們用的這個控制元件這裡是寫死的。
產品同學：這個控制元件不能改一改嗎？
程式設計師： 改不了，這是一個系統預設控制元件……

作為技術人員，當被問及可行性的時候，應該仔細思考，必要的時候做一些調研，然後再給出答案。輕易地給出不可能的答案，可能會限制產品發展的思路。

實際上，很多的不可能，是侷限於現有實現而做出的片面的判斷。跳出現有邏輯，很多不可能就能變成可能。

要知道，許多偉大的產品都是突破了眾多的不可能才產生的。而在不可能向可能轉化的過程中，舊的技術體系被揚棄，新的開發方式被引入，原有的侷限被突破，技術本身也必將經歷一場浴火重生的洗禮。

盯著QQ秒回訊息

在一家公司工作一段時間之後，你負責的東西越來越多，跟你有關的事情也變得越來越多。於是，公司內經常有人在QQ上找你幫忙，或者問你問題。

每天從一上班開始，你的QQ圖示就閃個不停。等你剛剛處理完，正準備編碼實現一段演算法的時候，QQ圖示又亮了。

同事都誇讚你秒回訊息，有求必應。但你的核心開發任務卻總是一再拖延。

這裡涉及到一個時間管理的問題。

這個問題對於一些一線的技術管理人員，尤其嚴重。一會溝通協調，一會被拉去開個討論會，再過一會又有人跑過來商量技術問題。疲於應付了將近一天，眼看到了下午五六點鐘了。這時終於安靜一點了，但你整個人身心俱疲，儼然已經是強弩之末，再也進入不了深入思考的狀態了。於是，白天原計劃完成的工作，也只能晚上拿回家去開夜車了。

說實話，這個問題相當棘手。如果你能做到將注意力在不同的事情之間快速切換，我只能說你真的很厲害！這樣你在被打斷後，就能快速回到原來專注的事情上去。

而對於普通人來說，類似番茄工作法那樣，將時間精細切割，可能會有些效果。前提是你確實能夠堅持下來，並在需要的時候保持足夠的專注。

現在我們在教育小孩的時候都知道，專注是一種很可貴的品質，有可能直接關係到他/她未來能取得的成就。但可惜的是，越來越多的成年人正在喪失這種品質。

前段時間，我安裝了微信的Mac版。結果一發而不可收拾，各種群訊息不停地蹦出來，簡直是專注力的一劑毒藥。

最終，忍痛解除安裝。