瓶頸的由來
因為程式基礎不穩，找第一份前端工作的時候，能力範圍內的職缺通常是那種「我們有個 single page app，需要一位設計師來重做介面，而這位設計師要知道怎麼改我們的程式碼」的類型，比方說現職在招募的時候職稱就不是寫「前端工程師」而是寫「前端設計師」。由於 single page app 的介面設計跟程式實做之間的關係非常緊密，不管原本團隊怎麼分工，經過一定的時間後，冥冥中自然有股力量（？）會讓這個前端設計師變成單獨作業。一旦單獨作業就得開始做技術決策，而缺乏做出技術決策所需的背景知識的時候，就會有遇到瓶頸的感覺。
遇到瓶頸的感覺大致上可以分成兩個等級，第一個等級是不知道要用什麼方法才能做到某件事，第二個等級是已經知道好幾種方法可以做到那件事，但不確定當下應該用哪一個。
瓶頸感可能來自各種不同面向的技術決策。大一點的技術決策像是要採用哪些 library，需要的背景知識包括各家 lib 可以做到什麼、優點缺點、生態圈的趨勢，還需要一些經驗來判斷這些 lib 適不適合自家的專案、導入後可能會面臨什麼問題。小一點的技術決策像是該怎麼命名、切 component 跟抽 functions、一些細部的 coding style。其他還有跟開發環境相關的，像是決定 deploy 的方式、開發過程中的輔助工具，比如 charles 啦，postman 啦，json-server 啦。最後還有一些其實不是技術層面，而是管理層面的決策，像是釐清產品在什麼樣的階段、預估規格的變動性可能有多大，然後據此規劃開發時程。
克服的方式
克服這些瓶頸的方式，需要建立系統性思考模型的部分是靠 egghead 課程，lib 的技術規格比較則是靠 google search，coding style 靠 clean code，輔助工具、時程規劃、以及各種需要經驗的部分則是靠室友跟強者朋友這兩個最終兵器... LOL
小結
瓶頸感最重的時候是去年 10 月重寫產品前端，從開發環境到 lib 都全部砍掉重練，很多事情都卡在第一個等級的瓶頸。其次是今年 1 月為了某些功能大改架構跟加入測試、還有 5 月要導入 react hooks 再次大改架構，就主要是卡在第二個等級的瓶頸。現在倒是蠻順的，技術上的不確定性越來越低，連時程都估得越來越準確了 (°▽°)
隨著瓶頸一一過去，原本的深水區也漸漸變成了舒適區，等下次又離開舒適區的時候，應該就又會遇到新的瓶頸了，到時候再來繼續寫文章靠杯 😆
（謎之音：講來講去克服瓶頸的關鍵就是在家靠室友出外靠朋友嘛！這種經驗寫出來是能幫到什麼人蛤？）
ㄜ XDrz
沒有留言:
張貼留言