Problem Domain vs. Solution Domain

4/29 22:50 4/30 00:10

實驗室有個提早報到的新進準碩士班學弟被指派研究 CruiseControl，從最基本的安裝，學習如何撰寫 ANT scripts ，在建構活動中執行編譯與測試，最近進行到可以用 Cobertura 來跑 test coverage。某日，Teddy 在看過學弟的 demo 之後，問了他幾個問題：

1. Cobertura 所產生報表，裡面有 line coverage, branch coverage, 與 average complexity。這三個數據各代表什麼意思？
2. 你覺的使用 CruiseControl  (廣義的說，持續整合) 最困難的地方是什麼？
3. 你接下來打算做什麼？

學弟的回答：

1. 不清楚這些數據的意思 (PS：根據 Teddy 觀察，學弟認為只要把 Cobertura 的報表掛到 CruiseControl 中就代表完成了該項工作)。
2. 在寫 Ant scripts  的時候，需要依據不同的工作設定不同的參數，很容易出錯。
3. 預計把 StatSVN 的報表掛到 CruiseControl 中。

有帶過研究生經驗的鄉民們可以發現，這位學弟的回答是很典型的學生思考模式：只看到『Solution Domain』，而忽略了『Problem Domain』。

 ***

Problem Domain 就是問題發生的地方，也就是軟體開發所謂的『需求』。而 Solution Domain 就是問題的解決方案，也就是軟體開發所謂的『設計』或是『實做』。舉凡像是演算法，design patterns，refactoring，architecture 等等，都算是 Solution Domain 的範圍。

時時提醒自己哪些概念是屬於 Problem Domain 或是 Solution Domain  是一個很簡單，但卻很有用的思考與分析工具。以持續整合為例子，如果眼中只有 Solution Domain ，那麼這位學弟最後可能變成 ANT 大師，熟用數十種工具，但是卻不知道要如何利用這些 Solution Domain 的工具來幫助真實世界的軟體開發團隊來落實持續整合。為什麼，因為持續整合的 Problem Domain 是『軟體開發』，如果對於持續整合可以解決哪些軟體開發活動中所遭遇的問題未加以分析清楚，則光是會使用工具，並無法解決問題。這就像有一陣子很多公司花大錢買了 Rational Rose 的工具，以為這樣就增進軟體開發的速度並且改善軟體品質是一樣的。

光是知道問題，答案做不出來，也是白搭。答案寫出來了，但是答錯問題，更是白忙一場。所以，對於軟體從業人員而言，要能夠具備分析 Problem Domain 和『生出』 Solution Domain 都是同等重要的。以下列出幾個屬於持續整合 Problem Domain 的概念：

• 持續整合的主要目的，就是要找出『整合』的問題。哪麼，那些算是『整合』的問題？
• 針對不同性質的專案，持續整合的內含需包含哪些（例如，編譯，測試）？
• 當一個軟體專案大到一定程度，為了分工以及組織 (模組化與管理相依性) 的目的，因此專案通常會被切割成若干個小專案，而最終的產品將由這些小專案組合而成。
• 專案相依性對於持續整合有何影響？
• 公用（共用）元件對於持續整合有何影響？
• 持續整合的產出物有哪些？
•  持續整合的執行速度使否會影響到軟體開發活動？

大致分析這些問題之後，當鄉民們需要評估 Solution 的時候，例如，選擇哪些持續整合系統，使用哪些工具，要如何應用，如何改變專案結構與開發流程來使得持續整合更順暢等等，才有個取捨的依據。

 ***

Teddy 不是一個聰明人，在處理事情的時候所使用的招式也都十分簡單。『區分Problem Domain 與 Solution Domain』這一招 Teddy 已經用了好幾年了，非常用有。下次有人請你幫他 review 東西的時候，可以拿出來試看看，也許可以輕鬆幫對方找出一些盲點。

友藏內心獨白：感冒什麼時候才會好啊...