程序員安身立命的138條忠告

程序員安身立命的138條忠告

讓我們面對現實,每個開發人員都希望個人的技術能力以及團隊協同能力可以隨著時間的推移不斷得到提高。但大多數開發者都會提出的一個重要且關鍵性的問題:如何才能做到這一點呢?接下來,本文作者以自身的開發經驗分享在編程時作為開發者應該牢記的 139 條忠告,以成為更好的程序員。

代碼外觀

關於代碼佈局的討論越多,越有可能陷入沒有結果的爭辯中。眾所周知的爭論有 TAB 鍵與空格縮進的爭論,以及大括號要不要另起一行的爭論等。

良好的代碼格式不一定是你覺得最漂亮的那個。良好的格式是更易於瀏覽和閱讀的代碼格式。

良好的代碼外觀揭示了代碼的意圖。這不是一項藝術工作。

我們需要通過良好的外觀避免出現代碼錯誤。不是為了表現我們可以創造漂亮的 ASCII 藝術。

雖然我們寫的代碼是通過計算機執行的,但卻要給人類閱讀。

如果有人想寫清晰的風格,那麼首先讓他弄清楚自己的想法。

選擇一種佈局樣式,然後堅持使用這種樣式,或採用編碼標準或樣式指南。

如果你正在處理的文件不符合項目其餘部分的佈局約定,那麼請遵循該文件中的佈局約定。

命名

良好的命名具有描述性、正確性和慣用性。

如果你非常瞭解命名對象,那麼你可以為它起一個好名字。在為變量提供神秘的名稱之前,請確保你明白它是什麼。

避免冗餘。冗餘表明你沒有充分考慮正在創建的東西的名字。無論是類,函數還是變量。

採用你使用的語言中最常用的大寫慣例。比如在C#方法中,大寫的Console.WriteLine(“Hello World”)

確保明明準確無拼寫錯誤。

切勿同時修改外觀和行為。用不同的版本管理它們的更改。

隨著獲得的經驗調整代碼外觀風格。新手並不能總是保持良好的代碼外觀,你更應該關注程序的功能。

減少代碼量

寫的代碼多不一定意味著你寫了很多軟件。這可能只是意味著你寫了很多 Bug。

代碼越多,意味著需要閱讀和理解的越多,這會讓程序更加難以理解。

代碼量越大,隱藏 Bug 的地方就越多,追蹤 Bug 就會越難。

避免非必要的代碼

常見的沒有意義的代碼包括使用非必要性的條件語句和重複的邏輯構造。混亂的邏輯代表著混亂的思路。

代碼保持明確簡潔。避免不必要的冗長語句。它們不會為代碼帶來任何價值。

複製

不要複製代碼段。將它們重構成通用的函數。通過參數表示差異性。

如果發現重複代碼,請將其刪除。

無效代碼

無效代碼是指永遠不會運行,或永遠無法訪問的代碼。

要麼給代碼運行的機會,要麼乾脆刪掉。

無效代碼的其他表現形式包括:

永遠不會給調用的函數;

定義的變量永遠沒有不會被使用;

傳遞給內部方法的參數永遠不會被使用;

從未使用過的枚舉、結構、類或接口。

註釋

良好的代碼不需要大量註釋的支持,也不需要解釋它的工作原理。

確保每個註釋都有添加的價值。代碼本身就是工作原理以及方法的最好的說明。註釋應該解釋為什麼——只有代碼本身不夠清楚的時候。

刪除代碼時不要將其註釋掉。這會讓讀者感到困惑,而且很礙事。

每天都讓你的代碼變得更好。如果找到冗餘和重複時,請將它們刪除。

通過刪除代碼來改進系統

添加新代碼可以改進系統。你也可以通過刪除代碼來改進系統。

無效代碼會在開發過程中積累

應用程序的用戶界面的功能已被刪除,但是後臺的支持代碼依然保留了下來。

通過嚮導生成的用戶界面代碼經常會插入一些永遠不會被使用的邏輯。

隨時隨地刪除無效代碼。這些代碼很礙事,會影響你的工作速度。

刪掉將來可能需要的代碼也是安全的。屆時你可以從版本控制中恢復。

清理代碼始終應該和功能改變分開提交。

即使最好的代碼庫也有無效代碼 。

警惕過去

在寫代碼的時候,你覺得它是完美的,但是通過認真審視舊代碼,你可以發現所有代碼中的陷阱。

回顧舊代碼可以幫助你提高編程技術。

如何處置現有的代碼庫

接管現有的大型代碼庫是一件很困難的事。你必須迅速開始:

瞭解從哪裡開始查看代碼

弄清楚代碼每個部分的作用以及實現方法

衡量代碼的質量

瞭解如何操控系統

瞭解代碼的慣用語,這樣你的修改就可以完全融入

找到所有功能的可能位置(以及由此引起的後續bug)

瞭解代碼的最佳方式是由知情人士為你講解。大膽地尋求幫助!

學習代碼的最佳方法是修改代碼。然後從你的錯誤中吸取教訓。

許多程序員不是努力閱讀和理解現有代碼,而是更喜歡說“代碼很糟糕”並重寫。

準備好遭遇很差的代碼。準備好得力的工具來處理這些代碼。

一些慘不忍睹的代碼可能只是一個能力較弱的程序員編寫的。或者是一個有能力的程序員在心情糟糕的時候寫的。

遇到很糟糕的代碼時,控制好自己的厭惡情緒。你需要尋找實際的方法改進這些代碼。

不要指望任何代碼(甚至是你自己的代碼)完美。

遵循童子軍規則。無論何時遇到代碼,確保你離開時的代碼更好。

緩慢而謹慎地修改代碼。一次只改動一個地方。

錯誤處理

不要忽視代碼中可能出現的錯誤。不要一再推脫錯誤處理(逃避不是辦法)。

規規矩矩使用異常。瞭解語言的慣例和需求,有效地使用異常。

程序員必須瞭解程序錯誤。用戶必須瞭解使用錯誤。

記錄錯誤還不夠好,必須要讓勤奮的操作員每天注意到錯誤並處理好錯誤。

做好異常準備

每一步都要考慮所有可能發生的不尋常,無論你認為它們出現的幾率有多低。

時時刻刻都要考慮從錯誤中恢復,並編寫合適的恢復代碼。

確保你的錯誤處理是慣用手法,並使用適當的語言機制。

在寫代碼的時候,嚴密考慮代碼的運行分支。不要推遲處理“不尋常”的情況:轉頭你就忘了,導致代碼到處是 Bug。

追蹤 Bug

程序員寫代碼。但程序員不是完美的,所以程序員的代碼也不是完美的。因此代碼第一次不能正常工作也很正常。所以我們有 Bug。

我們應該採用合理的工程技術,量減少令人不快的意外事故。

首先調試的難度是寫代碼的兩倍。因此,如果你儘可能巧妙地編寫代碼,那麼顯然這對於調試是不明智的。

將重現 Bug 的步驟降到最少。

確保你只專注於一個問題。

斷言和日誌(即便是簡陋的 console.log 和 nodejs 斷言)是有效的調試工具。可以經常利用。

二進制刪除空格的問題可以更快地獲得結果。

在開發軟件時,花點時間寫一套單元測試。

未經測試的代碼是 Bug 的溫床。而測試是殺蟲劑。

瞭解如何使用調試器。然後在正確的時間內使用。

儘快修復 Bug。不要讓它們累積成災。

調試並不容易。這是我們的錯。我們寫了 Bug。

別忘了測試代碼

單元測試是專門針對最小“單元”的功能展開的測試,以確保它們可以獨立正常運行。這裡的獨立意味著單元測試不涉及任何外部訪問:不運行任何數據庫、網絡或文件系統操作。

質量是免費的,但只有那些願意為此付出高昂代價的人才能享有。

為了改進軟件開發,我們需要快速反饋,以便在出現問題時立即掌握問題。良好的測試策略可以提供快速的反饋迴路。

在編寫代碼時編寫測試。不要推遲測試,否則測試就不會那麼有效了。

所有測試都應作為持續集成工具鏈的一部分在構建服務器上運行。

測試應用程序中的重要內容。

全局變量和單例對象是可靠測試的噩夢。你無法輕易測試擁有隱藏依賴項的單元。

重構代碼,提高可測試性,以便獲得更好的代碼設計。

程序測試可以展示 Bug 的存在,但永遠無法證明沒有 Bug。

如何處理複雜性

簡單性是偉大的品質,但需要付諸福利才能實現,人人都應該重視簡單性。但糟糕的是:大家更喜歡複雜性。

複雜性通常是偶然的,很少有人會故意添加。

推遲設計決策,直到你必須做決定的時候。在還不瞭解需求時,不要做出架構決策。不要猜。

完美的實踐

程序員需要良好的品味和美感才能編寫出色的代碼。

任何聰明的傻瓜都會讓代碼變得更大、更復雜和濫用。我們需要一點天才的力量以及很大的勇氣,才能朝著正確的方向前進。

良好的軟件開發不是牛仔式編程,扔掉第一個你能想到的代碼。這是一項需要深思熟慮和朝著正確方向努力的工作。

優秀的程序員在工作中很謙虛。他們敢於承認他們並不知道所有的一切。

良好的代碼和良好的程序員源於以正確的方式編寫正確的東西的願望。

團隊合作

程序員團隊有一套規則。這些規則定義了我們的工作以及我們的工作方式。同時也描述了編程文化。

不要依賴模糊的不成文的團隊“規則”。要明確隱含的規則,並控制你的編程文化。

要從根本原因上修復 Bug,而不是表面症狀出現的位置。堅持修復表面症狀不會簡化代碼。

避免在代碼中隱含假設。

只需編寫所需的代碼。任何額外的複雜性都將成為負擔。

停下來想一想。不要寫愚蠢的代碼。

承認你的錯誤和錯誤的編程決定。並從中吸取經驗教訓。

勇敢地使用你的大腦。你有權批評代碼並做出改進代碼的決定。

瞭解使軟件易於修改的原因,並努力建立具有這些屬性的軟件。

修改代碼需要的是勇氣和技巧。而不是魯莽。

通常最好進行一系列頻繁、少量、可驗證的改動,而不是一次大規模的代碼變動。

避免複製和粘貼編碼。重構邏輯建立共享函數和公共庫,避免重複代碼(和重複的 Bug)。

編寫小的模塊化代碼段。保持乾淨整潔。

代碼應該“共享”,因為它可以用於多個客戶端,而不是因為開發人員想要創建一個漂亮的共享庫。

不要拒絕別人的代碼。使用現有的庫可能更好,避免編寫自己的版本。

建立軟件版本需要規範和規劃。這不僅僅是在開發人員的 IDE 中點擊“構建”。

始終從頭開始構建新的軟件。切勿重複使用構建軟件的舊代碼。

簡化構建過程,只需一步即可自動完成流程的所有部分。使用腳本語言執行該操作。

在 CI 服務器上部署構建以確保其健康。從同一系統發佈正式版本。

不斷學習。積極學習新知識。

我們的學習往往過於狹隘。考慮更廣泛的參考範圍。從許多領域中汲取靈感。

學習時記筆記。即使過後你會扔掉它們。

如果不能用簡單的方式做出解釋,那麼意味著你理解的不夠透徹。

教別人學習一個主題,可以促進自己更好地學習該主題。

耳聽為虛,眼見為實。實踐出真知。

使用你剛學到的東西可以加強記憶。嘗試示例,回答問題,創建業餘項目。

警惕停滯不前。渴望成為更好的程序員,就必須掙脫最舒適的生活方式。

投入時間和精力來提高你的技術力。這項投資物有所值,你會收穫豐厚的回報。

不要試圖通過編寫不可讀或不必要的“聰明”代碼來證明自己“不可或缺”。

獲取軟件資格證是一種榮譽。

不要一葉障目。要準備好面對新挑戰,學習成長為更好的開發人員。

愛所有的編程語言。

學習遵循不同語言的慣例和範例。

考慮學習一些不再常用的語言,以瞭解編程歷史。

一個優秀的程序員知道多種語言和多種慣例,這可以拓寬他們的解決方案。改進他們編寫的代碼。

使用編程語言是你每天的例行工作。

要用語言編寫最好的代碼,你應該接受它的風格和慣例,而不是強迫你自己。

優秀的程序員是良好的溝通者。他們會聽說讀寫以及編程。

不要指望一夜之間成為語言大師,在工作中不要感到沮喪。

首先集中精力處理最重要的事情。什麼是最緊迫的,什麼會產生最大的價值?

讓計算機幫忙處理重複性的工作。使用腳本完成自動化。

將大型任務分解為一系列小任務,這樣易於理解的任務。並且可以使你更準確地判斷這些進展。

確認你定義的“已完成”是什麼。

如果你不知道什麼時候能夠完成,那請不要著急動手。

使用代碼中編寫的測試來定義代碼的完成和工作的時間。

不要做非必要的工作。只做必須完成的工作。然後住手。

遇到問題,在開始解決問題前,請確保你考慮過多種解決方案。

目標明確是優秀程序員的品質。

註釋並不一定能改善代碼。簡單明瞭的代碼不需要額外的註釋支持。

瞭解開發的方法、趨勢、宣言和流行。


分享到:


相關文章: