希望您在第一份工作編寫代碼時(shí)都遇到困難

> Photo by Atul Choudhary from Pexels

您在軟件工程或數(shù)據(jù)科學(xué)領(lǐng)域的第一份工作可能會使人士氣低落。 特別是如果您沒有后臺編寫代碼。

我經(jīng)常收到人們的信息，要求他們提出改進(jìn)建議。 但是他們真正需要的是有人告訴他們-"您可以做到！"

以下是我在第一份軟件工程工作中親自犯的錯(cuò)誤。 如果您遇到困難，這應(yīng)該會讓您感覺更好。

1.編寫比可讀代碼更聰明的代碼

編寫好的代碼很難。 了解錯(cuò)誤的代碼更加困難。 但這剛開始時(shí)并不直觀。

值得慶幸的是，我有一個(gè)高級開發(fā)人員，他不止一次地就以下幾點(diǎn)提出了建議。

· 同一行上有多個(gè)嵌套的if / else語句

· 過多使用鏈?zhǔn)椒椒?/p>

· 正則表達(dá)式從堆棧溢出復(fù)制/粘貼而沒有評論

· 過度抽象

將邏輯壓縮到盡可能小的空間，讓我感到很聰明。 但這也使我的代碼不可讀。 現(xiàn)在，我總是嘗試在可讀性方面犯錯(cuò)誤。

調(diào)試的難度是一開始編寫代碼的兩倍。 因此，如果您盡可能聰明地編寫代碼，就定義而言，您就不夠聰明，無法對其進(jìn)行調(diào)試。-克尼根定律

2.使用沒有上下文的變量名

想出好的變量名非常困難，我想盡快完成票證。

因此，我選擇突然出現(xiàn)的名字。

· 用戶的姓氏變?yōu)閡ln。

· 一系列電子郵件變成了陣列。

兩者都是不好的主意，這使任何人都很難理解我寫的內(nèi)容（包括我自己）。

3.允許安全漏洞

在另一種情況下，我要感謝一位出色的高級開發(fā)人員，他將我的代碼免于遭到黑客攻擊。

我已完成以下所有操作：

· 允許SQL注入

· 允許通過URL跳轉(zhuǎn)訪問受限頁面

· 僅使用前端驗(yàn)證

· 具有增量ID的命名空間URL

建立了一份關(guān)于最佳安全實(shí)踐的心理檢查清單花了很長時(shí)間，我現(xiàn)在在檢查其他開發(fā)人員的代碼時(shí)會使用該清單。

4.閱讀功能票后立即編寫代碼

花一個(gè)星期花在某個(gè)功能上，然后意識到它的錯(cuò)誤功能令人尷尬。 我已經(jīng)完成了不止一次。

屏住呼吸，了解業(yè)務(wù)問題，并為之計(jì)劃代碼對工程師來說是一個(gè)巨大的乘數(shù)。

從中學(xué)到的東西，我讓我自己的啟動(dòng)中的新開發(fā)人員在開始之前詳細(xì)計(jì)劃票。 此級別的微型計(jì)劃有助于理清思路并開發(fā)更有效的解決方案。

5.評論太多或太少

一開始我什么也沒評論。

然后，我經(jīng)歷了一個(gè)階段，對每一行進(jìn)行評論。 一個(gè)名為add_two_numbers的方法將被注釋為＃，將兩個(gè)數(shù)字相加。 這太多了。

回想起來，直到我閱讀了其他開發(fā)人員編寫的足夠的代碼并注意到我希望他們添加注釋的位置后，才單擊正確的注釋數(shù)量。

6.推送重復(fù)和未使用的代碼

我已完成以下所有操作：

· 應(yīng)用程式中已存在的書面功能

· 左自動(dòng)生成但未使用的文件（即：測試文件）

· 添加了未使用的軟件包

一些框架會自動(dòng)生成許多不必要的文件。 當(dāng)您開始使用應(yīng)用程序時(shí)，您也不知道所有現(xiàn)有代碼。

有趣的是，我發(fā)現(xiàn)避免這些問題的最佳方法是先仔細(xì)閱讀您詳細(xì)編寫的代碼，然后再提交進(jìn)行審核。

7.編寫低效的數(shù)據(jù)庫查詢

當(dāng)我開始第一份工作時(shí)，我對數(shù)據(jù)庫一無所知。 我大概花了一年時(shí)間才弄清楚數(shù)據(jù)庫索引。

那時(shí)，我編寫了很多N 1查詢，并創(chuàng)建了db表來存儲大量沒有索引的數(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è)請求請求中合并多個(gè)功能。 審核代碼的人不好。

超過幾百行可能會使其他人很難在精神上走過不同的執(zhí)行路徑。

有時(shí)，這是票證范圍不佳的結(jié)果。 因此，我總是告訴新開發(fā)人員，如果他們認(rèn)為可以將票證進(jìn)一步細(xì)分為子票證，則應(yīng)推遲。 越小越好。

結(jié)論

學(xué)習(xí)編寫軟件非常困難。 您只能通過做中學(xué)到一百個(gè)動(dòng)人的作品。

我希望閱讀有關(guān)我的摸索的文章能使您在掙扎中感到更好。

對我最大的幫助是讓一位高級開發(fā)人員對我提交的每段代碼都提供了詳細(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)