[讀書心得] 少，但是更好

人生定期總是要買些洗腦書來看才有動力，這本書濃縮一句話當作心得就是，一次把一件事好好做好。

p.36~39
又是從清除衣櫥開始，找出自己真正喜歡的衣服，不要捨不得丟已經花很多錢買卻穿不到的衣服，決定好要哪些要丟就去丟了，不要在想著下一次。上面衣服換成其他事物都適用。

東西少，留下的東西都是自己最重要最好用的，把心力放在真正好的事物，而不用花時間去處理那些普通好的事物。

p.68~69
學會分辨那些才是真正投資報酬率高的事物，都想做好但都做不好，不如好好做好最重要得事情。承認自己必不完美，沒辦法做好所有事情。

P.78~80
引述本書"一個爐口代表你的家庭，一個代表你的朋友，第三個是你的健康，第四個是你的工作。為了事業有成，你必須關掉其中一個爐口。而為了真正的功成名就，你必須關掉其中兩個。"

每個人追求的目標不同，但要了解取捨，有得必有失，才不會永遠羨慕別人。你現在得到的你失去的，都是你過去的選擇。不要負面思考為何失去，這本來就是當初的取捨。

p.129~133
面對選擇，列出權值，只要你對他評價低於90%，那就是不夠好，那就要拒絕。

p.151
要清楚自己的人生目標，當我們走到人生盡頭，是否一路走來沒有遺憾，多想想就會知道哪些是自己真正該做的事情。

p.159~163
要有說不的勇氣，當別人與你價值觀不同時，要能堅定自己的信念。

p.223~230
解決問題的根本原因，而非想出一堆應急的解決方案。

p.255~259
活在當下，不去想過去的錯誤，不去擔心還沒發生的事情，活在當下。

引述本書"輸球和被痛宰是兩回事。被痛宰表示他們比你們好。他們更快、更強、更有天賦。...輸球則是另一回事。它代表你失去焦點。它代表你沒有專注在必要的事情上。"

p.262~p265
"當下，何者為重"。弄清楚最重要的項目，按優先順序排列，寫下來，劃掉現在不重要的事情，開始做。

寫在紙上，減少了必須記在腦中的壓力。

這樣想，你會更快活 讀後筆記

可能是我臉書寫的內容太暗黑了，所以我爸拿了這本書給我看，內容雖然很八股，但仔細想想，自己還真的是知道確沒有好好做到，人生總是說的比做的簡單。以下記錄一些對自己工作會比較有幫助的部分，與有需要的人分享之。

面對突如其來的意外

問自己最壞的狀況是什麼？ > 接受它！ > 設法改善它！

簡言之，就是盡快恢復思考分析的能力，開始解決問題而不要被當下不好的情緒所左右。

左腦運動法

右腦掌管情緒，左腦掌管邏輯(我以前都是痛左腦)。當遇到情緒不穩定的時候，就開始計算所在的環境有幾種顏色(白色的牆壁、藍色的滑鼠、紅色的杯子…)，又要辨識顏色，又要計算數量。這樣左腦就會開始運作，壓抑右腦的機制進而控制情緒。

遇到問題前先回答四個問題

1. 問題是什麼？
2. 發生問題的原因是什麼？
3. 目前有什麼解決方法？
4. 所有的解決方法中，我建議的解決方法是什麼？

自己經過回答這四個問題後，答案就自然而然出現了。

活在當下 學會放下

每天都當成只有今天來過，不要虛度光陰，你永遠不會知道明天你還有沒有機會去做你想做卻還沒做的事。

工作就像是個沙漏，裏頭雖有成千上萬粒沙，但通過中間的時候，還是只能一粒一粒通過。專注於手上的工作，不要分心去想其他事情。工作是做不完的，請挑最重要的做，然後認真去做！

約耳跟松本

又是整整一個月沒有更新的狀態了，沒有跑去生小孩，花了比較多時間在運動閱讀和手機上，但這些都不是沒有更新的理由。不更新是不需要理由的。很感謝大家的不離不棄，不過大部分訪客都應該是Google Sony那台W320才跑進來的，本站虛無飄渺的題材，已經讓本站的關鍵字走向不可預知的答案上了！

 

約耳這系列有兩本 － 趣談軟體和續談軟體。趣談的內容比較偏向工程師對軟體設計開發的兩三事，續談的語氣就比較偏向管理者對於專案管理和創業經驗分享。也許是從作者的blog的文章中收集成冊出的書，所以內容編排方面比較單元化，就像看小叮噹一樣，沒有看到上一話也不會影響到閱讀的樂趣。

在提到松本這一本之前，我不得不說一下，我之前一直以為Ruby之父是高橋征義，這再次證明記名字絕對是我人生最弱的項目之一。書的標題很長，但簡單來說就是用一種不是工具書的方式。而是以先介紹軟體設計概念，而後面在輔以Ruby語法的範例，從頭到尾貫穿的一本書。

對於軟體工程師來說，這三本都是很值得花時間閱讀的書。就像我之前看過的程序員修練之道，懶惰是好的程序員具備的特質之一，使用機器的時間成本絕對遠低於使用人腦的時間成本，約耳這兩本談軟體的書，對於一成不便的工作流程也許會讓你有新的想法和作法。

松本這本，我不得不很靠北的說，這根本是我這幾年在軟體開發上跌跌撞撞的編年史，讓我們來看看本書章節：

．物件導向與抽象化
．多重繼承的問題與Mix-in
．基於原型與基於類別的物件導向概念
．靜態語言與動態語言的差異
．Duck Typing與Metaprogramming
．區塊和閉包的強大威力
．設計模式與開閉原則
．Ajax與JavaScript
．Ruby on Rails與MVC
．開放類別與Monkey Patching
．字碼問題與Unicode
．正則表達式與「鬼車」
．整數、浮點數、位元運算
．程式最佳化技術與平行程式設計
．程式弱點與攻擊手法
．程式的時間問題
．資料的永續性與XML
．函數式程式語言的特性
．記憶體管理與垃圾回收機制
．程式碼產生技術與Ruby的擴充方式
．開放原始碼的精神與選擇授權的觀念

從物件導向、中介編程、設計模式等軟體設計概念，到字碼、時區、i18n這些比較實務上會遇到的問題，本書全部都有提到。這裡頭寫的主題90%我都有在這幾年遇到過，不管你會不會寫Ruby，我都覺得有入手一看的價值。

最後，我發現我只要不認真去構思章節，胡亂寫就會寫很順，越是想要認真寫些什麼，反而就寫不出什麼，這跟我在籃球場上的表現還真像啊！該是去公司練投的時間到了！各位掰！

有人來信問我考SCJD的心得，我懶得來信回了，因為我之前很認真打了一篇回信給其他人，但也是肉包打狗還不如寫在部落格自嗨，至少有人會看到。心得就是，想證明自己有一定的英文及軟體設計的實力，請當作是自己給自己的試煉去考。這證照對於找工作有沒有用，多少也許有一點但要看你找的是不是Java相關的工作，像我找韌體的話，這張跟大便一樣。然後，強者是不需要用證照來找工作的，直接用實戰經驗和業界名聲就被挖角挖到老了。以上！

不想浪費時間的程式設計師之道（中） – Input & Process

（照片來自於型男飛行日記的劇照）

我不是什麼很牛逼的程式設計師，不像電影裡頭演的電腦駭客，一坐在電腦前手指就開始不停地在鍵盤上飛舞。我也不像網路上的一些大師，隨時都在玩最火熱的技術在開發，知悉所有框架介面用法和規格定義。

我大部分的時間都是在電腦前追蹤自己或是別人寫出來的蟲子，更多的時間是用Copy Paste別人的程式碼然後做些小小的修改，能碰到新東西的機會並不多。想要擠出些多餘時間來精進自己專業知識，有效率地快速完成老闆交付的工作就是我努力想要達成的目標。

這篇文章是自己這些年實作下來的野人獻曝文，文章會寫得很簡短直白，我自己正在用的工具程式也會附在文內，參考書目寫在最後面。按照我的工程師思維，本系列文分成以下四個部分：

• Precondition ：營造一個好的工作環境。
• Input：決定要做哪些工作。
• Process：利用一些方式有效率地工作。
• Output ：工作告一段落之後。

歡迎大家留言討論，也許是您自己另外又寫一篇完整文章來分享自己的作法（歡迎留下您的文章連結），那就更棒了！

Input

人生沒有全拿這種事

＂人生沒有全拿的＂是我自己常對自己說的一句話，人的時間有限，但是慾望無窮，我們只能挑出幾個想要的目標來完成。工作也是一樣的道理，根據＂重要＂和＂緊急＂這兩個參數，就可以將工作分成四個優先權等級。

• 重要 + 緊急
• 重要 + 不緊急
• 不重要 + 緊急
• 不重要 + 不緊急

我習慣上是事情一來就分類後，按照約定時間或結案時間填入Google Calendar中，然後把最近幾天需要完成的工作填寫到To-Do List上。To-Do List也許只是一張放在桌面上的紙或是一張貼在螢幕旁的便利貼。要作的事情寫下來，寫的東西放在固定的位置，隔天很容易就能切換回原來的狀態，有了這份安心感，回到家大腦也不會被尚未完成的工作所佔據。

寫到這邊，其實我覺得這部分用Filter反而比較貼切！ XD

Process

學習

三分鐘念完一本書

閱讀時不是逐字逐句讀懂才往下讀下去，不要求第一次就完全讀懂，第一次用快速掃描的方式將整本書翻完，閱讀的同時用直覺將重要的部分折頁。第二次閱讀針對折頁部份劃線或是筆記，爾後有空就翻這些重點部分，這些重點在不斷地反覆閱讀下，很容易內化成自己的基本常識。

說起來很玄，但舉個例子，有人問Kobe執行最後一擊會不會特別緊張。他回答說＂這些投籃我每天都練習很多次了，對我來說這就跟打噴嚏這種身體反應一樣。你打噴嚏會緊張嗎？＂

紙上談兵

記錄我會選擇不需要花太多時間的方法，因為人容易抗拒丟棄花時間作出來的東西。所以我選擇的工具都是，很容易完成，很容易修改，當然也不會排斥丟掉重新寫一份。

我大多使用純文字格式作些簡單的記錄，理由是不會有轉換或沒有辦法開啟的問題。

需要創意發想或是整理想法的時候我會使用心智圖（XMind），好處是圖形容易激發人的聯想力，另外不論是軟體還是用筆畫都很方便重新調整架構。

需要作投影片的時候，我會選擇高橋流投影片，同樣有簡單意修改的特性，當然視狀況最後我會修改成比較比爾蓋茲流的投影風格，但相對來說來是簡潔許多。

程式碼是程式設計師最好的朋友，但在時間許可的情況下，我還是比較喜歡用UML工具（ArgoUML）來設計自己的架構或是了解其他人寫的程式碼。UML產出的圖形可以作為設計時的參考，也可以保留作為設計文件的概念圖。

待續…

參考書目：

• 少做一點不會死 
• 時間活用術
• 程式設計師提升生產力秘訣
• 時間管理 給系統管理者
• 超閱讀力 不誇張 一分鐘讀完?本書
• 高橋流簡報

不想浪費時間的程式設計師之道（上） - Precondition

（照片來自於駭客任務的劇照）

我不是什麼很牛逼的程式設計師，不像電影裡頭演的電腦駭客，一坐在電腦前手指就開始不停地在鍵盤上飛舞。我也不像網路上的一些大師，隨時都在玩最火熱的技術在開發，知悉所有框架介面用法和規格定義。

我大部分的時間都是在電腦前追蹤自己或是別人寫出來的蟲子，更多的時間是用Copy Paste別人的程式碼然後做些小小的修改，能碰到新東西的機會並不多。想要擠出些多餘時間來精進自己專業知識，有效率地快速完成老闆交付的工作就是我努力想要達成的目標。

這篇文章是自己這些年實作下來的野人獻曝文，文章會寫得很簡短直白，我自己正在用的工具程式也會附在文內，參考書目寫在最後面。按照我的工程師思維，本系列文分成以下四個部分：

• Precondition ：營造一個好的工作環境。
• Input：決定要做哪些工作。
• Process：利用一些方式有效率地工作。
• Output ：工作告一段落之後。

歡迎大家留言討論，也許是您自己另外又寫一篇完整文章來分享自己的作法（歡迎留下您的文章連結），那就更棒了！

Precondition

什麼時間做什麼事

花個一個星期觀察自己，甚麼時段自己的大腦處於一個絕好調的狀態，甚麼時候是自己腦殘時間，整理出自己一天當中的大腦狀態曲線圖。我們之後就可以根據這張曲線圖，將困難的工作安排在大腦的絕好調時段，其他時間則是處理一些比較不需要大腦的工作。

創造出一個你會想待的地方

善用抽屜、文件夾和書櫃來收納工作上所需要的東西。東西放在固定的地方，讓自己用身體反應去找需要的東西，而不需要花時間腦力去找。整齊的桌面也釋放出一切都在掌握當中的印象，無形中也會減少自己心理上的壓力。



如同實體桌面，電腦的桌面也同樣地需要整理。整齊的桌面、有規則的檔案命名之外，如果同時開起許多程式，善用虛擬桌面（Dexpot）的功能，將不同類型的程式放在不同的桌面，用切換桌面的方式來取代在工具列上尋找程式。個人習慣使用四個桌面，一是上網收信，二是寫程式，三是各種Console介面，四是文書作業。所有工作被分成四個桌面，在接到工作的瞬間，便能快速切換到對應的桌面開始執行。

替自己創造靜默時間，工作在被打斷之後，我們需要更多的時間來進入狀況。早點進公司，利用這段沒有人打擾的時間來完成昨天沒有完成的工作。嚐試在離線模式下工作，別分心在與工作無關網頁上，然後在固定的時間點收信，而不是讓電子郵件不斷地中斷你。

一台速度快的電腦很直接地節省了程式設計師開發的時間。使用大螢幕可以顯示更多的程式碼，雙螢幕可以減少在程式碼與實作規格切換的時間。一個好的人體工學鍵盤能保護手腕關節。滑鼠支援上一頁下一頁功能的按鈕，方便我們在龐大的專案程式碼下跳躍。最後是一張好的椅子，這絕對值得投資不要跟自己的腰過不去，我只想說我看病都不只一張好椅子的錢了。待續…

參考書目：

• 少做一點不會死 
• 時間活用術
• 程式設計師提升生產力秘訣
• 時間管理 給系統管理者
• 超閱讀力 不誇張 一分鐘讀完?本書
• 高橋流簡報

少做一點不會死！ 越少越厲害的超簡單工作生活雙贏法則

標題很偷懶，直接就拿書名的主標題跟副標題來用了！在看這本書之前，我一直很樂中於找到同時處理多種事情的好方法，比如說邊吃飯邊看NHK新聞，邊看NBA邊上網，想要塞滿我醒著的這16個小時。完成的項目看起來是變多了，但實際的達成率就像是你快速把遊戲全破了一次，但卻沒有體驗到遊戲中的醍醐味一樣。

常看到的書都是在教我們如何在有限的時間下作更多的事，這本書試著用另一個角度去解決時間不夠的問題（題外話，其實我覺得當一個人開始會覺得時間不夠了，就已經是另一個人生階段的開始了。）－不用作那麼多事情。而我整本書讀兩次下來，感想如下面三點。

簡化

就跟準備考試一樣，你不可能把書全部背下來，找出重點針對重點準備，這就是一種簡化。這跟攝影的減法概念很相像，唯有不斷將雜物從構圖中去除，才能更容易將你想呈現的主題傳遞給觀眾。

核心價值

＂人生沒有全拿的＂－是自己常掛在嘴邊的一句碎碎念。

哪些事對自己的重要的，那些東西只是一時的慾望，哪些事是違背自己價值觀的，哪些事其實是微不足道的。找出生活中不重要或是根本不需要的項目，從待作項目中把它們刪除，只作真正重要的事情。

專心作一件事

學會重拾單工的樂趣，專注於眼前的事物，也許是工作也許是吃飯，享受每一個當下，用心去體驗每一秒。人腦本來就比較擅長單工架構的作業方式，把一件事作好，遠勝於把兩三件事搞砸。

 

心得雖然沒有提到，但其實最重要的就是要持之以恆，再好的想法若只不能長期持續，那就真的只是想法而已。簡單就是力量，讓我們一起加油！

重構-改善既有程式的設計

重構：狹義的解釋是重新整理已經寫好的程式碼。

重構：更廣義地解釋是不斷地整理正在寫的程式碼。

對於有重構思維的程序員來說，不論程式碼是否已經被完成，重構其實在編程過程中是不斷地在同步進行的。重構不在是笨重的黃金鎚！重構已經是一種內化行為！

三年前，剛考了一張號稱全民都有的SCJP，寫著自己都不知道有沒有OOP程式碼的菜鳥。還記得上班後第一次參加JAVA研討會，SDK的API都還不能算是熟捻的程度（現在也不熟XD），更何況大部分的議題都是不同應用領域的技術，兩天下來真的有萬念俱灰想死的念頭

（照片出處：http://www.flickr.com/photos/swanky-hsiao）

當時侯捷老師的議題是Design Pattern相關的主題，當時我還很開心想說中於是跟「寫程式概念」有相關的主題，此行終於能學到些可以用的技術。依稀記得走出會場我的臉是呆滯的，侯老師這堂課也是壓垮我編程信心的最後一根稻草。當時還不能夠體會編程之美的我，回到新竹的路上，腦裡都在想轉行的事情。從此到書店看到侯老師翻譯的書，眼光都不自主地飄開，跟勇九可以在地圖上選擇不遇敵一樣。

超愛看中文程式輸的我，寧願上網看英文的重構相關文章。一半的原因是當年揮之不去的心魔。另一半的原因也是我一直在等歐萊里，看它們會不會出一本無腦的深入淺出重構。三年過去了，沒盼到深入淺出重構的問世，也只好硬著頭皮買了這本重構聖經的中文版。

書花了一兩個星期就完食了，看完一整個是相見恨晚真的是恨自己怎麼硬撐那麼久才買。書裡頭得重點我就不花時間寫心得了（最近也沒時間寫），直接把值得推薦的原因寫上。

作者的文筆和翻譯品質都在水準之上。我最怕的程式書就是API的說明狂貼，要不然就是文筆不順，明明都是中文但整句看完卻完全看不懂作者想要表示什麼。

內容完全與編程技巧相關。沒有太多抽象空泛的長篇大論，每道手法的使用時機、詳細步驟和範例都一應俱全。

程式碼範例皆用JAVA與簡單的UML來說明。我不需要在花時間在思考語法轉換或語義的問題上。

文章編排簡潔，行距也夠寬，眼睛不會看到很吃力。

每個技巧是一個獨立章節，第一次看當觀念書看，整本看完以後，將來透過索引快速參照就變成一本實用的工具書。

自己的編程水準是找不太出這本書的缺點，唯一硬要挑毛病的話，大概是程式碼範例如果能使等寬字型會更好（果然水準不夠的人都是從外觀開始找問題XD）。

這本書最棒的地方在於，藉由範例讀者可以知道什麼樣的程式碼是糟糕的程式碼，而這原本可能是你需要犯上大量的錯誤代價才能學到的經驗。更棒的是，不僅教你釣魚連釣魚竿都幫你買好了，範例的後面就是解決問題的答案（XD）。

花上幾百元再加上認真讀個一兩個星期，而光譜的另一端是犯下已知錯誤不得不加班修改的爆肝生活，真的會想的研發都應該知道要選擇哪一種未來！

程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第八章讀書心得

續上一章 程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第七章讀書心得.

此為讀後重點筆記,好書值得大家購買閱讀.

本章是本書的最後一章,我終於 K 完這本書了,雖然頁數不多,但看原文速度真的慢很多啊!

注重效率的團隊 將之前章節強調的觀念,以套用在團隊的立場在強調一次. 成員間要多交流,大家互相學習及成長,把好的開發流程或概念帶進團隊來,整個團隊不斷往前邁進,公司對外才會更有競爭力.

無所不在的自動化 告訴我們電腦是處理重覆性工作的專家,懶惰則是好的工程師需要具備的特性之一,利用工具或自己開發程式,把需要浪費時間的工作交給電腦處理,省下來的時間再去學新的東西.

無情的測試 強調測試並不是用完即丟,或是寫完就不用去修改它的. 測試程式應該是不斷被執行,並且會隨著程式碼演化的.

代碼文檔不分家. 註解是程式設計師最好的朋友,多花一點時間到離職都可以受用無窮,大腦就應該拿去裝一些需要思考運轉的東西,而不是用來挖掘當初為何自己要這樣寫的理由. 另外,每一份印出的文件都只是當時專案的快照,並不代表其永久有效,透過使用開放編輯的方式,讓文件跟程式碼同步演化,文件才有其存在的價值.

巨大的期望 需要與客戶持續互動,才能確保專案是朝著客戶想要的方向邁進. 回饋的頻率拉得越長,其修改所需的代價也會越高.

傲慢與偏見 - 很日劇式熱血的一小章. 反正就是要激發讀者身為職人的自尊,我以我的程式碼為榮,別人看到作者是我就知道這是品質保證. 因為自尊所以更認真保證品質,品質提高別人對自己的 Credit 變高,如此便是一個良性的循環.

第七章 Pragmatic Projects

Pragmatic Teams

• 開發團隊必須重視程式碼的品質.
• 開發團隊必須察覺不論是專案內(ex:新需求)或專案外(新技術)的變化.
• 鼓勵團隊內的成員互相交流.
• 建立成員對開發團隊的認同感.
• 在一個專案中,給予每個人負責不同面向的責任,以免多個人都在做一樣的事情.
• 不要看完書就急著要求團隊開始實行,維持夠好的規範和風格即可,而不是將額外的負擔加諸在開發團隊上.

Ubiquitous Automation

• 當你發現自己不斷在重複某些步驟時,那就是該自動化的時候到了.
• 電腦本來就適合用來處理重複性的工作.

Ruthless Testing

• 透過測試能盡早發現問題.
• 發現問題後,將該問題建立成測試條件.
• 程式本身沒有問題,但給個不是使用者想要的東西,那還是有問題.
• 使用者不好上手的操作流程,也算是有問題.
• 越解耦的程式碼,若容易做模組測試.
• 測試覆蓋範圍的重點,不在於有測到所有程式碼,在於有測到所有的狀態.

It’s All Writing

• 再強的記憶力也抵不過一支筆.
• 註解說明為什麼要做這件事,動機和目的. 而程式碼本身會說明如果做這件事.
• 良好的變數/方法命名習慣,讓程式碼更容易被閱讀.
• 雖然這段程式碼你可能只會寫這麼一次,但它可能之後要被閱讀好幾百次.
• 比”沒有意義命名”還糟的是 – “讓人產生誤解的命名”.
• 利用工具或自寫程式,將文件的表現方式(ex: PDF, HTML …)從內容中獨立出來.

Great Exceptions

• 寫出來的東西不符合使用者的期待,那就是失敗.
• 藉由不斷與客戶互動(ex: 展示雛型),來確保成品是客戶所預期的.
• 試著超出使用者所預期,只要超出一些些,讓使用者覺得我們真的是想做一個很好的系統.

Pride and Prejudice

• 在自己的程式碼上署名以示負責.
• 尊重夥伴所寫的程式碼,你怎麼對他們,他們就怎麼對你.

程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第七章讀書心得

續上一章 程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第六章讀書心得.

此為讀後重點筆記,好書值得大家購買閱讀.

本章重點放在開始寫碼之前應該有的準備工作 - 收集需求,解決臭蟲,確認可行性,製訂規格 和 開發流程.

需求之坑 在於使用者很可能自己都不知道自己的需求為何的情況下,其實很多需求是在回饋的過程中,不斷地被挖掘出來的. 個人的經驗通常是,通過層層的關卡後,我做出來的東西,通常變的不會是終端使用者所想的功能,以至於後續會不斷上演砍掉重練的情況發生.

解決不可解的謎題 和之前提過的”靠巧合編碼”一樣,都是要求程式設計師要真正了解問題,把發生問題的原因解決,而不是掩飾表面或後續衍生的問題.

直到準備好 要求在寫碼之前要先規劃藍圖,房子不會邊蓋邊想要改幾層,但寫程式時常會被要求這要搞,但無腦之開寫的下場,辛運一點就是可運行但很難維護的程式碼,最衰的就是寫到一半才發現根本此路不通準備黑掉…

規範陷阱 相對於不規劃就編碼,它位於光譜的另外一端(凡事太過或是不及都不會是好事 XD),嚐試著一次完成所有的規格是件不可能的事,再加上客戶不斷增加或變化的需求,規格與實作往往會漸行漸遠. 做人腦筋不要太死板,規格也是一樣,且戰且走,邊做邊改,最後才不會拿到一本根本過時的兩千頁規格書.

圓圈與箭頭 要程式設計師對於各種開發方式採取開放的態度. 個人覺得這可以套用在各種地方,不排斥學習新知,好的學起來,不好的也了解壞在哪裡. 井底之蛙,以管窺天. 海納百川,有容乃大.

第七章 Before the Project

The Requirements Pit

• 將會變動的部份從需求中分離出來.
• 找出客戶為何需要此需求的原因,如此當你實作時才會更貼近其需求.
• 實際到使用者工作環境,觀察使用者會採取的行為操作.
• 利用工具紀錄新增的需求,好讓自己能夠知道目前到底增加了多少需求,以求通盤了解整體狀況.
• 從專案開始,就維護一份詞彙表,用來讓客戶,程式設計師以及其它人對照參考,確定彼此指的是同一個東西,而這份表格也能應用於使用者介面以及程式變數名稱上.
• 將文件放上內部網頁上,可供參與者觀看或編輯. 而非印出一份沒人會看也辦法即時更新的文件.

Solving Impossible Puzzles

• 跳脫既有的框架來思考問題.
• 遇到難題時,不要明知不可為而為之. 反之,列出所有可能的原因,然後一一去驗證,直到找到真正的問題來源為止.
• 靜下心來思考,哪些是真正的問題? 哪些只是衍生或是使人誤解的問題?

Not Until You’re Ready

• 準備好了再開始寫程式碼! 坐下來啥都沒想,邊寫邊想,那只能叫做敲鍵盤而已.
• 分辨你只是 想拖台錢 還是 真的覺得還沒準備好 的方法: 找出需求中你認為最困難的部份,開始寫一些 Prototype 的程式碼,若你發現你寫的很順,甚至開始覺得這樣下去只是浪費時間,那代表你已經準備好實作這個需求了.
• 正式編碼前先撰寫 Prototype ,就像大軍出動前會先派斥候去偵查敵方實力一樣.

The Specification Trap

• 不用想一次就補捉出系統的所有細節.
• 長篇大論讓人很好入睡.
• 取代先定規格再編碼的方式,讓 編碼 和 規格 同時進行. 這種開發流程鼓勵我們不斷從實作中得到回饋,然後將其轉換成最適合的規格. 編碼跟規格是同步在進化的,規格不在是一灘死水.
• 有經驗的程式設計師,在編碼時腦中應該會浮現最適合當前情況的設計抉擇.
• 在沒有考慮技術層面下,很容易定出沒有辦法實作出來的規格.

Circles and Arrows

• 對於各種開發流程,不要太過拘泥於形式.
• 客戶喜歡看到實際的產品,而非文件及圖表.
• 對各種開發流程採取開放的態度,學習並融合其優點,不斷改進自己的開發流程.

程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第六章讀書心得

續上一章 程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第五章讀書心得.

此為讀後重點筆記,好書值得大家購買閱讀.

本章主要強調的重點是 – 程式設計師是否真的了解自己在寫什麼. 而 程式黑手 與 程式設計師 的最大差別我想也在於此 - 是否有在用腦在寫程式碼,還是不管三七二十一拼出一個會動的東西而已.

靠巧合編碼 最好的解釋情境 – 修一個關於迴圈的 Bug ,只是不斷地去調整迴圈 index 的範圍,而不是找出錯誤的真正原因. 如果在寫程式時有這樣的心態,那你就是在靠巧合在編碼.

演算法的速度 使用 O() 表示法,在編碼(或 檢視程式碼片段)的過程中就能大概知道其效率,提早察覺效能上可能會遇到的瓶頸.

重構 鼓勵程式設計師週期性地檢視過去的程式碼,昨日的程式碼不見得符合現今的需要. 不斷地透過重構來整理程式碼,而不是在歪斜的骨架上搭建新的疊層屋.

易測試的代碼 在於寫程式之前就已經準備好測試的程式碼,如此所寫的程式碼不自覺就會以好測試為目標來下筆. 理想中,程式碼的大功能會被切分成小功能(這樣比較好分別測試). 另外,測試程式是重構最好的朋友,重構完是否搞砸了原有的功能? 問問測試程式是最快的方法.

邪惡的嚮導 也就是靠 IDE 工具生成出來的程式碼. 如同靠巧合編碼,是否真的了解程式碼,是 程式黑手 與 程式設計師 的最大的差異之處. 就算只是想當個程式黑手過日子,我相信多了解程式碼還是能節省許多解 Bug 的時間,好讓你回家看老婆抱小孩就是.

第六章 While You Are Coding

Programming by Coincidence

• 清楚自己要做什麼再下去做,不要只是盲目地寫程式碼.
• 倚賴可靠的結果,而不是”假設它應該是…”,遇上 假設 請實際去驗證它.
• 不要讓 過去的程式碼 限制了 當下的程式碼! 過時了那就重構它!

Algorithm Speed

• 對於 O() 表示法有所了解,並了解自己寫的程式碼其 O() 值.
• 如果真的看不出來,可以直接調整 input 將結果做成圖表,利用圖表看出大概的效能.
• 根據實際情況選擇適當的作法即可,不需要總是使用最完美的作法.
• 確認是瓶頸後再去優化它,而不要掉進過早優化的陷阱中.

Refactoring

• 與其說寫程式是在蓋房子,更不如說是在規劃你家花園,花草會爛所以你要加肥料,也許你覺得看膩了你又會買新的花回來種. 這裡要強調的是,需求及環境是不斷隨時間而變遷的,不符時宜的程式碼就可以重構之.
• 當你發現 1)重複的程式碼片段 2)正交性很差的設計 3)過時的資訊 4)效能差 的情況,這代表你該重構你所看到的問題了.
• 重構和增加新功能不要同時進行.
• 重構前先準備好對應的測試程式,這樣你能馬上知道你有沒有搞砸任何東西.
• 把重構拆成多個小步驟,每完成一個步驟就檢查一次,而不是一次重構完再來檢查.

Code That’s Easy to Test

• 若欲測試的模組有關聯到別的模組,那先從關聯模組開始測試.
• 測試程式能向別人展示如何使用你寫的程式.
• 測試程式能在你做了任何的變動後,快速告訴你是否改爛了哪些原本正常的功能.

Evil Wizards

• 了解利用工具自動產生出來的程式碼.

不好笑系列-籃球之星(The Five)

 

後面兩格的梗如果沒有看過 神劍闖江湖(十本刀篇) 的人應該看不懂(囧).

今年開始,打球的次數算是恢復到未受傷前的頻率,但自我訓練的時間少了很多,主要是不想給身體太多的負擔. 正所謂場上一分鐘,場下十年功,偷懶的下場就是累的很快.

一累就開始嘴砲,有時嘴砲到腳傷,又可以講他個三五分鐘. 但其實這根本不是什麼值得拿來說嘴的事情,深深地厭惡著這樣的自己.

今天又被說胖了,看來我每天下班要開始運動三十分鐘了. 打球雖然要佛! 但也要有佛的本錢才是!

推薦一套勵志好漫畫:

 

引述自博客來:

受到平成經濟不振的影響，由社會人所組成的籃球隊也一一被迫停止和解散。連名門「五十鈴汽車」的王牌，被譽為「籃球先生」的明星球員佐古賢一也遭到瞭解雇。再也沒有辦法打籃球了嗎…？！

就在此時，一隻球隊對已有引退覺悟的佐古伸出了歡迎之手。這隻球隊就是集合了全國被解僱的中年選手，準備奪下優勝的「愛辛」！佐古將在新的一片天中朝日本第一邁進！！

 

(圖片截自: www.asics.co.jp/pressrelease/2006-11-30.html)

真人真事改編,全套只有五集,個人覺得前面兩集很好看,一方面重點是放在當時轉隊時的故事,外加每一話點出一位老球員的經歷,感覺很像在看傳記一般.

但後面三集因為熱血梗用完了,二來幾乎都是在畫比賽的過程(籃球比賽要畫的吸引人真的很難),再加上劇中好像插入了一個虛擬的角色 - 朝日雄太郎(強到爆,不傳球都能贏球,超級大黑洞只想打 NBA 的超強新人.),強調世代交替的戲碼,如果是真有其人是還蠻熱血的,但上 Google 根本查無此人,真的有種在拖台錢的感覺. 囧rz

個人小評: (滿分五隻猩)

延伸閱讀:

• 佐古賢一 wiki

程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第五章讀書心得

續上一章 程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第四章讀書心得.

此為讀後重點筆記,好書值得大家購買閱讀.

本章強調彈性的好處,寫出鬆散低耦合的程式碼,在將來能用最少的修改以完成變動的需求(理想烏邦托是這樣).

解耦 就有點像 島耕作 在公司裡的作為 - 不結黨營私,越少的利害關係才能明哲保身. 其中的Demeter 法則,是在譔寫方法時很好用的一個開發心法.

Metaprogramming 又是更進一步將工作流程從程式碼中解耦出來,現在很多框架都也是用這種方式來做設定. 不過也代表除了程式碼之外,也得知道 要到哪? 做哪些設定? 設定的效果? ,以上是我在遇到設定時比較頭疼的問題(不過有好好看文件,這些應該都不是問題.).

時間耦合 是提醒在一開始就以將來會支援並行性的心態來撰寫程式,當加入行程的考量時,程式的設計不得不跳脫線性執行的思考,同時也比較模組化.

這不僅僅是 UI 主要是使用 訂閱/發佈 和 MVC 的概念,將 資料/商業邏輯 從 UI 中拔出來. 不過只有提到大觀念跟架構,實際寫法我建議還是要另外找書看,免得寫出一堆自稱是 MVC 的爛扣出來!

最後一章黑板,我只能說寫的很抽像,若是套用在開發流程上,我知道是要大家在同一個地方做溝通與設計的動作(ex: wiki),不過後面將黑板套用在程式設計時則完全是沒有提到如果實作,本人極度懷疑這段是請某個會劃大餅的 sales 寫的啊! XD

第五章 Bend, or Break

Decoupling and the Law of Demeter

• 限制程式元件間的互動,其實是在保護所有的程式元件.
• 減少藕合就像裝潢房子,你只會跟設計師溝通你的想法,而不是跑去跟木工/油漆工/水泥工說你想要怎麼做. 另外,如果你跟設計師說你這面牆想要塗成黑色,設計師不應該是把油漆工叫到你面前 –> designer.callPainter().drawColor(Color.BLACK) // 火車頭寫法 囧rz
• 根據上面例子,如果客戶不想要跟其它人沾上關係的話,那你的設計師就要夠包山包海. 換句話說,設計師類別裡頭會有大量的包裝 (Wrap) 方法,將客戶的要求轉給 (Delegate) 師父去執行.

Metaprogramming

• 讓程式碼抽像化(以高階的思考撰寫),將實作細節隔離出來(容易抽換,文中是期望用改寫 config 的方式,在執行期動態切換.).
• 越容易變動的地方,越是要用更容易替換的作法來處理.
• 用設定檔的方式控制常會變動的流程/實作方式(常使用第三方框架應該知道我在說啥),而不是直接進入程式碼層次去搬泥巴.
• 重新啟動很快的小程式,可以採取一開始就載入配置檔(只會載入一次)的策略. 大型需要長期執行的程式,則採取每次執行時總是載入配置檔的策略.

Temporal Coupling

• 時間耦合度在程式設計中,指的是 順序 以及 併行 這兩種情況.
• 利用 UML 的活動圖分析客戶提供的工作流程(通常是線性順序),找出其實可以同時執行的行為,以排除時間耦合度(原本被順序相依性所耦合).
• 開發時就以支援並行性的角度來設計架構.

It’s Just a View

• 利用 發佈/訂閱 的型式 取代 集中發送訊息/SPAM … 等不良作法.
• MVC <- 這東西一言難盡,有心人請找書看與實作. 很多人號稱會 MVC 寫出來還是只有 V ,我自己也不敢保證自己有正確實作出 MVC . XD

Blackboards

• 用黑板來溝通,主要概念就是有一塊大家可以 共同編輯/觀看/歷史紀錄 的環境,一個集中式的腦力激盪的空間,而不是每個人都在自己的小房間內搞自己的想法.

程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第四章讀書心得

續上一章 程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第三章讀書心得.

此為讀後重點筆記,好書值得大家購買閱讀.

本章終於開始進入寫程式的階段,利用語言或是外掛提供的功能,在進入程式實作之前建立一些規則/定義,讓潛在的問題提早在開發階段發生,而不是出包會黑掉的部署階段. 囧rz

按合約編程在實際開始編碼前,先規定好預期的 input 和 output ,我剛開始寫程式似乎都是用此想法開始,但後來我比較喜歡用測試先行的方式來寫碼.

死掉的程式就是死了! 換句話說有問題就讓程式早點死掉,忽略問題雖然可以讓程式繼續執行,但有很大的可能它已經是個活死人了(而已你也只會覺得它怪怪的),人死了才會讓程式設計師去正視問題!

斷言編程 不同於 合約編程,合約編程定出預期的事物,斷言編程用於檢查程式設計師(不要相信自己是本書的中心思想之一)認為不會發生的情況. 現實生活中,我還是習慣用 測試先行 來包含 合約編程 + 斷言編程 這兩種作法.

例外 是 Java 處理錯誤的方式,我只知道 1)不要亂隱藏例外,2)要寫有可讀性質的例外,3)將例外用於真正異常發生的時候,而不是當作 true/false 的昂貴代替寫法.

Java 有垃圾回收機制,所以資源部份我就不亂發表心得了! 以後我若改去寫 C 的工作,我相信我要重花一段時間好好學習這一塊. XD

第四章 Pragmatic Paranoia

Desing by Contract

• 正確的程式就是”不多做事! 也不少做事!”.
• 寫出懶惰的片段程式碼 - 也就是專注做好一件事的程式碼.
• 合約 會定義出 進入條件 和 結束時會得到的結果.

Dead Programs Tell No Lies

• 利用 例外機制 盡早在開發階段就發現錯誤.
• 一旦在某個地方發生了自以為不會發生的錯誤,這之後的程式也就不能夠被保證是正確的.
• 假裝還活著的程式(對問題視而不見) 比 早點死掉的程度(強迫中止讓開發者察覺) 造成更大的傷害.

Assertive Programming

• 若你肯定不會發生,那就加上 Assertion 來確保真的不會發生.
• Assertion 是用來檢查不會發生的情況,而不能當成程式流程的一部份(若關掉 Assertion 就會造成流程錯亂).
• 出貨時,在講求效能的地方關掉 Assertion ,其它地方則持續開啟 Assertion .
• 若檢查行為會影響程式的行為(Side Effect),這就是有問題的程式.

When to Use Exceptions

• 觸發例外的時間點: 當未預期的事情發生. 換句話說,你預期發生的事情並沒有發生. ex: 開啟一個系統內應該要存在的檔案.
• 如果你不確定這件事該不該發生,那 不觸發例外 是合理的作法. ex: 開啟一個使用者指定的檔案.

How to Balance Resources

• 拿到資源要記得把資源還回去(有始有終).
• 由拿到資源的人(方法),在離開時負責釋放資源.
• 釋放資源的順序 要跟 取得資源的順序 相反.
• 若程式在不同的地方,都有取得同一組(多個)資源的需求,取得資訊的順序要一樣,可以減少死結的情況發生.
• 巢狀資料結構適放資源的三種策略:

1. 最上層 必須負責 其擁有的資料結構的釋放資源動作.
2. 最上層 只釋放自己所佔用的資源.
3. 如果最上層其下擁有資料結構,便不允許釋放資源.

美象成真

這是一本偽裝成小說的勵志書. 這本號稱專為三分鐘熱度的人寫的書.藉由上班族主角跟一隻奇怪的大象神-迦尼薩的對話,每天這隻機車的大象都會叫主角做一些奇怪的事情(擦皮鞋,掃廁所…),當然每件事情後面也會有它的意涵,逐步地讓主角(其實也就是我們)在不知不覺中變得更好.

以下是書中的所有章節:

【課題1】擦皮鞋
【課題2】在便利商店捐出零錢
【課題3】吃飯吃到八分飽
【課題4】早一步發現別人想要的事物
【課題5】逗身邊的人笑
【課題6】打掃廁所
【課題7】下班直接回家
【課題8】誇獎當天努力的自己
【課題9】試著放棄什麼一天
【課題10】營造一個讓自己持之以恆的環境
【課題11】每天早上照全身鏡整理服裝儀容
【課題12】問別人自己最擅長的事
【課題13】問別人自己不擅長的事
【課題14】愉快地想像夢想
【課題15】告訴自己「我運氣真好！」
【課題16】讓別人免費為自己服務
【課題17】為明天做準備
【課題18】討身邊最重要的人歡心
【課題19】發現別人的優點並誇獎對方
【課題20】偷別人的優點
【課題21】看徵人資訊雜誌
【課題22】去拜拜
【課題23】進入受歡迎的店內，觀察受歡迎的理由
【課題24】送禮帶給別人驚喜
【最後的課題1】從今天開始做因為沒做而後悔的事
【最後的課題2】本著服務世人的精神訴說夢想
【最後的課題3】幫助別人成功
【最後的課題4】毛遂自薦
【最後的課題5】每天心懷感謝

我自己比較有感觸的章節-試著放棄什麼一天. 上帝對每個人都很公平每個人每天都只有24小時運用,就像杯子能裝的水是有上限的. 我們有時應該要選擇放棄些什麼(ex: 上網,看電視放空…),就像把水杯裡的水倒掉一些,你才有空間裝些不一樣的東西.

不以強調教條式的寫法,讀起來也就沒有什麼壓力. 而已還有描寫一些日本上班族的想法(ex: 為何下班都要去喝一杯,總是要進大企業上班…),外加有些思考方式真的很日式,算是跟其它勵志書很不一樣的地方!

故事中不時會穿插一些真實名人的小故事(機車象號稱他教導過他們 Orz),所以不只勵志看完還有長知識喔! 還能用這些知道去唬美妹喔! XD

(原圖來自: http://i.ndsbbs.com/news/fast/200904/03-18856.html)

除了日劇,電影外沒想到還有出 NDS 軟體,真不虧是熱賣200萬本的大作! Orz

程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第三章讀書心得

續上一章 程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第二章讀書心得.

此為讀後重點筆記,好書值得大家購買閱讀.

本章開始介紹程式員應該設置好有效率的工作環境和工具. 建立專屬於自己的一套火藥庫,並不斷將這套環境更新及進化.

純本文的威力在於它沒有太多格式問題,人腦可理解也很容易寫程式去解析它. 雖然文字檔是人眼可讀的,但只要寫入的人無腦,還是能寫入一堆不可讀的資料,讓文字檔失去人腦可讀的特性.

Shell 這方面,只能說 GUI 讓更多人擁抱電腦,但在 Shell 才能讓電腦發揮它的長處 - 重覆性的耗時工作.

編輯器算是影響程序員產能的重要因素之一吧! 雖然我知道打開筆計本寫扣看起來很屌很大師,但我還是寧願打開我的 IDE ,背好熱鍵,讓 IDE 幫我產生樣版打出正確的名稱.

版本控制真的是好物,但不知為何總有人喜歡這邊留一份那邊留一份,然後再來人眼比對. 我想這這就是學校講授上和業界實務上的鴻溝之一吧學校沒教的事吧! XD

測試首先就是要冷靜,不要有先入為主的假設,遇到假設就要能證明它. 最後找出臭蟲的源頭並修正它,不要只做些表像的修補工作. 試問你家馬桶大便沖不下去, 1)你會每次大便完,把大便撈出來丟垃圾桶? 2)還是把馬桶修好?

文字處理算是程式員常常在接觸的東西,所以學好一個本文處理語言算是有益無害的東西. 有時只是臨時需要(用完可丟的)一個文字處理小程式,像 JAVA 的正規表達式的寫法就很難用,這時你若會寫 Ruby 就方便多了! 雖然我對於學新技術很排斥(我不愛追最新的東西,我覺得這東西追不完,這個十年你可以看到都是這些人在追,但下個十年可能就是完全沒看過新的一批人了. 至少我會想拿這些時間去學些可以永遠使用的技能. 但我還是很感謝勇於追新技術又肯分享的人.),但我不排斥能讓我早點下班的技術觀念. XD

透過程式碼生成器,可以將一些重覆的概念封裝在同一處,讓產生器根據此處來產生其它語言程式碼(讓它變成一個 Build 的步驟之一),變動只出現在一個地方,其它所需要的變動都讓生成器幫程式員做完了.

第三章 The Basic Tools

The Power of Plain Text

• 使用可讀性的純文字,而不是用純文字寫些不可讀的東西來困擾自己.

Shell Games

• GUI 限制了某些原本應該能達成的功能.

Power Editing

• 自己是否已經發揮 IDE 的最大效用.
• 用好一個 IDE 而不是每種都碰一點但又不熟.
• 讓熱鍵變成你的反射動作. 沒有人在用滑鼠寫扣的,除非你是 CP 流的人還說的過去.

Source Code Control

• 再好的記性都比不上版本控制系統.

Debugging

• 解決問題而不是找理由或是責怪創造他的人.
• 冷靜以對,而不是一股傻勁就開始玩泥巴.
• 找到問題發生的源頭,而不只是胡亂解決表面上的問題.
• 試著把問題講解給別人聽.
• 不要什麼問題一開始就先入為主地認為是別人的問題. 再檢查一下自己的程式.
• 若覺得這段程式碼應該是對的,就拿出證明而不要只是瞎猜假設.

Text Manipulation

• 至少學一種本文處理程式.

Code Generators

• 被動式程式產生器產生出來的結果是會被保留下來的. ex: 事先產生需要昂貴計算的查表(儲存結果),這份表格會被保留,之後就不用再經過計算來取得結果.
• 主動式程式產生器產生出來的結果是用完即丟的. ex: 利用 SQL Schema 當做來源,透過程式產生器產生高階的對應程式物件,這行為屬於 build code 的一部份(代表每次都會重新產生). 這樣做的好處是 – DRY(Don’t Repeat),只有一個地方負責資料庫表格的結構.
• 在由不同程式語言所組成的應用程式中,有時會有兩個物件對應到同一個概念的情況(重覆是一件不好的事)發生. 此時可利用獨立於程式之外的的表達方式,利用程式產生器來產生各自的程式碼.
• 產生器不一定是要產生程式碼,也可以用來產生 XML, HTML, 文字檔.

程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第二章讀書心得

續上一章程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第一章讀書心得.

此為讀後重點筆記,好書值得大家購買閱讀.

持續第一章,本章點出一些開發人員必要的心法,謹記在心可以避免很多低級錯誤!

重覆之罪這我幹醮很多次了! 不管再怎麼憤怒都不應該 CP 來 CP 去,好好靜下心來思考是否可重新利用(重構)可運行的程式碼,這才是王道. 另外減少重覆同時也是在縮小出包的範圍. XD

正交就是指每個元件的交集程度,交集越小也代表重覆的概念or責任越少. 但正交性這章看完,我不知道為什麼我總是會想到”上班好同事,下班不認識.”這句話. XD

可逆性白點就是話不要說太死,說太滿結果最後說錯可是很丟臉低. 寫扣前要好好想想是否未來此處有變動的機率,留點後路以後也不會太痛也可以少加一點班.

我個人開發還常用 Tracer Bullets 這個技巧,不浪費每一個我摸索所寫下的程式碼,我果然有客家人的血統.

相對於 Tracer Bullets ,我覺得寫程式用 Prototype 真的很腦殘,刻一個看起來正確卻無用的東西,真的是白癡!

領域語言我覺得跟第一章所說的溝通有關. 如何用對方了解的事物解釋對方所不了解的東西,就某方面來說,我覺得這是一個好 RD 跟 普通好 RD 的差別之一.

最後一章節就真的屌了! 估時程,坦白說,我真的覺得有些東西根本沒辦法估時程,有時候你很認真估了一個時程,到實際上也不一定照這個時程跑. 我覺得與其自己學好這些技巧,不如讓整個團隊也重視這個觀念來得有用!

第二章 A Pragmatic Approach

The Evils of Duplication

• DRY.
• 不要用低階的思唯層次寫註解,這樣子的註解可視為程式碼另一種型式的重覆. 另外,不符合程式碼的註解 不如 沒有註解.

Orthogonality

• 系統中,每個程式元件都專心做好自己的事. 關於正交性最簡單的說法 : 大家都就做好自己該做的事.

Reversibility

• 沒有替代方案是最危險的事.
• 需求總是一直在變的.
• 一次寫一點點,回饋快,砍掉重練也不那麼痛.

Tracer Bullets

• 不是在紙上討論出所有未知問題的正確規格,而是用一種實驗性程式碼來找出問題的答案,每一次都是在寫一個從頭到尾的使用者案例.

Prototypes and Post-it Notes

• 相對於 Tracer Bullets , Prototype 是隨時可以丟棄的程式碼,最終不會成為產品上的一部份.

Domain Languages

• 領域語言幫助你補捉客戶的需求,隨著轉換成實作碼,最終它會變成可執行的程式碼.
• 領域語言讓你先在高階層次思考問題,之後再來考慮低階的實作細節.

Estimating

• 估時程前先問問自己: 對方是想要多精確的時程?
• 單位要使用正確. 14天跟兩個星期都代表一樣的時間長度,但人們會覺得14天很快就到了(然後每天來問你好了沒)!
• 估時程前,可以問問之前有做過一樣事情的人.
• 估時程前,先了解問題.
• 別人叫你估時程時,你最好回他”我估好再跟你說”.

八招就讓你的員工不快樂

本文為 8 rules to discourage your employees 的簡短重點筆記,有興趣的人請讀原文.

鼓勵大家要積極一點

主管很愛的一招,此口號一出員工”應該”就會積極地尋找任何問題的解答!

扼殺過度積極的人

可以叫他去寫文件,寫公司內部使用的工具,重構程式碼 或 依照你最近看書學到的開發流程來寫扣. 反正就是不要讓他學自己想學的東西!

隔離 管理階層 跟 開發團隊

去外面找個專長是開會(總是攜帶皮制的筆記本或 iPhone,常安排開會,無俚頭的非專業討論,很嚴肅地說著完全不著邊境的話.)的管理者就好.

頒獎給某人

只有被頒獎的人士事會上升.而其他人的士氣會下降.

不讓員工使用他們想用的工具

不準他們使用他們覺得好用的工具. 如果你又要求要有一樣水準的結果,那使用效果會更好!

分散他們注意力

電郵 + 開會 + 吵雜的工作環境

在教育訓練中打擊他們的興趣

強迫他們參與他們完全沒有興趣的教育訓練.

叫他們解 Bug

最好是要他們解不是他們寫的 Bug ! 再狠一點的話,加上一個很急的時間限制!

 

最後送上一個我覺得最能厄殺 RD 的情境:

我相信你可以的

當你估算後發現你無法在時間內完成工作時,你將這個事實反應給你的上司. 你總是有機會聽到這個答案 - 我知道這工作很艱難,但我相信你可以的…

程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第一章讀書心得

此為讀後重點筆記,好書值得大家購買閱讀.

本章沒有太多技術性的東西,主要是導正程式設計師上一些心態.

貓吃掉了我的源碼是多麼愚蠢的理由,但有時我就是會說出這種不成理由的理由,面對問題不應該急著推卸責任,找出可行的解法才能體現個人價值所在.

專案中的無序狀態,根本就是在說我. 面對殘破不堪的程式碼,即使不能大破大立的砍掉重練,也應該築起防火牆,讓腐敗不影響後面新加入的程式碼.

石頭湯教我要做團隊中的摧化劑,大家一起學習才是最快的進步方式. 不知水溫的青蛙則是在警告我們要不時注意大環境潮流,更新自己的知識才能維持自己的價值.

寫出夠好的程式碼 然後 就夠了,前往下一個村莊吧.

建立自己的學習地圖,定期以及有效率地投資自己的知識. 我們是科技業,這不完全是一個寫越久就越有價值的達人系統行業.

最後,我們要學會如何好好表達自己的想法. 也許我是不喜歡跟人溝通才進入工程師這個職業,但事實上,除了跟電腦溝通(寫扣),我要跟主管溝通,我要跟客戶溝通. 沒錯! 很殘念的事實! 我們必須學會與別人溝通.

第一章 A Pragmatic Philosophy

The Cat Ate My Source Code

• 對自己寫的程式碼負責.
• 不要害怕承認錯誤.
• 出錯時,不要找藉口,而是要找解決方法.
• 說藉口時,先想想這個藉口別人聽起來是否很可笑.
• 藉口與指責並無法解決問題.
• 不要想做不到,而是要想還能做什麼.

Software Entropy

• 一但程式碼開始出現不好的事物,便會加速專案的腐爛速度. (破窗理論 可參考 景氣大蕭條與塗鴉.....)
• 不予以不好的程式碼出現. 重構它,改寫它,即使只是注釋,都能避免進一步的毀滅.
• 保持程式碼的有序狀態,因為誰都不會想當第一個搞亂程式碼的人.

Stone Soup and Boiled Frogs

• 人們總是害怕變化,不願意分享. 自己要試著去做團體中的催化劑.
• 做事要看大方向,太專注於不重要的細節容易造成 最後結果 偏移 當初的目標.
• 不時環顧四周的變化,而不是整天在死守在自己的工作上.

Good-Enough Software

• 寫出夠好的程式碼. 所謂的夠好指的是 使用者會滿意,後續維護者會感激 而 你自己看得懂你自己在寫什麼.
• 知道什麼時候該收手,離開已經夠好的程式碼! 你要了解這世界上並沒有完美的程式碼!

Your Knowledge Portfolio

• 知識跟經驗是我們最大的資產,但很不幸地我們是科技業,你的知識跟經驗隨著新技術的出現而失去其價值.
• 知識管理機制 跟 投資機制 類似:
  • 強者總是規率地投資 - 這是一種習慣.
  • 多方面的學習 是 長期成功 的關鍵.
  • 聰明的投資者 會按比例將資金 保守投資 和 積極投資.
  • 買低賣高以取得最大的投資報酬率.
  • 定期重新檢視及規劃之前的策略.
• 不要只讀電腦書,別忘了你寫的程式也是在服務”人”.
• 對任何事物保持開放不排斥的態度.

Communicate

• 再好的點子沒有人知道也沒有意義.
• 自己要知道自己在說什麼.
• 對方知道你在說什麼.
• 在適當的時間點溝通. 星期五下午六點就不是一個好的時間點.