QBQ！問題背後的問題 - 重點節錄

QBQ實踐原則：
個人責任不是通過改變他人，而是通過改變自己力求解決問題
個人責任不是抱怨團隊，而是要充分認識個人的力量
個人責任就是要適應變化，不斷完善自我
個人責任就是要利用現有的資源與工具實現目標
個人責任就是要做出具有積極作用的選擇
個人責任就是要不斷自問"我還能做些時麼？"

QBQ的精隨：藉由提出更好的問題，立刻做出更好的選擇。

個人責任感的不同，造就了個人事業的差異。
請做更好的選擇吧！

QBQ指導原則：答案就在問題之中

QBQ三項簡單指導原則：
1.以"什麼"或"該如何"這兩個詞來發問，而不是用"為什麼"、"什麼時候"或"誰"。
2.在所有問題中包含"我"字在內，而不是只包含："他"、"他們"、"我們"、"你"或"你們"。
3.把問題的中心詞放在動詞上面，也就是放在行動上。
EX.我能做什麼？

如果你想贏，就要擊敗三個人：你的對手、你自己以及裁判。

"個人負責的精神"可以改變世界的方法就是：每次都做出一個最好的選擇。

承諾用自己的智力、心力和勞力解決問題，而且絕不再爭功諉過。

團隊精神的基石就是：欣賞團隊中每個人與生俱來的天賦與優點。

在工作中要麼選擇言行一致；要麼選擇辭職離開！

個人責任的重點不是期盼他人首先改變，或是改變他人，而是首先改變自己，進而改變現況。

QBQ祈禱文：
願上帝賜我平靜，接手我無法改變的人。
願上帝賜我勇氣，改變我能改變的人。
願上帝賜我智慧，了解我自己這個人。

實踐個人責任的方法：
1.提煉自己的想法
2.問比較好的問題
3.最後付諸行動

領導(Leader)就是那些時時刻刻都在提煉自己的想法，以承擔個人責任為己任，不斷做出具有積極意義的選擇並付諸行動的人。

QBQ的內涵是"個人責任"：
別再有"小媳婦"的心態，別再拖延、推諉或怪東怪西。
我只能改變我自己。
立刻就去執行！行動高於一切！

時光旅人~~

花費了這個周末，我看完了一本小說式的自傳：時光旅人

主要是在描寫一個物理學家故事

他如何在小時候因為父親的驟逝

走入了人生的低潮及憂鬱的胡同之中

直到他接觸到了一本小說

威爾斯的｢時光機器｣

一個夢想 從他的心中油然而生

打造出時光機器  回到過去再見到他的父親一面

於是  他開始了他的科學人生

雖然結尾時他還沒有打造出真正的時光機器

且他那基於愛因斯坦相對論的理論

在一位知名教授的點醒下 發現了一個很大的問題

根據他的理論所打造出來的時光機器

最遠只能回到時光機器打造出來的那個時間點

即便如此他還是沒有放棄他的夢想

如今他已值花甲之年

但他應該還會繼續努力下去 朝著他的夢想前進

就讓我們繼續看下去吧~~

挪威的森林~~

今天我終於把挪威的森林看完了

會想看這本書的動機是因為

之前看過一本書 那年我心中最每個旋律

書中常常提到這本書 而且這本書也是 小橘 的遺物之一

我想過幾天我應該會再重看一遍 那年我心中最每個旋律

就我目前能觸及的記憶 是

兩本書中都有一個女生 不知是

對未來 對現實生活 還是...  沒有辦法適應

於是都選擇了 結束自己的生命

不同的地方是

小橘 在臨死前 演奏了讓人永生難忘的 雙簧管 演奏

她的自創曲 弱水三千

而

直子 則是在上吊前 帶著微笑過了一個

在Kizuki選擇離開人世後 最輕鬆的一天吧(我猜)

兩個人都有低調且冷清的葬禮 可能都是因為是自殺吧

就在前幾個小時 我邊看來邊認為會有 不錯的結局

結果就再倒數的幾章 劇情急轉直下 直子 自殺了

男主角 渡邊君 經歷了兩次身邊人(摯友及愛人)的離世

都有了不同的領悟

死不是生的極反，死只是生的延伸

死去的人 總會帶走自己身上的某些東西

寫到這邊總覺得一整個很灰暗

至於好不好看 感覺是見仁見智

但蠻多地方值得去深思的

寫到這覺得怎麼一整個很灰暗的感覺

說點其他的吧

像是男主角的一個朋友永澤兄

離去前給了他一個禮物：不要同情自己，同情自己是下等人幹的事

還有書中有一個蠻常出現的口頭禪：要命

另外，這本小說關於色色的畫面描寫相較於一般的小說好像稍多了點

大道至簡 - 軟體工程實踐者的思想 內容整理

客戶不會用C，難道就會用UML嗎？客戶是因為他認為你理解了他們的需求，而在｢需求確認書｣上簽字，而不是因為你的UML畫的是否精確。

需求階段：

1. 確定了專案的實際目標，以及遠期的方向

2. 設計需求條目

我們開始在網路上查看相關的軟體系統的特徵以抽取客戶所關注的內容；瞭解該客戶的公司、經營理念、組織結構形式以及工作模式；瞭解同類公司的成功經驗和優秀的管理模式，以及客戶的競爭對手在做什麼和在關心什麼。經過上述的步驟，可以總結出產生需求的資訊點為：

1. 客戶在公司層面的外在表現、內部機制和運營管理手段。

2. 客戶在專案中既已明確的需求和可能發生的需求，以及客戶圍繞其公司行為(和方向)所提出的需求。

專案的歷史資料：

History是為整個專案而記錄的。一些參考的記錄內容有：

l需求階段：與誰聯繫，聯繫方式、過程、結果以及由此引發的需求或變更；

l設計階段：如何進行設計、最初的構架、各個階段的框架變化、因需求變更導致專案結構上的變化(有助於瞭解構架的可擴充性)；

l開發階段：每一種技術選型的過程、每一種開發技巧的細節和相關文檔、摘引的每一段代碼、演算法、開發包、元件庫的出處和評測；程式單元的測試框架；每一個設計和構架變更所導致的影響；

l測試階段：還記得測試用例和測試報告嗎？那是最好的history之一。

另一件最重要的事，是記得在每一筆記錄後寫下時間和你的名字。

由於軟體工程的興起，工程被當成了藉口，掩蓋了我們做事的真正目的：“實現”。因此，我們在一個項目中常常聽到說“工程要這樣做”，或者“工程要那樣做”，而絕少聽到“專案要求這樣做”或者“客戶的本意是那樣的”。

從成本的角度思考專案：

1. 不計成本的專案計畫不會得到經營者的支持；

2. 毫無目的地消耗成本是項目中的慢性毒藥；

3. 最致命的風險是成本的枯竭

成本因素包括：時間、人力、資金和客戶成本（客戶的數量及耐心）。

語言只是工具：

方法：是對既有行為的歸納總結。

過程(Process)：過程伴生工程而出現。過程解決的是工程中角色間的關系問題。

工程：

組織：

軟體工程理論體系：

軟體工程三要素：流程(process)、方法(methods)和工具(tools)

軟體測試實踐：測試web MSN - 內容整理

測試用例是軟體測試的最小單位，是測試工程師的子彈。對軟體測試入門者來說，測試用例是第一位的，有了好的測試用例你就能發現別人沒有發現的bug。只有當你具有良好的、開放型的測試思維，你才能得到優秀的測試用例。

1. 我們要熟悉產品的需求規格說明書(軟件需求是測試的標準與範圍)。若需求不具體或者需求文檔過於簡略，這時測試應該去推動需求的制定。

a. 測試以需求規格說明書為基礎，但同時也要去發現它裡面的錯誤，推動需求的完善。

b. 測試工作是貫穿於整個軟體開發過程的，越早發現錯誤，修正這個錯誤的成本就越小。

2. 測試工程師要瞭解專案的整體安排(即專案的時程)

a. 測試是無窮盡的vs.實際測試是有限的 <= 測試的經濟面(時間、成本等限制)

3.預備好測試環境

a. 工作環境與測試環境要分開

b. 功能測試環境和性能測試環境要分開

c. 提前準備好硬體(伺服器、客戶端、網路設備)和軟體(作業系統、瀏覽器)

d. 測試支援平台也是測試環境的一部分。測試支援平台：一套測試的自動化辦功系統，例如測試用例管理系統、bug管理系統、測試報告產生系統等。

e. 把搭建測試環境時遇到的問題和相應的解決辦法記錄下來，形成文字，以備之後查詢。

<<測試常用專有名詞>>

黑盒測試：只知道功能的測試。 <= 功能測試

白盒測試：只知道程式碼結構的測試。 <= 單元測試

灰盒測試：知道功能也知道程式碼結構。 <= 執行某個功能中所有的單元測試??

功能測試：對產品的功能做測試。

性能測試：一般是檢驗在普通場景下產品的性能。

壓力測試：檢驗產品在極端條件下的性能(極端條件下的性能測試)。

回歸測試：

1. 在開發人員修復一個bug後，去驗證這個修改是否正確所做的測試。

2. 在軟體開發後期，選擇否依部分重要的測試用例去驗證產品的某一個版本工作是否正常。

單元測試：函數級別的測試，一般都由開發人員來完成。

整合測試：將各模組代碼整合到一起，實現一個或一些功能。驗證代碼的整合是否正確。

系統測試：針對子系統做測試，也就是大一點的整合測試。

邊界值：是確定合法輸入與非法輸入的判斷條件(通常會在邊界值的左右在各選一個值來測試，也就是每一個邊界值得測試會有邊界左值、邊界值、邊界右值，三種值)。

等價類：將涵意或影響相似的值分在同一類中，並為每一個類選一個代表即可。例如，在0~100中，如果以偶數奇數來分類的話，就是兩類，各選一個奇數和偶數來測試就可以了。

里程碑：軟體專案一般可分為多個階段，每做完一個階段，我們就說實現了或達到一個里程碑。

評審(Review)：

bug重現(再現)：不能重現的bug，它的嚴重性一般都不會很高。

BVT(Build Verification Testing)測試：在一個新版本出來後，先要做一個最簡單的測試，保證這個版本的基本功能工作正常。亦稱冒煙(煙霧)測試。

自動化測試：透過測試工具來實現自動運行的測試。

UI測試的關注點：

1.      界面元素要符合通用規範

2.      窗口能在不同的尺寸下顯示正常

3.      支持用戶不同的作業系統的設置

4.      支持用戶使用不同的解析度

5.      處理好焦點問題

6.      作語法檢查，避免文字錯誤

7.      對不方便人群的支持

8.      支持快捷建

測試計劃的關注點：

1.      測試時間的安排

2.      測試人員的安排及任務分配

3.      測試資源的安排，包括需要的軟體、硬體

4.      自動化測試的安排

5.      測試風險的分析以及對策

                                                                                                          

<<設計測試用例的一些思維>>

1. 一個測試用例只負責一個細小的使用場景，越細越好。

2. 軟體的基本數據也在測試範圍之內。

3. 檢查默認值是一種很好的測試思想和習慣。

4. 使用"排列組合"的方式編寫測試用例(測試是無窮盡的vs.實際測試是有限的)。

5. 輸入框為空是一種特殊值。

6. 做軟體測試時，總有一些"附屬項"需要驗證。

7. 測試用例要有覆蓋到極限值(邊界值測試)的情況。

8. 登入驗證在安全性方面要多多考慮。

9. 懷疑一切，驗證一切。

10. 網頁得標題欄也是需要測試的。

11. 考慮一個測試點時，需更多的從動態的角度出發。

12. 快捷鍵的驗證。

13. 下拉式表單的每一個子項都要測試。

14. 即便功能類似，用例還是要分開寫。

15. 幫助文件的內容也是需要測試的。

16. 在測試一項複雜的功能時，可嘗試使用Bottom-Up的測試邏輯。

17. 不要忽視功能點，他們也需要被測試。

18. 所有不正確的需求、設計和程序錯誤都可以報告為bug，讓相關人員去修正。

19. 測試員的眼界要越過被測試的對象，可以考慮與之相互通信的”兄弟軟體”之間的協作。

20. 工具攔中的每項設置都需要遍歷；設置之間的組合可以隨機來做，不必遍歷。

21. 測試人員應站在最終用戶的角度上看問題(UX)。例如，輸入框得到默認的輸入焦點；快捷鍵等。

22. 在每一個軟體的需求之外，還存在著一些”公理”，不言自明的。需求規格書不可能面面俱到，測試員可以根據這些”公理”來擴展需求。

23. 不以機率小而不為。

24. 有些功能可能是界面上沒有入口、看似沒有的，但是在某些條件下卻會出現。

25. 盡量對可能交互或產生影響的產品都有所了解，這樣在考慮問題的時候思路會更開闊。

26. 再考慮複雜場景前，可先以基本場景為切入點，接著列一些提綱，然後再根據一個個的提綱去思考、去突破。

27. 數據不是靜止的，我們需要使用動態的思維方式來考慮問題。

28. 瞭解同事的工作，就能夠做一些跨模組的思考，把測試做得更深入。並避免報告重複的bug。

29. 面對一個窗口的時候，從”變量”入手做測試是一個好的思路。既然它是變量，變成什麼就都有可能。

30. 除了琢磨模組自身內部包含的功能外，我們還要把它和其他相關模組放在一起測試。

31. 有效數據和無效數據都是需要驗證的(有時候他們被稱為合法的和非合法的數據)，測試中需要正反兩方面的用例。

32. 拆解功能的流程，然後逐一分析測試，用以避免遺漏掉很多問題。

33. 狹義上的UI測試：專指對操作介面的非功能性的測試。

34. 文檔保持更新，測試保持更新，保持一種在動態前進的心理預期。任何文檔不可能是一勞永逸的。

活著~~

活著是由大陸的作家 余華 所著。
本書主要在講述主人翁福貴的一生。他如何從田僑仔，然後敗光家產，接著被抓去當兵，
後來又怎樣回到家中，直到最後剩下的孤單一人。

在敗光家產後，他想著如何養活自己母親和妻兒，於是向地主租了五畝田地來耕作。
在被抓去打國共戰爭時，他想著如何活著回家，於是在槍林彈雨中搶著小米及大餅。
在中國解放後，回到家的他，想著如何在超英趕美的大躍進中取得食物養活一家人。
在家人一個一個經他手落土於西村後，最後想著的只是如何單純的讓自己不會餓死。

這樣簡單、深刻的描述了福貴這一個小人物的一生，雖沒有引人入勝的精采情節，
但卻讓人愈讀愈無法釋手。

花了幾天時間看完後，在看完的當下讓我想起了雷洛探長最後在劇末問家僕的問題。
｢人這麼辛苦是為了什麼？｣
｢為了吃飯。｣

我的成功可以複製 － 唐駿

Today, I read a book "My success can be replicated".
It is a biography for Jun Tang(唐駿), one of the best CEOs in China.
I think it is a good book for everybody, whatever you are students, engineers or managers.
I summarized some contents as follows:


1.成功的秘訣是什麼？做人簡單，做是勤奮。成功4+1：4分別代表智慧、勤奮、激情和機遇；1代表性格。

2.能考入重點大學固然很好，但是並非進到重點大學就可以解決你的問題，也不意味著到了非重點大學你的人生就缺少機會。

3.只有勤奮才能真正引領以實現人生的目標。其實每個人的智商都差不多，每天我比你多工作20%，也許就意味著我成功的機率多了50%。

4.大學裡的學習絕不只是簡單地把書本讀會。讀什麼專業固然重要，但是比這更重要的是培養自己學習的能力。

5.當周圍人沉迷於溫飽時，你應該去發現新的機會所在。如果你在一家公司裡感覺工作很安逸，你就需要尋找新的發展空間。

6.在一個人具備相當的經濟基礎、管理經驗、對未來方展的預見能力、對公司業務模式的深入理解和對市場的全面了解之前，個人創業並不是一種可取和可行的選擇。

7.每一個看似低的起點，都是通往更高峰的必經之路。任何時候都沒不能放下的成就。這種心態可以使人無往而不利。

8.第一份工作不是選一份好職業、不是選一份好薪水，而是一定要選一家好公司。因為一家好公司可以在各方面奠定你的職業基礎。

9.每個人的職業生涯一定要有良好的規劃，不能盲目努力。沒有目標地工作，在勤奮也沒有用，而且5年、10年以後，你會發現你還在原地踏步。

10.一個成就事業的人，最重要的素質是對工作的激情，而不是能力、責任心或者其他東西，雖然他們也不可或缺。

11.我們在企業裡要做得不是抱怨、不是提意見和建議，而是真正的對公司做一些實質性的改進。能提出問題，又能提出解決方案，且還能論證出方案可行性的人才會真正的被重用。

12.不僅做好自己的本職工作，還要替公司考慮哪些做的不合理或者不夠完善的地方。與上級長官溝通的規範，應該先和直屬長官溝通，在一級級地向上匯報。

13.真正的創新必然是基於對市場的了解，對客戶反饋的觀察，開發出來的產品一定要適應市場，提出的模式一定要能解決實現的問題。

14.一定要做自己最內行的東西，一定要在自己本身的職位上來提升自己。從技術做到管理，角色的轉變首先是一個學習的過程，其次是一個潛移默化、循序漸進的實踐過程。

15.許多了不起的成功，其實都靠點點滴滴的細小努力積累而成，作人就是這些細小努力中最重要的部分。向上、感恩、關心－這三種性格是做人最需要的。如果一個人能力不錯、性格又好，想不成功都很難。

真夏方程式~~

兩三個月前看完寫的心得，剛剛在寫我的夢的時候看到，順便貼上來~~


花了兩天的時間看完了東野圭吾的最新作：真夏方程式結局真的很出乎意料，湯川說的很多話也很值得玩味。

這是一本述說 偵探伽利略－湯川學 與 一個小學生 一起度過暑假的故事只是在其中發生的有人死亡的事件，而且那個人是一個退休的刑警我並不想描述太多關於這本書的內容，只是想討論一些湯川說出來的我覺得是圍繞在整個故事的一句話：恐怕會使得某個人的人生嚴重扭曲。很多殺人事件，每一個人的想法都是一定要找出兇手，釐清事實，雖然這樣並沒有不對但這樣的事實卻可能使得某個人的人生嚴重扭曲。

最近看了不少的推理日劇，其中有一個故事是：一個只相信自己的女生，也是所有事件的主謀，但她卻非常的相信男主角(刑警)但最後男主角發現自己都被這個女生主謀給騙了，於是他整個爆發要討回來，並設下陷阱抓到了那個女生也許看起來好像是解決一個案件，但卻毀了一個人的人生，就是那個女生因為從小的一個人，女生誰都不相信，只相信自己，連很崇拜自己的跟班，也只想著利用而已而那個刑警是他第一個相信的人，但最後還是欺騙了她她非常的難過，並且封閉了自己這樣的結果，讓她無法去體會與瞭解，她身邊其他的人對她的關心，尤其是那個跟班女生

也許有人會覺得那個女生活該，因為她是直接犯案人，但她還是人~~

柯南的故事中也有提過類似的劇情，並不是所有的事情都要全部說出來的~~

而這次書中的故事，就是那個小學生：恭平因為大人的欺騙使他成了共犯，但他完全不知道，直到故事結尾時，他也慢慢的發現也許湯川可以全部都說出來，讓所有的真相還原但，他知道這樣做將使得 恭平 剩下的人生造成嚴重扭曲

於是最後他對恭平說了這段話：任何問題一定都有答案，但答案不見得能立刻導的出來。換成人生也是一樣的。今後你會碰到很多無法立刻提出答案的問題。每一次煩惱都有價值。但沒有必要焦急。想要找出答案，很多時候自己必須成長才能找到。所以人一定要學習，要努力，要不斷磨練自己。這次的事件，到你能找出答案那天為止，我會和你一起抱著同樣的問題，繼續煩惱下去。千萬不要萬記，你不是孤單一個人。

看完之後，我能不斷的咀嚼這段話，其實人生很多事情都是這樣的也許故事中這段話是說給 恭平 的，但在現實中，這段話是可以說給每個人的大家都是經歷這樣過程而成長：疑問，煩惱，學習，瞭解

或許這整篇文章，只是想跟自己說：也許你現在身邊就圍繞著很多沒有答案的問題，但不要焦慮、也不要急躁慢慢來，突然有一天，所有的事都會豁然開朗的~~

如果高校棒球女子經理讀了彼得杜拉克~~

最近看了這本書

大概的內容就像標題所說的

一個高校棒球隊的女子經理 如何透過彼得杜拉克的管理方法 讓球隊打進甲子園

看完這本書的時候 感觸很多

不論是對於之前亂讀的管理學

還是在經營社團方面

回想起來，當社長時

自己真的蠻失敗的

沒有留住社員的能力

沒有提高社員的演奏能力

沒有團結社團的能力

整個只有一個爛字可以形容

虧我還是管理學院的

看了這本書 回想了很多 當社長時發生的事情

如果我也能夠這樣的管理我的社團

不知道會有怎樣的結果

雖然都已經過去了 也算是一種學習吧

書中的理論與棒球實務 搭配過去的社團經驗

好好的思考一番 真的讓我學到不少的東西

這真是一本很有趣的書啊~~


July 14, 2011

Peopleware~~

最近比較有空一些，所以就再看這本書。這本書和人月神話堪稱是軟體工程界的重量級巨著。在裡面我看到一個有趣的小故事，是作者狄馬克和一位大型專案的經理交換實戰經驗時聽到的。

以下是作者所描述內容的節錄：

幾年前，我和南加州一個大型專案的經理交換實戰經驗，經他講述在專案中把瘋狂的時間壓力加諸於部屬的效果。兩名組員的離婚可直接歸咎於超時的工作；一名組員的小孩染上毒癮，原因可能出在孩子的爸一年來忙到無暇善盡親職；最後，測試小組的組長精神崩潰。
隨著他不斷敘述這些可怕的經過，我開始明白，此人正以一種奇怪的方式在向我炫耀。你也許會懷疑，要是再有一兩個人離婚或自殺，這個專案就會大獲成功，至少在他眼中是如此。
－狄馬克

數學女孩 - 費馬最後定理~~

｢費馬最後定理｣ x^n+y^n=z^n, 當n>=3的時候，沒有自然數解
證明概略 - 使用反證法
1.假設：費馬最後定理並不成立，即x^n+y^n=z^n,當n>=3的時候，有自然數解。
2.根據假設，當x,y,z為自然數，n為質數且>=3時，可以製造出弗維曲線。
3.弗維曲線：橢圓曲線的一種，但卻不是模型式，即無法透過黎曼zeta函數與自守形式做連結。
4.也就是說有非模形式的半穩定態橢圓曲線存在，弗維曲線為一半穩定態橢圓曲線，即約化到有限體f_l的時候，會有重根。
5.懷爾斯定理：所有半穩定態的橢圓曲線，都是模形式。此為有限制的谷山志村猜想，在谷山志村猜想中針對的橢圓曲線是沒有限制的，即所有的橢圓曲線都是模型式。
6.由懷爾斯定理可以知道，非模形式的半穩定橢圓曲線並不存在。
7.上述的4.與6.互相矛盾。
8.因此可以得證，費馬最後定理成立。

日光旋律~~

    星期五，部隊放假，和弟兄一起坐計程車回新竹，在等待父親的到來時，我走進平時常去的書店，剛走進去，在書店的一隅便看到一本勾引我眼光的書，一個簡單的書名，一個朦朧的封面，日光旋律，一個在黎明中的琴鍵上跳舞的女孩。原來是一本網路小說，讓我回想到過去曾看過一本讓我印象的網路小說，幸福專賣店。我看著這本日光旋律封皮的簡單介紹，它著實吸引了我，使我出手將它帶回。

    終於回到家中，我打開這本書，開始仔細的品嘗它，一本富含友情、愛情、哲理的書，一本很能接觸到我的心的書，一本簡單、淡淡、不矯揉造作的一本書。一個發生在寧波的故事，淡淡的擁有，痛心的失去，簡單的描述，白話的言語，很久沒有看過這樣的愛情故事，真的讓我繞梁三日，三不五時的去回味其中的情節及饒富寓意的字語。

落葉呀，當它落下的時候，是樹在痛呢？還是葉子在痛？

    簡單的一句，直白的描述，卻是讓人深思的問題，是葉子在痛還是樹在痛，看到這句話的時候我也思考了一下，不同於書中的回答：我覺得應該是爬在樹葉上，結果跟著一起摔下的毛毛蟲最痛吧？我有了自己的一套看法。我一看到這個問題，就覺得真是一個好問題，不同的人都會有不同的想法，有人可能會說是葉子、有人可能會說是樹，也可能有人說是毛毛蟲等等，然而我卻覺得是人，看到這個現象，提出這個問題的人。
    因為樹跟葉子沒有神經是不會痛的，而且這樣一個亙古不變的現象，這麼多的人看過，問的人卻不多。例如蘋果從蘋果樹掉下來，沒有人問是蘋果在痛，還是樹在痛，只有一個人發明了讓後輩痛恨不已的理論。所以一切都是端看，看到現象的人的內心，人是一個很奇怪的動物，喜歡把自己內心的情緒投射到其他宇宙萬物中，像古人們常用動、植物來表現自己的情緒。落葉呀，當它落下的時候，是樹在痛呢？還是葉子在痛？我覺得是看著提出問題的人的心最痛，他可能失戀了、可能投資失敗了、可能成績考不及格了、可能剛剛跟家人吵了一架等等，痛的是這個人的心，心痛驅使想法，於是想著是樹還是葉子在痛？寫到這裡讓我回想了大學時的一些心痛往事，但都已如遠去的船，船邊的水紋~~