怎樣度過第一份編碼工作的艱難時期?
全文共 1726 字,預計學習時長 6 分鐘
圖源:pexels
軟件工程或是數據科學對於很多人來說,實在不是一件容易的事。特別在沒有編碼經驗的情況下,如果第一份工作是在這兩個領域,會讓人士氣低落。
我常常收到“尋求改進方法”的留言或者私信。但事實上,你真正需要的是有人對你說“你能做到!”
本文總結了我在第一份軟件工程工作中犯的錯誤。假如你和那時的我一樣,正在經歷艱難的日子,這篇文章應該能夠給你幫助。
1.巧妙即可,無需可讀
寫好代碼很難,理解錯誤的代碼更難。剛開始時我們很可能難以直觀理解,有一個高級開發人員就以下問題提出了建議:
· 過度抽象
· 同一行上有多個嵌套的if/else語句
· 過度使用鏈式方法
· 從堆棧溢出複製或粘貼正則表達式,不帶註釋
將邏輯壓縮到儘可能小的空間裏,使筆者自覺很聰明。但代碼的可讀性就消失了。 根據克尼根定律: 調試的難度是編寫代碼的兩倍。 因此,如果讀者儘可能巧妙地編寫代碼,那麼根據定義,就因爲不夠聰明而無法對其進行調試。
2.提交審閱的代碼合併了多個功能
筆者最先學到的事項之一,就是不要在同一個請求中組合多個特性。這對於審查代碼的人並不友好。超過幾百行的代碼,會讓其他人很難在腦海中走一遍執行過程。
有時這是tickets範圍不佳的結果。所以筆者總是告訴新開發人員,如果他們認爲可以將ticket進一步細分爲子ticket,則應回推,越小越好。
3.使用無上下文的變量名
想出好的變量名非常困難,但那時我很想要儘快完成它。所以筆者選擇了腦海中浮現的第一個名字。
· 用戶的姓氏是uln。
· 一組電子郵箱是array。
兩者都不算好主意,並且使得任何人都很難理解所寫內容,甚至包括筆者自己。
4.讀取特性Ticket後立即編寫代碼
圖源:pexels
花一週的時間在一個特性上,然後才意識到這一特性是錯誤的,這實在是太尷尬了,然而筆者不止一次犯過這個錯誤。
放鬆心態,理解業務問題,並且圍繞其規劃代碼,這對於工程師而言工作量很大。從中吸取教訓,在筆者自己的創業計劃開始之前,讓新的開發人員詳細規劃一些tickets。這種微觀規劃水平有助於理清思路,制定更有效的解決方案。
5.註釋過多或過少
最初,筆者沒有任何註釋。
第二階段時,筆者每一行都有註釋。add_two_numbers的函數將會有着 # adds 2 numbers的註釋。這就有點矯枉過正了。
回想一下,直到筆者閱讀了其他開發人員編寫的足夠多的代碼,並且注意到希望他們添加註釋的地方,才明白了註釋的真正用處和正確數量。
6.推送重複和未使用的代碼
筆者做了如下所有工作:
· 已存在於應用程序中的書面功能
· 保留自動生成但未使用的文件(即:測試文件)
· 添加了未使用的軟件包
有些框架會自動生成許多不必要的文件。當開始使用一個應用程序時,也不知道所有的現有代碼。筆者發現,避免這些問題的最佳方法是,在提交代碼供審閱之前,一定要仔細閱讀自己編寫的代碼。
圖源:unsplash
7.允許安全漏洞
筆者很感謝一位出色的高級開發人員,使筆者的代碼免受黑客攻擊。我做了下述所有操作:
· 允許 SQL注入
· 允許通過URL跳轉訪問受限頁面
· 僅用於前端驗證
· 具有增量ID的命名空間URL
建立一份有着最佳安全實踐的心理檢查清單花了很長時間,現在筆者查看其他開發人員代碼時會使用該清單。
8.編寫低效的數據庫查詢
筆者在開始第一份工作時,對數據庫一無所知。大概花了一年的時間才弄明白數據庫索引。
那時我寫了很多 N+1 queries ,並且創建了db表來存儲大量沒有索引的數據。這兩者都是應用程序緩慢而讓人煩悶的原因。
9.使用基於錯誤的條件邏輯
條件語句if/else是軟件的核心部分。在僞代碼中,它們通常是這樣的:
if x is true do this else do that
但是筆者在編寫自己的第一個投門磚軟件時,就充滿了如下的邏輯:
do this if this fails do that
有時需要挽救一個錯誤,比如當碰到一個不可靠的API時。偶爾出現這樣的問題是可以的,但這不能是常態。
編寫軟件是一件困難但充滿成就感的事,實踐能讓我們很快成長起來。正處於困難的時期的小夥伴們,但行好事,莫問前程,結果會在你努力的過程中悄悄地來。
推薦閱讀專題
留言點贊發個朋友圈
我們一起分享AI學習與發展的乾貨
編譯組:王俊博、王小燕
相關鏈接:
https://towardsdatascience.com/coding-mistakes-i-made-as-a-junior-developer-e151dd3b3c7d
如轉載,請後臺留言,遵守轉載規範
推薦文章閱讀