今天在珍饈吃飯時在 程式設計師提升生產力秘笈 質疑權威章節裡面看到一個有趣的小故事…

說有科學家做實驗，把一群猴子關在一個房間裡面，放了一個樓梯並在樓梯上方放了一串香蕉，當開始觀察後，聰明的猴子們花了一點時間在房間內找到梯子，並學會爬梯子上去拿香蕉，但當猴子爬上去拿香蕉時，科學家就在房間內放出大量的冰水，科學家馬上得到一群憤怒的猴子。在接下來的時間，猴子們很快的學會不能接近梯子。
接著科學家換掉房間內的一隻猴子，剛進入的猴子很快的找到梯子並打算爬上去吃香蕉，但馬上被其他猴子阻止，並大打一頓，吃了苦頭的猴子之後也不敢前往梯子了…
之後科學家一個一個把猴子慢慢換光，之後再也沒有猴子敢接近梯子了…

沒有照原文打上，但是原文描述的更有趣一些，看到這裡可能還不知道在做什麼，作者在這是在提他工作中發生的一件有趣的事。

在程式設計中，programing style是一件重要的事情，例如變數命名中的駱駝峰與底線，例如：getString(),get_string()
這件事在我寫了兩年程式以後才開始慢慢發現，當我開始考慮這件事時曾經煩惱了一段時間，思考著該採用什麼風格？有什麼取捨點？各有什麼好處？，閱讀了幾本相關的書籍以後，慢慢有一些領悟，當時的理解是認為style只是一種在team work時對整個程式的一種統一的感受，閱讀的書名已經忘了，當初找到跟style最有關的書，就直接拿閱讀了，後來看完才發現 style 以外在思考的其實是一種語意的清晰，最終期待的目的其實是一種自我解釋的語言，在不寫任何註釋的情況下，能夠讓程式本身的命名與編排方式可以表達自身所代表的含意。
在沒有注意的情況下，剛開始入門撰寫程式時，根本不會考慮到這一塊，但到理解了以後，撰寫程式耗費了很多時間在思考變數的命名與編排統一風格的程式，主要除了相信書上所說明的以外，也相信著閱讀(修改)程式比撰寫的次數還多，所以希望在團隊合作中，可以寫出讓別人也能夠輕鬆理解與維護的程式。

回到憤怒的猴子…作者當時發生了一件趣事，就是撰寫測試的程式時，需要較具描述力的函式名稱，testUpdateMyNameAndAssertCheck 例如此，但是當使用Java統一的programing style駱駝峰時當單字過多時，閱讀會變得有些困難，他馬上想到改成採用底線表示 test_Update_my_name_and_assert_check ，並認為較清晰，但馬上引起他團隊部份程式設計師的反感，說為什麼你要破壞風格？
雖也得到一部分人認可，但是他是首席程式設計師可以決定，書中舉出上面故事，主要想要表達說，雖平常做的每件事情都有他的意義，但是請隨時檢視自己所作的每件事情，有沒有忘記了初衷，當初也到底是為了什麼才建立風格的呢？

其實也認為自己時常太被動的吸收接收到的觀念，而沒有仔細檢視是否適用與身旁的情況，而一昧的接受流傳已久的觀念。

他在另外一章也有提到，在物件導向開始時的第一本巨著(small talk)，值得去閱讀，從程序式轉物件的第一本巨著，雖已經過了很久了，但是閱讀後更能知道當時時代背景所發生轉變有多大的意義，雖與質疑權威有一點相反意，但我認為也跟這裡所要表達的有點類似呢！

2010 3 14 補充
今天突然想到在日常生活中比較長發生類似這件比喻的實例，在PTT上不能打注音文是從許久以前開始許多板的板規明定禁止，目的是不希望用這種不標準的敘述方式來降低文章閱讀性，進而達到抑止注音文在網路上的流行(副作用)，後來或許許多人故意在鬧，刻意打了一些注音文邊緣的東西，造成版規越訂越嚴格，說什麼情況可以什麼情況不行，甚至懶得管就整個禁止，到後來變成鄉民運動..看到就會罵，甚至只是「一」不小心打成注音的「ㄧ」這種不算造成瀏覽困難的小事，然後推文就會開始指責說怎麼可以打注音文，然後發文的人也不曉得為什麼要被指正，但也被迫改正並且道歉…並且越演越烈…最近似乎有較好轉的現象，但是讓我想到這些被指正的人…是否知道為什麼不能爬上樓梯呢？