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

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

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

　　稍微修改幾行代碼就調試

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

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

　　新手對于敲下的每一行代碼都不太有確信的把握，因此需要依靠高密度的調試來一步步確認。當一個老手在項目中首次使用一個新的技術時，情況也與此類似。

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

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

　　更好一點的方式是：動手編碼之前，提前想好一個完整功能或模塊的關鍵邏輯，然后一口氣敲完所有代碼，最后一次性調試所有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版。結果一發而不可收拾，各種群消息不停地蹦出來，簡直是專注力的一劑毒藥。

　　最終，忍痛卸載。