在程序員圈子中，我只是一名平庸的開發者

有一天，我看到一句話，「我只是一個頗爲平庸無趣的普通人」。每一句話都須要放在必定的語境中理解。說話者也許輕鬆自在，用這句話來幽本身一默；也許他的生活平靜平凡，用這句話來自嘲；也許他自信心不足，那這句話就是情緒灰暗低落的表達。

撇開題目不談，我我的認識一些很是有才華的開發人員，他們能夠一路順風地建立極好的軟件。正是這些天賦人士，使得外行人對咱們這個行業充滿了很高的指望。但我要說的一個可悲的事實是：並不是每一個人都是忍者/大師/明星開發者。
我就不是這些閃耀的新星，我只是一名平庸的開發者。若是你也不是天才玩家，那麼本文將指導你如何在這個行業中生存下去。

最簡單的事情——只要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，磁盤，網絡和內存配置顯示器的地方。你甚至能夠在用戶實際破壞你的服務以前發現須要增長的時間
  簡而言之，咱們須要監控生產中的應用。咱們有時使用全部這些工具，有時只使用最須要的部分。

學無止境

須要學習的東西是無窮的。若是咱們想編寫出好的軟件，那麼咱們須要不斷地學習怎麼作。沒有捷徑也沒有魔法。天天進步一點點，就會愈來愈好。

總之，咱們須要理解兩件基本的事情：

每一個人都會遇到問題。關鍵是咱們得對這些問題作好準備；
咱們能夠將問題的源頭控制到一些可接受的水平。
這些與你的心智能力或心態無關。

「金三銀四」來臨，我這邊總結出了互聯網公司java程序員面試涉及到的絕大部分面試題及答案作成了文檔和架構視頻資料免費分享給你們（包括Dubbo、Redis、Netty、zookeeper、Spring cloud、分佈式、高併發等架構技術資料），但願能幫助到您面試前的複習且找到一個好的工做，也節省你們在網上搜索資料的時間來學習，也能夠點贊和關注一下之後會有更多幹貨分享。QQ羣號：603619042