新手軟體開發者容易誤觸的幾個雷區

更新於 發佈於 閱讀時間約 7 分鐘

前陣子在跟讀者聊天的時候,發現在 Junior 階段很容易遇到一些工作上挫折,但又不太知道怎麼解決或是優化。

也有可能在開發過程中碰到了些大地雷,但身邊的前輩、同事不一定能用比較軟性的方式好好的傳達,這是非常常出現的,尤其是在跨部門協作經驗較少的工程師,會不曉得怎麼用淺顯易懂的語言告訴 Junior 做調整。

這一篇整理了個人認為新手軟體開發者容易遇到的幾個雷區,以及對應的解法:

無腦複製貼上

在遇到不會做的功能時,新手就會去嘗試模仿其他人的程式碼,或是參考前人寫的程式架構,這在寫程式的過程中是很常見的。然而對於有些新手來說,可能會因為時間壓力、緊張,就一次性將不懂的程式碼複製貼上,也不檢查中間有沒有挾帶一些累贅、不需要的邏輯,認為只要在執行時有過就當作寫完了。這個行為會造成自己在技術上無法進步外,在協作上也會造成其他人的困擾,例如:Code Review 時別人問你為什麼會這樣做,你答不出來,團隊就需要花時間調整程式碼,並且花額外的時間釐清你的問題出在哪。

解法:有意識的選擇自己要使用的內容與方法,搞清楚自己在寫什麼,就算搞不清楚,也要想辦法知道自己是哪裡看不懂,其他人才可以進行協助,或是後續挪出其他時間回來重看。


縮寫

縮寫這件事只對「當下寫程式的人」很方便,但過了一段時間,不要說是別人或是承接專案的老手,自己有機會再回來看,都會有可能看不懂,這絕對會大幅降低程式碼的可讀性與維護性。

解法:要如何解決呢?最好的辦法就是在一開始把變數命名好,除了變數語意化化,也要注意有沒有打錯字。


沒有善用專案內的工具

對於有歷史包袱的中大型專案來說,產品的生命週期較長,中間一定會經手非常多人,如果每個人都不看 README、自己想怎麼寫就怎麼寫,後人上手的難度就越高。舉例來說:同一個邏輯因為自己當下的隨性,導致無意識產生好幾種處理風格、util 函式,後人要多花好幾倍的時間去理解。

解法:學會閱讀、釐清專案架構,參考同一專案內類似元件以相同的脈絡開發會更省時、省力,如果有些邏輯對自己來說還太負擔,理解不來,有意識的「複製貼上」也是很好的辦法。


任意重構

程式碼重構有兩種情境,一種是前人的程式碼,一種是當前一起協作工程師的程式碼,先來聊聊前者:前人看似醜醜又臭臭又長長的程式碼,可能會隱含很多我們不曉得的時空背景、開發考量,任意改動一開始可能看不出差異,但很有可能在未來的某天爆炸,讓接手的人找不到問題在哪。另外一種重構的情境是:通常中大型的專案會配置多個工程師,並透過分工在有限的時間內完成指定功能, 這種情況下常常會有衝突、改到共用元件的狀況,這種情境比重構前人的程式碼更加的複雜,原因有:

    1. 有些工程師有程式碼潔癖,要改一定要跟對方溝通,不然容易起爭執,但溝通要考量到是否有必要性、有時間,是不是團隊優先順序
    2. 改動到同時會有很多人被影響到,還會有漏改的狀況
    3. 有時間性的案子,任務目標不在「好」,而是「完成」,所以根本不需要標準太高的程式碼

解法:有需要重構的需求時,一定要謹慎檢查有關聯到的變數、程式碼是否有跟著一起改動,loader、套件是否有重大調整,或是乾脆起一個新的服務也許會更有效益,團隊有時間的話,可以跟需求方討論看看是否有機會有更多的人力資源一起考古。建議漸進式的調整與試錯,如果有協作夥伴一定要多討論,不要自己一意孤行。


不做錯誤處理

「正確性」在軟體開發中的重要性是非常客觀的,然而程式碼是否能被正確運行有時候跟開發者無關,很多時候甚至都是第三方服務在搞鬼,伺服器掛掉、CDN 掛掉、連線錯誤、使用者操作的過程中安裝其他擴充插件,都有可能造成程式碼的運行錯誤。如果不做錯誤處理,很有可能讓使用者進入神秘空間,卡在某個操作行為中跳離不出來,萬一不幸在正式環境或是服務上線後出現這個狀況,整個團隊就皮繃緊了吧。

解法:此時儘管不是工程師錯誤,也要進行錯誤的捕捉,至少要讓使用者知道現在服務有狀況,不能使用,也同時檢視程式碼是否有邊緣情境是自己沒考量到的。


沒釐清需求就直接動工

程式碼的正確性往往會讓新手工程在評估需求時帶來矯枉過正的副作用,對需求端的人來說,比較不能理解工程面的東西,所以在規劃功能時往往會以「解決某個具體的使用者情境」出發。就像日常生活一樣,能解決某個問題的方式不會只有一個解法,新手工程師在初期很容易把客戶、專案經理、產品經理的話奉為聖旨,覺得問題解決不了都是自己的問題。但實際上需求的釐清是雙向的,不僅是需求方,工程師身為第一線的開發者要有能力跟有意識的評估需求,直接動工可能會造成:

    1. 不必要的人力、時間成本
    2. 需求方在規劃後續流程時規劃錯方向
    3. 為了應付少數奇妙的商業邏輯,而產出的奇妙程式碼

解法:有意識的去協助需求方更了解團隊的目標,在需求方知悉的狀況下,在工程面嘗試給出自己現階段能負荷的開發流程與解法。


不做程式碼拆分

「抽象化」對新手來說非常不好理解,因為新手還沒看過夠多解法、程式碼架構,但這件事並不影響在功能層面的程式碼切分,不能拿來當作不切割程式碼的藉口。新手在開發時可能會為了方便,把所有的事情都寫在同一個檔案、頁面上,導致後續自己回頭要改東西時也不知道自己在寫什麼。

解法:觀察其他人都是怎麼進行程式碼拆分的,看是要依照功能性、程式碼行數、元件、區塊都可以,維持最基本的 DRY (Don’t repeat yourself)原則。


使用中文變數或是屬性名稱

雖然許多文章會跟你說寫程式可以用中文,但基本上這是一個很不常見的開發習慣,就程式碼而言,只要是非英文,都有可能會在不知道什麼情境下需要被重新編碼,拿中文當作變數名稱跟屬性名稱,不僅破壞整個大環境的開發方式,也會在一些情境下變得難以辨識。

解法:應避免使用中文寫程式,如有專有名詞真的需要用在屬性或是變數中,也應該轉譯成有意義的中文拼音。


等到需求確定才開發

功能的開發都會有時間上的限制,等到需求確定才從零開始開發一定是來不及的,以網頁服務來說,光是要把一個最簡單的檔案自動化部屬到主機上,就要花去不少時間,更不要提完整的服務會有很多複雜要素集合而成。

解法:嘗試找出有哪些東西即便沒有規範在需求中,也一定會需要處理的基礎建設著手開發。


不溝通

自己看過很多新手工程師,可能會因為太沈浸在程式碼裡面,而沒有去培養與需求方交涉的能力,也有可能會因為對方不懂程式,進而產出一些優越感,導致讓工程師覺得跟其他角色溝通很麻煩、累費時間,也不知道該怎麼去處理人的問題。不溝通的下場非常可怕,可能會造成時程延宕、開發功能或是流程錯誤、團隊氣氛差等等數不完的缺點,大部分都是因為缺乏功能造成的。多溝通絕對利大於弊,能協助我們釐清需求外,更多時候可以免去很多做白工的情境發生。

解法:不論個人的人格特質為何,都要透過觀察、學習讓自己培養一套溝通模式,至少讓團隊有辦法理解當前團隊的困境是什麼,可以怎麼處理。


以上就是我認為新手工程師在工作初期比較容易遇到幾個雷區,自己在工作的時候也是多少踩過一些,好在身邊的前輩都很願意、也很給空間讓我進行磨練。

希望這篇文章可以讓比較沒有方向的新手,更坦然的去面對自己的弱點,在未來 code review 時看到有人這麼做了,也可以善用影響力讓程式碼品質變得更好。

如果文章內有任何錯字,或是有想要跟我討論的內容都歡迎下留言告訴我,我是 Vivian,我們下次見。


關於我:

一名從英文系畢業的前端工程師,喜歡閱讀、寫東西及自我成長。

|Instagram: Vivian Yeh|vivian_enlife

|聯絡我:vivian.enlife@gmail.com

為了追求可以窩在座位上、可以心無旁騖思考問題、座位可以亂七八糟沒關係、不需要到處哈腰點頭跑客戶,不用腳踩十公分、連妝都可以不用化的職場人生,文組少女毅然決然踏上RD的養成日常。
留言0
查看全部
avatar-img
發表第一個留言支持創作者!
「Hi,Vivian 想要請教妳有沒有在寫程式的時候遇過瓶頸呢?」這大概是我在經營自媒體後,最常收到的問題了。 說實話,身為非本科系的我,在還沒掌握寫程式的精髓時,多多少少都會有感到很挫折的時候,在分享我自己的狀況前,先來聊聊讀者及一些朋友與我分享他們在學習程式時卡關的狀況:
在還不是工程師以前,我非常著迷於「自學」這個詞,不論在工作上、興趣方面的問題,我都會告訴我自己:「嗯!我可以自己學起來!」 於是乎我就有了「自學行銷」、「自學設計」、「自學吉他」等,各式各樣的自學行為,有時候我會買書學習,但有時候又會覺得:「啊,網路上這麼多免費的資源,我多看幾個影片就可以學會了。」
讀者 W 從 2021 年的春天開始,就斷斷續續的私訊我一些有關程式學習的小困擾,直到 2021 年的夏天都快要結束時,讀者 W 還是沒有辦法進入到穩定的學習階段⋯⋯
這一次再分享心得,主要是要跟大家聊聊,在結束 JavaScript 直播班後,我發現自己的切版技能跟不上實作功能的開發速度,於是又再投入了同樣是六角學院開的切版直播班之學習心得。
HackMD 是一個協作共筆文件彈性很高的工具,但也因為彈性高,更需要學習系統性的管理方式。 當瞭解 HackMD 的編寫邏輯,就能依照協作文件的性質,來進行不同的管理方式。
前陣子有讀者來信詢問我:「嗨!Vivian,我想要請問妳都是在哪裡學程式的呢?是實體課程嗎?」
「Hi,Vivian 想要請教妳有沒有在寫程式的時候遇過瓶頸呢?」這大概是我在經營自媒體後,最常收到的問題了。 說實話,身為非本科系的我,在還沒掌握寫程式的精髓時,多多少少都會有感到很挫折的時候,在分享我自己的狀況前,先來聊聊讀者及一些朋友與我分享他們在學習程式時卡關的狀況:
在還不是工程師以前,我非常著迷於「自學」這個詞,不論在工作上、興趣方面的問題,我都會告訴我自己:「嗯!我可以自己學起來!」 於是乎我就有了「自學行銷」、「自學設計」、「自學吉他」等,各式各樣的自學行為,有時候我會買書學習,但有時候又會覺得:「啊,網路上這麼多免費的資源,我多看幾個影片就可以學會了。」
讀者 W 從 2021 年的春天開始,就斷斷續續的私訊我一些有關程式學習的小困擾,直到 2021 年的夏天都快要結束時,讀者 W 還是沒有辦法進入到穩定的學習階段⋯⋯
這一次再分享心得,主要是要跟大家聊聊,在結束 JavaScript 直播班後,我發現自己的切版技能跟不上實作功能的開發速度,於是又再投入了同樣是六角學院開的切版直播班之學習心得。
HackMD 是一個協作共筆文件彈性很高的工具,但也因為彈性高,更需要學習系統性的管理方式。 當瞭解 HackMD 的編寫邏輯,就能依照協作文件的性質,來進行不同的管理方式。
前陣子有讀者來信詢問我:「嗨!Vivian,我想要請問妳都是在哪裡學程式的呢?是實體課程嗎?」
你可能也想看
Google News 追蹤
Thumbnail
/ 大家現在出門買東西還會帶錢包嗎 鴨鴨發現自己好像快一個禮拜沒帶錢包出門 還是可以天天買滿買好回家(? 因此為了記錄手機消費跟各種紅利優惠 鴨鴨都會特別注意銀行的App好不好用! 像是介面設計就是會很在意的地方 很多銀行通常會為了要滿足不同客群 會推出很多App讓使用者下載 每次
★★★先到自己電子郵件信箱下載教材上的圖片對照閱讀操作。 有人拿 python 程式來問我,他看不懂那段程式,忘記當初是怎樣寫出來的 ? 經過執行除錯後解決了,同時告訴他程式的功能與原理。 撰寫程式如果不養成隨時作註解的習慣,時間久了很容易發生類似的狀況,尤其是多人共同開發的專案,會變成很難
這時候修改的程式部分變多了,而且也會遇到Bug,所以重點不僅是要學會把程式路徑打通,還要知道怎麼描述錯誤,了解邏輯錯誤或語法錯誤在哪裡。 簡單來說,就算要複製貼上也要貼對位置。 另外,GPT的確會考慮多一些問題,看到程式的當下會覺得:「哦對,這個要注意。」然後就又佩服GPT可以做到這個程度。
軟體開發中,我們經常會遇到各種令人抓狂的設計問題。有時候是趕進度的壓力讓我們妥協了設計質量;有時候是忽略了好的設計原則,結果掉進了各種反模式的坑裡。今天我們來繼續聊聊幾個常見的反模式。 寫死 Hard Code 直接將資料值或邏輯硬寫死在程式碼裡,當需求變更時,修改這些 Hard Code
今天想跟大家聊聊軟體開發中那些年大家踩過的「坑」,沒錯,就是那些看不見的陷阱,常常搞得我們焦頭爛額的坑,痛到想哭。 需求改來改去 本來覺得這次的需求挺清楚,覺得「這很簡單,幾天就能搞定」,結果寫完第一個版本,需求就改了。還沒喘口氣,需求又變了!連改了五六次,改到懷疑人生。 會議太多,程
1. 沒有從整體架構著手,過早進入細節: 很多學生一開始學習程式設計時,容易陷入只關注某個程式碼段或技術細節,卻忽略了先掌握整體系統的全貌。這就像在蓋房子時,還沒設計好整體藍圖就直接開始裝修內部,最終只會導致整體混亂。事實上,先了解系統的目的、架構、以及如何運作,是有效解決問題的關鍵。如果
Thumbnail
一款遊戲的開發,肯定伴隨大大小小的修改和調整。 創作者不能怕改。但問題是,改東西需要花時間。一些看似簡單的改動,背後程式邏輯可能要好幾天,甚至幾星期才能修正。 對於不懂程式的人,有時很難判斷東西好不好修。所以今天就來說一下,對程式來說什麼樣的修正會令我們頭痛呢?   先以一個草莓奶油蛋糕為例
Thumbnail
改稿真的不是一件需要太多情緒的事,把錯的挑出來、改掉,就這麼簡單!很少有什麼「大錯」需要去爭執誰對誰錯。不過真的滿多時候鬼遮眼或是偶爾真的會發生某種「明明前一版是對的,這一版居然是錯的」的鬼故事,把問題找出來解決就好!
上一篇主要在說如何做決定的,這篇就來寫寫面試前該做什麼準備。
Thumbnail
追求乾淨的程式碼是好的開始,但不要陷入過度設計的陷阱,導致程式難以維護。實際上,考慮團隊狀況和專注於解決真正的問題更為重要。了解公司的規模和現實情況,適時調整工作重心。技術不斷進步,使得寫程式變得更加容易,但這並不意味著工程師的角色會消失。在選擇技術時,也要考慮隱形成本有時簡單的解決方案反而更有效。
Thumbnail
對理工出身的我而言,「人的感受」真的很難處理,因為你控制不了對方的感覺。 你想嘛!工程師寫程式,寫錯了,改一改重新編譯,我們沒有必要去對程式碼噓寒問暖呀~
Thumbnail
/ 大家現在出門買東西還會帶錢包嗎 鴨鴨發現自己好像快一個禮拜沒帶錢包出門 還是可以天天買滿買好回家(? 因此為了記錄手機消費跟各種紅利優惠 鴨鴨都會特別注意銀行的App好不好用! 像是介面設計就是會很在意的地方 很多銀行通常會為了要滿足不同客群 會推出很多App讓使用者下載 每次
★★★先到自己電子郵件信箱下載教材上的圖片對照閱讀操作。 有人拿 python 程式來問我,他看不懂那段程式,忘記當初是怎樣寫出來的 ? 經過執行除錯後解決了,同時告訴他程式的功能與原理。 撰寫程式如果不養成隨時作註解的習慣,時間久了很容易發生類似的狀況,尤其是多人共同開發的專案,會變成很難
這時候修改的程式部分變多了,而且也會遇到Bug,所以重點不僅是要學會把程式路徑打通,還要知道怎麼描述錯誤,了解邏輯錯誤或語法錯誤在哪裡。 簡單來說,就算要複製貼上也要貼對位置。 另外,GPT的確會考慮多一些問題,看到程式的當下會覺得:「哦對,這個要注意。」然後就又佩服GPT可以做到這個程度。
軟體開發中,我們經常會遇到各種令人抓狂的設計問題。有時候是趕進度的壓力讓我們妥協了設計質量;有時候是忽略了好的設計原則,結果掉進了各種反模式的坑裡。今天我們來繼續聊聊幾個常見的反模式。 寫死 Hard Code 直接將資料值或邏輯硬寫死在程式碼裡,當需求變更時,修改這些 Hard Code
今天想跟大家聊聊軟體開發中那些年大家踩過的「坑」,沒錯,就是那些看不見的陷阱,常常搞得我們焦頭爛額的坑,痛到想哭。 需求改來改去 本來覺得這次的需求挺清楚,覺得「這很簡單,幾天就能搞定」,結果寫完第一個版本,需求就改了。還沒喘口氣,需求又變了!連改了五六次,改到懷疑人生。 會議太多,程
1. 沒有從整體架構著手,過早進入細節: 很多學生一開始學習程式設計時,容易陷入只關注某個程式碼段或技術細節,卻忽略了先掌握整體系統的全貌。這就像在蓋房子時,還沒設計好整體藍圖就直接開始裝修內部,最終只會導致整體混亂。事實上,先了解系統的目的、架構、以及如何運作,是有效解決問題的關鍵。如果
Thumbnail
一款遊戲的開發,肯定伴隨大大小小的修改和調整。 創作者不能怕改。但問題是,改東西需要花時間。一些看似簡單的改動,背後程式邏輯可能要好幾天,甚至幾星期才能修正。 對於不懂程式的人,有時很難判斷東西好不好修。所以今天就來說一下,對程式來說什麼樣的修正會令我們頭痛呢?   先以一個草莓奶油蛋糕為例
Thumbnail
改稿真的不是一件需要太多情緒的事,把錯的挑出來、改掉,就這麼簡單!很少有什麼「大錯」需要去爭執誰對誰錯。不過真的滿多時候鬼遮眼或是偶爾真的會發生某種「明明前一版是對的,這一版居然是錯的」的鬼故事,把問題找出來解決就好!
上一篇主要在說如何做決定的,這篇就來寫寫面試前該做什麼準備。
Thumbnail
追求乾淨的程式碼是好的開始,但不要陷入過度設計的陷阱,導致程式難以維護。實際上,考慮團隊狀況和專注於解決真正的問題更為重要。了解公司的規模和現實情況,適時調整工作重心。技術不斷進步,使得寫程式變得更加容易,但這並不意味著工程師的角色會消失。在選擇技術時,也要考慮隱形成本有時簡單的解決方案反而更有效。
Thumbnail
對理工出身的我而言,「人的感受」真的很難處理,因為你控制不了對方的感覺。 你想嘛!工程師寫程式,寫錯了,改一改重新編譯,我們沒有必要去對程式碼噓寒問暖呀~