• The Bootstrappers: Zero to MVP

  • Bolt
  • v0
  • screenshot-to-code / figma-to-code

• The Iterators: daily development

  • Cursor
  • Cline
  • Copilot
  • WindSurf

  

Senior 或 Junior 誰更能從 AI Tools 中獲益​

• Senior
  • 根據已知的知識，快速 prototype idea
  • 能夠 refine AI 產出來的 code
  • 能夠探索其他不同的解法
  • 自動化重複性的 coding tasks
• Junior
  • 接受不正確或版本不正確的解法
  • 沒有留意到安全或效能上的問題
  • 苦於 debug AI 產出來的程式
  • 做出一個自己也不了解的系統
• 正確使用 AI 的方式（難 😔）
  • 使用 AI 進行快速原型設計
  • 花時間了解產生的程式碼如何運作
  • 在使用 AI 的同時學習基本的程式設計概念
  • 逐步建立知識基礎
  • 使用 AI 作為學習工具，而不只是程式碼產生器
  • 矛盾：不要只是 accept => 但這樣我要 AI 幹嘛？

工程師會被取代嗎？​

AI 適合拿來快速做 Prototype​

AI 只能解決問題的 70% 後，接著就會撞壁​

AI 能夠以讓你驚訝的速度，幫助你解決問題中 70% 的部分，但剩下的 30% 可能會讓你非常痛苦，甚至走一步、退兩步（因為每次都有新的 bug）：

• 您嘗試修正一個小錯誤
• AI 建議一個看起來合理的變更
• 這個修正破壞了其他東西
• 您要求 AI 修復新問題
• 這又產生了兩個問題
• 不斷重複

Non-engineers using AI for coding find themselves hitting a frustrating wall.

工程師的價值反而更重要（至少以目前來說）​

真正給使用者用的產品，而非只是 Prototype​

• UX
• 留意細節
• 注重工藝

產品不是只需要程式，工程師也不只是產生程式​

• 了解需求
• 設計可以維護的系統
• 確保安全性和效能
• 處理不同 edge cases（不同 devices 上的情況）
• Maintainable：不同團隊有不同標準

AI Model目前碰到的瓶頸​

新的 Model 進步的越來越有限：

進步的速度也漸趨緩慢：

AI 對我們帶來的優勢​

• 加速我們學習、探索沒想到的想法
• 快速驗證 MVP
• 自動化 routine tasks
• 讓工程師能跟專注在「真正的」產品開發上

AI Model 未來的發展？更快？更聰明？​

• 提升反應的速度

  • 針對 LLM 特製的硬體（更快且更便宜）

• 在 LLMs 沒有更聰明的情況下，更清楚 AI 適合以及能做到的是什麼

• 越快也表示越聰明？

• Agent

  • AI Agents？
    • AI Model 目前仍無法自主完成整個任務，會需要有人協助，否則很快就會脫軌、失控

  

  • Micro Agent
    • 進行測試、編寫程式、測試

Reference​

• The 70% problem: Hard truths about AI-assisted coding
• The Big Lie AI Vendors Keep Telling You
• Is OpenAI's o1 model a breakthrough or a bust?
• Why AI Is Making Dev Skills More Valuable, Not Less

面對人、組織的問題時，想想如果這是在寫程式的話，可以怎麼處理？

拆分工作與並行​

在軟體開發中有並行（concurrency）和平行（parallel）的概念。善用這兩個可以帶來更有效率的工作表現；就像如果能妥善分派工作，將每個工作拆成相對獨立的的任務，同時交付給多個人去處理，就能夠在更短的時間內完成更多的事項。

權責與分工​

在軟體開發中有分層（layer）的概念，每個 layer 內只負責和管理好自己應該知道的事，如此可以減少程式耦合、讓程式更好維護與管理；就像組織中，並不是所有部門都需要知道所有的訊息，更有效率的做法應該是每個部門只需知道和自己相關的資訊，並把自己部門內的事項負責好後，再交派給其他部門做處理。

不變的就是總是會改變​

軟體的世界變化很快，不論是架構、框架、語言，都以非常快速的方式在成長。即時你今天真的設計出了一個完美的系統架構，它也很有可能在幾個月後，或幾年後被推翻，而且很有可能推翻的人還是你自己。因為隨著時間的改變，人的想法會改變、使用者會改變、需求會改變、能夠拿來解決問題的工具也會改變。最重要的不是想出什麼是完美的做法、而是寫出最有彈性、能夠適應未來改變的程式。

為什麼不要加班？​

我認為下面這幾種情況是「合理」加班：

• 因為自己犯錯需要彌補錯誤而加班：可能是因為理解錯需求、寫出 bug 等情況
• 因為自己能力不足而加班：這比較像是職稱和能力不太對等的情況，這時候也許會需要花時間補足自己能力不足的部分
• 不是公司要求，但想要自己花時間研究該需求到使用的技術

不加班的好處實在太多了，這些時間不論是拿來休息或進修都非常好。

平常上班的時候，腦袋都在想上班的事情，下班後有時候還沒辦法即時轉換，但一但轉換後，你會發現腦袋有很多想要完成、或想要去做的事：

• 隨時把自己準備好（找工作）：這並不是說你真的要去找工作，但你應該要有這樣的準備。軟體工作的變化很快，如果是新創的話公司有可能倒閉、經濟不好的時候有可能被裁員，隨時把自己準備好，可以讓你碰到危機的時候不那麼擔心。
• 花時間學習工作上能用到的技術
• 花時間研究自己有興趣的技術
• 當你不去做公司的事情，漸漸的你會發現有其他許多想做或該做的事冒出來...

加班是為了自己，還是為了公司？​

大部分的人可能都會覺得加班是為了公司，但我發現，我加班其實常常是為了自己，但這不是說「為了自己」而做就有多偉大。確切來說，我發現我加班常常是因為：

• 「我」害怕他人對我的評價
• 「我」害怕其他人覺得我事情做的很慢
• 「我」想要透過加班表現出自己是很負責任的人
• 「我」想要透過加班表現出自己和公司的目標一致、站在同一條線上

可以發現到，其實我加班的本意都不是為了公司，而都是為了自己，可能是減輕焦慮、可能是想塑造形象。

如果真的是為了公司好，我其實或許不應該加班。為什麼呢？因為當加班變成一種文化，漸漸的許多人會受不了而選擇離開（包括你自己）。

當加班變成一種公司文化​

這點是我覺得最可怕的，當公司原本只是幾個人加班或只是因為短期專案衝刺而加班，我覺得這都還好。

比較恐怖的是，事情明明多到只用上班時間是不可能完成的，但有些人為了準時交付任務而加班完成，但這樣的「不正常」卻慢慢變成「正常」而被拿來當作比較的基準。當不正常的加班在主管眼中變成了一種正常：「他（加班的人）都可以完成，為什麼你沒辦法？是不是你能力不足？」

為了獲得更好的績效或主管的肯定，這時候你可以選擇「一起加班」或「照著自己的步調」—— 選擇前者你會讓自己越來越辛苦，選擇後者你可以「正常」上下班，但在主管眼中，你的產出卻可能變成了「不正常」，進而得到了比較差的考績或無法獲得加薪、升遷...。

的確，你可能是為了自己而加班，你可能會想「是我自己想要加班的，其他人可以不用照著做」，但是請盡可能減少自己加班對他人造成的影響，其他人會不會因此而有非常大的壓力？如果長時間一直加班下來，你真的不會倦怠嗎？會不會最後，因為給自己的壓力太大，第一個想離開的人，反而是自己。

為了公司好，請不要讓公司走向這種不健康的職場文化。

好好利用時間，下班了，做做和工作無關的事吧！

剛剛用日常上班前挑衣服的例子和沒學過程式的 00 說明時間複雜度的概念很好理解耶～！

例子是這樣的...

一早要出門的時候，想要從衣櫃中找出紅色的上衣。

其中一種方式是像左圖一樣，這是掏寶上很熱門的「疊衣服褲子收納神器」，雖然看起來整理的很乾淨，但如果你要從中找到紅色的衣服，你就得要由上而下一件一件找，最糟的情況就是一直翻到最下面才能找到你要的紅色衣服。

另一種方式是像右圖一樣，把衣服用立起來的方式，一眼就可以看到紅色的衣服在哪，直接拿出來，幾乎不用找。

左圖的那種方式，時間複雜的就是 O(n)，n 就是衣服的件數，雖然紅色的衣服有可能就放在最上面，一眼就可以看到，但在探討時間複雜度的時候都要考慮最差的情況，所以如果你有 n 件衣服，最差的情況就是要把 n 件衣服都翻過才會找到紅色那件。

右圖的方式它的時間複雜度是 O(1)，在你沒有忘記其實衣服已經被丟到洗衣籃的前提下，你看一眼，翻都不用翻就可以把紅衣服直接取出（請先忽略掉人腦內建的視覺搜尋系統，那是另一個有趣的故事 XD）。這種不用一個一個找，就直接取出的，時間複雜度就是 O(1)。

有了這個時間複雜度的概念後，是不是覺得左邊的那個商品實用性沒這麼高啦～ XDD

但我還是附一下購物連結（誤）

真的是沒想到學演算法還可以用在購物吧！

圖片來源​

• 叠衣服裤子收纳神器
• 連日本主婦都瘋狂的「怦然心動整理法」

這次求職過程中，在和幾位不同的 Team Lead 或是 CTO 面談的過程中，真的讓我感受到多數厲害的人總是自信而謙虛的，他們不會透過問題來讓你覺得自己不懂，反倒是很 open-minded 讓你感受到雖然這個自己現在不懂，但沒關係，甚至會進一步透過提問來協助你進一步釐清自己的思路。

同樣地，我也期許對於自己的專業能夠是「自信而謙虛」的態度。

過去雖然常聽大神說，工作一陣子後，通常就不用自己找工作，而是靠別人介紹或挖角，但我可能還沒到這個階段，周圍沒什麼人介紹，更別說是挖角，所以還是只能靠自己 XDD。

下面是我這次有面試的幾間公司，主要找公司市場不侷限於台灣的公司，面試的職缺全部都是前端工程師。

Line Pay​

首先 Line Pay 和 Line Taiwan、Line Bank 雖然都隸屬於 Line 集團底下，但在台灣是三間不同的公司。Line Pay 的面試過程較嚴謹，這次從投遞履歷到最終回覆的時間約需要一個多月的時間。

Line Pay 公司的地點是在大直美福大飯店的側邊，給人非常氣派豪華的感覺。

第零關：線上測試​

給予連結，並透過線上測試的方式，題目主要是演算法的測驗，印象中是三題。

第一關：onsite-interview with Taiwan Engineer​

面試的對象是 Taiwan Line Pay 的工程師們，會針對線上測試的作答進行討論，接著會根據過去實作過的專案進行問答，並可利用白板進行概念的解釋與說明。

第二關：onsite-interview with Korean Engineer​

這關給我的經驗很特別，因為是透過視訊的方式和韓國的工程師們進行面試，原本以為會需要用英文會話，但面談現場直接就有一位中韓文的即時口譯，所以並不需要說到英文，和面試官的溝通會完全透過這位翻譯。（心裡 OS：大公司就是直接找翻譯這樣的氣派。）

第三關：onsite-interview with HR​

最後會和 HR 進行面談，除了討論期待的薪資，也會針對個人或過去的工作經驗進行暸解。據 HR 表示，目前 Line 和 Line Bank 都搬到同一棟建築物，但 Line Pay 因為剛搬到美福大飯店這邊不久，因此暫時沒有再次搬遷的打算。

最後，HR 會與你進行基本的英文會話，確認有基本英文溝通能力。

KKStream​

KKStream 則是隸屬於 KKBOX Group 的公司，做的是影音串流服務，可以想成是讓客戶能夠透過 KKStream 的服務建立 Netflix 或 MyVideo 這類影音平台。

第零關：線上測試​

給予連結，並透過線上測試的方式，題目主要是演算法的測驗。

第一關：onsite-interview with Team Lead​

完成線上測驗通過後，會有一份作業，作業內容是用 React 寫一個待有基本的 CRUD 以及搜尋功能的網站（可以簡單想成 TodoList 這類），作業需在此次面試前完成，並提交到 Github 私人的 repo。

KKStream 前端目前分成三個組別－Core Tech、BlendVision 和 Enterprise。各組各派一人前來面試，會針對作業內容進行討論，接著則根據過去開發過的專案進行討論。

第二關：onsite-interview with PM & Engineer Manager​

第一關結束後，會根據各組人數的需求將面試者配到適合的組別，也就是一開始投的組別，不見得會是最後的組別，這個部分也可以再和 HR 或 Engineer Manager 進行了解。

PM 和 Engineer Manager 比較不是針對技術的部分進行發問，而是針對過去的經驗試著了解自己是個怎麼樣的人。在這次面試中和 Engineer Manager 聊了蠻久的時間，包括帶領 Team 的方式、對於前後端的想法、測試撰寫的想法等等，覺得有非常多的收穫。

第三關：online-interview​

HR 會針對期待薪資進行了解，並試著了解自己過去的經歷。另外，會與一位主管進行面談，過程比較像是在聊天，互相分享彼此的經驗和價值觀。

OneDegree​

OneDegree 的前端工程師還有分不同 team，分別是做 2C 和 2B，這裡我是面試 2B 的團隊。OneDegree 主要是開發保險系統，讓保險公司能透過此保險系統建立保險商品，並供一般消費者能夠以網路進行線上投保。

第零關：線上測試​

給予連結，並透過線上測試的方式，題目包含演算法、React 和 Git 的問答題。

第一關：onsite-interview with Team Lead​

主要是與 Frontend Team Lead 們進行面試，一開始會先請面試者以英文自我介紹，並且透過英文進行簡短的問答，主要也是確認面試者有基本的英文能力。接著會切換回中文，同樣是根據過去做的專案進行討論，並且分享彼此對於不同技術上的想法。

第二關：onsite-interview with Taiwan Director & HR​

再來會與 OneDegree 台灣區的總監和 HR 進行面談，這次面談比較不會談到技術上的問題，比較像是互相了解彼此的聊天。

總結​

OneDegree 的回應速度還蠻快的，對於面試者來說不會有太長時間的等待。

Privé Technologies​

Privé Technologies 的 recruiter 主動聯繫，Privé Technologies 是一間立基於香港的 Fintech，工程師遍佈在世界不同的地方，目前工程師主力是在香港和台灣。

第零關：線上測試​

給予連結，並透過線上測試的方式，題目主要是前端 JavaScript / React 的測試。

第一關：online-interview with Frontend Team Lead​

透過 Online 的方式與位在香港的 Frontend Team Lead 進行面談，過程全程使用英語。主要是針對過去的專案進行提問，也有詢問到對撰寫測試的想法，並討論「怎麼樣算是好的程式碼」？

第二關：online-interview with Frontend Engineer​

一樣是透過 online 的方式進行面談，面試官是在台灣的前端工程師（很巧的是過去和他還有短期合作過相同的專案）。一開始一樣會以英文進行自我介紹和簡短的問答，確認面試者有足夠的英文會話能力。接著會切換回中文，討論「怎麼樣算是好的程式碼」、還有聊到 OOP 和 Functional Programming 適合的時機、另外則是 JavaScript 有關的題目。

另外，也有進行 online 的 coding test，內容偏向基本的演算法和邏輯實作。

第三關：online-interview with CTO​

印象沒錯的話 CTO 是澳洲人，但在香港待了蠻久的一段時間，目前和 Frontend Team Lead 一樣都在香港，他也曾在 LaLaMove 擔任過 CTO 的職位。

面試全程以英文進行，一樣會討論到「怎麼樣算是好的程式碼」，另外則是聊一些個人的經歷、和同事的相處、人格特質等等的。

總結​

Privé Technologies 是回覆相當快速的公司，收到回覆後會立即安排下一場的時間，不論是 HR、Team Lead 到 CTO 都給人很和善親切的態度，可以讓人感受到是相當尊重且重視面試者的。

慧科訊業 Wisers​

慧科是由 Headhunter 推薦，公司主要是做輿情分析的，會去爬各媒體或社群的資料、關鍵字，以此分析當前熱門的議題或輿論風向，市場主要是在中國。

第一關：online-interview​

第一關會先以線上的方式進行面談，面試官來自台灣、香港和中國。這裡我有一點小烏龍的是，收到通知的時候，看到 email 寫的是「phone interview」，誤以為是面試官會打電話來...，接著等了又等，想說時間到了怎麼都沒打電話來，後來才知道 phone interview 指的是視訊面談 XDD

面試主要問過去實作過哪些專案，有沒有處理過複雜的圖表或大量資料需要 render 的經驗，怎麼樣優化和除錯等等。

第二關：onsite-interview​

雖然說是 onsite-interview，但除了和台灣的工程師面試之外，同時也會透過視訊和香港以及中國的主管面談。中國的 Frontend 主管問了很多技術相關的問題，從 CSSOM、Web Component、micro-frontend、performance、如何避免瀏覽器被阻塞（block）都有問到。

總結​

可以感覺的出來 Frontend Team Lead 的知識深度很深，我也並沒有全部都回答得出來，但 Team Lead 人非常有耐心，就像個 mentor 一樣，會給我一些思路讓我再去思考這個問題有沒有其他的可能性或答案，面試完後真的有一點「如沐春風」的感覺不誇張 XD。

常見問題​

如果需要準備英文面試的話，也很推薦 Coursera 上這堂免費的課程 English for Career Development，若時間不夠的話，也可以根據自己的需要，直接跳著進度看，不一定要從頭開始慢慢看。

從技術面來說，JavaScript 面試的內容除了可以參考很久以前整理過的「JavaScript: Understanding the Weird Part（JavaScript 全攻略：克服 JS 的奇怪部分）」筆記之外，網路上也可以搜尋到非常非常多；React 的話，基本的官方文件一定要看過。

有些東西雖然每天都在用，但若沒準備一時被問到的話，還是可能會沒辦法很快速且順暢的解釋出來。例如，請你解釋 event loop 是什麼。

在上述的面試中，撇除技術問題外，有一些共同常被問的，像是：

• 自我介紹
• 為什麼離開前一份工作
• 上一份工作中覺得最困難或最具挑戰的是什麼？
• 想像未來三年後你預期自己會是個什麼樣的人？
• 有什麼問題要問我的嗎？

另外，也可以參考這部 3 分鐘的影片，裡面許多題目大家一定都聽過，但還是可以稍微想一下怎麼回答：

這次很幸運有機會能夠擔任 ALPHA Camp 與天下雜誌合作舉辦的實體／線上活動，也是我自己第一次擔任活動主持人。

從小，我家就非常多與天下相關的雜誌，不論是天下、康健、Cheers 都有，因為我爸媽算是很早期的訂戶，所以一開始收到 ALPHA Camp 詢問能否的擔任活動主持人時，我內心是有些興奮的，是一種竟然可以有機會進到從小就一直在接觸的媒體的雀躍感，而且天下雜誌多數時候也給我相當正面的感受，算是台灣媒體界的清流之一。

除了天下雜誌相當知名的媒體之外，我也很好奇工程師在當今的媒體產業中究竟扮演了什麼角色。主力是在開發「內容管理系統」？或多在進行資料視覺化的專案？

在這次的活動中很幸運能夠聽到已經在天下雜誌 10 多年的資深產品經理－紹謙，和數位轉型過程中加入團隊，負責從專案發想到實際落地的資深工程經理－世彥，一起來聽他們分享天下雜誌的數位轉型。

數位轉型是什麼？​

在聽演講前，其實我完全不知道「數位轉型」究竟是怎麼一回事，我單純地以為就是把紙本書變成電子書，或是推出幾個 App 後，就算是完成了數位轉型？

數位轉型不是事件的完成，而是持續且沒有終點的歷程​

然而，在聽完兩位講者的分享後，我深切感受到數位轉型絕對不是「做完了 OO」就叫完成了數位轉型這麼簡單，並非把紙本雜誌電子化、推出幾個手機 App、開發幾個 Web 專案就叫完成了數位轉型。數位轉型的過程相當複雜，牽涉到的不只是使用到的技術、文章撰寫的工具、還包括整個組織架構的調整。

不是完成了某幾個「事件」就叫數位轉型，數位轉型是持續且沒有終點的「歷程」

最早天下雜誌完全是紙本作業、編輯是以寫稿紙作業。過去上稿流程是先有紙本文章然後把文章變成電子檔後放在網路上，現在則轉變成線上文章先推出後，才有實際紙本內容；過去團隊中大部分都是編輯，現在則多了產品經理、軟體工程師、數據分析師等各種角色加入團隊；過去沒辦法從使用者的操作中取得大量的資料，現在則可以透過使用者使用 App 或閱讀文章等資料作為反饋，來協助指導後續的決策和產品修正。

數位轉型是不怕面對改變，敢於挑戰不熟悉的事物​

如果要我說數位轉型是什麼？我認爲就是不怕潮流的變化，努力學習讓自己能夠跟上最新的事物，不怕面對自己不熟悉的事物，願意不斷嘗試與接受挑戰。這就好像一個永遠不會老的人，不斷地透過新陳代謝讓自己的身體和腦袋維持在年輕的狀態。

天下雜誌並沒有在完成了雜誌電子化，推出手機 App、建立網路內容平台後，就因為覺得「完成了數位轉型」而停下來。在近年 Youtube 的普遍和 Podcast 的竄起，天下雜誌也都沒有缺席，推出了 Youtube 頻道和 Podcast 節目，繼續跟著數位的潮流前進。因為數位轉型是一種不怕面對改變，敢於挑戰不熟悉事物的精神，因此它是沒有什麼叫做「已經完成的」。

有價值的工程師​

在這場活動中，兩位講者也分享到他們認為什麼樣的工程師是有價值的。

先釐清問題，再提出更多可能的解決方式​

其中一點是當 PM 提出一個需求（或功能）時，好的工程師會試著向 PM 去了解這個需求（或功能）是想要解決什麼問題，先把實際想要解決的問題釐清，接著再和 PM 討論如果是想要解決這個問題的話，有哪些可行的做法，因為 PM 一開始提的功能或許只是其中一種解決方式，但工程師在釐清問題後，會多了工程面可行性的評估，進而有機會提出不同的解決方式供 PM 參考與選擇。

對於開發的產品有 Ownership​

另外一個特質則是對產品有強烈的 Ownership，工程師不單純只是把 PM 所交付的功能完成，同時他也喜歡自己完成的產品、會好奇使用者使用時的體驗、會去思考怎麼樣能把這個產品做得更好。

不怕面對改變，勇於嘗試新事物、敢於挑戰自己的態度​

作為軟體工程師，總是有新的技術、沒用過的工具、沒聽過的詞彙，但許多時候我也會怠惰，覺得學新的好累、現有的東西就夠用了吧？聽完這場活動後，我最大的反思在於，我想有價值的工程師絕對不止是學會了某些技術或工具後，就成為了一個優秀的工程師，反倒是一種態度或精神－一種不怕面對改變，勇於嘗試新事物的精神；一種不怕碰到沒解過的問題，敢於挑戰自己的態度，而這點也正好呼應了這場活動談到的「數位轉型」。

總結​

很開心初次主持活動就能和天下雜誌合作，而且又能夠聽到兩位非常有經驗的產品經理與工程經理進行分享。

當主持人意外拿到了一本天下雜誌創刊號的復刻版

由於自己沒有真的很理解過敏捷開發或 Scrum 到底是怎麼一回事，但公司的新專案又開始想要嘗試用這種方式來做 MVP，基於凡事問網友的心態，在 ALPHACamp 社群以及 Twitter 上得到了很多有價值的回饋，很感謝大家分享意見讓我知道。

我的問題大概是這樣的：

「想要請問大家所謂的敏捷開發？ 團隊認為敏捷開發就是要快，不用管太多細節，先推出去收到市場回饋再來修改。但很多工程面的東西像是 DB 的設計，API 的規格的改動，添加幾個欄位還好，但若是動到比較大的架構改起來都很痛。 是真的想要了解大家在碰到這種情況是怎麼處理？因為我沒有深入理解過敏捷開發，不清楚在實際執行上的細節，只知道每次都說就是要快，先不考慮其他情況。

是不是我們沒有掌握到敏捷開發的核心？還是具體來說有那些東西是可以很「敏捷」？哪些東西不適合嗎？ 先謝謝有經驗到大家」

下面則整理大家的想法和意見。

敏捷的重點在於快速應對市場需求變化的能力​

首先，敏捷的重點在於快速應對市場需求變化的能力，同時也驗證自己對於產品能否達到市場需求的概念（Proof of Concept, POC），減少過多的時間或人力成本在開發某個專案，做到非常完整，但推出去之後才被市場打臉。

這裡直接 quote Jack Sung 所說的：

Jack Sung：「敏捷開發並不是短期的速度快，畢竟開發還是需要跑完基本的流程，而是面對市場變化的反應速度比起瀑布流還快，就像 POC(Proof of Concept)，敏捷開發是更務實的去驗證想法，而非一個美好的想像去花費很高的時間跟成本去開發一個未經驗證的產品，等到真的推上線才被市場賞兩巴掌。」

敏捷的目的是要提早發現問題：對象是市場而非開發團隊​

之所以要敏捷是因為市場的變化太快速，因此當有產品沒有收到預期的回饋時，適時且立即的停止、停損或轉換方向是敏捷的重點與核心。

然而，這並不表示要壓縮開發時程或開發品質，如同 Yan 所說的，整個開發流程應該還是嚴謹可靠的，而不是隨便快就好的。

Yan：「敏捷開發不單單是針對開發團隊而是整個軟體工程，從訪談>需求>規格>設計>開發>測試>發布，整個流程應該還是嚴謹的，只是它縮小整個目標進行對目標進行快速迭代，中途有錯應該立即修改或終止，這是 scrum 所謂的「快速試錯」，而已經成型產品遇到要整個砍掉重來，長遠來說如果是必要，我也認同需要去做，根據我的經驗以開發來說敏捷並不會減少「開發時間」。」

敏捷開發不會比較快速：敏捷 != 快​

如同上面所述，敏捷的重點是為了因應市場的快速變化，避免到後來才發現一場空。但這個敏捷並不是快的意思，該有的開發流程還是不能省，Rafeni 分享的這張圖我覺得很到位：

這裡直接引用 ALPHACamp 助教 Yan 所說：

Yan：「目標是造車，縮小目標往往會被誤認為先造輪子，但其實應該是「可用的」滑板車，因為只造輪子根本收不到市場/客戶回饋，根本無法知道產品方向對不對；壓縮開發時間＝壓縮開發品質，各種開發模式都是透過流程改善來減少時間成本，而非去壓榨單位去達到節省目的。」

每次開發出來的「可用的產品」，到底是要驗證什麼概念，是否能實際收到市場的回饋都是要考慮的問題。至於給人使用的「產品」和有功能就好的「東西」之間的界線要如何定義，又是另一門藝術了。

盡可能在開發時做到解耦、模組化​

據 Jack Sung 所說，一般來說走敏捷開發對工程團隊來講是痛苦的，太多東西是無法預期或事先規劃的，因此打掉重練是常有的事，能做的是盡可能在開發時做到解耦、模組化，以減少這個痛。

畢竟以上圖來說，腳踏車和滑板車已經是完全不同的概念了，要做到擴充性和預留彈性幾乎就是不可能的事，所以要認知到打掉重練可能是必經的過程。

打掉重練是常有的事，但 ⋯ 再想想 ⋯​

雖然說打掉重練可能是常有的事，但如果總是在經歷「整個」打掉重練，而不是部分功能或模組打掉，或是整個系統架構的調整，這時候就需要再多想想了。

如同前幾個段落中的金字塔圖（MVP）所示，在敏捷開發中並非省略掉開發流程來達到敏捷。Rafeni 提到，不應該打著敏捷開發就跳過了規劃、跳過了去思考產品是設計給誰用的、是要幫誰解決問題。 Jacob 則提到，PM 和 RD 溝通不良，或當問題都沒有先想清楚就馬上進到開發，產品設計沒有做好使用者研究時，常常才是導致架構需要不斷大改。

Rafeni：「因為起點對了，過程與終點才可能對。否則錯誤的流程也是會導致錯誤的結果的。」

也就是說，如果你覺得常常是整個系統在進行大架構的改動，甚至是經常感受到隕石擊落般的痛快時，那麼不要乖乖的抱著「打掉重練是正常的想法」，而是需要好好的再想想。

參考資料​

• ALPHACamp 社群
• Twitter 網友
• Top 5 Misconceptions About Building A Minimum Viable Product @ medium

過去的「未整理筆記」一直是使用 hexo 建置的，hexo 用起來其實非常方便，$ hexo generate -d 基本上就搞定了。大概在去年（2020）年中時接觸到 docusaurus 這套由 Facebook 推出的 docs + blogs 的工具，雖然目前還在 alpha.70 階段，但一用就非常吸引我。

Docusaurus v2 對於 markdown 有高度的支援，除了基本的程式碼高亮外，還可以哪些選擇行號要特別標註。下面列出幾點 docusaurus 特別吸引我的地方：

• 程式碼高亮更方便，可以顯示檔名、標註特定行號
• 和 React 無痛整合，可以用 React 撰寫獨立的頁面，也可以把 React Component 直接透過 mdx 插入文件中
• 可以在 md 中插入 live editor 的功能
• 開源專案可以免費使用 algolia search
• 內建深色和淺色主題
• 部署上很方便，且整合 Github Action 可以自動 CD
• 小恐龍很可愛
• ...

雖然有很多文章需要慢慢搬過來，但好險這些文章本來就都是 markdown，要改動的幅度不算太大，這也是我為什麼一直覺得筆記一定要用 #markdown 寫（搭配 Typora 👍），不要太倚賴其他第三方筆記軟體，因為搬家時會方便許多。

但因為 docusaurus 和 hexo 的 front matter 不太一樣，所以還是要簡單調整一下。