重新點燃職涯衝刺的引擎
前方高能，文長慎入！
離開學校數年，對於還有機會上課實在是又新鮮又懷念，今年開始排了較多外訓，期望能站在巨人的肩膀上跳得更高。上次分享了 2021 年第一個里程碑，那今天這篇文章算是我上完 91敏捷開發之路 兩門課的心得，我覺得也許可以幫到比我菜或是年資跟我差不多的同行們，與大家共勉之！💪
『 我感覺後端只是處理一下 CRUD 而已？』🤨
讓我來教各位一個國學小常識，XXX 只是 OOO 的這種語法，無論你前面跟結尾加上您、感覺、請問，呢這些感覺比較恭敬的修飾，依舊無法掩飾你的無知跟無禮 🤣
我記得那是一次 Kotlin 聚會吧，坐在我對面的陌生社群朋友在簡單了解我的背景之後，開始很不會聊天的跟我聊天，開場沒多久就對著我問了這句。Anyway，我還是笑笑地瞭解他的背景之後（Android Engineer）細心地跟他解釋其實還有哪些議題跟眉角值得注意。雖然講完之後我就顧著我兒子沒再搭理他惹。
那如果順著他的理解去思考，我們後端到底是什麼？我自己是常對團隊小朋友解釋成，可以理解成邏輯流跟資料流的交互。而資料流總有進出跟落地的議題，CRUD 便是其中一個面向。
『 那，你看起來像是一個資深後端工程師，你不用寫 CRUD 嗎？或是我這麼問，你寫出來的 CRUD跟別人不一樣嗎 ？』🧑💻
必須要說，這個問題比第一個有深度多了。這樣說好了，一個寫 N 次的東西，別的不說，至少我寫得快。是那種還沒開始寫，步驟就像抬頭顯示器浮在眼前，不需要太多腦力也可以霹哩啪拉寫完。第二層次是了解需求及符合大架構原則下，保留基本彈性，儘量保持簡單，不要過度設計，不要讓邏輯流跟資料流整個混在一起。最後是注意語言的細節跟效能並且了解框架跟 IDE 能幫你到什麼程度。
舉 Java CRUD 例子來說，以現代 Spring Framework 的強大，如果你不是 heavy transaction type 的小系統 POC。Domain Object 設計好直接配 MongoDB 和 Rest Repository 開出去就結束了，真的是宇宙無敵快，頂多我 Cache 跟 Index 調一下補個效能 🚀
那，為什麼我還要去上課看看能夠學到什麼讓我再成長？因為我意識到我這種正面硬上的方式雖然看起來兼顧了該有的面向，但在需求的改變與團隊的協作上無法再次加快，也無法再更近一步提高效率跟降低溝通成本。更糟的是這一切都太相依那當下的 context ，無論是個人的精力，協作人員的能力，額外的需求改變等等 👀
其實我覺得這幾年的軟體從業人員越來越辛苦，五花八門的 Keyword 跟新概念需要學習。久了讓人產生一種「雖然我知道這行是要一直學，但資訊量跟變化也太大，阿姨我不想努力了」😂
「大道至簡，殊途同歸。雖然要弄的簡單有時候並不簡單，但別想太多，剛剛好才是最好」無論是 OOAD、Design Pattern、Agile、_Ops系列、_DD系列，終歸他是要讓你的專案越來越好、產品越來越棒。
那，什麼是專案越來越好、產品越來越棒？我在這邊試著以我七年又七個月的職涯不自量力的表達一下 😎。把需求真實地用例子傳遞給開發人員，使用這些例子完成可反覆驗證的測試程式碼與產品程式碼，只要你的需求對應到的例子夠真實夠完整，你完成的功能就會足夠健壯，於是便產生了價值。而因為有各種測試的保護，面對不斷迭代進化的專案與產品，這條路才能做的久走得長，也得以再反覆產生價值 ⭐️
很多人習慣寫程式需求還沒全部想清楚就上，覺得我就先偷跑嘛，時間不夠了R。結果寫出來的東西跟需求單位有著我跟金城武之間的差距，下次就說可惡你們不寫 Spec 我就不開發了，大家認 Spec。嗯嗯，一個XX各自表述的例子，各位台灣的孩子還不夠熟悉嘛。這就是所謂眼前的黑不是黑，你說的白是什麼白，惡性循環之下也只是互相消耗 Credit 而已。
建立頻繁而有效的溝通，培養信任感跟建立 Credit。如同向上管理，需求單位也不是妖魔鬼怪，好好談判，專案再急，至少一定可以分段交付。因為人都是有底限的，不會有人想看到雙輸，就算你的對口不懂這個道理，他後面總會有人懂。
所以，試著讓自己慢下來看清本質。當然我並不是說那些 Keyword 和概念不要學，有餘力能學當然很好，只是希望你能先想清楚，才不會一不小心就迷失自我。
你講的都是開發新專案，可是我都是去接人家的 Legacy Code，那個那麼髒，我好想一言不合就重寫。首先齁，你要重寫你屁股要夠大，位子要做的夠穩，不然你那個大屁股長官在你後面，他非常火。
我以前也覺得哇塞這什麼鬼東西，我重寫一定比這個好，但後來我逐漸認知到，其實在有限的時程內，這個前人也許是千百個不願意才變成這樣，如果程式碼用手寫，紙上說不定有未乾的淚痕 😝。收起我把別人當傻瓜的大前提，我不一定能做得比他更好。更重要的是，他在目前的 context 下面 working well，你貿然重寫，讓我再提醒你一次，你那個大屁股長官在你後面，他非常火。
所以更高的境界就是重構了，但重構不是說爽拉我就改 👻。是要先了解需求，實例化它們，建立測試程式碼，確認當下的 Legacy Code 歐趴，再進行紅燈綠燈重構的小步動作。步驟拆細，做好版控，紅燈停，綠燈行。
而至於細節上要怎麼做，就要依靠重構那些書所教的認出壞味道跟對應處理方法加上多多練習重構 Legacy，雖然我只做過幾遍，但每次做的想法都不同，每次都有新滋味！
其實上兩節就大概是我上 測試驅動開發與持續重構 學到的跟我自己過去的知識融合起來講了。那剩下的部份大概應該是測試驅動開發！
先寫測試！聽起來很酷！但你很快就會發現，就算我上一節那些東西我都會了，品質已經提升。但因為開發的步驟變多所以你開發的速度會下降，而且需求哪有定版的那天，萬一需求改了我測試不是要改嗎？是啊，沒錯，需求本來就可能再變動，但若是因為這樣不開始寫，連改的機會都沒有，所以才會說要頻繁溝通小步快進。而且再換句話來說，如果需求真的變動地頻繁，你沒有測試保護真的能保證你的產品程式碼活得健康嗎 🤔
所以當你撞到這個檻，要嘛克服，要嘛放棄走回老路。木桶理論告訴我們，這個桶子能裝水的高度是最短的那塊木板的高度。所以你的思維再快，如果開發的工藝水平跟不上，速度就會上不來。我特別用工藝來強調，是因為那天我敬重的前輩被問了一個問題，『 想請問極速開發是否僅是背下許多的Shortcut？』😅
如果只看表象，我相信張三豐打的太極也只是比手畫腳而已。能夠完成這整套，除了外在展現出來的招式（很多Shortcat），背後需要對Vim、JetBrains 整套 IDE、軟體開發有一定程度的理解，才能融會貫通這些內功心法，招式才有威力。於是在反覆練習跟深刻體會之後，工藝水平上升了，首先最明顯的是開發的速度會上升，手速才能跟上你的思維，達到劍及履及、劍隨意轉的境界 🗡
舉數字實例來說，我在上完 極速開發 之後，因為去教一些公司同事跟社群朋友 TDD，為了不要讓他們挫折感太大，我試著降低門檻，不教 Vim，把招式簡化成必要的 IDE Shortcut 配合必要的 Plugin，大概是四個熱鍵兩個 Plugin，Tennis Kata大概也可以來到 20 分左右，我估計再熟練一點大概 18 分沒有問題。但對比上過課的前輩，他們最快可以來到 10 分出頭，這個差異我想應該很明顯。
那你可能想說，把這種早就 set 好的套路練到這麼快有啥用？試問，你最熟悉的東西你都快不起來，未知的需求開發你要怎麼快呢？換個實例來說，我以前桌球大概是大專乙組校隊的程度，你知道桌球員除了基本功之外就是不斷的練套路練套路、打比賽打比賽。🏓 正式比賽時，那些動作意識跟肌肉反應都是平常練套路的，然後加上打比賽的實戰經驗調整變化以致勝。
好拉好拉，你真的寫得很快，那又怎樣，學這個的人一定強嗎？Umm… 是說強如武當，還不是出了個宋青書R。但無論如何，我唯一能告訴你的是，在你反覆練習跟深刻體會之後，你的工藝水平一定會上升，而且應該真如武當的功夫，後期進步的加速度應該比前期更快。
因為這個工藝並不是只有開發變快而已，TDD 跟他之後的 ATDD 帶來的優點還有更好驗證的測試規格、測試的保護、產品程式碼的精練等等。對於這個講求快速迭代的時代，這才是真正價值所在。
當然，即便 JetBrains 一定程度的提供各語言接近的開發體驗，但不同的語言可以開發的如此行雲流水又一致，這門工藝真的是讓人嘆為觀止，你如果第一次上課看他寫，一定是覺得花生蛇魔術。
以上，廢話了那麼多，不管你想不想聽，來做 Q & A 好惹
Q: 你跟武當有仇嗎，為什麼一直 Cue 武當？
A: 就剛好太極拳境界夠高夠飄渺，宋青書夠渣（武當派表示：X的
Q: 你說你只有七年七個月的職涯，這長相不像R？
A: 你們真的跟那位 CRUD 朋友一樣不會聊天捏
Q: 可不可以舉個實際的例子說明你跟金城武的差距到底多大？
A: 掰掰（丟筆
