當前位置:
首頁 > 知識 > 我只是一名平庸的開發者

我只是一名平庸的開發者

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

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

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

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

學無止境

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

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

每個人都會遇到問題。關鍵是我們得對這些問題做好準備;

我們可以將問題的源頭控制到一些可接受的水平。

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

END

喜歡這篇文章嗎?立刻分享出去讓更多人知道吧!

本站內容充實豐富,博大精深,小編精選每日熱門資訊,隨時更新,點擊「搶先收到最新資訊」瀏覽吧!


請您繼續閱讀更多來自 JavaScript 的精彩文章:

關於 ECMAScript 2015的一些有用的提示和技巧
Node.js 專題系列

TAG:JavaScript |