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