程序員世界常見的6個問題
我作為CTO已經有一段時間了。在這個工作崗位上，我不但制定準則，還帶領團隊、管理項目、設計架構、組織工作、制定代碼審查、調查不同的問題、研究各種解決方案、結識許多技術人員和聯系客戶等等等等，做了很多事。
在完成這些任務的過程中，我不但學到了很多不同的技能，并得出了很多觀察結果，想與大家分享。
本文針對的是***技術官和開發人員，因為可能并不是每一個人都碰到過我下面發現、學習并得到解決的問題。
問題1：“我不熟悉X技術/工具”
這是每次在我要介紹新技術和語言的時候，最常聽到一句話。也是在我要求某人用一種他們不認識的工具準備一個概念證明時，非常耳熟的一句話。
這讓我很驚訝，為什么呢？因為我認為程序員都是高智商的！學習一些新的東西，新的理念、模式和架構對于他們來說難道不是一件很容易的一件事嗎？難道他們不應該不斷學習新的東西，關注***的消息嗎？
可能這只是一種假象？也許我們早就滿足于我們以前學會的東西，并不想轉變？也許真相是，我們已經喪失了進取心，不想發展了？也有可能是我們沒有時間學習新的東西？
一段時間后，我要求對方完成的任務做好了。他們做到了，他們交付了。最初的猶豫最終被克服了。又掌握了一些新的東西。那么，一開始缺乏動力的原因是什么呢？
我認為這是因為害怕，害怕陌生的東西，害怕失敗。做自己已經會的東西，總讓人感覺得心應手，這是因為我們知道它，我們認為這是我們擅長的。但問題是，我們也可以擅長別的東西，只要我們需要它，肯去了解它，用之前相同的完成方式去學去做。
問題2：“一開始就想太多”
這是我在啟動新項目時看到的最常見的問題之一。開發人員之所以覺得加入已工作的應用程序會更舒心，是因為需要做的決策會少很多。而開始一個新項目則不同。我們需要作出決定，并優先考慮需求是什么以及***能夠具備的特點。
***的失敗是在實現中，例如，在一開始的身份驗證時。這是不是應用程序最重要的特點？要不要關注安全？No，大錯特錯。
我們應該盡可能地縮小范圍。我們應該提供MVP來展示概念驗證。我們應該提供基本的商業規則，應用程序的核心功能，而非著眼在性能、分頁、超安全認證和極度可擴展性上面。要簡單化，至少在一開始的時候。
如何做到這一點？我覺得與客戶的談話是至關重要的。這是他們投資的錢，我們需要拿他們的薪水。我們不希望浪費自己的資金，客戶也是。我們應該一起討 論什么重要，什么應該提交給他們的潛在客戶或投資者。我們不需要關注那些不能讓別人將我們的應用程序區分出來的事情，如登錄/注冊功能，更改電子郵件或刪 除帳戶。
問題3：“沒有選擇一個合適的工具”
我和不同的公司談過很多次關于他們的開發堆棧。有時，他們會使用Ruby做一些非常花里胡哨的，并行的和分布式的事情。當我問他們為什么為這個要求 苛刻的進程選擇這么個相對低效的語言時，他們的答案是——所有的開發人員都知道Ruby是***的。理所當然這是最快，也顯然是最廉價的方法。事實上他們并 沒有關于可維護性的長遠目標。他們專注于價格和便利。這導致他們背負了巨大的技術債務，并且可能會成為很多黑客行為實現的既定目標。
還有一件事是，我多次看到開發人員在他們熟悉商業規則之前就選好了技術堆棧。我看到很多動力十足的開發人員也一般無二。他們是如此熱衷于立馬啟動開發和利用所有***的框架。他們認為無論要做什么系統，要解決什么問題，都可以用他們已經選好的數據庫和語言。
在這樣的情況下該怎么辦呢？我的高招是去招聘懂得不同技術的開發人員。在熟悉了這個問題并使用案例后，我們可以討論我們知道或不知道的工具的利弊。 洞察現在市場上正在發生什么，什么框架和語言受歡迎，這些框架和語言能解決什么問題，是一件好事。堅持一個每個人都知道的工具，而不是為每個用例制定解決 方案，可能會成為開發過程中的痛腳。
問題4：“重新發明輪子”
這個問題涉及到有的開發人員不夠熟悉他加入的項目。這在我審查別人的代碼時時有發生。我經常問：“你看到那個類/模塊/功能了嗎？它跟你的實現完全一樣”。這常見于那些沒有好好瀏覽代碼的開發人員。他們沒有看到，有些功能不拘在哪里提取，都是可重用的。
特別是當我們遵循一些共同的模式、準則或架構時，尤其如此。極有可能其他的開發人員已經在別的地方解決了這個問題，或者已經提取和抽象好了我們現在需要的某個功能。
為了避免這類問題，我們應該用一種明智的方式實現更多的代碼審查。我們不應該檢查是否對齊括號，或添上缺少的逗號，而是應該通過一些智能自動化的工 具進行檢查。我們應重新審視業務邏輯和行為。一段時間后，我們會想：“哦，Kamil已經實現過了，我用一下他的模塊就可以了。”
問題5：“學習語法不是編程”
我見過兩個組的開發人員。
***組是優秀的程序員。他們知道他們所使用的編程語言的各個方面知識，他們知道整個標準庫，和很多很多第三方工具。他們知道如何用8種方法寫循環， 如何使用模式匹配和他們可以使用的所有語法。問題是，他們不知道架構和范例。他們的代碼是命令式的，他們不會提取小功能，也不會處理封裝和單獨的不同層或 模塊。他們只會寫代碼。
第二組是非常棒的工匠。他們是真正的建筑師，他們會模型化應用，各自負責提取組件，遵循格式和設計有效流。他們只是不會寫代碼。有時他們將太多的時 間花在了設計上，他們使用的是低效率的算法，廢棄的功能，過時的庫等等。也許架構是可靠的，工作流程是強大的，但是代碼本身卻既丑陋又難以閱讀。
問題出在哪里？***種情況可能是因為開發人員只讀他們使用的語言的相關編程書籍。這就像只學習語法而不學其他。我們以為我們知道了語法之后就可以編 程。其實我們只會寫代碼。第二種情況則是因為開發人員沒有去看維護者或創造者發布的工具和語言的新版本。這一組的程序員不閱讀更改日志，也不看新聞和簡 訊。
如何解決？項目中這兩種類型的人都要有。相互學習，這樣才能既讓大家滿意，又獲利***。
問題6：“無視模式”
當你進入一個已經擁有堅實基礎的項目中，那么很可能它遵循某些規則和指引。因為通常情況下，開發人員要保證每個應用程序有一個約定，以使其易于閱讀和理解。
不幸的是，很多人在剛開始編碼時，往往看不到持續開發中內置的現有算法。他們會使用不同又沒有必要的方法來兼容現有的方法。
我們總是興致勃勃地提供新的功能，我們不想在觀察目前的趨勢和模式上面浪費我們的時間。于是我們無視了既定的規則，引進我們自己的習慣，從而打破一致性。
這是不好的嗎？不總是。有時，特別是當更多有經驗的開發人員加入團隊時，這么做反而會化腐朽為神奇。他們會教其他人如何構建應用程序，并分享他們的 知識。有時，它可以為現有的架構帶來新的視圖，并改善很多已有的概念。但是事實上，上面這些情況很少發生。大多數的時候，新的開發人員往往會給大項目引進 麻煩。
那么解決方案是什么？引進是必要的。但是我們不應該要求盡快提供新的功能，而應該先讓人好好研究既定的規則。我們應該任命一名主管，讓他在開始的時候指導，讓他掌握所有的概念。
總結
在編程世界中存在著許多問題。我們每個人都有著不同的技能，不同的能力和動力來源。我們應該互相溝通，共同解決問題，權衡利弊。
學習是關鍵。自我發展應該永不止步。如果我們不這樣做，就會歸為壞程序員。我們的工作要求我們不斷地學習和了解新的東西。
可以讀書，可以結對編程，可以訂閱時事通訊，也可以寫博客。
方法很多很多，我們只需要選擇最適合我們的。
