通過這么廣泛的任務(wù)，我學(xué)到了很多不同的技能，并有很多想法想跟大家分享一下。也許你的觀點是不同的，也許你學(xué)到了一些其他的東西想在這里跟我們分享一下。我期待著聽到您的意見和見解。
本文主要針對 CTOs 和程序員，因為不是每個人都遇到過這些我觀察到的、學(xué)到的和解決過的問題。
問題1. “我對XX技術(shù)/工具不熟悉”
這是當(dāng)我要介紹一門新的技術(shù)或者語言的時候聽到的最常見的一句話。這也是當(dāng)我要求某位同學(xué)用他之前沒用到過的工具驗證他的想法的時候常常遇到的問題。
這讓我感到非常驚奇，因為我是在問一個非常聰明的人，一個開發(fā)人員。我們是不是能夠很容易地學(xué)習(xí)新的東西，一些新的理念，模式和架構(gòu)？我們不應(yīng)該不斷的學(xué)習(xí)新的事務(wù)，了解***的消息嗎？
或者，這只是一種假象？也許我們對很久之前學(xué)到的東西感到很滿足并且不想更換？也許是我們沒有時間學(xué)習(xí)新的東西？也許我們不能有不同的想法？
一段時間之后，那個被我安排了任務(wù)的人完成了任務(wù)。他們做到了，最初的猶豫終于被克服了，他們的舒適區(qū)擴大了。那么，一開始缺乏動力的原因是什么呢？
我認為這是一種對新鮮事物的恐懼，對失敗的恐懼。我們在我們所做的感到舒服，因為我們了解它，我們認為我們擅長它。事實是我們可以擅長其他一切東西，只要我們像學(xué)習(xí)之前的技能那樣去學(xué)習(xí)、去實踐。
問題2. “在一開始就考慮的太多”
這是我在開始新的項目時遇到的最常見的問題。程序員更加愿意加入到已經(jīng)在開發(fā)的項目中，因為不需要做什么決定。而新的項目卻不一樣，我們需要考慮并確定需求以及功能。
我看到的***的失敗就是實現(xiàn)，比如，一開始的身份認證。這不是我們應(yīng)用中最重要的功能嗎？我們不應(yīng)該考慮安全嗎？不，根本不是。
我們應(yīng)該盡可能的縮小范圍。我們應(yīng)該提供一個MVP展示概念驗證。我們應(yīng)該提供基本的商業(yè)規(guī)則，以及應(yīng)用程序的核心功能，而不是考慮性能、分頁、安全認證以及擴展等等。這是非常簡單的，至少在一開始的時候是這樣的。
如何實現(xiàn)呢？我覺得跟客戶的溝通是至關(guān)重要的。這是他們的錢，他們的投資，他們是給我們付錢的人。我們不想浪費他們的資金，他也不想浪費。我們應(yīng)該 一起討論重點是什么，我們應(yīng)該向他們的潛在客戶或者投資者提供什么。我們不應(yīng)該專注于其他人不會考慮的地方，如登錄/注冊功能，更改電子郵件或刪除帳戶。
問題3. “沒有選擇正確的工具”
我多次與不同的公司談到他們開發(fā)堆棧。有時候他們做的很花哨，并發(fā)和分布式事物使用Ruby…。當(dāng)我問他們?yōu)槭裁催x擇這個相對低效的語言時，他們的 回答是所有的程序員對Ruby最了解。當(dāng)然，這顯然是最快并且最廉價的方式。他們并沒有考慮到長期運行的可維護性。他們只關(guān)注價格和便捷性。這給他們帶來 很大的技術(shù)債務(wù)，并且很可能需要做很多hacking來實現(xiàn)既定目標。
另一個常見的現(xiàn)象是，很多程序員在熟悉業(yè)務(wù)規(guī)則之前就選擇技術(shù)棧。經(jīng)常可以在充滿激情的程序員中見到這種現(xiàn)象。他們是如此熱衷于開始開發(fā)和使用所有的***的框架。他們不考慮系統(tǒng)將要做什么，需要解決什么問題，他們就已經(jīng)選好了數(shù)據(jù)庫和語言。
在這種情況下該怎么辦？我的建議是讓程序員了解很多不同的語言。在熟悉問題和用例后，我們可以討論這個工具的利弊。了解市場上有正在發(fā)生什么，有什么框架或者語言，它們解決了什么問題是非常好的。堅持使用一種大家都知道的工具，可能在開發(fā)過程中帶來很大的痛處。
問題4. “重復(fù)造輪子”
這個問題主要是對其他人參與的不熟悉。當(dāng)我review別人代碼的時候經(jīng)常看到這種情況。我經(jīng)常問：“你看到那個class/module /function 了嗎？它跟你已經(jīng)實現(xiàn)的完全一樣。”這主要是程序員不經(jīng)常瀏覽代碼，他們不知道一些代碼可以重復(fù)使用，而不用在任何地方都重復(fù)提取。
如果我們遵循一些共同的模式，指導(dǎo)方針和架構(gòu)的時候尤其如此。極有可能其他程序員已經(jīng)在其他地方解決了這個問題，提取、抽象出了我們現(xiàn)在需要一個功能。
為了避免這種情況，我們應(yīng)該用一種更加明智的方法更多的做 code reviews。我們不應(yīng)該檢查別人的括號是不是對齊了或者是不是缺少了逗號，這些應(yīng)該留給自動化工具來做。我們需要 review 業(yè)務(wù)邏輯和行為。一段時間之后，我們會想，“ Kamil 已經(jīng)實現(xiàn)了它，我可以用他的模塊”。
問題5. “學(xué)習(xí)語法，而不是編程”
我遇到過這樣兩種程序員。實際上我可以說還有一種是前兩種結(jié)合起來的第三種程序員，但在這里并不重要。
***種是非常優(yōu)秀的 coder。他們了解所使用語言的各個方面，他們知道所有標準庫以及很多第三方的工具。他們知道8種方法來寫一個循環(huán)、如何使用模式匹配和所有的語法。但問題是，他們不知道架構(gòu)和模式。他們的代碼是必要的，但他們不能提取出功能、處理封裝并分解到不同的層或者模塊。他們只會編碼。
第二種是非常棒的 craftsmen (工匠)。他們是真正的架構(gòu)師，他們會模塊化他們的應(yīng)用程序、使用單獨的庫來提取組件、按照模式設(shè)計有效的流程。只是他們不會編碼。他們把太多的時間花費 在低效的算法、不建議使用的函數(shù)、過時的庫。也許他們的架構(gòu)體系是可靠的，工作流是強大的，但他們的代碼可能很難看，很難讀。
問題出在哪呢？***種情況可能是程序員只讀與他使用語言有關(guān)的編程書籍。就相當(dāng)于只學(xué)習(xí)語法而不學(xué)習(xí)別的。他們認為他們會語法，所以他們會編程。而實際上我們只會寫代碼。第二種情況是程序員忘記了他們使用的語言或者工具的新版本，他們不看更新日志，不看新聞和簡訊。
解決方法是什么吶？就是在項目中兩種人同時存在，每個人都會互相學(xué)習(xí)，這是每個人都會感到滿意和受益最多的一種方式。
問題6. “忽略模式”
當(dāng)一個人加入到一個有堅實基礎(chǔ)的項目是，他很可能會遵循一些規(guī)則和指引。通常，開發(fā)人員在每一個地方都會有一個慣例，使其在每個地方都是可讀和可理解的。
不幸的是，當(dāng)一個新人加入編碼的時候，他可能不知道內(nèi)部正在開發(fā)項目的相似性。他可能會使用一種不同的、不符合當(dāng)前要求的方法。
我們是如此熱衷于提供一個新的功能，以至于我們不想浪費時間來觀察現(xiàn)有的趨勢和模式。我們完全忽略了既定的規(guī)則，并因為我們自己的習(xí)慣打破一致性。
這是不好的嗎？并不經(jīng)常是這樣。有時候，特別是有經(jīng)驗的程序員加入團隊的時候，這可能是好的。他們可以教其他人如何架構(gòu)應(yīng)用，并給他們分享知識。這 有時候會給現(xiàn)有的架構(gòu)帶來一些新的觀點，提高其中的一些概念。但事實上，這種情況很少見。大多數(shù)情況下，一個新的開發(fā)者只會帶來麻煩。這在 The Mythical Man-Month (人月神話) 這本書中描寫的很好。
如何解決呢？我覺得引進一個新的項目是必要的。我們不應(yīng)該要求盡快的有新的功能，而是要有人能夠深入到既定的規(guī)則。我們應(yīng)該任命一個一開始就能指導(dǎo)別人的人為主管，讓他掌握所有的概念。
總結(jié)
編程的世界中有很多的問題，我們每個人都有不同的技能，不同的能力和動力來源。即使是我們不這么想的方式也會不同。我們應(yīng)該互相溝通，共同解決問題，并做出權(quán)衡。
學(xué)習(xí)是關(guān)鍵。自主開發(fā)不應(yīng)該停止。我們不得不這樣做，除非我們不想成為優(yōu)秀的程序員。不斷地學(xué)習(xí)和了解新的東西是我們應(yīng)該做的工作。
讀書是***方式，結(jié)對編程是第二種方式，訂閱電子報可能是第三條道路，以及關(guān)注一些博客可能是另一個方式。
可能性是***的，我們只需要選擇適合我們的就是***的。
via：medium.com，由 Specs 翻譯整理，發(fā)布在 Coder資源網(wǎng)。
