程式設計師世界常見的6個問題

本文由碼農網 – 小峰原創翻譯，轉載請看清文末的轉載要求，歡迎參與我們的付費投稿計劃！

我作為CTO已經有一段時間了。在這個工作崗位上，我不但制定準則，還帶領團隊、管理專案、設計架構、組織工作、制定程式碼審查、調查不同的問題、研究各種解決方案、結識許多技術人員和聯絡客戶等等等等，做了很多事。

在完成這些任務的過程中，我不但學到了很多不同的技能，並得出了很多觀察結果，想與大家分享。

本文針對的是技術長和開發人員，因為可能並不是每一個人都碰到過我下面發現、學習並得到解決的問題。

問題1：“我不熟悉X技術/工具”

這是每次在我要介紹新技術和語言的時候，最常聽到一句話。也是在我要求某人用一種他們不認識的工具準備一個概念證明時，非常耳熟的一句話。

這讓我很驚訝，為什麼呢？因為我認為程式設計師都是高智商的！學習一些新的東西，新的理念、模式和架構對於他們來說難道不是一件很容易的一件事嗎？難道他們不應該不斷學習新的東西，關注最新的訊息嗎？

可能這只是一種假象？也許我們早就滿足於我們以前學會的東西，並不想轉變？也許真相是，我們已經喪失了進取心，不想發展了？也有可能是我們沒有時間學習新的東西？

一段時間後，我要求對方完成的任務做好了。他們做到了，他們交付了。最初的猶豫最終被克服了。又掌握了一些新的東西。那麼，一開始缺乏動力的原因是什麼呢？

我認為這是因為害怕，害怕陌生的東西，害怕失敗。做自己已經會的東西，總讓人感覺得心應手，這是因為我們知道它，我們認為這是我們擅長的。但問題是，我們也可以擅長別的東西，只要我們需要它，肯去了解它，用之前相同的完成方式去學去做。

問題2：“一開始就想太多”

這是我在啟動新專案時看到的最常見的問題之一。開發人員之所以覺得加入已工作的應用程式會更舒心，是因為需要做的決策會少很多。而開始一個新專案則不同。我們需要作出決定，並優先考慮需求是什麼以及最好能夠具備的特點。

最大的失敗是在實現中，例如，在一開始的身份驗證時。這是不是應用程式最重要的特點？要不要關注安全？No，大錯特錯。

我們應該儘可能地縮小範圍。我們應該提供MVP來展示概念驗證。我們應該提供基本的商業規則，應用程式的核心功能，而非著眼在效能、分頁、超安全認證和極度可擴充套件性上面。要簡單化，至少在一開始的時候。

如何做到這一點？我覺得與客戶的談話是至關重要的。這是他們投資的錢，我們需要拿他們的薪水。我們不希望浪費自己的資金，客戶也是。我們應該一起討論什麼重要，什麼應該提交給他們的潛在客戶或投資者。我們不需要關注那些不能讓別人將我們的應用程式區分出來的事情，如登入/註冊功能，更改電子郵件或刪除帳戶。

問題3：“沒有選擇一個合適的工具”

我和不同的公司談過很多次關於他們的開發堆疊。有時，他們會使用Ruby做一些非常花裡胡哨的，並行的和分散式的事情。當我問他們為什麼為這個要求苛刻的程式選擇這麼個相對低效的語言時，他們的答案是——所有的開發人員都知道Ruby是最好的。理所當然這是最快，也顯然是最廉價的方法。事實上他們並沒有關於可維護性的長遠目標。他們專注於價格和便利。這導致他們揹負了巨大的技術債務，並且可能會成為很多黑客行為實現的既定目標。

還有一件事是，我多次看到開發人員在他們熟悉商業規則之前就選好了技術堆疊。我看到很多動力十足的開發人員也一般無二。他們是如此熱衷於立馬啟動開發和利用所有最新的框架。他們認為無論要做什麼系統，要解決什麼問題，都可以用他們已經選好的資料庫和語言。

在這樣的情況下該怎麼辦呢？我的高招是去招聘懂得不同技術的開發人員。在熟悉了這個問題並使用案例後，我們可以討論我們知道或不知道的工具的利弊。洞察現在市場上正在發生什麼，什麼框架和語言受歡迎，這些框架和語言能解決什麼問題，是一件好事。堅持一個每個人都知道的工具，而不是為每個用例制定解決方案，可能會成為開發過程中的痛腳。

問題4：“重新發明輪子”

這個問題涉及到有的開發人員不夠熟悉他加入的專案。這在我審查別人的程式碼時時有發生。我經常問：“你看到那個類/模組/功能了嗎？它跟你的實現完全一樣”。這常見於那些沒有好好瀏覽程式碼的開發人員。他們沒有看到，有些功能不拘在哪裡提取，都是可重用的。

特別是當我們遵循一些共同的模式、準則或架構時，尤其如此。極有可能其他的開發人員已經在別的地方解決了這個問題，或者已經提取和抽象好了我們現在需要的某個功能。

為了避免這類問題，我們應該用一種明智的方式實現更多的程式碼審查。我們不應該檢查是否對齊括號，或添上缺少的逗號，而是應該通過一些智慧自動化的工具進行檢查。我們應重新審視業務邏輯和行為。一段時間後，我們會想：“哦，Kamil已經實現過了，我用一下他的模組就可以了。”

問題5：“學習語法不是程式設計”

我見過兩個組的開發人員。

第一組是優秀的程式設計師。他們知道他們所使用的程式語言的各個方面知識，他們知道整個標準庫，和很多很多第三方工具。他們知道如何用8種方法寫迴圈，如何使用模式匹配和他們可以使用的所有語法。問題是，他們不知道架構和範例。他們的程式碼是命令式的，他們不會提取小功能，也不會處理封裝和單獨的不同層或模組。他們只會寫程式碼。

第二組是非常棒的工匠。他們是真正的建築師，他們會模型化應用，各自負責提取元件，遵循格式和設計有效流。他們只是不會寫程式碼。有時他們將太多的時間花在了設計上，他們使用的是低效率的演算法，廢棄的功能，過時的庫等等。也許架構是可靠的，工作流程是強大的，但是程式碼本身卻既醜陋又難以閱讀。

問題出在哪裡？第一種情況可能是因為開發人員只讀他們使用的語言的相關程式設計書籍。這就像只學習語法而不學其他。我們以為我們知道了語法之後就可以程式設計。其實我們只會寫程式碼。第二種情況則是因為開發人員沒有去看維護者或創造者釋出的工具和語言的新版本。這一組的程式設計師不閱讀更改日誌，也不看新聞和簡訊。

如何解決？專案中這兩種型別的人都要有。相互學習，這樣才能既讓大家滿意，又獲利最大。

問題6：“無視模式”

當你進入一個已經擁有堅實基礎的專案中，那麼很可能它遵循某些規則和指引。因為通常情況下，開發人員要保證每個應用程式有一個約定，以使其易於閱讀和理解。

不幸的是，很多人在剛開始編碼時，往往看不到持續開發中內建的現有演算法。他們會使用不同又沒有必要的方法來相容現有的方法。

我們總是興致勃勃地提供新的功能，我們不想在觀察目前的趨勢和模式上面浪費我們的時間。於是我們無視了既定的規則，引進我們自己的習慣，從而打破一致性。

這是不好的嗎？不總是。有時，特別是當更多有經驗的開發人員加入團隊時，這麼做反而會化腐朽為神奇。他們會教其他人如何構建應用程式，並分享他們的知識。有時，它可以為現有的架構帶來新的檢視，並改善很多已有的概念。但是事實上，上面這些情況很少發生。大多數的時候，新的開發人員往往會給大專案引進麻煩。

那麼解決方案是什麼？引進是必要的。但是我們不應該要求儘快提供新的功能，而應該先讓人好好研究既定的規則。我們應該任命一名主管，讓他在開始的時候指導，讓他掌握所有的概念。

總結

在程式設計世界中存在著許多問題。我們每個人都有著不同的技能，不同的能力和動力來源。我們應該互相溝通，共同解決問題，權衡利弊。

學習是關鍵。自我發展應該永不止步。如果我們不這樣做，就會歸為壞程式設計師。我們的工作要求我們不斷地學習和了解新的東西。
可以讀書，可以結對程式設計，可以訂閱時事通訊，也可以寫部落格。

方法很多很多，我們只需要選擇最適合我們的。