你與其他程序員可能常犯的 6 個錯誤

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

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

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

問題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 (人月神話) 這本書中描寫的很好。

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

總結

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

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

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

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

via： medium.com ，由Specs 翻譯整理，發布在Coder資源網，轉載請注明來源。