原文連結：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
- 一切使用自動化部署
- 使用docker作為開發、測試和生產環境
- 使用部署工具
在部署應用後，我仍然不相信我自己
最後，我的應用已經在生產環境上線了，它已經在執行了。我可以打個小盹兒了，什麼事兒都不會發生。等一下，不，一切都將崩潰。是的，一切。
實際上，有一些工具可以很容易的發現和修復現在問題。
- Sentry. 任何一個你的使用者產生異常時，你都會收到通知。Sentry已經支援幾乎所有的開發語言。
- 各式各樣的服務和工具，可以將多個程式的日誌收集到一個地方。
- 服務監控.你可以對CPU、硬碟、網路和儲存器配置監控。你甚至可以在使用者實際壓垮你的服務之前，確定需要進行服務擴容的時間。
簡單來說，我們需要在生產環境上進行監控。有的時候你需要上述所有工具，有的時候你只需要一部分。要根據自己的情況進行判斷。
持續學習
哇，有好多需要學的東西。但這就是我的生存方式。如果我們想寫好程式碼，我們就需要持續學習。成功路上沒有捷徑，你需要做的就是學習如何一天比一天好。
總結來說，我們需要理解兩個基本原則：
- 每個人都會遇到問題。最關鍵的是，我們對這些問題，準備好了嗎，準備到什麼程度。
- 我們可以把問題的根源降低到可接受的程度。
這與你的思維能力或心態無關。