我曾在「反省 vs. 反思」一文,說明我對這兩個字彙的對比,也經常在軟體設計的文章,多次提及,軟體設計者,更需具備「反思」的能力。
所以,什麼是「反思」? 我覺得有兩個含意:
- 反覆思考
- 反向思考
反覆思考,會針對某一個特定的主題,思考探索其根本道理。因為需要探究至問題的本質,所以要花上相當多的時間研究與該主題相關的事物上,這是屬於一種關聯性思維的學習;同時也需要用心去觀察周遭包括生活與其它領域的知識,以萃取其精華與智慧,並將所體會的哲理應用(Apply)於該主題上。
反覆思考,不是去找 “How-to”、尋求 “Solution”,而是將焦點集中於思索問題本質的過程。某一個時間點,你可能突然 “頓悟” 到問題的本質(頓悟是由一連串的頓悟,在某個當下的時間點突破),實際上,我們也從來無法去確定是否悟道的就是問題的本質。不過,每一次的 “頓悟”,都會讓你 “抽象” 的層次更為提昇。
然後,再從問題的本質,倒推回來來找或創造自己的 “How-to” 及 “Solution”,自然而然,就不會有哪種只學或仿其形,卻無法理解其髓,不知所以然的那種感覺了。
反覆思考者,腦中思索的永遠都是問題,卻不是急著找答案;眼中所看到的都是問題,而經常會在內心深處問 “為什麼?”,而不是 “如何做”。
舉我個人為例,軟體設計領域中,個人認為最難解釋的詞彙,一個是 “架構(Architecture)”、另一個是 “元件(Component)”。這兩個字彙所衍生的問題, “What” and “Why” 架構 與 元件,已深植在我心中有三年多以上了。我可不會急著去找答案,也不可能透過軟體專業的書籍,找到真正的答案。坊間的軟體設計書籍,如 RUP 的 4+1 View,根本不足以解釋 “架構” 的萬分之一。
以前,Mr. Kao 曾問我如何測試架構? 若無法測試,那麼,單元測試就是個 “Garbage”。當時我無法回答,頓時語塞,還真不知道 “如何” 測試架構。這個問題停留在我心中一年多了,最近,我想通了,而且答案是意外的簡單。(賣個關子,以後有機會再提與架構相關時,再來說明) 😉
又如,最近我從以往所思索的兩個詞彙:複雜度(Complexity)與封裝(Encapsulation),突然領悟了一些道理,並將之應用在 “使用案例” 的哲理上。嘿,對於使用案例的觀念與寫作的實務技巧,可真是心神意會,得來全不費功夫。
我是不是就真的 “悟” 到了 “複雜度” 與 “封裝” 這兩個本質? 我不知道,應該是還差太遠太遠了。不過,我卻能以這兩個當作是課程的主題,不用任何講義,不需任何準備,講上 8 個小時以上對這兩個詞彙在軟體設計領域上的哲理與實務應用。這應該也算是因有長期 “反覆思考” 鍛鍊的一種收穫吧。
反向思考,則是學習從不同的觀點、不同的角度看待問題。
當你思索某一個主題,有一個結論時,你就想像在你心中就是有一個一直站在與你相反立場的人,會質疑你的結論,此時,你需要思索該如何解釋與回答。這是一種心智的鍛鍊,久而久之,面對不同的角度、不同的聲音、不同的質疑、不同的挑釁時,你可以很快地在你的腦海裡轉好幾遍,思考對方問答的合理性,也能很快地思考回應的解決對策,甚至能 “引導” 對方說出他自己對原假設答案的矛盾之處。
無論是反覆或反向思考,都需要與自己的內心對話。與內心對話的過程中,常常是需要自己找出一堆問題來,自己思索這些問題;也經常需要自己反問自己、自己質疑自己原先的假設。
最親密的 “良師益友”,英文稱之為 “Mentor”,就是你的內心。應該要常常與自己的內心對話,活化腦中的思緒,而不是急著去尋求從外界找答案,反而讓頭腦僵化。與內心對話的過程,我是把祂稱之為 「反思」。