尋夢新聞LINE@每日推播熱門推薦文章，趣聞不漏接❤️
簡單的事情——只要google一下
私信小編007即可獲取數十套PDF哦！
我記不了很多東西。像標準庫中的函數和方法、參數位置、軟件包名稱，樣板代碼等等，都在我腦容量之外。
所以，我必須使用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，磁盤，網路和記憶體配置顯示器的地方。你甚至可以在用戶實際破壞你的服務之前發現需要增加的時間
簡而言之，我們需要監控生產中的應用。我們有時使用所有這些工具，有時只使用最需要的部分。
學無止境
需要學習的東西是無窮的。如果我們想編寫出好的軟件，那麼我們需要不斷地學習怎麼做。沒有捷徑也沒有魔法。每天進步一點點，就會越來越好。
總之，我們需要理解兩件基本的事情：
每個人都會遇到問題。關鍵是我們得對這些問題做好準備；
我們可以將問題的源頭控制到一些可接受的水平。
這些與你的心智能力或心態無關。
