感覺清明連假挺好的，發文跟看文的人都有比先前多一點。
除了掃掃墓，也要掃掃各種觀念的新仇舊恨 !?
改變一經啟動，最先遇到就是混亂。你一定也經歷過，
就是當你用了新工具、新程序，卻發現比以往還糟的時候，
有人會說：「要是把這些新玩意丟掉，或許能重拾秩序...」
你飽受學習曲線的折磨，並認為問題就出在改變上，這項評斷或許沒有錯，
至少在當時是對的，當時的你真的比以前還糟。
這就是為什麼人對改變的反應是如此情緒化的原因，放棄專精已久的做法，
再次變成初學者，真是令人洩氣與尷尬，沒有人喜歡掙扎的感覺，
更何況你知道用老方法可以做得更好。
很不幸，混亂是改變的必經之路，沒有捷徑。
Peopleware P. 260
※ 引述《YAYA6655 (YAYA)》之銘言：
: 以我20年的經驗來說，什麼敏捷，設計模式，很多都是脫褲子放屁。
: 更早期還有什麼OO方法論，部分人神鬼上身，什麼東西都要OO一下，連寫個九九乘法
: 表都要開一個 class ninenine。
: 就好像1995年，C++鋒頭上的時候，說C++難用的會被一堆腦粉抨擊，不外乎就是說，
: 不是C++難用，是你不會用。
: 這是不是跟太極拳很像？太極拳多強，打輸泰拳，腦粉會跟你說，不是太極沒用阿，
: 是你自己沒有把太極的精髓發揮出來。
: 到最後這根本就是信仰了。但時間會證明一切阿，C++就是產能低落，太極就是打不贏
: 綜合格鬥。
: 回到正題吧，有一段期間我們公司也導入設計模式，搞到每一個簡單的動作都要有
: USECASE，你能想像這是怎麼回事嗎？這就像建構式數學，明明簡單到可以9x5=45的東西，
: 他規定你要9+9+9+9+9。
: 工程師是人，不是白癡。每一個輸出入函示都要UNIT TEST？有些簡單到如同9x5的東西
: 你真的還要替他見一個UNIT TEST？單步追蹤一次就夠了吧，裡面程式碼沒幾行，還是
: 呼叫共用的函示庫，這能出錯叫做共業，根本不需要花時間在這種地方演戲。
: 後來我們導入設計模式大約一兩年後，大家就慢慢不了了之，很多狀況都是慢慢不了了
: 之的，沒有人會願意出來說，我們當初想法天真錯誤啥的，就一切盡在不言中了。
先說說對於整篇文章的看法，
過去我們的學習適教學者為權威，不管他教的好的，或教不好的都太深信不已。
在整個『國立編譯館』的洗腦框架與競試 KPI 下，
我們挺少反思知識的來源是否正確，或對自己是否有價值，該不該追求它。
離那個代年越遠，我們的思考才會越活絡，更加能對知識產生質疑。
由前輩的分享，可以看出在公司導入新觀念、新技術時，
所受到的不平無法抒發之處，這些東西必需有計劃的導入，
本質上得學習組織的活性要足夠，那並不是拿著『權力』大筆一揮，
宣示一下就能成功的事，而是由一連串的小變動，讓組織
(先想個小一點的，例如 3 ~ 5 人的 team) 適應保持變動。
累積足夠的活性與習慣接受新觀念並願意改善行為後，
才能有真正的大幅革新，例如替換工作方法、工作流程。
或是得有回饋機制產生正增強。
先來做點簡單的名詞或概念釋疑
: 以我20年的經驗來說，什麼敏捷，設計模式，很多都是脫褲子放屁。
: 更早期還有什麼OO方法論，部分人神鬼上身，什麼東西都要OO一下，連寫個九九乘法
: 表都要開一個 class ninenine。
就先從敏捷開始吧.
提到『敏捷』就得提與它相對，作為他『假想敵』的 waterfall。
實際上，他們並不是真正的對抗關係，以『定義良好』的系統，
並『完全符合使用者需求的 SD/SA 後』產生的規格書，
並寫了簡易的 reference implemenation (或若干組 POC)，
直接發包、大撤幣是一種相當有效率，而且相當直覺得軟體開發流程。
若上面的『前提』都能滿足，那專案管理與人力調整，
那就單純是程式的『生產線』順不順暢的問題。
是什麼東西，破壞了這些前提呢？軟體開發最終還是在實現需求，
但使用者也許不一定真的理解需求，特別是在若干次使用者訪談之後，
可能發生矛盾的需求，特別是東西做出了一個雛型後，將使用者由
「想像」拉回現實，使用者接著反應「這不是我要的」。
那麼我們還要繼續走完 waterfall 嗎？或是回頭 blame 當初的 SA/SD 嗎？
以商業角度來說，那都不適當，合約在走，違約日一天一天逼進，
不是做完領錢、逾期賠錢或是違約倒閉。
所以，自然地，不太應該在一開始就想著最初的規格是會走完的，
得設定小一點、合理的目標先達成它，
並週期性確認雙方認知是否還在同一個線上，但認知明顯不同
才能以較小的『成本』反應需求變更，以敏捷常用的單位就是 iteration
而後續相依需求的 iteration 也都不用再排入到工作內。
時時確認客戶的需要，適時反應改變，才能符合需求達到降低違約的風險的目標
後來發現，除了對客戶間的互動，開發人員之間也得多多互動。
每個人對於規格或需求的解讀不太一樣，或設想的前提假設也不同，
所以才會有週期性短短的會議，不管是時間預估或是反省會議，
都有機會透過其他人的角度來看事情，知道為什麼不同人估同一個工的時間不同
是他多想了，還是我少想了，或是他知道有哪些既有的 library 或演算能採用
以加快處理的速度。
PS. 由於篇幅有限，其中也很重要的 working software 就省略一下了
大致上，專案在開發初期頭幾個 iteration 就可以有完整的軟體能跑，
好處是客戶能玩到會動的東西，不會過度想像，它就像我們剛進入
新的遊戲，基本功能都能動，但有很多未開發的關卡，等實作到了才開放
再來，談談單元測試 (雖然在你腦中是設計模式)
在聊了敏捷後，看單元測試就特別有意思了。
對比儘可能直衝整個進度的 waterfall，
或幾個 iteration 釋出新版本的敏捷開發，
『單元』是僅測試一部分軟體的功能，而不是整個完整的軟體。
特別是在進入 OOP 的年代，物件與物件之間的界線更好區分了，
而那個界線，自然地可以成為單元測試的切入點，
若是非 OOP 語言也會有其他可以作為界線的部分，
讀者倒是不用太擔心是哪種類型的語言
原 PO 是停留在一組簡單的 unit test 要如何實作的引言部分
但還需要充實一下部分的觀念：
* unit test 測試粒度，至少以 OOP 來說，我們只測 public method
* 不管你喜歡 TDD 或 BDD 都蠻值得看一看的
* 怎麼樣的實作，讓 unit test 難以實現 (ex. singleton pattern)
與適當的工具知識的補充，像是
*. 單元測試常用的 library，怎麼方便建立 test fixture
*. 需要 mock/stub 時，哪些 library 可以輔助
*. mock/stub 成本太高，是否要改用整 e2e 測試
*. 建置持續性整合環境 (並考慮邁向持續性部署)
推薦閱讀：
《Growing Object-Oriented Software, Guided by Tests》
看著原 PO 的年資與對 OO 痛恨的感覺，可以理解並表示同情
因為在早些年代的 OO 概念，確實比較傾向『對應現實世界』的實作方式，
像是弄個 Car 類別，再給他 N 個輪子，給他喇叭之類的東西。
比較現代化的方法，其實很少這麼作，除非學習者只看了入門教材就放棄了
剛入門的人，確實需要較『具體』的解說，但在實際開發的情況，
我們並不會那麼做，千萬不要那麼做 (除非有相當好的理由)
常見的設計方向有 3 種：
1. 標準的 OOAD，就定義好各種 interface 與它們間的互動關係
(語言提供的標準 API 大致走這個路線)
2. 隱喻，採用隱喻或一組故事來設計，比較容易記憶，而且有趣味!?
3. 由 2. 為主，但基底包裝好的 Design Pattern.
簡單來說，我們要過 Design Pattern 學習時，
練習出的眼光試著將程式面對『變更』的節奏做『抽象化』的處理。
Design Pattern 實作可能會讓程式變得比原長，但這代價挺低廉的。
Design Pattern 的精華並不在 Pattern，而是在每章開頭的 Intention
雖然意圖可能不儘相同，但目標如何『動態』地面對改變與擴充。
這裡的『動態』是指 Runtime 為主 (自以為)，
即使在這個 source code 很好取得的年代，
我們並不希望直接修改其他人的程式碼，
或是期望原本的專案，一開始的需求固定處理某些情境就行，
但後來得動態擴充它，都能由 Design Pattern 找到靈感
雖然不求有一模一樣的情境，但我們回頭推敲，
能簡單地設計一下，達到 Open-Closed Principle 的目標
我們該學的除了具體的 "Pattern"，同時是訓練識別 Intention 的眼光
同樣的理由，會出現在 refactoring 的學習上，refactoring 技法固然重要
但培養出快速嗅出 bad smell 的直覺。
====================================================================
回到最開頭講的，脫離了過去教育方式的框架後，
我們有機會『越過』第一次授與知識的源頭，
例如：像是認同原 PO 想法的人且初次知道這些『名詞』
不能只是停留在各自的同溫層取暖，也不能全然相信我單方面的解說。
要略過我們，找找原文書看看那些知識如何使用。
特別在這個資訊多元，價值多元的時代，
更應該鼓勵一些過去受過不好經驗的人，正視一下那些荒謬的經歷
學不學它都沒關係，但至少讓自己由惡夢中醒來。
同時，也該接納不是所有人都能學習的會那些被鼓勵學習的技術，
以我個人來說，對於 agile 沒特別的好惡，並鼓勵『自助餐』
開發者，或同事，只要能做出他能有最大貢獻的『選配』就行了。
我個人『進度至上』主義的，只要求是要有足夠的生產力。
code 寫得好不好看，有沒有 OO 什的，倒不那麼重要，
反正重構技能與砍掉重練技能點滿了，
等那部分要賺錢了、得能 scale out 時，再整理就是。