希望您在第一份工作編寫代碼時都遇到困難
> Photo by Atul Choudhary from Pexels
您在軟件工程或數據科學領域的第一份工作可能會使人士氣低落。 特別是如果您沒有后臺編寫代碼。
我經常收到人們的信息，要求他們提出改進建議。 但是他們真正需要的是有人告訴他們-"您可以做到！"
以下是我在第一份軟件工程工作中親自犯的錯誤。 如果您遇到困難，這應該會讓您感覺更好。
1.編寫比可讀代碼更聰明的代碼
編寫好的代碼很難。 了解錯誤的代碼更加困難。 但這剛開始時并不直觀。
值得慶幸的是，我有一個高級開發人員，他不止一次地就以下幾點提出了建議。
· 同一行上有多個嵌套的if / else語句
· 過多使用鏈式方法
· 正則表達式從堆棧溢出復制/粘貼而沒有評論
· 過度抽象
將邏輯壓縮到盡可能小的空間，讓我感到很聰明。 但這也使我的代碼不可讀。 現在，我總是嘗試在可讀性方面犯錯誤。
調試的難度是一開始編寫代碼的兩倍。 因此，如果您盡可能聰明地編寫代碼，就定義而言，您就不夠聰明，無法對其進行調試。-克尼根定律
2.使用沒有上下文的變量名
想出好的變量名非常困難，我想盡快完成票證。
因此，我選擇突然出現的名字。
· 用戶的姓氏變為uln。
· 一系列電子郵件變成了陣列。
兩者都是不好的主意，這使任何人都很難理解我寫的內容（包括我自己）。
3.允許安全漏洞
在另一種情況下，我要感謝一位出色的高級開發人員，他將我的代碼免于遭到黑客攻擊。
我已完成以下所有操作：
· 允許SQL注入
· 允許通過URL跳轉訪問受限頁面
· 僅使用前端驗證
· 具有增量ID的命名空間URL
建立了一份關于最佳安全實踐的心理檢查清單花了很長時間，我現在在檢查其他開發人員的代碼時會使用該清單。
4.閱讀功能票后立即編寫代碼
花一個星期花在某個功能上，然后意識到它的錯誤功能令人尷尬。 我已經完成了不止一次。
屏住呼吸，了解業務問題，并為之計劃代碼對工程師來說是一個巨大的乘數。
從中學到的東西，我讓我自己的啟動中的新開發人員在開始之前詳細計劃票。 此級別的微型計劃有助于理清思路并開發更有效的解決方案。
5.評論太多或太少
一開始我什么也沒評論。
然后，我經歷了一個階段，對每一行進行評論。 一個名為add_two_numbers的方法將被注釋為＃，將兩個數字相加。 這太多了。
回想起來，直到我閱讀了其他開發人員編寫的足夠的代碼并注意到我希望他們添加注釋的位置后，才單擊正確的注釋數量。
6.推送重復和未使用的代碼
我已完成以下所有操作：
· 應用程式中已存在的書面功能
· 左自動生成但未使用的文件（即：測試文件）
· 添加了未使用的軟件包
一些框架會自動生成許多不必要的文件。 當您開始使用應用程序時，您也不知道所有現有代碼。
有趣的是，我發現避免這些問題的最佳方法是先仔細閱讀您詳細編寫的代碼，然后再提交進行審核。
7.編寫低效的數據庫查詢
當我開始第一份工作時，我對數據庫一無所知。 我大概花了一年時間才弄清楚數據庫索引。
那時，我編寫了很多N 1查詢，并創建了db表來存儲大量沒有索引的數據。
兩者都是令人討厭的緩慢應用程序的配方。
8.使用基于錯誤的條件邏輯
條件if / else語句是軟件的核心部分。
在偽代碼中，它們通常看起來像這樣。
if x is true do this
else do that
但是我為自己的投資組合編寫的第一個應用程序充滿了這樣的邏輯。
do this
if this fails do that
有時我們需要挽救錯誤，例如遇到不可靠的API時。 但這應該是例外，而不是常規。
9.提交包含多個功能的代碼以供審核
我學到的第一件事是不在同一個請求請求中合并多個功能。 審核代碼的人不好。
超過幾百行可能會使其他人很難在精神上走過不同的執行路徑。
有時，這是票證范圍不佳的結果。 因此，我總是告訴新開發人員，如果他們認為可以將票證進一步細分為子票證，則應推遲。 越小越好。
結論
學習編寫軟件非常困難。 您只能通過做中學到一百個動人的作品。
我希望閱讀有關我的摸索的文章能使您在掙扎中感到更好。
對我最大的幫助是讓一位高級開發人員對我提交的每段代碼都提供了詳細的反饋。 找到可以得到的公司/團隊。 這是最快的改進方式。
(本文翻譯自Chris的文章《Coding Mistakes I Made As A Junior Developer》，參考：https://towardsdatascience.com/coding-mistakes-i-made-as-a-junior-developer-e151dd3b3c7d)
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。
