怎樣度過第一份編碼工作的艱難時(shí)期？
本文轉(zhuǎn)載自公眾號(hào)“讀芯術(shù)”(ID：AI_Discovery)
軟件工程或是數(shù)據(jù)科學(xué)對(duì)于很多人來說，實(shí)在不是一件容易的事。特別在沒有編碼經(jīng)驗(yàn)的情況下，如果第一份工作是在這兩個(gè)領(lǐng)域，會(huì)讓人士氣低落。
我常常收到“尋求改進(jìn)方法”的留言或者私信。但事實(shí)上，你真正需要的是有人對(duì)你說“你能做到!”
本文總結(jié)了我在第一份軟件工程工作中犯的錯(cuò)誤。假如你和那時(shí)的我一樣，正在經(jīng)歷艱難的日子，這篇文章應(yīng)該能夠給你幫助。
1. 巧妙即可，無需可讀
寫好代碼很難，理解錯(cuò)誤的代碼更難。剛開始時(shí)我們很可能難以直觀理解，有一個(gè)高級(jí)開發(fā)人員就以下問題提出了建議：
- 過度抽象
- 同一行上有多個(gè)嵌套的if/else語句
- 過度使用鏈?zhǔn)椒椒?/li>
- 從堆棧溢出復(fù)制或粘貼正則表達(dá)式，不帶注釋
將邏輯壓縮到盡可能小的空間里，使筆者自覺很聰明。但代碼的可讀性就消失了。根據(jù)克尼根定律：調(diào)試的難度是編寫代碼的兩倍。因此，如果讀者盡可能巧妙地編寫代碼，那么根據(jù)定義，就因?yàn)椴粔蚵斆鞫鵁o法對(duì)其進(jìn)行調(diào)試。
2. 提交審閱的代碼合并了多個(gè)功能
筆者最先學(xué)到的事項(xiàng)之一，就是不要在同一個(gè)請(qǐng)求中組合多個(gè)特性。這對(duì)于審查代碼的人并不友好。超過幾百行的代碼，會(huì)讓其他人很難在腦海中走一遍執(zhí)行過程。
有時(shí)這是tickets范圍不佳的結(jié)果。所以筆者總是告訴新開發(fā)人員，如果他們認(rèn)為可以將ticket進(jìn)一步細(xì)分為子ticket，則應(yīng)回推，越小越好。
3. 使用無上下文的變量名
想出好的變量名非常困難，但那時(shí)我很想要盡快完成它。所以筆者選擇了腦海中浮現(xiàn)的第一個(gè)名字。
- 用戶的姓氏是uln。
- 一組電子郵箱是array。
兩者都不算好主意，并且使得任何人都很難理解所寫內(nèi)容，甚至包括筆者自己。
4. 讀取特性Ticket后立即編寫代碼
圖源：pexels
花一周的時(shí)間在一個(gè)特性上，然后才意識(shí)到這一特性是錯(cuò)誤的，這實(shí)在是太尷尬了，然而筆者不止一次犯過這個(gè)錯(cuò)誤。
放松心態(tài)，理解業(yè)務(wù)問題，并且圍繞其規(guī)劃代碼，這對(duì)于工程師而言工作量很大。從中吸取教訓(xùn)，在筆者自己的創(chuàng)業(yè)計(jì)劃開始之前，讓新的開發(fā)人員詳細(xì)規(guī)劃一些tickets。這種微觀規(guī)劃水平有助于理清思路，制定更有效的解決方案。
5. 注釋過多或過少
最初，筆者沒有任何注釋。
第二階段時(shí)，筆者每一行都有注釋。add_two_numbers的函數(shù)將會(huì)有著 # adds 2 numbers的注釋。這就有點(diǎn)矯枉過正了。
回想一下，直到筆者閱讀了其他開發(fā)人員編寫的足夠多的代碼，并且注意到希望他們添加注釋的地方，才明白了注釋的真正用處和正確數(shù)量。
6. 推送重復(fù)和未使用的代碼
筆者做了如下所有工作：
- 已存在于應(yīng)用程序中的書面功能
- 保留自動(dòng)生成但未使用的文件(即：測(cè)試文件)
- 添加了未使用的軟件包
有些框架會(huì)自動(dòng)生成許多不必要的文件。當(dāng)開始使用一個(gè)應(yīng)用程序時(shí)，也不知道所有的現(xiàn)有代碼。筆者發(fā)現(xiàn)，避免這些問題的最佳方法是，在提交代碼供審閱之前，一定要仔細(xì)閱讀自己編寫的代碼。
圖源：unsplash
7. 允許安全漏洞
筆者很感謝一位出色的高級(jí)開發(fā)人員，使筆者的代碼免受黑客攻擊。我做了下述所有操作：
- 允許SQL注入
- 允許通過URL跳轉(zhuǎn)訪問受限頁(yè)面
- 僅用于前端驗(yàn)證
- 具有增量ID的命名空間URL
建立一份有著最佳安全實(shí)踐的心理檢查清單花了很長(zhǎng)時(shí)間，現(xiàn)在筆者查看其他開發(fā)人員代碼時(shí)會(huì)使用該清單。
8. 編寫低效的數(shù)據(jù)庫(kù)查詢
筆者在開始第一份工作時(shí)，對(duì)數(shù)據(jù)庫(kù)一無所知。大概花了一年的時(shí)間才弄明白數(shù)據(jù)庫(kù)索引。
那時(shí)我寫了很多N+1 queries，并且創(chuàng)建了db表來存儲(chǔ)大量沒有索引的數(shù)據(jù)。這兩者都是應(yīng)用程序緩慢而讓人煩悶的原因。
9. 使用基于錯(cuò)誤的條件邏輯
條件語句if/else是軟件的核心部分。在偽代碼中，它們通常是這樣的：
- if x is true
- do this
- else
- do that
但是筆者在編寫自己的第一個(gè)投門磚軟件時(shí)，就充滿了如下的邏輯：
- do this
- if this fails
- do that
有時(shí)需要挽救一個(gè)錯(cuò)誤，比如當(dāng)碰到一個(gè)不可靠的API時(shí)。偶爾出現(xiàn)這樣的問題是可以的，但這不能是常態(tài)。
編寫軟件是一件困難但充滿成就感的事，實(shí)踐能讓我們很快成長(zhǎng)起來。正處于困難的時(shí)期的小伙伴們，但行好事，莫問前程，結(jié)果會(huì)在你努力的過程中悄悄地來。
