163study

平庸開發者的生存指南

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

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

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

最簡單的事情——只要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,磁盤,網絡和內存配置顯示器的地方。你甚至可以在用戶實際破壞你的服務之前發現需要增加的時間

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

學無止境

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

總之,我們需要理解兩件基本的事情:

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

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

譯文鏈接:http://www.ztsusc.tw/article/i-am-mediocre-developer.html
英文原文:I am a mediocre developer
翻譯作者:碼農網 – 小峰
轉載必須在正文中標注并保留原文鏈接、譯文鏈接和譯者等信息。]

發表我的評論

取消評論
表情 插代碼

Hi,您需要填寫昵稱和郵箱!

  • 必填項
  • 必填項
22选5今晚开奖公告