題目

• 聽到需求的時候，不要先想邏輯，先想怎麼驗收 ?

• OO 善用封裝繼承的特性，不要修改 Product 類別，不要修改測試方法

• Extract and Override 的 SOP

  • 找到 Dependency
  • Extract Method
  • private → protected
  • 建立 SUT 的子類
  • Override Dependency
  • Create Setter
  • 改測試
  • Assign 依賴值
  • 無法適用的情境
    • final
    • static

• SPR 的 anti Pattern

  • 職責過多
  • 單元切得過細

• 測試案例為什麼用 Snake 寫法?

  • 測試案例是用來描述情境
  • 反思：中文表達力強但描述精準度低
  • 要看見測試案例的因果關係
  • 測試案例的設計
    • 2+2 = 4
    • 2x2 = 4
    • 2^2 = 4

• 重構測試案例

  • 只呈現與情境相關的資訊

• 養成用 Domain 情境而不是 Code Level 的語言

• 不要為了測試把 Production Code 搞得複雜

• Mock Framework 的本質與要解決的問題是什麼

• 3A原則與Given When Then

• 減少 Content Switch(利用工具)

• 錢時間要花在刀口上

  • Unit Test
  • Pair Programming
  • Code Review
  • 整合測試
  • QA 測試
  • Alpha/Beta 測試
  • 部署策略

• Test Anti-Patter

  • 小心過度指定(使用 Argument Matcher
  • 測試案例之間相依
  • 一次測不只一件事（Data Driven)
  • 測試案例名字過於實作細節

• 不要為了寫測試使用 Virtual

• StoreProcedure 的測試不是單元測試，但是很好測試，只有與 Table 相依，透過 ORM 可以輕易作到，

Nice to Have

• Coverage

  • Missing Test Cases
  • Dead Code
  • 實例分享：大家都不知道*
  • 童子軍法則(趨勢>數字)
  • > 0%

• ROI

  • 出過問題
  • 經常變動的
    • 對不會變動且運作正確的程式寫測試是種浪費
    • 共用的模組
    • 商業價值

• 架構設計

  • 三層式架構
  • 六角架構

課程總覽與個人的建議順序

反思:如果是我會怎麼設計內訓課程?

• 附錄課程

  • 為什麼寫測試?
  • 第一個測試(計算器或 FizzBuzz)
  • 5 種假物件(Test Double)
    • Stub(模擬回傳)/Mock(前置驗証)/Fake/Spy:驗証互動(後置驗証)/Dummy
    • 小心不要落入名詞解釋

• 主要課程（假設學生已經有一定的理解）

  • 第一個測試
    • 3A原則
  • 3正1反
  • 三種互動
    • 呼叫次數，參數，順序
    • 狀態改變
    • 回傳值
  • 隔離相依
    • 原生操作
    • 使用框架
    • 測試案例
      • 可讀性:增進理解 / 規格書 / 穿越時空的傳承
  • TDD
  • 重構
  • Design Pattern

課程上的反思

• Setter 的重構要加強
• 依賴注入點，不一定要在建構子也不一定要在 Prod (抽方法)
• 要有能力判斷切入點
  • 善用工具
  • 練習
• C# 參數善用Optional
• OOP & UT
• Fp & UT
• UT & Refactor & Design Pattern
• Pattern 工廠／簡單工廠／
• 存在監控 Running Code 計算方法呼叫次數的工具嗎 ?
• 快速打出六個０ ?

參考

• Repository
• Paper

(fin)

前情提要

單元測試可以說是我這幾年投入最多學習項目，
我為什麼會這麼投入? 是因為我相信這是一個有效的開發方式，
持續的上課與練習，稍微記錄一下這些年來的反思。

想法

單元測試是我覺得不論何種程式語言(雖然我並不甚理解 FP)，最最基礎的技能，
非常值得深耕，好的單元測試本身是一種規格書(spec)與使用者案例(use case)，
你想搞 CI/CD、敏捷、DevOps、DDD，都一定要有單元測試，
甚至我認為這一切只是軟體開發的本質的多面。

我個人是相當推崇 XP (極限編程)的，雖然不知道是不是因為「每周工作 40 小時」這一條，
導致企業不愛，公司不疼、專案管理協會不推、主管不敢用，
但就我來說 XP 反而是最貼近軟體工程的具體實踐(而 Scrum 只是框架，你可以把 XP 放進去)，
也是真正能快速帶來品質的作法(簡單而務實)。

缺少的拼圖(困難的現實)

1. 學習曲線

   有寫單元測試的工程師非常非常稀少，能內化寫得好的更是稀少。
   為寫而寫的單元測試不但無法帶來好處，反而弊病叢生又無法為產品帶來價值。
   但是學好單元測試要多久 ? 要導入又要多久 ?
   這點有些因人而異，但我敢說不是只有一兩次的內訓或 WorkShop 就可以實際上戰場。

2. 人員素質參次不齊

   承上，寫測試的好處，短期內很難有立竿見影的好處，
   人性就是多一事不如少一事。
   更糟的是，過沒多久這些人員離職、調任、昇遷，
   人走了留下了代碼，一年年過去，
   就只剩一個焦油坑，一代一代傳承的業力，等待被引爆。

3. 教育體系的缺乏

   在台灣能把測試說到點上的講師，我只能推 91 大，
   也可能是我同溫層太厚或是見識太少，有很棒的講師或網路資源請推薦給我。
   如果可以的話，我希望所有軟體的教育機構都應該介紹並深入指導這門知識，
   包含大專院校與各類補教機構 。

   不過反過來說，91 大的課程對學生來說並不便宜，時間也相當短促資訊量大，課也很難搶。
   在我的觀點，台灣整體軟體產業不能只依靠一個人，希望有更多高品質的課程能夠出現。

4. 產品生命周期短

   現在的公司壽命，往往比一個人的職涯短，更不用說是內部的專案壽命，
   人員也常常被調任，也導致開發人員對產品或代碼的擁有權與責任感降低，
   當你對自已的產出只當作是個過客，那就不會原意用單元測試去細細打磨

5. 人各有志

   並不是所有人都與我有相同的想法，我認為身為開發人員必須對自已的負責，
   要有「匠人心態」所以我的基礎會建立在單元測試之上。
   但有得人就只是「討口飯吃」、有得人著重「商業思維」、
   有得人偏重「架構設計」、有得人在乎「市場行銷」。
   退一步說，這都沒錯，但是這些開發者往往不會投入太多的精力在單元測試上(或是排序上靠後)

與未來的展望

單元測試可以幫開發人員可以用更少的資源，對代碼有更深的理解，
一切都是案例，而案例是對產品的解釋，
一但理解了案例，工程師只需要組合單元或是創造新的單元。
而代碼就會是活的工程文件，可以跨越時間傳承給下一位 RD，
你傳承的不再會是業力，而是產品品質的火炬。

一但單元測試的基本知識抓住後，
測試趨動開發與重構就會水到渠成，
這兩門技術也不容易，本質上也易學難精，很需要經驗值，
測試趨動會讓我們更接近使用者，這裡指的是代碼的使用者。

反思:也許是我們太常一人同時飾演多角才會這樣的問題，那麼 Pair Programming 是不是能解決這樣的問題)

重構會引導我們到設計模式，
當然設計(架構與軟體)又是另一個領域了，未來會多找這一些課程來上。
目前這塊我也覺得是有缺憾的，TDD 之後就是重構了。
但是我並不認為硬背重構的準則或是 Design Pattern 就是解決之道，
而是應該結合兩者有系統化的設計課程，
理想上是有一個開發案例，可以循序漸進，反覆迭代的開發，
讓學徒可以由作中學，進而掌握這兩本藝術。

我希望可以有更多課程與資源可以學習讓學生們在接觸程式的當下，就接觸測試。
如何讓初階的開發者在學習路上，就接觸到正確的單元測試的姿勢呢 ?
如果未來有一天，人人都能寫出水平之上的測試，這個產業將會進入什麼樣領域呢 ?

參考

• 單元測試分享(一) — Why ? How ? What ?

(fin)

前情提要

本來想寫寫單元測試活動的心得，
但是覺得需要先說說我對單元測試的想法，
但是在那之前有需要說明我經歷了什麼，我又是怎麼樣的人。
寫著寫著越來越多，就拆了這篇文章出來。

剛好就業也差不多 10 年有餘了，也算是給自已一個重新審視的機會。

經歷

退伍的第一份開發工作就被開除;
原因不明，但我的解釋就是戰力不足不是即戰力，
但是因為該公司很快就放掉我，我反而是感謝的。
那個時候工作很難找(08年金融海嘯)，就業面臨了沒經驗找工作的蛋生雞問題。

所以就想去補習(資策會的課程)，
但是家裡沒錢(房貸/學貸)還有一些長輩的不良債務(家裡被潑漆之類的)，

後來跑去一個電子線材公司作資訊助理工作了 1 年半，
存夠了錢就去上課了，半年後也順利找到 W 社的工作，
這個時候去各個地方面試就蠻搶手的 Offer 拿到蠻多的，
但是我開的薪資，現在想想蠻都低的，另外比較印象深刻的是面試被保哥打槍了兩次(無聲卡)，
W 社最主要讓我認識了 Gelis 大大，還有獨立接手一個專案的經驗。
但離開的原因也是因為缺乏刺激，一個人怎麼作都不會有人管你，
看著一大份前人遺物，同事們的想法就是能動就好，沒有人想改進代碼，
那個時候我蠻受「學徒模式」一書的影響，想成為一個匠人，沒有回饋(與加薪)的環境我選擇了離開。

到了 C 社以後，蠻受主管肯定，工作氛圍比較接近新創，
同事之間的互動也蠻不錯的，最主要的成長是獨立開發了幾個專案，而且蠻賺錢的。
那個時候的角色也不錯，能清楚知道需求端開發端的狀況，
而且有幾個蠻重要的技術導入經驗。
但是後來碰到一個蠻低的薪資天花板(就知道我起薪有多低XD)，所以離開了。
現在想想離開也蠻正確的，不單單是薪水，對技術過於保守，其實現在有點吃老本的感覺。

後來就進了 N 社，我是在 N 社的成長期進去的，裡面很多大大，
也有一些 MVP，也是這個機會接觸到 TDD 與 SkillTree 的課程，
但是也是蠻掙扎的，一直無法作主要的專案，理想的開發方式也常常被現實打臉，
社群活動也參加的蠻多的，前期一些中國的講者的課程影響我蠻深的(也跟測試有關)，
跟 Ruddy 老師也有蠻近的接觸，看了蠻多的好書「軟技能」、「軟體開發本質論」、「進化」等…，
工作上實作了敏捷(雖然有蠻多地方怪怪)，也取得 Scrum Master 的認証，
但是我其實不是太認同社群的造神運動，還有認証機構進來以後說一些虛無飄渺的東西。
我還是想將「理論」與「現實」的鴻溝抹平，
離開的原因是想要有程式外的與人(妹子)接觸與時間(不太想 10-19 的上班方式)，薪資當然也有所提昇。

想法

早期的我很受「學徒模式」一書的影響，
想成為一個匠人，但是現在開始反思這個想法會不會過時了，
現在會比較想要斜槓，但是我不認為這兩者是衝突的。
主因是受前端開發影響，真的是一年萬變。
以前的我是前後端都開發，現在主流的開發方式都是分離的，
有其時空背景的因素在，而敏捷團隊講求的是跨職能(ps.我認為應是團隊而不是個人的跨職能)。
對於我來說，我個人也願意多學一點，但是反而有些貪多嚼不爛，
時間會是我最大的敵人，也是朋友，
而要考慮的會是價值與風險，單純的一直學「新」技術，沒有累積話只是一種浪費(比如說:SliverLight)，
所以我現在遇到新技術，會讓子彈飛一會兒，畢竟時間與精力都是稀缺資源。

開發之外也有很多重要的事，這些在「軟技能」一書可以看到，
包含維持自已身體的健康、習慣的建立、時間管理、財務管理、第二外語與溝通的技巧，
甚至是你的社交圈、家庭與親密關係，到這裡其實就是你的人生了。
軟體工程師不應該只是一個開發工具，軟體開發應該是未來人人具備的技能，

而你擁有這些技能，如何善用讓自已可以過得更好，反而才是一個議題。
舉例來說，有人用來增加收入(接案)，有人用來分析投資(股票爬蟲&程式交易)，
有人用來找伴侶，有人用來建立品牌或創業。
不要讓開發只在工作之中，要讓開發落入你的生活之中。

(fin)

前情提要

2020 年搭客運南下高雄，時間長達 5 小時，
有在關注的 Podcast/YouTube 節目都聽完了。
百般無聊的情況下，滑 facebook 滑到了保哥的直播節目，
講的題目恰巧是我一直想改善的軟勒—英文，
裡面有提到相當多的資源，稍作記錄一下。

摘要

保哥

• 學習的順序應該是「聽」「說」「讀」「寫」。(但我們的環境「聽」「說」的機會很少)
• 三個月連續上課的衝次班
• 語感的建立，先看懂文字與脈絡，再聽慢版，再聽快版(莫彩曦的建議是不要看字幕)
• 要找自已有興趣的主題
• 動機是學習新的技術

David

• 強烈的動機:交女朋友
• 快樂的環境:能讓你快樂的環境
• 選擇口說補習班
• 人會有惰性，要有強烈的動機

其它

• 自發學習的動機，認識外國朋友，與外國人溝通的虛榮心，承擔家庭責任
• 中英文的思考模式不相同，不要用翻譯的方式(在其它地方也有聽過中文腦與英文腦的說法)
• 學習資源:空中英語教室，大家說英語
• 不要怕犯錯，可以犯錯的環境
• 有 Context 的情況下，你可以用肢體語言協助理解
• 有興趣的東西:英文攻略
• 英文單字量不夠
• 如何維持語感? 多與外國人聊講話
• 閱讀原文書，先要有大概的理解
• 美劇的看法，看現代美劇
  • 第1遍，聽英文看中文字幕
  • 第2遍，聽英文看英文字幕
  • 第3遍，聽英文不看字幕
• 不是所有的外國人都是友善的
• 師大國語文中心附近公園，會有外國人主動攀談
• Meetup.com 的語言交流活動

小結

• 要有強烈的動機
• 建立環境(反思，應該是建立系統與生活結合;ex:看同儕有在追的美劇(如:后翼棄兵)可以成為聊天話題&訓練英文)

參考

• 直播聯結
• 分享幾個學習英文聽力的絕招
• Marques Brownlee
• 多語言習得學習網
• Learn English With TV Series
• Front End Happy Hour
• 師大國語文中心
• 阿滴英文

(fin)

大事記

社會

• 武漢肺炎
  • 東京奧運停辦
  • 無限量 QE
• 香港民主運動失敗
• 美國大選與黑人平權運動
• Kobe 墜機死亡
• 中天新聞停播

生活

足球

今年只有打一場比賽，2020 Arsenal 足總盃冠軍 2:1 Chelsea，然後賽季表演持續探底。

Lindy Hop

生涯首次在百人面前表演，所屬教室(YM)結束經營，
學了 BaLboa 到放棄，上了 36 堂長課(YM & YM 2.0)，中間因為疫情有延期，
會持續到 2021 (還有6堂)

今年是 Podcast 興起的一年，年初聽了股癌、光說不設計(偶然發現竟然是跳舞的老師，但是我沒跟他說)
後來聽了百靈果、台灣通勤第一品牌、徐豫切入點、大人學等…
身邊也有一些朋友開始在作，我心裡反而有一個 voice log 的想法，
但是還沒有很清晰，2021 或許可以作一些探索，當作日記用聲音記錄一些想法與事情。

• 閱讀
  • 大話設計模式
  • 硝煙中的敏捷
  • DDD
    • Domain-driven Design
    • Implementing Domain-driven Design
    • Domain-driven Design Distilled
• 婚禮
  • 阿棠
  • 蛋頭
• 英文
  • TUTORING APP 第四屆體驗大使
  • Voice Tube 零元挑戰成功
• 體驗
  • 潛水: 考証中
  • 抱石: v0(8/10)，目標 v2

職涯

• 2月 N 社離職
• A 社入職，Scrum Master
  • 3 月入職
  • 8 月產品上線
  • 12 月完整團隊開會
    • QA 納入團隊
    • 具有 PO 職權的人全數進入會議之中
• Scrum Guide 2020 改版

小結

2020是外面風好大的一年，今年的我反過得還算不錯(?)，
但是大家都在躲風避雨，所以相對有些寂寞(?)

生活上最主要的改變是轉換了工作到了 A 社，
主要的工作項目也從開發者變成了引導者(Scrum Master)，
這裡其實也有一點反思，這是我要的路嗎?
長期以來我是以「學徒模式」一書的模式在發展我的職涯，
以成為工匠為目標，但是實際上帶來的收入並不豐碩。
自動化的時代，自媒體的時代，純粹的工匠思維還足夠嗎 ?
狐芳自賞的模式能讓我生存下去嗎 ?
在「軟技能」一書中也提到了一些開發之外的選擇，
自我營銷、健身、理財等…
甚至在現今主流的開發流程框架之中，
跨職能跨領域才是未來的生存之道。
而我的職業選擇帶我到了這個地方，我應該冷靜評估自身與自處的優劣，
找到自已的一片天才是。

來談談 2021 幾個大目標，

• 人際關係
• 英文
• 作息
• 財務
• 職涯

人無遠慮，必有近憂，明年應該調整自已生活的節奏。

人際關係方面，想改善我的表達技巧，
我的表達方式在工作場合相當適用，就事論事講求效率極高，
在有相同領域的認知下，可以高度輸出大量訊息。
但是在人與人的場合，反而缺乏溫度，太過一板一眼，
可以試著模仿一些人，但不確定是否適合我。

在財務還算穩定的狀況下，我想強化我的英文與身體健康。
英文是個痼疾，我想找到可以直接口說的英文夥伴或老師。
具體來說，目前會考慮莫彩曦的課程與 myClass 大人的英語課，
要更加有意識的系統化思考時間的運用。

財務方面，我已經規劃好一連串系統操作，運作順利的話，
未來理財會更加的輕鬆寫意才對，關鍵點會在 1/1、1/4、1/5 這幾天。
幾個項目:

1. 設定孝親費轉帳
2. 主帳戶的轉移
3. 証券戶的轉移
4. 消費的預算制
5. 業外的收入

而身體隨著年紀漸長，需要更細心保養了，
我想先從健身與早睡早起開始，希望體重可以維持在 BMI 正常的水準。
並不像理財那樣有長期執行的經驗，希望可以有系統化的作法來維持;
此外，飲食也是相同重且複雜的環節，在 2021 年要綜觀全局的認真思考這件事，
並減少不必要的聚餐。

職涯短期我打算更加詳細的記錄我在 A 社推動的敏捷改變，
同時鍛鍊我的寫作與表達能力。
另外要有計劃的建立我的專案，
我想將單元測試與 TDD 的一些概念與心得分享在 YouTube 與 LBRY 上(免費)
另外我會想討論一下專業養成與市場需求的落差。

(fin)

前情提要

2020/11/18 將迎來 Scrum 25 周年與 Scrum Guide 的更新，
活動有一些大師對談，錄影放在文末連結之中，
另稍微比較一下 2017 與 2020 Scrum Guide 的差異(以中文為主)，
特別感謝譯者這麼有效率的更新，我差不多在 19 號就可以在網站下載了

排版與封面

2017 版本主要視覺的位置放了兩個大師的合照，首行字為「Scrum 指南 ™」
2020 版本主要視覺的位置為「Scrum 指南」，首行字為兩位大師的名字。
理想我會希望使用 2020 的版本，然後兩位大師的名字縮小到角落 :D

目錄

2020 將目的前移到目錄之前，我覺得這樣的調整很好。
讓人可以先讀取本指南的目的。

Scrum 指南的目的

篇幅相比 2017 更長了，並將 2017 版「Scrum 的運用」縮減並挪移至此處。
簡介了 Scrum 的起源，概述了 Scrum 的運用範圍與現況。

另外有兩句預防性的警語，是這個段落的重點

• 改變 Scrum 的核心設計或 Scrum 的各種理念，遺漏其中任何元素，或是不遵照 Scrum 的規則，是在掩蓋問題，並限制了 Scrum 的各種好處，甚至可能使其變得毫無用處。
• 這些使用 Scrum 框架內的戰術技巧有很大的變化，因此不在此描述。

這個篇幅簡述了 Scrum 已是被時間與不同產業實証有用的框架，
但擅自修改 Scrum 可能會導致 Scrum 效用打折甚至無用，
並具體說明 Scrum 的戰術實作不會在此指南描述。

Scrum 的定義

相比 2017 的版本，這裡直接提到了 Scrum 中所有的角色與其職責。
並明確的說明「原封不動地應用 Scrum」, 並強調這份指南是人之間的指引，
而不是具體的流程、技術與方法。

這裡也是我覺得很好的地方，以前在首次與團隊成員說明 Scrum Guide 時，
如果按照 2017 的章節說明，我都要另外安排一個段落先簡述 Scrum 中的角色，
因為 2017 在角色出現的篇幅比角色的說明還要早。

Scrum 的理論

2020 的版本加上精實思維(Lean Thinking)，
並具體說明了檢視、調適的事件( 2017 翻譯為活動)與三大支柱的關係。

透明性的段落強調了没有透明性的檢視會產生誤導和浪費(做出讓價值減少且風險增加的決策)
很有感觸，我在團隊導入 Scrum 的首要宗旨就是看見事實。
(有機會再談談如何定義事實與 Ruddy 老師說的「看見全貌」的差異之所在)

檢視性強調 Scrum 將以 5 個事件有節奏實踐檢視性(具體作法與事件在這個段落還沒提)，

檢視性促成調適性。 沒有調適性的檢視是沒有意義的。Scrum 的事件旨在激發改變。

這句話作到了承先起後的作用，可以將檢視性視作三大支柱的樞鈕。

調適性的篇幅提到了授權與自我管理，這也許是導入常常碰到的地雷。
團隊不被授權或缺乏自我管理的能力或意識(有點像有沒有病識感)。

2020 的編排我很喜歡，除了一再預告事件如何產生三大支柱之外，不再僅僅以順序暗示三大支柱的關係。
而是明確的說明透明性促成檢視性。檢視性促成調適性。。
(有點像真善美，沒有真後面就會變成假善、假美那就豪無意義了)

Scrum 的價值觀

對承諾、專注、開放、尊重、與勇氣的排版更明顯了，另外 Stakeholders 也明文納入其中了。

誒、不對啊，這些態度不是跟四維八德一樣，小朋友都知道嗎?
而且應該不論是你的老闆、雞巴主管、龜毛客戶、秋條前輩到所有人都應該要有相同的態度，不是嗎?
這就是知易行難吧… 說個滑坡的，最近在思考尊重與尊敬的差異，
朋友給了我一個例子:

• 尊重:念在你是一代宗師，你自盡吧
• 尊敬:我的戰鬥力只有六千，他起碼有一萬以上

聽說看得懂的都是老人。

Scrum Team

引言強調一位 Product Owner(2017 在後面的段落才提到)，
強調了沒有子團隊與階級架構(具體實務上會影響到組織結構，實作起來並不容易，需要更多的經驗)。
這次沒有翻譯目標/目的了，直接使用 Product Goal 並在後面的段落具體指由 PO 開發、描述溝通。

然後強化了對當責的描述，調整了後面篇幅的介紹順序
2017:PO > Development Team > Scrum Master
2020:Developers > PO > Scrum Master
我認為順序都是有暗喻性的，但解讀方式是自由的，就不過多解釋了。

重點是責任的部份，我覺得比起 2017 更能簡單的用 Scrum Guide 說明現在角色的職責所在了。

Developers

● 打造一份 Sprint 的計畫，也就是 Sprint Backlog；
● 藉由遵循完成之定義，以灌輸品質；
● 每天調適其邁向 Sprint Goal 的計畫；和，
● 作為專業人士對彼此負責。

Product Owner

● 開發並明確的描述溝通 Product Goal；
● 創造並清楚的描述溝通 Product Backlog items；
● 對 Product Backlog items 進行排序；和，
● 確保 Product Backlog 是透明的、可見的與可理解的

這裡特別加上了

Product Owner 可以自己做上述工作，或者也可以將職責委託他人，然而，Product Owner 仍肩負最終責任。

這句話我視為對大型組織導入 Scrum 的困難之處的回應。
錯誤 Scrum (其實就不是 Scrum)會產生缺乏實際權限的 PO，
或是有權無(卸)責的傳統型領導。

Scrum Master

明文Scrum Master 對 Scrum Team 的效能負責;職責更明確了，語句更洗鋉，贅字更少。
但我覺得「真正的領導者」這段文字將會產生轉型時的爭議，特別是將「僕人式領導」文字又被拿掉。
我會建議作為 Scrum Master 要把這件事放在心中，Title 只是浮雲啊。

Scrum 事件(原為 Scrum 活動)

Sprint

明文採用時間較短的 Sprint，可以建立更多學習周期，此外更加強調三大支柱與 Sprint 的關係。

特別提醒經驗主義的重要性，更勝於實際的做法(諸如:燃盡圖、燃起圖，或是累積流量圖等…)
這與我的經驗也是不謀而合，主管一開始就投入過多心力在要求製作圖表，
而忽略了在圖表之前，進行預估其實是需要訓練的，最後圖表變成作假帳…
失去透明度，檢視性與調適性將無法發揮功能，Scrum/Sprint 將會失敗(或是不知道成功或失敗)。

取消 Sprint 的章節被大幅縮減，僅以不合時宜一句代過。
反而釋放更多空間給 Product Owner。
我覺得 PO 當要取消 Sprint 時，要思考以下的問題，

• 要如何與其它角色互動?
• 要如何持續實現 Product Goal?

這樣的文字編排方式，我覺得是很大的改善，強調在 Scrum 之中，
我們的所有行為都是為了實現三大支柱，而我們相信這樣的方法可以領我們到達終點之地。
後面的事件也都有類似的描述，我就不再補充。

Sprint Planning

2017 版本
第一個討論題目：這次 Sprint 能做出什麼？
第二個討論題目：如何完成所選的工作？

2020 版本
主題一：為什麼這次 Sprint 有價值？
主題二：這次 Sprint 能完成（Done）什麼？
主題三：如何完成所挑選的工作？

明顯多了一個有關價值的主題，但是需要與 Stakeholders 在 Sprint Planning 結束前被確定下來，
就我實務的經驗 Stakeholders 與 PO 會比 Developers 提早決定未來的目標，
所以 Stakeholders 依然不是會議中必要的角色。

Daily Scrum

1
2
3
4

Developers 可以選擇他們想要的任何 Daily Scrum 的結構和技術，
只要他們的 Daily Scrum 專注於實現 Sprint Goal 的進展，
並且產生下一個工作天可執行的計畫。
這樣可以更專注並改進自我管理（self-management）。

把經典的三個問題拿掉了，這也符合我的經驗，不要流於形式，
而是更專注在實現 Sprint Goal，不流於形式則更能讓團隊自我管理。

Sprint Review 與 Sprint Retrospective

這兩個段落的篇幅都縮短了，但是我覺得更言簡意賅。
但投影片展示的描述，我還比較喜歡 2017 版本的描述 是為了引發意見的反饋和提升協同合作，
但的確實務上往往會淪為簡報報告。

關於 Retrospective 這個會議對我的定義，
我目前的團隊沒有在跑 Scrum ，但是我直接引入 Retrospective。
Retrospective 是一個可以雕塑團隊的會議。
有趣的事，團隊現在調整的越來越像 Scrum (當然依然不是 Scrum)

Scrum Artifacts

明文: Artifacts 的設計是為了使關鍵資訊之透明性極大化。(其實 2017 年的版本也有提到)
2020 版本的文字組織更簡明之外，都加上了承諾的區塊，

• Product Backlog 是為了實現 Product Goal 的承諾
• Increment 是為了實現對完成之定義(Definition of Done) 的承諾
• Sprint Backlog 是為了實現 Sprint Goal 的承諾

結語

結語的部份並沒有太大幅度的修改，
但是我想要再一次強調 「雖然實施部分的 Scrum 是可能的，但結果就不是 Scrum 了。」

小結

整體的文章的結構完整性更好了，三大支柱與活動的連結，產出與承諾的連結。
然後將實作(戰術)面與角色的行為(戰鬥)樣版移除，這樣給了更多空間讓團隊發揮。
也會促使團隊思考背後的原因(Why) ?

想起以前聽過「守、破、離」的演說，我想這次 Scrum Guide 有一點這樣的味道，
在 25 年前，什麼經驗都沒有情況，這樣的樣版帶來了相當大的幫助，
現在我們都有一些實作有一些失敗有一些成功，是時候把樣版移除了(或是回到問題的本質)。

• 你真要的三個問題嗎 ? 背後想問到的是什麼 ?
• 真的不取消 Sprint 嗎 ? 為什麼不行 ?
• 不站立真的不能開 Daily Scrum 嗎 ?

20201125 補充:
Adrian 的分享相當清晰明瞭，補充連結如下:

• Scrum Guide 2020 Update — Adrian
• Scrum Guide 2020 少了什麼? — Adrian
• Scrum Guide 2020 多了什麼? — Adrian
• Scrum Guide 2020 改了什麼? — Adrian

校錯

參考

• 活動影片
• Scrum guide 2020 翻譯後記
• 2020 中文版
• 2017 中文版
• 對產品負責人角色的錯誤觀念會如何毀了您的組織，以及其因應之道

(fin)

耶和華所賜的福使人富足，並不加上憂慮。— 箴 10:22.

前情提要

投資理財是現代人生活極為重要的部份，
但是我在學生時期並沒有學習到這方面的知識，
出社會也大概 10 年了。稍微作個記錄與分享。

概念

開源節流是基本理財認識，簡單分為收入與支出。
收入方面，最常為工資所得，在網路時代也有很其它的賺錢方式，
最主要我想還是要建立系統，這裡不過多著墨，
我的系統屬於股票投資，但是記得你可以不只有一個系統，而建立系統是需要時間與反覆思考的。

支出方面，其實滿足一個人的生活所需，金額不會太大，
當然想過得比較滋潤的話，會比較花錢，
跟據你所居住的區域來說(不是要戰南北)，還是會有比例上的差異，
你也可以用時間來轉換成本，不過裡面藏著一些魔鬼細節，小心得不償失。

舉例來說:
如果是自行開伙，飲食的費用並不會太高(特別是家庭人數較多的情況)，
但是就要考量到材料準備、保鮮、整理等環節，外食也可以有便宜的選擇，
但是可能會是太油太鹹太甜的餐點，導致健康受到影響。

但除此之外，孝親、偶爾為之的旅行、進修、稅、保險等等…什麼都要花錢。
簡單的一句，所有的支出，我都建議預算制。

以下是以一個小資上班族(就是我啦)的概念去設計的，
不包含保險、股票、信用卡等…其它的工具。
如果有人喜歡，也許未來才再寫相關文章吧。

帳戶分類

受薪帳戶(InCome Acct)

受薪階級通常會有薪轉戶，至少要有 1 次以上的跨行轉帳免手續費，
如果非工資收入(接案/紅利等…)，應該儘可能直接轉入主帳戶(Main Acct) 。

主帳戶(Main Acct)

目的:負責最多轉出轉入功能的帳戶，主要的活存會放在這裡，
應該有一定次數的跨行轉帳免手續費，或是約定帳戶免手續費，
依個人使用習慣，建議要有 5~10 次以上，此外要有好用的APP/網銀，
最後才是活存利率要儘可能的高，因為你大多數的生活費會停滯在此。

目前有些網銀放 5 萬或 10 萬就有 2% 以上的利率，比定存還高。
10 萬放一年就有 2000 是蠻值得的，當然不要本末導致，
省下的跨行交易手續費與其方便性才是我們要的。
這個帳戶的設計上金錢會有小額高頻的流通，
不要為了 2% 而讓錢鎖死不流動，
假設股市的投資如果有 5% 報酬的話應該讓現金流向股市市場(需要考慮投資風險)，
當然有閒錢還是可以考慮…

2020 年可以參考這篇文章，轉帳免手續費帳戶比較
雖然開戶作業有時候很麻煩，這些優惠也常常過幾年後就消失與改變。
但是僅僅這幾年中帶來的方便性也是很高的喔，手續費這種磨血的花費真的建議能省則省。

証券戶/証券銀行

目的:主要的股票投資帳戶，銀行與証券戶轉帳不應有手續費，
還沒有投資就先虧一筆，就好像跑百米你讓人家 10 公分，
你覺得沒差嗎？我覺得有差，跑百米我不是 Bolt ，理財我不是連公子。
証券銀行轉到其它銀行有一定次數的跨行轉帳免手續費
這裡的次數不用多 1~5 次即可，主要是我的交易頻率其實不高，
需要交易，通常是有大筆資金需要轉投資其它項目的時候，
反而是單日/周/月轉帳上限比較重要，可以在開戶的時候作約定。
最重要的是証券交易手續費要儘可能的低，
基本上會有 1.425‰*0.6(ex:富邦) 的折扣，
高交易額或有活動開戶的券商可以更低 (ex:華南 1.425‰*0.3)，
不要小看這千分一點四二五的 3 折，以前我不知道，傻傻被扣的錢可以訂好幾年的 Spotify 了
最後要有 好用的App (實際上好像每家都一樣，都是三竹作的？)

其他投資

活存

在低/零利率時代，活存已經不適合作投資的首選，
所以通常會與 主帳戶(Main Acct) 作結合，
主要用於生活上食衣住行娛樂所需的花費，
方便性將大於投資目的，但是仍要選擇活存利率高，
或是回饋高(ex:刷卡回饋/ShopBack)的消費方式

定存

利率要高，但是在低/零利率時代，定存已經不是良好的投資標的。
但建議可以將緊急預備金作為定存

外幣:

性質會與活存類似，但以外幣計價，應為國際通用貨幣(美金、歐元等…)，利率要高，
主要的目的為美股、旅遊、海外置產(目前沒有)，特性是交易手續費都不便宜，所以持有比例不會太多。

美股/其它市場股票

台股之外第一選擇，以美股為主，
好處是標的超多，可以賺世界上所有標的的錢，
缺點是美金計價所以想轉換成現鈔或是台幣手續費都很高，
沒特殊情況這些錢不會拿出來花，會變成純粹的投資。
研究中…

黃金/貴金屬:

有使用黃金帳戶買過，非實體黃金，
只能賺差價而不生息，所以不愛，目前已經不再投入。

支出

所有的支出應該都採取預算制，
每年編列並支出，作為個人，不應有消耗預算的行為，
但是可以挪移至下一年度。

Fixed Charge (固定支出)

• 保費(綁定信用卡)
• 稅金(分期 0 利率)
• 孝親費
• 訂閱制服務
  • 域名( Domain )
  • Spotify (綁定信用卡)
  • 水/電/瓦斯
  • 網路/手機電信/第四台
• 生活費
• 投資
  • 定期不定額
  • 主動式投資

浮動支出

預算制設定上限，但是以實支實付為主

• 學習費用
  • 買書
  • 上課
• 娛樂費用
  • 旅行
  • 聚餐
• 婚喪禮金
  • 好友/親人
  • 普通同事/朋友，只包不去通常可以省時省錢

Over View

參考

• 轉帳免手續費

(fin)

As aspiring Software Craftsmen we are raising the bar of
professional software development by practicing it and helping
others learn the craft. Through this work we have come to value:

Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

作為有理想的軟件工匠，我們一直身體力行，
提升專業軟件開發的標準，並幫助他人學習此工藝。
通過這些工作，我們建立以下的價值觀：

不僅要讓軟件工作，更要精益求精
不僅要響應變化，更要穩步增加價值
不僅要有個體與互動，更要形成專家的社區
不僅要與客戶合作，更要建立卓有成效的伙伴關係

也就是說，左項固然值得追求，右項同樣不可或缺。

簽署心得

這些價值觀我是相同認同的,
可是這個網站的感覺並沒有呈現出那樣價值觀啊…
或許還少了一點美感.

我的簽署資訊如下,
30196 Marsen (Taiwan) 2020/10/28,
查詢功能不能查 ID 與國家有點弱,
沒有正體中文的翻譯, 補充資料的部份很不錯,
但是也只是沒有系統的散落在那裡.
想給點回饋,也找不到留言區或討論區, 或是網站的 Repository.

參考

• 【還少一本書】Clean Agile
• Software Craftsmanship Manifesto（軟體工藝宣言）
• Software Craftsmanship Manifesto（軟體工藝宣言）#相關閱讀

(fin)

前情提要

擁有自已域名的網站已經 4 年啦, 雖然我只有用在 Blog 上，
而且是用靜態網站的方式呈現，但也是算小小的一個成就.
不過其實心理還是有一個小小的缺憾，就是我沒有自已域名的 email.
之前沒有好好作功課，想到還要架設一個 Mail Server 就覺得不可能.
但其實並沒有那麼複雜.
我使用 Google Domain 的服務結合 CloudFlare.
大約只要 30 分鐘就能收到信啦.

實作

首先是進入 Google Domain 的後台,
記得如果你人在台灣是不被允許使用 Google Domain 的服務,
所以必需要透過 VPN 跳轉到美國才能操作後台喔.

真的是超簡單的,但是數量上限為 100 個,
加上 Google 的服務常常說收就收, 有商務需求的人還是不建議這個方式喔.
電子郵件 > 新增電子別名,輸入自已想要的名字,然後填入現有收件者電子郵件地址

如果你全部使用 Google 的服務的話,這樣子的設定就好了,
DNS 的 MX 記錄 Google 會自動幫你處理到好.
但是如果你像我一樣, 使用了別的 DNS 服務就必須要自已手動將 MX 記錄註冊上去喔
在 CloudFlare > DNS 就可以進行設定.

設定完成後依照 Google 的說法會收到一封信(但是有些情況收不到)就會生效,
我實測上沒收到信,但是寄信馬上就生效了.
有了自已域名的信箱虛榮感專業度是不是又上升了幾個百分點呢?

補充 20201118

前面已經可以透過自已的域名收信啦，
那麼怎麼寄信呢?

想像一下，如果用 [email protected] 收信，
卻用 [email protected] 回信，
是不是整個 Low 掉了，而且收信者是不是會懷疑怎麼寄信給 A 卻是 B 回信呢?。

為了解決這個問題，請參考在 Gmail 中使用別名傳送電子郵件，

1. 產生應用程式密碼

   • 登入 Google 帳戶後，前往Google 帳戶頁面。
     
   • 左側安全性 > 應用程式密碼 > 選取應用程式(選擇郵件) > 選取裝置(其它) > 輸入自已的 Domain > 產生
     
     
   • 把系統產生的 16 個字元密碼記錄下來。等一下我們會需要用到這組密碼

2. 新增電子郵件別名

   • 登入 Gmail > 設定 > 帳戶和匯入 > 選擇寄件地址 > 新增另一個電子郵件地址
   • 電子郵件地址輸入 自訂網域信箱 > 勾選「視為別名」
   • SMTP 伺服器輸入 smtp.gmail.com 通訊埠 587，選取採用 TLS 的加密連線
     
   • 使用者帳戶請輸入 Google 帳戶(不用包含@gmail.com)，密碼使用上一步的應用程式密碼 > 新增帳戶
   • 系統會寄一封驗証信，驗証後即可使用新的信箱寄信了
     

3. 變更「寄件者」地址

   • 登入 Gmail > 設定 > 帳戶和匯入 > 選擇寄件地址
   • 設定回覆郵件時：來自和郵件傳送地址相同位置的回覆
   • 將自訂網域的信箱設定為預設郵件

參考

• 轉寄電子郵件
• 設定自訂名稱伺服器的電子郵件轉寄功能
• 在 Gmail 中使用別名傳送電子郵件

系列文章

• 怎麼建立一個網站？(一)
• 怎麼建立一個網站？(二)
• 怎麼建立一個網站？(三)
• 怎麼建立一個網站？(四)

(fin)

前情提要

初探 ElasticSearch Service (以下簡稱 ESS )，
結合 Logstash、Kibana 合稱 ELK，
Elastic Cloud 提供更多的功能雖然蠻多還用不到，但比起自已架設會快相當的多。
因為主系統仍在開發中，只有部份功能上線，所以我選擇 ESS 作為我們的 Log System。
選擇 ESS 的原因如下:

1. 快速實現，只需要在 Elastic.io 簡單的操作，便可以有一個功能齊全的服務
2. 提供很全面的 Kibana 圖形介面
3. 與 .NET 的整合很單純，安裝完 NuGet 套件後，只要設定好 Config 立即可以使用
4. 開源且社群活躍，也是目前主流的 Distribution Search Engine

現有配置如下

初始的配置更低，是使用最小單位、最少節點的配置。
Memory 只有 1 GB，Storage 有 30 GB。
在初始配置的情況下，JVM memory pressure 常態性達 70% ~ 80%，
這是個異常狀況，在實務上緊急將 Memory Scale Up 到 2 Memory 暫時解除這個問題。

效能問題

追究後面的本質原因的話，是在系統設計上, 每日建立新的 Index，
在官方的 blog 也有提到這樣的實踐方式。

a lot of people use Elasticsearch for logging.
A standard format is to assign a new index for each day.
中略 …
Indices are fairly lightweight data organization mechanisms,
so Elasticsearch will happily let you create hundreds of indices.

但是實務上我產生了太多的 Shards ，這也是初學者常踩的一個雷包，
一不小心就會 Oversharding 可以參考 How to size your shards 進行修正。

這裡我使用了 Reindex 這個 API 來將一些碎小的 Index 作結合(Combine Smaller Indices)。

實作記錄

Reindex 的 SOP

1. 確保 maximum shards 的足夠
   ESS 為了避免 Oversharding 導致整個 Cluster 崩潰會有設定一個上限值，
   7.x 版本預設為 1000 ，而 Reindex 每一個 Index 都會需要 2 個 Shards (猜測是 SWAP 機制)
   以我為例，原本我的 Shards 已達 999 ，當我試著要 Reindex 時會拿到以下會錯誤。

   this action would add [2] total shards, but this cluster currently has [1000]/[1000] maximum shards open

   處理的方法也很簡單，只要透過 /_cluster/settings 加大 cluster.max_shards_per_node 即可。

   1	curl -X PUT localhost:9200/_cluster/settings -H "Content-Type: application/json" -d '{ "persistent": { "cluster.max_shards_per_node": "3000" } }'

   實務上我 Reindex 後會刪除碎小的 index，刪除後 Shards 的數量也會下降，
   當 Shards 剩餘數量足夠時，我會重設回 1000。

2. 執行 reindex ，請確保新舊 index 符合商業邏輯
   example:

   1 2 3 4 5 6 7 8

   { "source": { "index": "staging-aaa-service-2020.06.*" }, "dest": { "index": "staging-aaa-service-2020.06" } }

3. 確保查詢一致

   • query 數量為 N
   • Reindex
   • query 數量為 2N
   • delete
   • query 數量為 N

4. 執行紀錄

   • staging-aaa-system-*
   • staging-bbb-server-*
   • staging-ccc-service-*
   • prod-aaa-system-*
   • prod-bbb-server-*
   • prod-ccc-service-_ - prod-ccc-service-2020.09-_ 有掉資料(12 萬筆 →9 萬筆)
     

5. 結果評估
   Memory 只有 2 GB，Storage 有 60 GB 時。
   ReIndex 並刪除碎小 Indices 前 JVM memory pressure 常態性達 40%，
   執行後，JVM memory pressure 約為 20%。
   也就是說我可以改用更小(便宜的配置處理目前的資料量)。

改善建議

• 重要敏感的資料，要先備份才能進行 Reindex 的操作
• 下次 reindex 遇到大量資料，要切成更小的單位進行，
  比如說每 10 天或每天，減少一次性 reindex 的資料量，
  減少失敗與掉資料的可能性發生。
• 需要將系統改用較長的時間周期去建立 Index
• 縮小雲端系統配置。

進階思考

• 如果我想要維持 Daily Indices Created 但是又不想讓 Shard 成長爆量，我應該怎麼作呢 ?
• 或是有什麼機制，可以讓我定期將某些資料 Reindex 嗎 ?

參考

• Shard 的最佳化管理
• What is an Elasticsearch Index?
• [Elasticsearch] 基本概念 & 搜尋入門
• Elasticsearch 7.x node 開放 1000 個 shards 限制
• How many shards should I have in my Elasticsearch cluster?
• 圖解 Elasticsearch 原理

(fin)