前陣子在跟讀者聊天的時候，發現在 Junior 階段很容易遇到一些工作上挫折，但又不太知道怎麼解決或是優化。
也有可能在開發過程中碰到了些大地雷，但身邊的前輩、同事不一定能用比較軟性的方式好好的傳達，這是非常常出現的，尤其是在跨部門協作經驗較少的工程師，會不曉得怎麼用淺顯易懂的語言告訴 Junior 做調整。
這一篇整理了個人認為新手軟體開發者容易遇到的幾個雷區，以及對應的解法：無腦複製貼上
在遇到不會做的功能時，新手就會去嘗試模仿其他人的程式碼，或是參考前人寫的程式架構，這在寫程式的過程中是很常見的。然而對於有些新手來說，可能會因為時間壓力、緊張，就一次性將不懂的程式碼複製貼上，也不檢查中間有沒有挾帶一些累贅、不需要的邏輯，認為只要在執行時有過就當作寫完了。這個行為會造成自己在技術上無法進步外，在協作上也會造成其他人的困擾，例如：Code Review 時別人問你為什麼會這樣做，你答不出來，團隊就需要花時間調整程式碼，並且花額外的時間釐清你的問題出在哪。
解法：有意識的選擇自己要使用的內容與方法，搞清楚自己在寫什麼，就算搞不清楚，也要想辦法知道自己是哪裡看不懂，其他人才可以進行協助，或是後續挪出其他時間回來重看。
縮寫
縮寫這件事只對「當下寫程式的人」很方便，但過了一段時間，不要說是別人或是承接專案的老手，自己有機會再回來看，都會有可能看不懂，這絕對會大幅降低程式碼的可讀性與維護性。
解法：要如何解決呢？最好的辦法就是在一開始把變數命名好，除了變數語意化化，也要注意有沒有打錯字。
沒有善用專案內的工具
對於有歷史包袱的中大型專案來說，產品的生命週期較長，中間一定會經手非常多人，如果每個人都不看 README、自己想怎麼寫就怎麼寫，後人上手的難度就越高。舉例來說：同一個邏輯因為自己當下的隨性，導致無意識產生好幾種處理風格、util 函式，後人要多花好幾倍的時間去理解。
解法：學會閱讀、釐清專案架構，參考同一專案內類似元件以相同的脈絡開發會更省時、省力，如果有些邏輯對自己來說還太負擔，理解不來，有意識的「複製貼上」也是很好的辦法。
任意重構
程式碼重構有兩種情境，一種是前人的程式碼，一種是當前一起協作工程師的程式碼，先來聊聊前者：前人看似醜醜又臭臭又長長的程式碼，可能會隱含很多我們不曉得的時空背景、開發考量，任意改動一開始可能看不出差異，但很有可能在未來的某天爆炸，讓接手的人找不到問題在哪。另外一種重構的情境是：通常中大型的專案會配置多個工程師，並透過分工在有限的時間內完成指定功能， 這種情況下常常會有衝突、改到共用元件的狀況，這種情境比重構前人的程式碼更加的複雜，原因有：
- 有些工程師有程式碼潔癖，要改一定要跟對方溝通，不然容易起爭執，但溝通要考量到是否有必要性、有時間，是不是團隊優先順序
- 改動到同時會有很多人被影響到，還會有漏改的狀況
- 有時間性的案子，任務目標不在「好」，而是「完成」，所以根本不需要標準太高的程式碼
解法：有需要重構的需求時，一定要謹慎檢查有關聯到的變數、程式碼是否有跟著一起改動，loader、套件是否有重大調整，或是乾脆起一個新的服務也許會更有效益，團隊有時間的話，可以跟需求方討論看看是否有機會有更多的人力資源一起考古。建議漸進式的調整與試錯，如果有協作夥伴一定要多討論，不要自己一意孤行。
不做錯誤處理
「正確性」在軟體開發中的重要性是非常客觀的，然而程式碼是否能被正確運行有時候跟開發者無關，很多時候甚至都是第三方服務在搞鬼，伺服器掛掉、CDN 掛掉、連線錯誤、使用者操作的過程中安裝其他擴充插件，都有可能造成程式碼的運行錯誤。如果不做錯誤處理，很有可能讓使用者進入神秘空間，卡在某個操作行為中跳離不出來，萬一不幸在正式環境或是服務上線後出現這個狀況，整個團隊就皮繃緊了吧。
解法：此時儘管不是工程師錯誤，也要進行錯誤的捕捉，至少要讓使用者知道現在服務有狀況，不能使用，也同時檢視程式碼是否有邊緣情境是自己沒考量到的。
沒釐清需求就直接動工
程式碼的正確性往往會讓新手工程在評估需求時帶來矯枉過正的副作用，對需求端的人來說，比較不能理解工程面的東西，所以在規劃功能時往往會以「解決某個具體的使用者情境」出發。就像日常生活一樣，能解決某個問題的方式不會只有一個解法，新手工程師在初期很容易把客戶、專案經理、產品經理的話奉為聖旨，覺得問題解決不了都是自己的問題。但實際上需求的釐清是雙向的，不僅是需求方，工程師身為第一線的開發者要有能力跟有意識的評估需求，直接動工可能會造成：
- 不必要的人力、時間成本
- 需求方在規劃後續流程時規劃錯方向
- 為了應付少數奇妙的商業邏輯，而產出的奇妙程式碼
解法：有意識的去協助需求方更了解團隊的目標，在需求方知悉的狀況下，在工程面嘗試給出自己現階段能負荷的開發流程與解法。
不做程式碼拆分
「抽象化」對新手來說非常不好理解，因為新手還沒看過夠多解法、程式碼架構，但這件事並不影響在功能層面的程式碼切分，不能拿來當作不切割程式碼的藉口。新手在開發時可能會為了方便，把所有的事情都寫在同一個檔案、頁面上，導致後續自己回頭要改東西時也不知道自己在寫什麼。
解法：觀察其他人都是怎麼進行程式碼拆分的，看是要依照功能性、程式碼行數、元件、區塊都可以，維持最基本的 DRY （Don’t repeat yourself）原則。
使用中文變數或是屬性名稱
雖然許多文章會跟你說寫程式可以用中文，但基本上這是一個很不常見的開發習慣，就程式碼而言，只要是非英文，都有可能會在不知道什麼情境下需要被重新編碼，拿中文當作變數名稱跟屬性名稱，不僅破壞整個大環境的開發方式，也會在一些情境下變得難以辨識。
解法：應避免使用中文寫程式，如有專有名詞真的需要用在屬性或是變數中，也應該轉譯成有意義的中文拼音。
等到需求確定才開發
功能的開發都會有時間上的限制，等到需求確定才從零開始開發一定是來不及的，以網頁服務來說，光是要把一個最簡單的檔案自動化部屬到主機上，就要花去不少時間，更不要提完整的服務會有很多複雜要素集合而成。
解法：嘗試找出有哪些東西即便沒有規範在需求中，也一定會需要處理的基礎建設著手開發。
不溝通
自己看過很多新手工程師，可能會因為太沈浸在程式碼裡面，而沒有去培養與需求方交涉的能力，也有可能會因為對方不懂程式，進而產出一些優越感，導致讓工程師覺得跟其他角色溝通很麻煩、累費時間，也不知道該怎麼去處理人的問題。不溝通的下場非常可怕，可能會造成時程延宕、開發功能或是流程錯誤、團隊氣氛差等等數不完的缺點，大部分都是因為缺乏功能造成的。多溝通絕對利大於弊，能協助我們釐清需求外，更多時候可以免去很多做白工的情境發生。
解法：不論個人的人格特質為何，都要透過觀察、學習讓自己培養一套溝通模式，至少讓團隊有辦法理解當前團隊的困境是什麼，可以怎麼處理。
以上就是我認為新手工程師在工作初期比較容易遇到幾個雷區，自己在工作的時候也是多少踩過一些，好在身邊的前輩都很願意、也很給空間讓我進行磨練。
希望這篇文章可以讓比較沒有方向的新手，更坦然的去面對自己的弱點，在未來 code review 時看到有人這麼做了，也可以善用影響力讓程式碼品質變得更好。
如果文章內有任何錯字，或是有想要跟我討論的內容都歡迎下留言告訴我，我是 Vivian，我們下次見。
關於我：
一名從英文系畢業的前端工程師，喜歡閱讀、寫東西及自我成長。
｜Instagram: Vivian Yeh｜vivian_enlife
｜聯絡我：vivian.enlife@gmail.com
