不利于寫出好代碼的15個職場因素

        英文原文：15 workplace barriers to better code

        每個開發者在編碼時，都希望代碼像水管的水一樣源源不斷的流出，思緒不被打斷。但在現實開發中，經常會由于一些事情突然中止或停下。本文就總結了現實工作中，影響編碼進度的 15 個“攔路虎”。

        1. 開會

        停止手頭的編碼工作，去參加會議。程序員或許不會相信，他們可能已經在會議室花費了數周或數年時間和老板閑聊技術細節。

        當你從會議室出來后，大腦可能需要一定的轉換時間，才能再重新投入到編碼工作上，你很有可能需要一個小時的過渡。

        2. 回復所有的電子郵件

        如果會議已經夠糟糕的了，那么沒完沒了的郵件可能更讓人頭疼。經過幾個小時的來回討論，最終卻沒有個結果。

        3. 衡量生產能力

        有些管理團隊受到一些書籍啟發，對提交到代碼庫的代碼行數或 bug 修復數進行統計，并且作用一種衡量標準。他們認為，統計是一種衡量，而衡量肯定是有好處的。

        然后他們根據此標準為開發者的工作能力進行排名。開發者猶如網絡游戲中的玩家，他們將更加關心自己的排名，而不是如何讓代碼更好。

        開發者的重點變成了統計代碼所編寫的行數、解決 bug 或把所統計的提交的倉庫里。如果代碼行數都計算在內的話，原本一個問題只需 10 行代碼即可解決，程序員有可能編寫 5000 行代碼，來讓功能更加靈活和兼容，這樣，他的代碼總量就會增加 5000 行了。

        衡量生產力反而會使代碼變的更糟，讓項目里充滿功能豐富但過度設計的代碼。

        真正解決這個問題，我們需要跟蹤 bug，我們需要組織工作流和協調軟件開發，這些都是無法準確衡量。

        4.  愛慕虛榮（Prima donna）的開發者

        就開發者而言，最糟糕的莫過于其他開發人員沒有按照項目需要進行開發，而是用自己的方式來迭代項目。每一個開發者都能識別出可怕、不可原諒的最后一次迭代行為。

        這種不考慮之前已完成編程工作的態度會拖慢項目的進度。傲慢和利己主義會導致程序員扔掉合適的代碼，而以他們認為的“正確的方式”重新構建。

        5. “以后再修復”思維模式即“技術債務”

        有時候，我們很難按照需求在數天里完成相應的功能，因此我們可能會偷工減料、補丁代碼等。聰明的項目經理在弄清事后必須補上的“債務”后，形象的稱它為“技術債務”。

        每個項目都會有一定的技術債務，有的可能會快速還清，而有的可能會在下一個版本中初見端倪。

        6. 非程序員經理

        有些程序員很喜歡這樣的經理，他們不會對你的代碼指手畫腳，而且在技術上愚弄他們很容易。而他們也很難給你技術上的指導。

        7. 程序員經理

        雖然程序員可能會抱怨要和完全沒有編程經驗的項目經理一起工作，但他們也經常私底下說如果項目經理具備編程能力可能會更糟糕，甚至有多糟糕就多糟糕。

        具有編程能力的項目經理可能會對項目管理的太細，因為他們一旦有新的觀點，代碼就會大片修改。

        8. 技術過硬但有些強勢的程序員

        程序員往往都是因為過硬的技術才被公司賞識，而不是人際交往。但不能每次出現問題都責怪穿西裝不自在或銷售人員過于熱情，有可能問題出現在自己身上。

        客戶想要一些不同的東西，這對此類程序員來說無關緊要，他們更多的是關注于技術參數。

        然而在人際相處中，他們經常會過濾掉彼此的特質，當他們彼此產生爭議時，就可能影響到整個團隊的進度。

        9. 自私或莽撞的程序員

        自戀狂程序員的工作可以說是非常酷和快，但遺留的問題也會很多，而你的工作就是處理這些瑣事，對程序進行測試保證它不會崩潰。

        許多團隊在發現這一點后，都已經太晚了。在早期的測試中，代碼塊都可以很好的工作，但在推送一些真實數據后，大家才意識到并沒有人檢查這一問題。

        10. 文檔不全

        有時，這里會有大量的文檔，但它可能是幾個月前或者一些老版本的記錄。我們沒有時間繼續記錄和修復代碼，但它對我們來說仍然是有用的。

        11. 純粹地編寫文檔

        雖然我們都經歷過沒有文檔的項目，太多的廢話和較少的代碼常常會導致代碼失敗。程序員經常會根據需求編寫評論，他們很詳盡地把每個細節記錄在文檔里，沒有總結或進行深入的理解，但如果沒有提供太多的抽象和理解，這很有可能是一份失敗的文檔。

        12. 易分散注意力的環境

        雖然銷售和營銷團隊能夠在具有噪音的環境里很好的工作，而程序員則需要圖書館般那種安靜的環境。雖然許多企業給包括程序員在內的員工提供了類似乒乓球這類的運動，但他們常常忘記，程序員需要在安靜的環境下辦公，否則，嘈雜的環境很容易分散程序員的注意力。

        13. 辦公文化

        你想擁有自己的辦公室嗎？還是你想在可以隨時提出你的問題團隊里工作？你是喜歡在清晨工作還是熬夜呢？

        如果一個團隊擁有一個相似的風格，那么這個團隊會運營的更好。如果無法找到一個共同點，很有可能會快速失敗。

        這可能太一概而論了，但你想象下，如果你正在編譯或者準備完成項目，而此時團隊里的人在互相爭吵，你不得不中斷下來，這樣時間不就浪費了嗎？

        倘若我創建了一個非常復雜的算法，而中斷、談話、甚至是敲鍵盤的聲音都會使我無法集中精力，這時，我就非常希望有屬于自己的辦公室。

        14. 緊隨遺留技術

        最令人討厭的莫過于去改寫那些塵封已久的舊東西，他們經常會忘記這樣做所花費的成本，有些代碼是在 ASCII 之前編寫的，意味著你要重新轉換輸入輸出。舊的系統通常會計算空格字符，僅僅是為了弄清其在數據庫中是干嘛的，這更要進行轉換。

        程序員做大量的工作來截圖、重新格式化等，而過一段時間后，他們可能會花更多的精力去復制代碼，而不是去重新編寫邏輯代碼。

        15. 迷戀最新的工具

        最新的工具可以給你帶來很多樂趣，處于最前沿的程序員總是喜歡修改整個 API，并且重寫它們，迫使人們不得不修改底層的代碼。

        當我試圖兼顧 Python 3.0 和 Python 2.7 兩個版本時，盡管 Pyhton 是一個相對穩定的版本，但我還是感到很煩。

        在許多情況下，新的工具都沒有得到十足的鍛煉。例如，Node.js 的確非常快，但只有在你重新學習了關于創建進程時死鎖的所有知識后才能做到。利用最新的工具是可以帶來很好的結果，但天下沒有免費午餐，并且會為此付出足夠多的學習成本。