程式設計師可能常犯的 6 個錯誤

我擔任 CTO 已經有一段時間了，我覺得這是一個非常好的鍛鍊機會，因為我不僅可以編寫程式碼，還要帶領團隊，管理專案，設計架構，組織工作，審查程式碼，調查不同的問題，研究各種解決方案，瞭解許多技術以及聯絡客戶等等。

透過這麼廣泛的任務，我學到了很多不同的技能，並有很多想法想跟大家分享一下。也許你的觀點是不同的，也許你學到了一些其他的東西想在這裡跟我們分享一下。我期待著聽到您的意見和見解。

本文主要針對 CTO 和程式設計師，因為不是每個人都遇到過這些我觀察到的、學到的和解決過的問題。

問題1. “我對XX技術/工具不熟悉”

這是當我要介紹一門新的技術或者語言的時候聽到的最常見的一句話。這也是當我要求某位同學用他之前沒用到過的工具驗證他的想法的時候常常遇到的問題。

這讓我感到非常驚奇，因為我是在問一個非常聰明的人，一個開發人員。我們是不是能夠很容易地學習新的東西，一些新的理念，模式和架構？我們不應該不斷的學習新的事務，瞭解最新的訊息嗎？

或者，這只是一種假象？也許我們對很久之前學到的東西感到很滿足並且不想更換？也許是我們沒有時間學習新的東西？也許我們不能有不同的想法？

一段時間之後，那個被我安排了任務的人完成了任務。他們做到了，最初的猶豫終於被克服了，他們的舒適區擴大了。那麼，一開始缺乏動力的原因是什麼呢？

我認為這是一種對新鮮事物的恐懼，對失敗的恐懼。我們在我們所做的感到舒服，因為我們瞭解它，我們認為我們擅長它。事實是我們可以擅長其他一切東西，只要我們像學習之前的技能那樣去學習、去實踐。

問題2. “在一開始就考慮的太多”

這是我在開始新的專案時遇到的最常見的問題。程式設計師更加願意加入到已經在開發的專案中，因為不需要做什麼決定。而新的專案卻不一樣，我們需要考慮並確定需求以及功能。

我看到的最大的失敗就是實現，比如，一開始的身份認證。這不是我們應用中最重要的功能嗎？我們不應該考慮安全嗎？不，根本不是。

我們應該儘可能的縮小範圍。我們應該提供一個MVP展示概念驗證。我們應該提供基本的商業規則，以及應用程式的核心功能，而不是考慮效能、分頁、安全認證以及擴充套件等等。這是非常簡單的，至少在一開始的時候是這樣的。

如何實現呢？我覺得跟客戶的溝通是至關重要的。這是他們的錢，他們的投資，他們是給我們付錢的人。我們不想浪費他們的資金，他也不想浪費。我們應該一起討論重點是什麼，我們應該向他們的潛在客戶或者投資者提供什麼。我們不應該專注於其他人不會考慮的地方，如登入/註冊功能，更改電子郵件或刪除帳戶。

問題3. “沒有選擇正確的工具”

我多次與不同的公司談到他們開發堆疊。有時候他們做的很花哨，併發和分散式事物使用Ruby…。當我問他們為什麼選擇這個相對低效的語言時，他們的回答是所有的程式設計師對Ruby最瞭解。當然，這顯然是最快並且最廉價的方式。他們並沒有考慮到長期執行的可維護性。他們只關注價格和便捷性。這給他們帶來很大的技術債務，並且很可能需要做很多hacking來實現既定目標。

另一個常見的現象是，很多程式設計師在熟悉業務規則之前就選擇技術棧。經常可以在充滿激情的程式設計師中見到這種現象。他們是如此熱衷於開始開發和使用所有的最新的框架。他們不考慮系統將要做什麼，需要解決什麼問題，他們就已經選好了資料庫和語言。

在這種情況下該怎麼辦？我的建議是讓程式設計師瞭解很多不同的語言。在熟悉問題和用例後，我們可以討論這個工具的利弊。瞭解市場上有正在發生什麼，有什麼框架或者語言，它們解決了什麼問題是非常好的。堅持使用一種大家都知道的工具，可能在開發過程中帶來很大的痛處。

問題4. “重複造輪子”

這個問題主要是對其他人參與的不熟悉。當我review別人程式碼的時候經常看到這種情況。我經常問：“你看到那個class/module/function 了嗎？它跟你已經實現的完全一樣。”這主要是程式設計師不經常瀏覽程式碼，他們不知道一些程式碼可以重複使用，而不用在任何地方都重複提取。

如果我們遵循一些共同的模式，指導方針和架構的時候尤其如此。極有可能其他程式設計師已經在其他地方解決了這個問題，提取、抽象出了我們現在需要一個功能。

為了避免這種情況，我們應該用一種更加明智的方法更多的做 code reviews。我們不應該檢查別人的括號是不是對齊了或者是不是缺少了逗號，這些應該留給自動化工具來做。我們需要 review 業務邏輯和行為。一段時間之後，我們會想，“ Kamil 已經實現了它，我可以用他的模組”。

問題5. “學習語法，而不是程式設計”

我遇到過這樣兩種程式設計師。實際上我可以說還有一種是前兩種結合起來的第三種程式設計師，但在這裡並不重要。

第一種是非常優秀的 coder。他們瞭解所使用語言的各個方面，他們知道所有標準庫以及很多第三方的工具。他們知道8種方法來寫一個迴圈、如何使用模式匹配和所有的語法。但問題是，他們不知道架構和模式。他們的程式碼是必要的，但他們不能提取出功能、處理封裝並分解到不同的層或者模組。他們只會編碼。

第二種是非常棒的 craftsmen (工匠)。他們是真正的架構師，他們會模組化他們的應用程式、使用單獨的庫來提取元件、按照模式設計有效的流程。只是他們不會編碼。他們把太多的時間花費在低效的演算法、不建議使用的函式、過時的庫。也許他們的架構體系是可靠的，工作流是強大的，但他們的程式碼可能很難看，很難讀。

問題出在哪呢？第一種情況可能是程式設計師只讀與他使用語言有關的程式設計書籍。就相當於只學習語法而不學習別的。他們認為他們會語法，所以他們會程式設計。而實際上我們只會寫程式碼。第二種情況是程式設計師忘記了他們使用的語言或者工具的新版本，他們不看更新日誌，不看新聞和簡訊。

解決方法是什麼吶？就是在專案中兩種人同時存在，每個人都會互相學習，這是每個人都會感到滿意和受益最多的一種方式。

問題6. “忽略模式”

當一個人加入到一個有堅實基礎的專案是，他很可能會遵循一些規則和指引。通常，開發人員在每一個地方都會有一個慣例，使其在每個地方都是可讀和可理解的。

不幸的是，當一個新人加入編碼的時候，他可能不知道內部正在開發專案的相似性。他可能會使用一種不同的、不符合當前要求的方法。

我們是如此熱衷於提供一個新的功能，以至於我們不想浪費時間來觀察現有的趨勢和模式。我們完全忽略了既定的規則，並因為我們自己的習慣打破一致性。

這是不好的嗎？並不經常是這樣。有時候，特別是有經驗的程式設計師加入團隊的時候，這可能是好的。他們可以教其他人如何架構應用，並給他們分享知識。這有時候會給現有的架構帶來一些新的觀點，提高其中的一些概念。但事實上，這種情況很少見。大多數情況下，一個新的開發者只會帶來麻煩。這在 The Mythical Man-Month (人月神話) 這本書中描寫的很好。

如何解決呢？我覺得引進一個新的專案是必要的。我們不應該要求儘快的有新的功能，而是要有人能夠深入到既定的規則。我們應該任命一個一開始就能指導別人的人為主管，讓他掌握所有的概念。

總結

程式設計的世界中有很多的問題，我們每個人都有不同的技能，不同的能力和動力來源。即使是我們不這麼想的方式也會不同。我們應該互相溝通，共同解決問題，並做出權衡。

學習是關鍵。自主開發不應該停止。我們不得不這樣做，除非我們不想成為優秀的程式設計師。不斷地學習和了解新的東西是我們應該做的工作。

讀書是第一方式，結對程式設計是第二種方式，訂閱電子報可能是第三條道路，以及關注一些部落格可能是另一個方式。

可能性是無限的，我們只需要選擇適合我們的就是最好的。