【譯】我是一個平庸的程序員

原文連接：https://dev.to/sobolevn/i-am-a-mediocre-developer--30hn
複製代碼

我我的認爲有一些程序員就是天才，他們能夠垂手可得地創造一些了不得的軟件產品。由於這羣天才的存在，咱們對這個行業充滿了期待。可是有一個悲傷的事實是：不是每個人都是大師級的程序員。

實際上這就是我，一個平庸的程序員。這篇文章將指導你，做爲一個非天才程序員，如何在這個行業中生存。

我一直用google搜索最簡單的技術

我記不住不少東西。好比，標準庫裏的函數和方法，參數的位置，依賴的包名，樣板代碼等等。

因此，我須要用google搜索，天天如此。我也從舊的項目裏複用代碼，有時也從StackOverflow或者GitHub上覆制別人的代碼。是的，我是一個面向StackOverflow編程的程序員。

但我不是一我的在戰鬥，不少不少程序員都像我同樣。Ruby on Rails的做者曾經發過一個很火的twitter。

這樣子寫代碼有什麼很差呢？有以下幾點壞處：

• 你可能從別人那拷貝的，是糟糕的設計或者很爛的代碼。
• 容易造成一個壞的心態：若是不能從網上搜索到你想到的，那麼就是「休斯頓，咱們遇到麻煩了」。
• 若是沒有網了，那麼你就沒法工做了。

可是，我並不認爲這是一個大問題。它甚至能夠做爲你的祕密武器。我有幾點建議減輕這些負面影響。

生存法則1

• 使用IDE的代碼自動補全和提示，你就不用去搜索語言的基礎用法了。
• 記住你在什麼地方或使用什麼方法解決了這個問題。下一次遇到一樣的問題，找出來看一下就能夠了。
• 你提交到項目中的全部代碼，都應該在以後進行分析、重構和評審。這樣作，就不會用糟糕的代碼下降項目的質量，而是幫助它得到快速的解決方案。

保存事情的簡單性

咱們說什麼，機器作什麼。有時候，機器作了錯誤的事情，僅僅是由於咱們下了錯誤的指令。所以軟件開發中的主要問題，不是機器，而是開發人員的思惟能力。這種能力是有限的。因此，咱們做爲一個平庸的程序員，不要浪費腦子去建立複雜的抽象設計、編寫晦澀的算法或不可讀的長代碼塊。保持簡單性。

然而，咱們怎麼區分這段代碼是簡單的仍是複雜的？咱們須要使用WTFs/分鐘的方法去衡量代碼質量。（譯者注：WTF = What the Fu**）

這條規則很是簡單易懂。你發現代碼中有一些你看不懂的東西，那它就是複雜的。你應該怎麼作？

• 重寫代碼，讓人看起來清晰
• 提供文檔
• 在最難懂的地方添加註釋。可是記住，過多的註釋自己，就是代碼的壞味道。（譯者注：參見22種代碼味道）

生存法則2

• 使用正確的變量名、函數名和類名
• 確保你代碼每一部分只作一件事件
• 優先使用純函數，而不是常規函數
• 優先使用常規函數，而不是類
• 只在很是必要的狀況下，才使用回調

我不相信我本身

一些開發者已經證實他們能提交高質量的代碼。像下面這位女神：Margaret Hamilton，阿波羅計劃的首席軟件工程師。這張圖裏，她旁邊的等身高的紙，就是爲登月任務編寫的代碼。

不過，但於我而言，不管我編寫任何代碼，我不相信我本身。即便是作項目裏最簡單的部分，我也能把事件搞得很是糟糕，可能包括：

• 語言錯誤
• 邏輯錯誤
• 設計錯誤
• 演示錯誤
• 安全性錯誤
• WTF錯誤（我最喜歡的）

世界上並無一本關於「如何編寫無bug代碼」的魔法師，因此這些錯誤都是正常的。全部的軟件都有bug，處理掉它就是了。

實際上，任何人都不容許編寫帶有明顯錯誤的代碼。因此至少咱們應該嘗試作到這一點。我應該怎樣保護我本身的項目呢？下面有幾條建議。

生存法則3

• 編寫測試用例，編寫大量的測試用例。大到集成測試，小到單元測試。在每次拉取請求前執行CI持續集成，這將減小你的一些邏輯錯誤。
• 使用靜態數據類型或者可選靜態類型。例如，咱們在python中使用mypy，在javascript中使用flow（譯者注：如今應該使用Typescript）。這樣作的好處是：清晰的設計和編譯時類型檢查。
• 使用自動樣式檢測工具。每種語言都有大量的樣式檢查工具。
• 使用質量檢測工具。有些工具在你的代碼庫上運行一些複雜的啓發式算法來檢測不一樣的問題，好比這行內部邏輯太多，不須要這個類，這個函數太複雜。
• 檢閱你的代碼。在合併到主分支以前代碼，有時候在合併以後也須要review。
• 花錢讓別人審覈你的代碼。這樣作有至關大的好處，由於當別的程序員第一次看你的代碼時，很容易看出不一致的地方和糟糕的代碼設計。

不該該只在個人電腦上有效

差很少十年前，當個人團隊開發完第一個大型軟件項目時，咱們將其做爲java源文件發佈。在咱們呈現給客戶前的幾個小時，它在目標服務器上編譯失敗了。這算是個大事故。雖然最終咱們修復好了並運行起來，但這是個終身難忘的經歷。

這是由於在構建管道里，有着大量的配置和大量的複雜性。咱們沒有能力去正確管理該系統的複雜性。從那天開始，爲了減小這一步的複雜性，我嘗試將程序打包在獨立的環境中，並在實際部署以前在此環境中進行測試。

這幾年，隨着docker（以及通常的容器）的興起，這件事情開始變得簡單起來。docker容許你在徹底相同的獨立環境下進行開發、測試和生產上線。採用這種方式，你不會遺留任何重要的事情。

很差嗎？說說我本身，在搭建服務、初始化配置或者連接一些東西的時候，我總會遺漏掉一部分。由於有許多東西須要記住。幸運的是，咱們仍然能夠實現自動化。有許多很棒的工具能夠進行自動化部署。如：terraform, ansible, and packer。查看他們的文檔，找到適合你的工具。

我也嘗試設置CI/CD進行持續集成和持續部署。當在測試和部署的自動化構建失敗時，我會收到報告通知。

生存法則4

1. 一切使用自動化部署
2. 使用docker做爲開發、測試和生產環境
3. 使用部署工具

在部署應用後，我仍然不相信我本身

最後，個人應用已經在生產環境上線了，它已經在運行了。我能夠打個小盹兒了，什麼事兒都不會發生。等一下，不，一切都將崩潰。是的，一切。

實際上，有一些工具能夠很容易的發現和修復如今問題。

1. Sentry. 任何一個你的用戶產生異常時，你都會收到通知。Sentry已經支持幾乎全部的開發語言。
2. 各式各樣的服務和工具，能夠將多個程序的日誌收集到一個地方。
3. 服務監控.你能夠對CPU、硬盤、網絡和存儲器配置監控。你甚至能夠在用戶實際壓垮你的服務以前，肯定須要進行服務擴容的時間。

簡單來講，咱們須要在生產環境上進行監控。有的時候你須要上述全部工具，有的時候你只須要一部分。要根據本身的狀況進行判斷。

持續學習

哇，有好多須要學的東西。但這就是個人生存方式。若是咱們想寫好代碼，咱們就須要持續學習。成功路上沒有捷徑，你須要作的就是學習如何一天比一天好。

總結來講，咱們須要理解兩個基本原則：

1. 每一個人都會遇到問題。最關鍵的是，咱們對這些問題，準備好了嗎，準備到什麼程度。
2. 咱們能夠把問題的根源下降到可接受的程度。

這與你的思惟能力或心態無關。