軟體開發的「○○驅動開發」實在太多了。可是每個框架都是前人智慧的罐頭,跟著走通常少走彎路。同樣的思路想套到育兒上 ── 把 TDD、BDD、DDD、XP 翻成「育兒框架」的系列,從這篇開始。
○○驅動開發,是不是有點多?
TDD (測試驅動開發)、FDD (功能驅動開發)、BDD (行為驅動開發)、MDD (模型驅動開發)、DDD (領域驅動設計)、TiDD (票券驅動開發)、CDD (元件驅動開發),最近還來了 AIDD (AI 驅動開發)。
講的東西,我都懂啦。
自己寫東西,基本上想用 TDD 走。先把測試情境寫起來,實作之前先決定什麼叫「動了」。
要把 MVP (Minimum Viable Product) 推出去的階段,我會切換到 FDD ── 按功能切碎,一塊一塊弄成 Done。
所以,我懂。可是 ○○驅動開發,真的有點多。
軟體開發裡的框架 (framework / 方法論),講白話就是前人血淚跟經驗幾乎都裝進去的罐頭。
什麼都不想,直接跟著罐頭走,通常都還順。手回少。判斷次數少。code review 也好做。
票券管理也好、ITIL (IT 服務管理的最佳實踐集合) 也好、PMBOK (專案管理知識體系) 也好,以前我全部讀過一輪。證照也考了。讀的時候大部分時間都在點頭,「對啊,就是這樣對啊」。把該做的事好好做,結果是最近的路,大概就是這個意思啦。
用我家比較像的例子講,就是食譜。
照職人寫的食譜煮,基本上都還能吃。要改良,「先按食譜煮三次再說」這條規則套用一下。
把這套搬到開發以外的同事身上,常常推不太動。
「太麻煩」「我們這個案子不用啦」「我們不這樣做也跑得很好」。
心裡 OS 就是,欸,你知不知道這個方法論集了多少前人的智慧。
不過,他們也有對的地方。
ITIL 仔細讀就會發現,它根本沒寫「就照這樣做」。反而很清楚:依案子、依組織、依成熟度去客製化。
○○驅動開發也一樣,看專案規模、看階段、看成員熟練度,挑著用、調著用。每次都把整套硬塞,然後全功率執行,那不是它的用法。
所以業務同事說「我們這邊不用」,有一半是對的。另一半就是,他們還沒讀過罐頭上的標籤而已。
講到正題了。
育兒大概也是一樣的結構。
前人留下的智慧 ── 育兒書、幼稚園老師講的話、兒童心理學的研究、阿嬤路過丟一句話。形狀不一樣,可是全部都是「方法論的罐頭」。
只是,沒有人把它整理成「育兒 TDD 是這樣思考」或「育兒 DDD 要尊重 4 歲的領域」。用工程師的詞彙看,育兒的智慧還沒被好好整理。
所以才有這個系列。
身分是工程師也是爸爸的人,用自己的詞彙把前人的智慧重新排排站,看成「育兒框架」,看看會跑出什麼來。
TDD 的話,讓小孩先小小地失敗一次再從中學,翻譯成「失敗確認驅動」。
BDD 的話,Given / When / Then,「這個時間、這個情境、小孩做了 X → 我這樣回應」,可以叫「觀察驅動」。
DDD 的話,4 歲的領域 (恐龍現在還在地球、電梯是活的) 要尊重,別用大人的世界去說服他,「小孩世界觀驅動」。
寫到這邊,我自己也覺得這是一個蠻跳的思考實驗。
有些回會剛剛好。有些回應該會完全套不上。套不上的時候,我會把「為什麼套不上」也寫出來。這也算是使用前人智慧的一部分啦,我覺得。
再放一個東西,當作系列的脊椎。
有個說法 ── 太太逛街問「哪一件比較好看?」,你回「都好」或「兩件穿起來都很適合你」,逛街時間會更長。坐下來陪她一起煩惱反而比較快。(出處我忘了,印象中是某個研究?)
這不就是 pair programming 嗎。是 XP (極限程式設計) 的精神。一個人盯螢幕苦惱,比兩個人一起盯著苦惱,慢很多。輸出沒有大幅變好,可是會稍微好一點點,而且 ── 比較有成就感。
育兒大概也是一樣。
「自己想啦」這條路當然也行。可是,坐在小孩旁邊一起煩惱,他下判斷的速度真的會比較快。然後我自己也跟著被刷新一次。不是單向教,是 pair。
XP 那種,小孩跟爸爸一起煩惱、一起長大的氛圍 ─ 那種「育兒框架」,就是這個系列想從軟體工程搬過來的東西。整個系列大概就是這個主軸。