如何設計軟體架構

December 22 22:00~23:04


鄉民們應該知道 Teddy 最近在整理部落格的文章準備出書（有人認識出版社的嗎？！），今天沒有人找 Teddy 聊天，參考 Peopleware 中文版的書本大小，關在家裡努力工作了一整天把書的草稿重新排版的差不多了，居然有 500 頁左右（Peopleware 中文版約 320 頁）。以下是這本絕世武功的...目錄：


第一部 現在 15
1 好深的怨念 16
2 老闆,軟體不是這樣開發滴 18
3 600 百多個 BUGS 要怎麼修? 23
4 這不是髒話 29
5 改行寫網路小說算了(1) 32
6 改行寫網路小說算了(2) 36
7 改行寫網路小說算了(3) 40
第二部 SCRUM 44
8 SCRUM 是一種制度 45
9 就是這個光:SCRUM + LEAN + XP 51
10 導入 SCRUM?謝謝再聯絡。 56
11 都市游擊隊 60
12 如何估算 STORY POINT? 65
13 STORY POINT 為何沒有單位:相對論篇 74
14 END-TO-END STORIES:切蛋糕篇 79
15 功課寫完沒: THE DEFINITION OF DONE 82
16 我不能採用 SCRUM,因為我家人不同意 85
17 0 與 1 的距離 90
18 SCRUM 之逆練九陰真經 94
19 同誰,九陰真經不是這樣子練滴 99
20 放下心中舉起的中指 105
21 REDUNDANCY 110
22 SHARED CODE:讓我們變成博格人吧 114
23 口袋不夠深 119
24 我鬧,故我在 121
25 TEDDY 的 PAIR PROGRAMMING 之旅 123
26 RETROSPECTIVE MEETING=許願池 128
27 CERTIFIED SCRUM MASTER, DAY 1 132
28 CERTIFIED SCRUM MASTER, DAY 2 136
29 我變成有牌的 SCRUMMASTER 了 140
30 傳福音 142
第三部 LEAN 147
31 軟體庫存 148
32 消除浪費 (1):PARTIALLY DONE WORK 152
33 消除浪費 (2):EXTRA FEATURES 156
34 消除浪費 (3):RELEARNING 160
35 消除浪費 (4):HANDOFFS 164
36 消除浪費 (5):TASK SWITCHING 168
37 消除浪費 (6):DELAYS 171
38 停掉生產線 174
第四部 加班 178
39 加班,加班,我愛你 179
40 非加班不能搞定之台灣經濟奇蹟幕後無名英雄 184
41 過勞死之軟工無用論 189
42 我可能不會 18:30 下班 195
第五部 洗腦 198
43 學習犯錯 199
44 為什麼不問問題? 205
45 風範 209
46 傻的願意相信 212
47 造船的目的 218
48 發語詞,無義 222
49 軟體是長出來的 225
50 咸豐皇帝是怎麼死的? 229
51 精神不好的時候 233
52 剽竊 236
53 你重視什麼? 239
54 THE POWER OF DUPLICATE CODE 242
55 這不是整人遊戲之 TIME LOG 紀錄方式 246
第六部 設計 254
56 PROBLEM DOMAIN VS. SOLUTION DOMAIN 255
57 再論 PROBLEM DOMAIN VS. SOLUTION DOMAIN 259
58 要抄就要抄最好的:架構師篇 264
59 你的軟體架構有多軟 267
60 設計最難的部份是什麼? 272
61 PROGRAM TO AN INTERFACE 277
62 DESIGN PATTERNS 分成三大類 280
63 時間到 284
第七部 HCI 291
64 窮人 HCI 設計入門 293
65 歪批 GOMS 300
66 HCI 分類開張: DESIGNING FOR ERROR (1) 307
67 DESIGNING FOR ERROR (2) 31268 DESIGNING FOR ERROR (3):KNOWLEDGE IN THE WORLD AND IN THE HEAD 319
69 DESIGNING FOR ERROR (4):CONSTRAINTS, FORCING FUNCTIONS, AND
NATURAL MAPPINGS 326
70 DESIGNING FOR ERROR (5):EXECUTION AND EVALUATION 331
71 HCI 之博士熱愛的算式 337
第八部 測試與整合 343
72 有 TEST CASES 改遍天下,無 TEST CASES 寸步難行 344
73 忙到爆的五月天 347
74 TEN-MINUTE BUILD 351
75 人客的要求:TEN-MINUTE BUILD 後續報導 356
76 TEN-MINUTE BUILD 後續報導 (2) 359
77 落實的能力 366
78 落實的能力(2) 370
79 用 ROBOT 寫自動化功能測試到底有沒有用 375
80 用 ROBOT 寫自動化功能測試到底有沒有用 (2) 380
81 誰 COVER 誰 388
第九部 還少一本書 393  -->考慮是否移除
82 THE TIMELESS WAY OF BUILDING 394
83 SMALLTALK BEST PRACTICE PATTERNS 400
84 RELEASE IT! 405
85 MANAGING THE SOFTWARE PROCESS 410
86 THE UNIFIED SOFTWARE DEVELOPMENT PROCESS 417
87 CONTRIBUTING TO ECLIPSE: PRINCIPLES, PATTERNS, AND PLUG-INS 423
88 SOFTWARE BUILD SYSTEMS: PRINCIPLES AND EXPERIENCE 428
89 零與無限大 432
第十部 閒扯蛋 437
90 TEDDY 的初衷 438
91 幸福有感 443
92 一步到位還是一槍斃命? 446
93 聞過則喜...誰說的? 448
94 白飯一碗 454
95 秀才遇到兵 458
96 ISO 大戰乖乖 462
97 一萬個小時的練習 465
98 小朋友不可以說謊喔 468
99 需求分析書中最重要的資訊是什麼? 471
第十一部 欲練神功 475
100 從 THE TIMELESS WAY OF BUILDING 學設計(1) 476
101 從 THE TIMELESS WAY OF BUILDING 學設計(2) 483
102 從 THE TIMELESS WAY OF BUILDING 學設計(3) 489
103 從 THE TIMELESS WAY OF BUILDING 學設計(4) 493 104 從 THE TIMELESS WAY OF BUILDING 學設計(5) 498
105 QUALITY WITHOUT A NAME VS A NAME WITHOUT QUALITY 503106 有駕照不會開車 506 ---> 這一篇好像放錯地方

雖然內容都是發表在部落格上的文章，但是經過分類之後 Teddy 才發現，哇賽，如果有鄉民真的認真一篇一篇都讀完而且讀懂的話，Teddy 的『日月精華』就全部被吸光光了說（還好自己還有暗槓一些不外傳的密技...XD）。

Teddy 內心獨白：我也太好心了吧我。

***

以上都不是重點，今天的重點是『如何設計軟體架構？』上次去面試還有昨天下午和某位很有趣的鄉民聊天的時候，Teddy 都被問到：『你如何設計軟體架構』或是『你如何應用 design patterns』。Teddy 突然被問到這個問題，一下子反而答不上來。就好像有人問你：『你如何吃飯？你如何喝水？你如何呼吸』一樣，於是 Teddy 就說：『很自然的就設計出來了』。

當然 Teddy 並沒有這麼厲害，剛剛 Teddy 又再次思考這個問題，到底平常 Teddy 是如何設計軟體架構與應用 design patterns 的？其實這個問題 Teddy 之前都談過了，請參考『軟體這條路：Architect 篇』，『要抄就要抄最好的：架構師篇』，『你的軟體架構有多軟』，『還少一本書：Contributing to eclipse: Principles, Patterns, and Plug-ins』，以及『從 THE TIMELESS WAY OF BUILDING 學設計系列文章』。今天 Teddy 再來幫鄉民做一下總整理：

• 首先，平常『有事沒空』的時候，就要多看 software architecture patterns 與 design patterns 這一類的書。由於大家時間都有限，因此看的目的不是要把這些一狗票的 patterns 全部都背下來，只要知道『有他們』這樣就可以了。等在工作上遇到問題的時候，再把可能可以派上用場的 patterns 拿出來研究一下看看是否有用。
• 當真正遇到問題的時候，如果腦海中沒有任何已知的 solutions（沒有任何已知的 architecture patterns or design patterns 可以直接套用），那麼就去找書或用 google 找看看有沒有『可以抄襲的對象』。除非鄉民們遇到的問題是很特殊或是很偏門，否則要完全找不到可以扯上關係的參考架構的機會應該很小（也就是說應該可以找到可以參考的架構）。
• 問題來了，假設可以找到一個或是多個參考架構，但是通常這樣的架構還是要經過一番的修修改改，才能用來解決鄉民們的問題。『功力好不好』此時就看得出來，這可能也是大部分的人在從事所謂的『架構設計』時遇到問題的時候。什麼問題？就是把一個參考架構調整成適合自己使用的樣子。
• 如果不幸真的完全找不到任何可以參考的架構，那...恭喜老爺，賀喜夫人，您也許找到一個可以當作碩士甚至是博士論文的研究題目，趕快找研究單位合作吧。不過，大部分的情況都是...找得不夠用力啦，再用力找一下，你就可以回到樓上了。

這樣講鄉民們應該還是覺的無法了解，Teddy 的文筆就僅只能解釋到這樣的程度了。不過沒關係，最近 Teddy 有提供『家教服務（上一次當家教已經是10幾年前的事了，教人家 DOS 和 PE2...XD）』，有需要的鄉民們在下單就好了。

最後 Teddy 要建議，如果真的對於『design patterns』與軟體架構想要『深深深深深....入研究』的鄉民們，Teddy 也是不藏私的，一本葵花寶典很早以前就告訴大家了，不怕死的就去買一本來 宮 攻吧。啊，什麼，你問 Teddy 那一本？！還有別本嗎，當然是 THE TIMELESS WAY OF BUILDING 啊。

***

友藏內心獨白：做功德的方式有很多種。