只聘請願意寫單元測試的軟體工程師

Jan. 30 17:48~19:00

▲古早味的VB程式

一個測試，各自表述

一位從事測試工作的朋友告訴Teddy，他在應徵工作時主管告訴他，公司的工程師都有做單元測試。到職之後，有一天朋友去找工程師…

朋友：我可以看一下你寫的單元測試程式嗎？

工程師：什麼程式？

朋友：單元測試程式，主管說你們都有做單元測試。

工程師：喔，單元測試喔。有啊，不過我們都是手動測試，自己手動測自己寫的function。

朋友：（黑人問號？？？）

***

自動化

單元測試是指對程式可執行的最小單位（單元）進行測試，可能是function或是object。一般而言單元測試如果沒有特別強調，預設狀況下應該會認為是自動化單元測試，也就是透過單元測試程式碼（unit testing code）去測試生產程式碼（production code）。

Teddy剛開始寫第一個自動化單元測試是N年前還在用VB 6.0開發Windows軟體的時候。寫過VB（非現在的VB.NET）程式的鄉民都知道，VB的程式邏輯很容易和UI元件產生緊密耦合，必須透過使用者介面來測試系統功能。Teddy從台北工專電子科畢業，然後當兵，到退伍，寫了好幾年的VB程式，獨自開發7~8個不同的系統。

一開始也都是自己手動測試系統功能，但是時間久了之後覺得好累，因為手動的「廻歸測試」簡直不是人幹的工作，太花時間、累人又無聊。但是如果不手動「廻歸測試」，什麼時候修改功能造成bug又不知道。等到客戶踩到雷回報錯誤，又有漫長的除錯工作和加不完的班，也是很討厭。

後來JUnit被發明且流行之後，Teddy才知道原來有自動化單元測試這種東西。可惜當時沒有免費的VB Unit工具，從網路上花了幾十塊美元買了一個VB Unit工具，正要興高采烈的寫單元測試時，才發現寸步難行。因為VB程式的邏輯很容易全部都寫在使用者介面中，根本無法單獨測試邏輯。

***

相依性分離

後來才知道原來VB可以寫OCX與DLL元件，沒有使用者介面的程式邏輯可以寫在Class裡面包成DLL（VB 6也有Class，支援介面繼承但不支援實作繼承）。把程式邏輯從UI元件抽離，改放到DLL之後，便可以對DLL寫自動化單元測試。

有了這次經驗，開始愛上單元測試。雖然自動化單元測試不能完全取代透過使用者介面執行的驗收測試，但可以大幅減少手動測試的數量，而且當單元測試案例執行失敗時，也可以減少除錯的時間。

另外還有一個好處，就是為了提高自動化測試的程度，程式的模組化也提升。以前Teddy很瞧不起VB 6，認為它不是一個「完整的物件導向語言」（因為不支援實作繼承）。但後來又讀了〈Design Patters〉，才知道原來應該多用物件聚合少用實作繼承。VB 6也可以寫出很棒的物件導向程式以及套用設計模式。

***

今天暫時停止

近20年後的今天，在台灣會寫單元測試的工程師已經很多了……才怪。和20年前相比的確是變多了，但是以全體程式開發人員當分母來看，工作上把「撰寫單元測試當作軟體開發不可分割的一部分」的工程師還是少數。這種狀況不知道是要歸咎於台灣的資訊教育有待加強，還是職場的大環境不支持。

一個沒有自動化單元測試的團隊，手邊的軟體不是「軟體」，而是「硬體」，硬梆梆的沒人想改也不敢改。這種情況還學人家談什麼敏捷開發、擁抱改變，早點洗洗睡吧。

***

軟體工程師要提升自己的價值，除了學好物件導向技術以外，最立竿見影的方法，就是開始寫自動化單元測試。

***

友藏內心獨白：一試成主顧。

流程權威

Jan. 29 21:28~22:31

▲起床了

問題

上周末在泰迪軟體上【Scrum敏捷方法實作班】，休息時間有一位學員問Teddy…

學員：《Essential Scrum》書中提到Scrum Master的責任，其中有一點是「流程權威（Process Authority）」。請問我要怎麼讓自己變成流程權威？

***

狹義來說

Scrum Master協助團隊、Product Owner、與公司獲得Scrum的好處（請參考〈Scrum Master 的存在〉） 。因此Scrum Master對於Scrum框架與價值、原則、實務做法等，都必須要非常熟悉。

換句話說，Scrum Master必須是敏捷專家。這一點聽起來好像很簡單，但Teddy遇過很多Scrum Master，即使已經上過CSM、CSPO的課程，但對於基本的敏捷精神與Scrum框架還是一知半解。

舉幾個例子：

• 只有Product Owner能撰寫user story。
• 只有在review meeting時可以review做完的user story。
• Sprint長度越短越敏捷，所以團隊不管怎樣就是要採用一周一個sprint。
• 在Review meeting討論流程改善，在retrospective meeting討論需求。
• 把cross-functional與multi-skills搞混。
• 把actively doing nothing搞成passively doing nothing。
• 這個sprint兩個禮拜功能做不完，所以動態調整把sprint改成三周。
• Sprint review只管完成user story的個數，忽略交付給使用者的價值。

***

廣義來說

Teddy認為敏捷開發的各個派別，XP、Scrum也好，精實開發、看板方法也罷，只是不同人對於追求 「The timeless way of software development（軟體開發的永恆之道）」所提出來的見解。

「能量不滅」，傳統軟體工程所探討的問題，敏捷開發幾乎都會碰到，只是敏捷開發採取的應對策略可能有所不同，但要解決的共同大問題就是那一個。所以要成為流程權威，就必須知道軟體工程所探討的問題，然後回頭對應敏捷方法如何處理這些問題。

最好有自己參與過軟體開發的經驗，包含專案與產品開發，與不同程度與背景的人合作，越多樣性越好。親身體驗軟體開發的各種forces（作用力、限制條件），越能夠感受軟體開發的Quality Without A Name（無名的特質）。

***

誰適合當Scrum Master

經常有朋友問Teddy：「哪種人適合當Scrum Master？」依據《Essential Scrum》的看法，Scrum Master必須是：

• Coach
• Servant leader
• Process authoring
• Interference shield
• Impediment Remover
• Change Agent

以上任何一點只要做到極致，就已經是該領域的專家了。而Scrum Master居然要同時精通「武當六絕」，這根本需要百年難得一見的練武奇才方能達成使命。難怪有一位HR曾經跟Teddy開玩笑說：「找Scrum Master好像在找聖人一樣」。

誰適合當Scrum Master？不同背景的人，只要具備上述能力其一，就有機會擔任Scrum Master。Scrum Master也是人，也需要持續學習。如果是coach背景的人當任Scrum Master，也許對於軟體開發流程不熟，就需要補足這方面的能力。如果是老闆的兒子或女兒當任Scrum Master，應該在阻礙排除、干擾屏蔽與變革代理有很大的貢獻，但其他責任可能就需要補強。

總之，將相本無種，人類當自強。

***

友藏內心獨白：把自已當成一座橋梁，理論與實務的橋樑。

Product Owner的怨念

Jan. 29 10:22~11:48

▲排除阻礙可以改善開發進度

價值驅動

在Scrum框架中，Product Owner的主要責任是負責產品的投資報酬率（ROI），換句話說要釐清對使用者有價值並且能為公司帶來收入的需求，並依據需求的價值安排施工順序。

但是，「使用者價值」是很抽象的概念。幸運的話，等產品上市之後，從銷售量與使用者回饋得以驗證。不幸的話，產品釋出乏人問津，怎麼死的都不知道。

***

PO心中的痛

既然價值不好控制也不易評估，許多Product Owner便將眼光放在「進度控管」上面，畢竟產品的釋出進度也是Product Owner需要負責的部分。Teddy認識的Product Owner，10個裡面有11個或多或少都覺得開發團隊進度太慢。Product Owner經常公開或私下抱怨：

為什麼這個sprint只拿那麼少量的user story？

每個sprint承諾的user story為什麼總是做不完？

承諾的user story做不完為什麼沒有「自願加班」把它做完？

***

為什麼快不了？

「預估進度與實際進度不符」是軟體開發經常面對的問題。根據字面上的意思，「預估」原本就包含「猜測」與「誤差」的涵義，而「實際進度」總是要等做出來之後才曉得。所以「預估進度與實際進度不符」實屬正常現象，請安心服用。

但是，身為Product Owner還是要為產品的整體進度跟老闆或客戶交代，因此無法容忍實際進度跟「Product Owner腦袋中的進度」相差太大。如同Teddy常說的，Scrum只是一面照妖鏡。Scrum跑的好，可以反映出個人、團隊與組織的現況。如果Product Owner覺得團隊進度太慢，應該與團隊一起探討關於進度認知落差的原因，例如：

不熟悉Scrum：剛開始接觸Scrum的團隊，前半年可能都還在熟悉Scrum與敏捷開發的思維與團隊合作模式，因此開發進度會比較慢。

團隊的真實進度就是如此：以前隱瞞現實狀況才讓進度看起來符合預期，例如：犧牲品質、功能沒有做完但卻宣稱已完成，反正有問題等QA測試再來除錯就好了。現在跑Scrum，透明性增加，只是反應出團隊的真實狀況而已。

需求的不確定性高：需求的不確定性高，或是Product Owner與開發團隊缺少問題領域的專業知識，導致邊開發邊釐清需求，以及增加重工（rework）的時間。

技術的不確定性高：開發過程採用太多新技術，因此團隊成員需要花很多時間去學習與熟悉這些技術。加上新技術通常不太穩定，學習資源也比較少，因此增加團隊的學習曲線。例如，採用新的JavaScript框架、新的程式語言、新的軟體架構、新開發環境或建構工具。

多工與中斷太多：除了開發工作，團隊經常被中斷處理其他產品或專案的維護或救火工作。這可能代表以前開發的品質太差，現在回過頭來「討債」。或是每個人負責的工作太多，多工切換導致浪費，雖然每個人看起來很忙，但真正花在工作上的時間反而很有限。

外部相依性高：開發的產品有很多外部相依性，例如需要與協力廠商配合，或是開發軟體相依於公司其他部門的韌體與硬體。無法有效管理外部相依性，因而影響到產品開發的進度。

開發環境與設備太爛：有些公司業務團隊就在開發團隊的隔壁，業務與客戶講話自然音量比較大，干擾了開發團隊的思緒。另外，開發設備太爛也會嚴重影響開發進度，例如開發電腦太慢、記憶體太小、沒有雙螢幕、鍵盤太難打、持續整合伺服器跑太慢、測試設備不足等，都會影響開發進度。

開發人員不適任：進度太慢當然也可能是開發人員本身的問題，可能能力不符合團隊的期望，而且一直無法有效提升自己的能力。或是有些團隊成員立志當米蟲，能撈就撈、能混就混。也有些人比較適合傳統瀑布式專案，一個口令一個動作，不習慣Scrum團隊的自組織模式，因此表現不佳。遇到這種情況，就不需要客氣，該換人時就需要換人。

***

對症下藥

沒有Product Owner會嫌自己團隊開發太快，只會覺得可以再快一點嗎。但Scrum的目的原本就不是快，而是讓公司可以在快速變動的環境之下保持成功。Scrum跑的好，首先可以反應出團隊現況的生產力。不管有多慢，很抱歉你的團隊就是這樣，除非你有能力可以換一個你覺得更棒的團隊，否則請先接受這個事實。

接下來才能夠靜下心思考，如何讓你手邊這個由派大星、海綿寶寶、天線寶寶與珊迪所組成的團隊，可以在兼顧需求交付的前提下，透過迭代與增量的方式，逐次提升團隊所能交付的價值。

這並不一定代表團隊馬上就具備越開發越快的能力，也有可能是Product Owner更能判斷客戶所需要的價值，因此開發越少的功能就能夠具備足夠的產品競爭力。也有可能是改善價值鏈的瓶頸，使得工作流動更順暢，減少交期（lead time）。當然團隊成員的投入程度、溝通與解決問題能力的提升，也是提升交付速度與價值的重要因素。

***

友藏內心獨白：敏捷就是最大化未完成工作的藝術。

台北101蘋果直營店送修MBP

Jan. 28 17:06~18:15

電池膨脹

▼Teddy有一台2016年購買的MBP 15”，平常當作桌機使用，附加功能就是Eiffel與Ada的熱墊。

去年12月初，無意中發現MBP的螢幕無法蓋起來，仔細一看才發現應該是電池膨脹。聯絡Apple 線上客服，把照片傳給客服人員，對方也覺得是電池膨脹，請我不要再使用電腦，趕快送修。

研究了一下網路上的資料，打算預約台北101蘋果直營店送修，但刷了好久的網頁全部時段都是預約額滿，根本無法松修。退而求其次找台北車站的Studio A，也是預約額滿。後來12月中出國，就拖到今年才處理。

***

僥倖預約成功

回國後又忙了一陣子，眼看MBP「大肚便便」，深怕有一天電池爆漿，要是把整台筆電都弄壞就慘了。最後放棄送修台北101蘋果直營店的想法，預約了德宜台大店，雖然網路上似乎風評不佳，但只有這間離Teddy家還算近的蘋果授權維修店還有預約的名額。

但是，有一天晚上失眠，1點多左右突然看到台北101蘋果直營店有一個送修時段。預約成功的當下，感動到快哭出來，比中了200元發票還高興XD。

***

送修

1月24下午提早一個小時出門，沒想到塞車加上找停車位，最後趕在3:11分才到達蘋果門市。現場狀況就跟網路上描述的一樣，人很多，標示不清。更精確地講，沒有任何標示。據鄉民表示送修要在一根大柱子旁排隊，走到大柱子旁抓了一位穿黑色外套紅色T恤的店員，確認這裡是送修的排隊隊伍。之後就等待蘋果的維修人員有空時會來找你確認資料。

等了不到10分鐘，就輪到Teddy。確認預約資料後，被帶到大桌上等待維修人員。

▼2~3分鐘後維修人員來，Teddy告知MBP疑似電池膨脹。維修人員看了一眼馬上就確認，真的是膨脹XD。二話不說開了維修單，做了基本的硬體檢查之後，告知Teddy換電池連同鍵盤與觸控板會一起換掉。因為Teddy有購買蘋果的延長維修服務，MBP用了兩年還在保固期內，所以不需付費。

送修過程還算順利，下午3:30我就離開蘋果門市，整個過程約20分鐘。

以下是維修費用，如果沒有保固要自負15,514元（未稅）。當初購賣AppleCare花了11,334元（未稅），算是有賺回來XD。

***

維修完成

Teddy要維修的零件有庫存，預計3~5天可完成。1月24下午送修之後，隔天1/25晚上7點就收到維修完成的通知。但26、27日Teddy剛好要上課，等到今天才去取件。

取件的過程一樣不知道要去哪裡排隊，問了店員，原來就在送修隊伍的右手邊走道。核對證件之後，很快拿到筆電。確認可以開機，看起來沒什麼問題就走人了。

***

後記

蘋果直營店的店員很客氣，但不知道為什麼，透著一種刻意想要營造某種氛圍的感覺，不知道用什麼言語形容（Quality Without A Name…XD）。

可能是電池膨脹的問題比較沒爭議，所以送修過程很順利。但前提是，你必須能夠預約到蘋果直營店…Orz。

***

友藏內心獨白：新的iMac什麼時候才要上市啊（敲碗）。

Product Owner 的存在

Jan. 15 12:48~14:33

▲擁有就要負責，不要製造流浪產品。

作為解決方案

Product Owner（產品擁有者、產品負責人）這個角色接近傳統專案的產品經理或專案經理，雖然傳統專案沒有這個角色，但Product Owner目的與責任並不難理解。畢竟不管瀑布式專案或敏捷專案，總是要有人來管理需求與規劃產品藍圖，

依據中文版Scrum Guide對於Product Owner的說明：

由此可看出Product Owner藉由管理Product Backlog將產品價值最大化，其他文字敘述則是進一步解釋Product Owner這個角色如何達到此目的常見做法，也就是對Product Owner這個解決方案的詳細說明。

***

解決什麼問題

如果Product Owner是一種解決方案（Solution），請問他要解決的問題是什麼？

從Scrum Guide的敘述，Product Owner要解決的問題有三種可能的表達方式：

Problem 1：如何最大化產品價值？

Problem 2：如何管理Product Backlog？

Problem 3：如何管理Product Backlog以最大化產品價值？

Solution：指派一位Product Owner來負責。

***

Product Owner Pattern對於Product Owner的描敘則是：

One person needs to be responsible for the Product Backlog. This person needs deep domain knowledge, business insight, understanding of product technology, technical dependencies, and the authority to force rank the backlog to maximize business value.

（一個人需要負責產品Backlog。 此人需要深入的領域知識、商業洞察力、對產品技術的理解、技術相依性，以及排序代辦事項以最大化商業價值的權限。）

依據Product Owner Pattern的描述，可以將Product Owner要解決的問題寫成：

Problem：如何管理Product Backlog？

Solution：指派一位Product Owner來負責。

***

Product Owner的難題

指派一個人當任Product Owner，透過排序product backlog item （產品待辦事項）來最大化產品的商業價值，即時且持續的交付高價值的產品給客戶，聽起來是多麼理想與合理的一件事。但實務上，好的Product Owner也是很難找。

Product Owner經常遇到以下難題：

• 未被授權：既然Product Owner「擁有產品」，就應該被公司充分授權，才能夠對產品的成敗負責。但實務上，Teddy遇到不少「有名無實」的Product Owner，只是老闆的代理人，大部分團隊提出的問題都無法當場回覆而必須回頭問老闆。遺憾的是，老闆又很忙，無法及時與Product Owner討論，導致整個團隊溝通非常不順，也很容易造成大量的重工（等產品做好之後老闆看到才說這不是他要的）。
• 沒有主見，不願承擔：也有不少Product Owner雖然獲得公司充分授權，但他卻不敢也不想承擔「做決策」的風險。這種Product Owner的口頭禪就是：「由團隊決定、都可以、這個需要再研究。」甚至把做決定的工作「外包」給其他單位，以便到時候萬一產品失敗，可以有人一起承擔「歷史共業」。

　沒有主見或不願承擔，也有可能代表Product Owner　對於產品領域知識不足，也缺乏產品的熱忱。

• 進度壓力無處發洩：依據Scrum框架，Product Owner決定What（做什麼），開發團隊決定How（怎麼做、做多久）。換句話說，完成每一個功能所需的時間是由開發團隊所決定，Product Owner必須尊重。

在傳統的專案開發中，如果產品經理或主管對於開發團隊的進度不滿意，大體脫不了痛罵一頓與祭出激勵手段（棍子與胡蘿蔔策略），最後再要求員工 強迫 自願加班。但採行Scrum之後，Product Owner突然失去「自願加班」這個萬用工具，當他覺得進度落後時，自然會產生焦慮感，然後將此種壓力用明示或暗示的方法轉嫁到開發團隊身上。久而久之Product Owner與開發團隊彼此看不順眼，互相抱怨。

***

熱情與看法

Teddy始終相信，如果你對於產品沒有熱情，就不要擔任該產品的Product Owner。就好像如果你不喜歡貓，就不要貿然的學人家養貓。你可以養狗、養鳥、養烏龜、養兔子、養小孩，甚至什麼都不養。

有熱情，才會想方設法把產品做好。熱情可能來自先天對於產品的喜愛，例如有些人天生就熱愛玩Game。熱情也可能來自後天的訓練，例如你原本不喜歡玩Game，但為了生活從事遊戲開發若干年後，慢慢地愛上玩Game。

對事情有熱情，就會慢慢培養出「職業達人」的堅持。自己對於產品有看法，才不會人云亦云，做出有特色的產品。

***

友藏內心獨白：不要製造流浪產品。

Scrum Master 的存在

Jan. 14 10:52~12:48

▲泰國清萊的白廟，過橋後到達天堂不可走回頭路

作為解決方案

對於初次接觸Scrum的朋友，Scrum Master這個角色是一個不容易理解的存在。依據中文版Scrum Guide對於Scrum Master的說明：

由此可看出Scrum Master負責推廣與支持Scrum。其他部分的文字敘述都是在進一步解釋Scrum Master這個角色如何達到「推廣與支持Scrum」的細部做法，包含Scrum Guide文件後續提到Scrum Master分別對於Product Owner、開發團隊與組織所提供的各種服務都是針對Scrum Master這個解決方案的描述。

作為一種解決方案，接觸過Scrum的鄉民多多少少可以講出Scrum Master是：

• 牧羊犬，保護開發團隊不受大野狼（外部因素）干擾
• 流程專家
• 敏捷教練
• 敏捷轉型引導者
• 僕人式領導

***

解決什麼問題

如果Scrum Master是一種解決方案（Solution），請問他要解決的問題是什麼？

從Scrum Guide的敘述，可以將Scrum Master要解決的問題寫成：

Problem：如何推廣與支持Scrum？

Solution：指派一位Scrum Master來負責。

***

在ScrumMaster Pattern中針對Scrum Master的解決的問題有一個較精確地描述:
Development Teams, Product Owners, and organizations cannot get the benefits of Scrum without deep understanding and application of its principles and values.

（如果沒有深入理解和應用其原則和價值觀，開發團隊、產品擁有者和組織就無法獲得Scrum的好處。）

依據ScrumMaster Pattern的描述，可以將Scrum Master要解決的問題寫成：

Problem：如何讓開發團隊、產品擁有者和組織獲得Scrum的好處？

Solution：指派一位Scrum Master來負責。

***

是否需要專職的Scrum Master

在台灣，Teddy遇到不少剛導入Scrum的團隊面臨到沒有專職Scrum Master的困境。其原因不外乎人手不夠、老闆不同意有一個專職的人每天無所事事不用寫程式，只負責「流程改善」這種虛無飄渺的工作。

依據Scrum框架，每個Scrum團隊都需要一位專職的Scrum Master。理由之前已經說明過了，就是「要讓開發團隊、產品擁有者、組織獲得Scrum的好處」。

如果你的團隊不需要Scrum Master也可以「獲得Scrum的好處」，那當然可以不需要這個專職的角色，畢竟Scrum Master只是「如何讓要讓開發團隊、產品擁有者、組織獲得Scrum好處？」這個問題的一種解決方案，團隊可以自行探索其他可能的解決方案。

《金剛經》中講過：「汝等比丘，知我說法，如筏喻者，法尚應舍，何況非法。」Scrum Master只是幫助團隊到達敏捷彼岸的一種媒介，正所謂「過河拆橋」，到達彼岸之後橋就用不到了，可以把Scrum Master丟掉XD。

但是，就是因為產品擁有者、開發團隊與組織都不懂Scrum，尚未獲得Scrum的好處，才需要「導入Scrum」。既然決定要導入Scrum，安排合適的專職Scrum Master，減少敏捷轉型過程的碰撞並提高成功機會，這一點點的投資也是很合理的。

***

友藏內心獨白：不要落入「省小錢、花大錢」的陷阱。

我想用Scala

Jan. 11 8:34~9:21

數年前Teddy帶幾個學弟開發一個系統，討論完需求後，學弟A建議採用Scala語言。

雖然Scala同時具備物件導向語言與函數導向語言的優點，但在當時Scala還是一個相當新的語言，採用的專案不多，會的人更少。Teddy擔心除了學弟A以外，Teddy自己與其他團隊成員還需要時間學習Scala，可能會模糊專案目標並且影響開發時程。另外，萬一學弟們畢業後，日後系統維護找不到懂Scala的人也是一個問題。再加上使用新語言雖然很酷，但新語言通常有很多「雷」等著不怕死的人去清除。為了 怕麻煩 降低專案風險，於是Teddy建議學弟還是保守一點，用實驗室最熟悉的Java語言來開發這個系統。

多年後函數語言已融入主流的物件導向語言之中，物件與函數的「混搭風」成為主流的開發模式。不知怎麼的幾天前突然想起多年前的這個故事，驚覺到隨著年齡增長，年輕時的冒險犯難精神不知道消失到哪裡了。

年輕時剛出社會寫程式，剛好趕上第一波網際網路大爆發時代，Java、Java Applet、JavaScript、HTTP、HTML，這些當年的「新技術」在學校完全沒學過（學校教的是Pascal、C/C++、Fortran、組合語言），但工作上就是要用到，怎麼辦？沒怎麼辦，做中學就是了，專案需要用到什麼技術，就去學什麼技術。當時雖然開發軟體的經驗不足，但企圖心與衝勁十足。

***

Ｎ年後，多做了一些專案、多讀了一點書，也多了一層鮪魚肚，漸漸補足了當年缺少的軟體開發與軟體生命週期管理的經驗。但隨著手中抓住的東西越多，很多時候反倒捨不得打破現況，去追求那些最新的、風險最高的新東西。

高風險通常伴隨著高失敗率與高收益。人在年輕時應該找機會多冒險、多累積失敗經驗，從失敗中學習。公司也是，特別是新創公司。

那年紀大了怎麼辦！？只能不斷提醒自己：「取捨風險與利益，不要事事都打安全牌，也不要變成自己年輕時所討厭的老屁股XD」。或者，變成支持年輕人去冒險犯難的老人，也是一種不錯的選擇。

***

友藏內心獨白：快速失敗，不斷學習。