平庸開發者的生存指南

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

撇開題目不談，我個人認識一些非常有才華的開發人員，他們可以一帆風順地建立極好的軟體。正是這些天賦人士，使得外行人對我們這個行業充滿了很高的期望。但我要說的一個可悲的事實是：並非每個人都是忍者/大師/明星開發者。

我就不是這些閃耀的新星，我只是一名平庸的開發者。如果你也不是天才玩家，那麼本文將指導你如何在這個行業中生存下去。

最簡單的事情——只要google一下

我記不了很多東西。像標準庫中的函式和方法、引數位置、軟體包名稱，樣板程式碼等等，都在我腦容量之外。

所以，我必須使用google搜尋。我每天都這樣做。我也一直在重複使用舊專案的程式碼。有時我甚至從StackOverflow或Github複製貼上答案。是的，我的開發其實可稱之為：StackOverflow驅動開發。

但我並不孤單。許多其他開發人員也這樣做。有一個受眾面很廣的twitter討論就是由Ruby on Rails的建立者所啟動的。

那麼，為什麼一開始會認為這種行徑是不好的呢？因為它有若干缺點：

• 會導致你複製到糟糕的設計決策或易受其他人攻擊的程式碼
• 會形成一種依賴心態：要是我們不能google到內容，那麼只能向人求助了
• 沒有網就不能工作

但是，我不認為這些是大問題。它甚至可以作為是你的祕密武器。我有一些建議可用於減少其負面影響。

生存指南：

• 使用IDE來獲得自動完成和建議，所以你不必google程式語言的基礎內容；
• 記住你曾解決過這個問題的地方（而不是如何解決的）。這樣你便可以隨時在那裡找到解決方案；
• 所有貼上到專案中的程式碼你稍後都應該進行分析、重構和審查。這樣我們在快速提供解決方案的同時也不會損壞專案。

一切保持簡單明瞭

我們說什麼，機器就做什麼。即便是錯的，它們也毫不遲疑。所以，軟體開發中的主要問題不是機器，在於開發人員的心智慧力。而這玩意提升的空間是非常有限的。所以，我們——作為平庸的開發人員——不能將有限的腦力浪費在建立複雜的抽象、模糊演算法或不可讀的長程式碼塊上。你需要保持一切簡單明瞭。

但是，我們怎麼判定程式碼是簡單還是複雜？我們使用WTFs / Minute方法來衡量程式碼質量。

這個原則很容易理解。每當你在程式碼中發現一些你不明白的東西時——哦，這太複雜了。怎麼做呢？

• 重寫，使設計更乾淨
• 提供文件
• 給最棘手的部分新增註釋。但請記住，註釋應該描述的是程式碼本身

如何從頭開始保持簡單明瞭：

• 對變數、函式和類使用正確的名稱
• 確保程式的每個部分只做一件事
• 純函式優於正則函式
• 正則函式優於類
• 僅在強烈需求的情況下使用類

不自信的我

一些開發人員會證明自己可以提供高質量的程式碼。請看圖中的這位女士：阿波羅登月計劃的首席軟體工程師Margaret Hamilton。那幾乎有她人那麼高的是什麼呢？好吧，那正是她為登月任務編寫的程式碼：

但是，每當我編寫任何程式碼時——我都不自信。即使是專案最簡單的部分，我也可以把事情搞得一塌糊塗。搞糟的原因包括：

• 語言錯誤
• 邏輯錯誤
• 設計錯誤
• 樣式錯誤
• 安全錯誤
• WTF錯誤（我向來最為喜歡的！）

關於“學習如何編寫沒有bug的程式碼”的魔法書是不存在的。因為所有軟體都有bug——除了這個框架之外。遇到bug我們就應該處理掉。

關鍵要點是：每個人編寫的程式碼都不應該帶有明顯的錯誤。對的，至少，我們應該朝著這個目標去做。但是我是如何保護我的專案免受我的摧殘呢？方法很多。

生存指南：

• 編寫測試。編寫很多測試。從整合測試到單元測試。在每次pull請求前在CI中執行測試。這可以避免一些邏輯錯誤；
• 使用靜態型別或可選的靜態型別。例如，我們在python中使用mypy，在javascript中使用flow。積極作用：更清潔的設計和“編譯時”檢查；
• 使用自動樣式檢查。每種語言都有很多樣式檢查器；
• 使用質量檢查。有些工具在你的程式碼庫上執行一些複雜的啟發式演算法來檢測不同的問題，比如這個程式碼行內有太多的邏輯，這個類是不需要的，這個函式太複雜了；
• 審查你的程式碼。在合併為master之前對其進行審查。以及合併後的某個時間也是如此；
• 付錢讓其他人來稽核你的程式碼。此手段可以產生巨大的積極影響！因為如果是陌生的開發人員來檢視你的程式碼，他們更容易發現不一致和糟糕的設計決策。

不僅適用於我

大約十年前，在我的團隊開發出我們的第一個大型軟體專案時，我們將其作為java原始檔釋出。然而，它無法在目標伺服器上編譯。這距離需要提交給客戶只有若干小時了。這是一個巨大的失敗！最後我們用盡辦法終於能夠啟動並執行了，但不可否認這真的是一次刻骨銘心的體驗。

發生這種情況是因為構建管道中存在眾多配置和複雜性。而我們無法妥善管理這個系統的複雜性。所以，從那一天起，為了減少這種複雜性，我嘗試在隔離的環境中打包我的程式。並且在實際部署發生之前在這個環境中測試它們。

在docker（通常還有容器）崛起的近幾年，事情變得簡單起來。docker允許你在相同的隔離環境中執行開發、測試和生產。所以，你永遠不會錯過任何重要的事情。

那麼你會怎麼做？說說我自己，我在建立伺服器、初始配置或連線的時候總是會忘記一些事情。因為有這麼多需要記住的事情！幸運的是，這些我們都可以自動化。有很多不同的工具可以自動化部署過程，這些工具厲害極了，如：terraform，ansible和packer。閱讀工具資訊，找出實際需要哪一個用於任務。

我也嘗試儘快建立CI / CD。這樣，如果我的構建在測試或部署中失敗，那麼就會有報告發我。

生存指南：

• 自動化用於部署的任何內容；
• 使用docker進行應用程式開發、測試和部署；
• 使用部署工具。

應用程式部署後，我仍然不自信

終於，我的應用程式已經進入了產品階段。它可以工作了。我可以休息休息，應該不會出什麼問題了。等等，不！一切都崩潰了。是的，我沒有說錯：一切。

實際上，有一些工具可以使得查詢和解決現有問題更加容易。

• Sentry。當你的任何使用者發生錯誤時——你將收到通知。幾乎繫結了所有程式語言；
• 使用不同的服務和工具將多個程式和伺服器的日誌收集到一個地方；
• 伺服器監控。這是你可以為CPU，磁碟，網路和記憶體配置顯示器的地方。你甚至可以在使用者實際破壞你的服務之前發現需要增加的時間

簡而言之，我們需要監控生產中的應用。我們有時使用所有這些工具，有時只使用最需要的部分。

學無止境

需要學習的東西是無窮的。如果我們想編寫出好的軟體，那麼我們需要不斷地學習怎麼做。沒有捷徑也沒有魔法。每天進步一點點，就會越來越好。

總之，我們需要理解兩件基本的事情：

• 每個人都會遇到問題。關鍵是我們得對這些問題做好準備；
• 我們可以將問題的源頭控制到一些可接受的水平。

這些與你的心智慧力或心態無關。