![](https://img.laitimes.com/img/_0nNw4CM6IyYiwiM6ICdiwiI0gTMx81dsQWZ4lmZf1GLlpXazVmcvwFciV2dsQXYtJ3bm9CX9s2RkBnVHFmb1clWvB3MaVnRtp1XlBXe0xCMy81dvRWYoNHLwEzX5xCMx8FesU2cfdGLwMzX0xiRGZkRGZ0Xy9GbvNGLpZTY1EmMZVDUSFTU4VFRR9Fd4VGdsYTMfVmepNHLrJXYtJXZ0F2dvwVZnFWbp1zczV2YvJHctM3cv1Ce-cGcq5CMyYDN2cTO5AzY4QWOhNzMzYzXwQjN1kDM4IzLclDMyIDMy8CXn9Gbi9CXzV2Zh1WavwVbvNmLvR3YxUjLyM3Lc9CX6MHc0RHaiojIsJye.jpg)
英文 | https://javascript.plainenglish.io/signs-that-you-are-a-bad-programmer-dc1c647827d6
不要誤會我的意思,我不想讓你感覺不好。我也有這些迹象,但我努力提升自己。如果你不知道自己的缺點,你怎麼去改正它們呢?我們需要有人告訴我們這些事情,但我們大多數程式員周圍是沒有這樣的一個人。
大多數時候,我們知道我們應該做什麼,但我們不去做。我們總想着可以以後再做改正。但“以後”永遠不會到來,這是一個懶惰的程式員的常見标志,也是成為一個糟糕的程式員的第一步。
昨天,我從 GitHub 閱讀了 Daryll Santos 的一篇精彩的長文。我總結并挑選了一些與我相關的迹象,是以讓我們進入事實。
不明白代碼的目标
在編寫代碼之前,你必須了解代碼的用途,你的代碼将做什麼。這就像在你的腦海中運作代碼一樣。
症狀
- 保留從未使用過的變量。
- 産生不相關的輸出。
- 調用與目标無關的函數。
- 為了确定,多次執行幂等函數,如 save()。
- 通過編寫一些覆寫錯誤代碼的代碼來修複錯誤。
- 不必要的價值轉換,就像首先将十進制轉換為字元串,然後再将字元串轉換為十進制一樣。
補救措施
- 使用 IDE 自己的調試器作為助手。
- 檢查變量更改前後的值。
對語言架構的了解不足
面向對象程式設計是一種程式設計模型,函數式或聲明式程式設計也是如此。它們不同于過程式或聲明式程式設計。當程式員從一種架構遷移到另一種架構時,他們會感到困惑,這很正常。但随着時間的推移,你必須對那個架構有更好的了解。
症狀
- 不遵循 OOP 标準。
- (OOP) 在未執行個體化的類中調用非靜态函數/變量。
- (OOP) 編寫了許多這樣的“XXXXManager”類,其中包含用于操作對象字段的所有方法,隻有很少的方法或沒有自己的方法。
- 将關系資料庫視為對象存儲。
- 在用戶端代碼中執行所有連接配接和關系強制。
- 建立同一算法的多個版本來處理不同的類型。
- 設定單個值(在指令式代碼中)而不是使用資料綁定。
補救措施
- 這不是一天就能克服的,你需要練習,練習,更多的練習。
- 文檔閱讀,如果你不了解該語言的架構或 OOP 基礎知識,請花時間更好地了解。
- 遵循進階程式員的代碼。
不信任自己的代碼
當你的邏輯很差時,你會感到困惑,并且會不信任自己的代碼。
症狀
- 寫不必要的 IsNull() 或 IsNotNull() 或 IsTrue(bool) 或 IsFalse(bool) 函數。
- 檢查布爾類型變量是否不是真或假。
- 多次調用相同的函數以确認它執行。
補救措施
- 不要從具有弱類型系統的語言中繼承不必要的舊習慣。
- 對你的邏輯充滿信心,如果邏輯有問題,請嘗試新的邏輯。
陷入遞歸陷阱
遞歸的想法很棘手,但并不難。但是許多程式員害怕遞歸,就像幽靈一樣。遞歸将使代碼更簡潔高效,遞歸就像梯子,你隻需要想象“你在哪裡”和“基地在哪裡”,以及你将如何上台或下台。
症狀
- 可以遞歸解決的問題的複雜疊代算法,就像周遊檔案系統樹一樣。
- 在遞歸調用之前和之後檢查基本條件。
- 不測試基本條件的遞歸函數。
- 連接配接/求和到全局變量或攜帶輸出變量的遞歸子例程。
補救措施
- 分幾個步驟運作代碼以了解流程,它可能會發生一些堆棧溢出,但别擔心。
- 更改基本條件以檢視輸出。
- 你的目标是對你在哪裡以及你在做什麼有信心和完整的感覺。
研究能力不足
現代架構和語言具有令人驚歎的内置指令和功能的廣度和深度。知識如此之多,以至于一個好的程式員需要幾年以上的時間來消耗。但是一個好的程式員總是在開始滾動他們自己的函數之前搜尋一個内置函數。
症狀
- 在沒有内置于語言中的基本機制(例如事件和處理程式或正規表達式)的情況下進行重新發明。
- 重新發明架構中内置的類和函數。
- 而不是搜尋解決,或者通過論壇釋出消息以求幫助。
- 即使新技術在這些情況下更好,也要堅持使用老式技術。
- 與其尋找一個直接的解決方案,不如通過編寫“Roundabout 代碼”使其複雜化,以在許多步驟中完成可以用更少的代碼完成的事情。
補救措施
- 這項技能需要時間來建立,是以不要着急。
- 當你遇到問題時,不要去找程式員或直接複制粘貼代碼。慢慢來,閱讀文檔。
對指針了解不佳
如果你不了解指針的概念,那麼你将很難編寫複雜的資料結構和高效的 API,你将産生糟糕的資料結構設計和錯誤。
症狀
- 缺乏區分方法調用中按值傳遞和按引用傳遞的知識。
- 未能實作連結清單。
- 錯誤地對指針執行算術運算導緻無法找到或修複錯誤。
- 無法編寫在不丢失或删除資料的情況下從連結清單或樹中插入/删除節點的代碼。
- 制作指針的副本,通過副本更改取消引用的值,然後認為原始指針仍指向舊值。
補救措施
- 指針很容易了解,但由于缺乏實踐而經常被誤解。
總結
以上就是我與你分享的關于糟糕程式員的一些迹象與補救方案,如果你也有這些問題的話,請經快處理掉它們,最後,感謝你的閱讀。