程序員的那些反模式

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

今天，咱們來談一談程序員的行爲中的那些反模式，涉及程序員的平常工做和學習的各個方面。

這些反行爲模式，並不針對某些特定的我的。若是你不幸中招，千萬不要懊惱，由於這實在太正常不過了，不少反模式的坑我也是親身踩過的^-^

稍微修改幾行代碼就調試

對全部程序員來講，這個行爲有一點心理上的緣由：工程師都喜歡在作完一點修改以後，當即看到它的效果。這是一種誘惑。

除此以外，這種作法通常多見於新手。

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

可是，不得不說，這種作法是低效的。

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

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

最終，忍痛卸載。

（完）

其它精選文章：

• 技術的正宗與野路子
• 編程世界的熵增原理
• 程序員的宇宙時間線
• Android端外推送到底有多煩？
• Android和iOS開發中的異步處理（一）——開篇
• 用樹型模型管理App數字和紅點提示
• 一張圖讀懂RxJava中的線程控制
• 宇宙盡頭的描述符（下）
• Redis內部數據結構詳解(5)——quicklist
• Redis內部數據結構詳解(4)——ziplist