感觉清明连假挺好的，发文跟看文的人都有比先前多一点。
除了扫扫墓，也要扫扫各种观念的新仇旧恨 !?
改变一经启动，最先遇到就是混乱。你一定也经历过，
就是当你用了新工具、新程序，却发现比以往还糟的时候，
有人会说：“要是把这些新玩意丢掉，或许能重拾秩序...”
你饱受学习曲线的折磨，并认为问题就出在改变上，这项评断或许没有错，
至少在当时是对的，当时的你真的比以前还糟。
这就是为什么人对改变的反应是如此情绪化的原因，放弃专精已久的做法，
再次变成初学者，真是令人泄气与尴尬，没有人喜欢挣扎的感觉，
更何况你知道用老方法可以做得更好。
很不幸，混乱是改变的必经之路，没有捷径。
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 时，再整理就是。