昨天,今天,明天

小時候，我媽是個銀行會計襄理
工作的銀行後門就有個幼稚園
平時就把我寄放在那，下班後就一起回家

因為古時電腦不發達，銀行少，業務相對多
傳票支票現金疊的滿滿跟山一樣，常常都要忙到六點多才能回家，
所有人都一樣

每天放學到下班中間
一個小鬼在銀行裡面活蹦亂跳

「媽咪~~偶功課寫完了 -w-//」
「乖～拿這邊的白紙去畫畫，不要吵摟」
於是我拿了一堆印壞報表紙畫無敵鐵金剛

「媽咪~~偶肚子餓了 >o< ... 」
「乖～這裡有１０塊先去買麵包吃，不要吵摟」
於是我買了四個小餐包，吃的渣掉滿地

「媽咪~~好無聊想回家睡覺了 zzz ... 」
「乖～先去後面趴著回家在叫你，不要吵摟」
於是不知誰的辦公桌被我沾滿口水

沒錯，是每天


連帶童年也分非常的銀行文化

那時不過六歲，我知道傳票跟支票的差別(因為叔叔都叫我幫忙拿)
那時不過六歲，我知道什麼叫會計年度(因為那天都好晚才能回家)
那時不過六歲，我知道開關金庫的方法(因為關好門才能回家)
那時不過六歲，我知道哪些數字容易混淆，比方說:17,06 (因為阿姨都叫我幫忙抓)
那時不過六歲，我知道會計襄理的章要蓋在支票的哪格(因為我媽蓋不完叫我幫忙蓋)

幼小的記憶真是好蠢，是吧
但我相信不只我一個


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝


歲月不饒人，今天，銀行滿街而立，科技進步，網路發達，
每個行員加班都是推業務，
誰還對帳？誰還對傳票？誰還戴眼鏡仔細看17跟06？

我以為不會有這種故事了，那只是個時代的悲劇

直到我看到ＸＸ軟體公司的一個精美桌上月曆，
每個月份都有一幅員工子女畫的圖，還有寫給父母的話

爸爸都很晚回家／媽媽在家還工作／一星期見不到幾次面／假日都沒辦法帶我出去玩
1-12月都差不多內容

我驚覺，故事不過換個地點罷了
而且內容更加驚心動魄，
只慶幸，演員數目少了一點點


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝


最近有個在軟體公司上班的朋友離職了，
每天工作超過１４小時，程式一改再改，CMMI也只是助纣為虐
舊的人一直跑，新人一直補，整間公司不知道再幹麻．．．

罄竹難書

跟他聊天的時候又回憶到此事，
我把故事說給他聽，再一直感謝他的英勇奮鬥
「時代考驗青年，青年創造時代」這種都出來了

「放屁！」他只回我兩個字


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝


很多人跟我說，寫程式的宿命就是這樣，加不完的班，改不完的Code
(如果還加上補不完的文件...)

如果有時光機回到２０年前，你跟我講會計年度結帳那天能準時回家
六歲的我會笑你不懂

所以我不相信宿命之類的，既然電腦能改變別人人生，為何不能改變我們自己的？

看看每個新技術背後，不都是想多擺脫一些這種"宿命"？
看看每個方法論背後，不都是想多解脫一些這種"包袱"？
[Mythical Man-Month][Peopleware]兩本書加起來都50年了

沒有銀彈，還是要尋找，最少我們有好幾顆銅彈了

或許有天我發覺我自己也是被宿命玩弄，
也許有一天我會很累想放棄，
但是不在此時，不在此地

人月神話

這是一本軟體專案開發的書
而且是40年前的
嗯？40年前？那時候我都沒出生勒，
而且我懷疑那時候的字典根本沒有「Computer」這個單字！

站在書店翻著這書心中還一直唸「這我早知了」
但是不爭氣還是買了

心得概要：

其實都是一些很古老的"老梗"
一直到今天 ,該死人類還是玩不出新把戲

1. 程式設計有苦也有樂，樂趣在能輕鬆創造，就跟魔法一樣；苦在必須事事完美，最常出現的bug總是很蠢 ,etc:大小寫,正負號,if先後順序
2. 人月是個神話：人多並不會贏，因為寫程式工作大都是連續且不可分割 ，十幾個人一起做再加上溝通的時間，搞不好比兩三個人做慢
3. 系統需要整體概念，這個讓一個人決定就好
4. 為何進度會落後這麼多，因為每天落後一點點；所以定mileStone的時候要夠明確，明確到自己騙不了自己
5. 文件的寫法？該寫那些？總是配合人類需要，而不是電腦需要：直覺，經濟，人性
6. 越成功的系統，開發者與客戶間的互動越頻繁
7. 沒有銀彈：其實拿來打電腦那一個現在不錯了(雖然java裡面那些api，還是多的跟怪物一樣，一堆還要套Design Pattern，看懂Design Pattern也要花不少時間，不過總比跟記憶體跟CPU排程搏命好)，可是打人類的那把卻越來越噁心(一堆怪方法論，怪工具，怪技術都出來了)
   
8. 軟體工程這條路還很漫長XD

總結：

其實書的內容比我寫的還多很多，像是跟預估跟第二系統之類的，有些則是我太年輕沒辦法體會(OS/360??組語寫薪資系統???)，但每每看到某個片段，就好像看到人生以前的走馬燈，歷歷在目，又好像能預測接下來的歲月，如猶在耳，只能說這條路還很漫長，但我相信走下去一定有終點，一定有！

深入淺出SQL(Head First SQL)

這本書出的時候，已經工作兩年多了

SQL也差多不用兩年了，大概不用深入淺出了？
但我只能說
「相見恨晚」

要是能早點看到就能少走點冤枉路

我讀了多少：

速讀了一遍，但是除了正規化、Subquery、join、union，這幾部分有仔細看

關於此書：
這是我看過的第四本HeadFisrt，所以我對裡面的詭異內容已經很習慣了XD
這系列的書除了易讀還有一個好處，會做一遍錯的事給你看
而且這本寫的不該在SQL做的事..我100%全部幹過,

....而且不只錯一遍

心得：

1. 資料與表：基本的格式跟資料型態，還有那該死的DB Null，他原來不是真的Null(相對於物件世界)
2. Select,Update,Delete：我的青春阿.....
3. 正規化：我從沒看過一本SQL書在講正規化的時候，花１６頁講一個沒正規化的Table，然後在本章最後一頁才完成正規化定義，真的很瘋狂，但是很有效率
4. Alter：我都用GUI工具調整Table格式，從沒用過Alter，我錯了對不起
5. order,group,sum,count,limit：常用，看看而已
6. 複數Table設計，複數Table操作：Table與Table之間到底該怎麼互連，也是跟Excel最大的差異(我認為!)，我自己寫過很多爛Table，就是因為沒考慮好互相之間的關聯，最後才會遇到複雜一點的指令就兵敗如山倒，我終於懂了！
7. subquery：比較少用，算是重新認識一下
8. outer join,union,except：這是數學！這是集合！

結論：

想當初我再上課的時候，老師都教的好難
或者我該說，太正常了，可是工作的時候通常大部分時間在處理不正常
所以變的學校教的好像沒用？

其實並不是，只是我還不曉得如何避開危險
看完後最大收穫，我對這些危險又有更多認識

Don't Make Me Think

好吧，我承認我買這本書的原因是我很喜歡這句話

「Don't Make Me Think ！」

腦殘才是王道！

本書內容：

大概是在講網站的使用性跟親合力之類的，一些以使用者角度來看的網站設計原則


心得：

1. 別讓我思考：使用性(usability)最高原則，用語越簡單越好
2. 人讀網頁跟讀報紙差不多，都是用掃描的，不太可能有人真的一字字看
3. 導覽列(Navigator)很重要，要在網頁上造出人類的空間概念都得靠他
4. 首頁應該如何配置？放上使用者覺得重要的東西，而不是業務單位(這裡我的想法又被證實一次，讓讀資工這種腦袋放磚頭的人管首頁，是很危險的！)
5. 如果遇到使用性的問題，找個人試試看好不好用，比在會議桌上爭論來的好

結論：

Yes, Dont make me think!

火箭說明(Retro-specification)

火箭說明(Retro-specification)：

在項目已經啟動之後才開始寫技術、功能說明

By wiki

白話一點就是先寫程式才後生文件

不過其實英文原文(Retro)字義並不是要講火箭，而是只另外一個"倒退";"追溯"的意思
但是我很喜歡
因為這種文件通常跟火箭一樣看起來很炫，但是實用價值很低

我不太會寫文件，
但是我知道不是跟Code一起或是早一步出來的文件，基本上都沒參考價值
(逆向工程不算)

好的文件通常說明「人類做什麼」，是表達人的心智模型
大部分的都是火箭說明都變成在說明「電腦做什麼」，是參考程式碼
所以說我不看文件，直接程式碼一行行看，搞不好更快能弄懂程式再寫什麼

現在很多大公司都搶著通過什麼CMMI，ISO之類的東西
讓我想到國中歷史課教的滿清末年的自強運動
改革只學外人船堅砲利，而不是其思想文化
最後結果大家都知道是失敗收場

我許多同學的公司都有通過，
在下資歷尚淺，不敢妄談成功失敗
但是就我聽到的而言，沒半個有學其精神

歷史老師都會說要記取歷史的教訓
諷刺的是，歷史的教訓告訴我們歷史只會一再重複

對寫程式的人而言，
文件的目的在於能節省了解或撰寫系統的時間，而不是浪費更多

寫給SA的UML/MDA實務手冊

學UML到底有什麼用？

是很多人的疑問，我也是
我剛開始工作的時候，UML一個也不會，程式照樣寫的出來
後來多會一點，其實也是半知半解，畫出來的東西殘破不堪，也毫無參考價值

這本是我看過的UML書裡面，最感覺是有真的用uml在解決問題，整個就很有質感

本書內容：

用OOAD/UML的做法，來實作一個分析設計案例，
大部分都在畫圖跟跟使用者對談
換句話說，程式碼一行也沒有

我看了多少：

看到第八章就沒看了，大約４／５吧

心得：
一個基金的申購 從Use Case開始，一直到商業邏輯的Class Diagran跟Sequence Diagram，一直"很順利"做下去
(為何我做的都沒發生過這種事？大概是程度差吧....囧)

滿難形容的，大概看了才知道


結論：
我對分析不是很拿手，所以也不太看的很懂
只知道有個高手秀了一手給我看，就當看看熱鬧Ｑ

別說你忘了他

「這段程式在寫什麼？」

「我忘了，要Trace一下看看...」

這段故事有沒有很熟悉？
上一次出現這台詞的時候，你是問的人還是答的人？
還是自問自答？

人類本來就很健忘，所以應該無時無刻留下提醒自己的紀錄
文字也好，uml也好，註解也好，便利貼也好，
總比看一行行的神秘符號來的好

剛開始工作時，我也沒寫註解的習慣，
仗勢自己的小聰明，只管Code能Run就好，管他啥註解跟文件的
不過久了後，覺得老是自己在整自己，昨日之我永遠比今天之我還聰明

試著寫一點註解以後，才發現這樣以後看起Code來快多了
我才了解到，與其浪費生命在Trace火星文，到不如多花時間留下點記憶

有些人會說，註解/文件寫的濫的要死，有跟沒有還不是一樣
不過我覺得這是做與不做的問題，而不是好跟不好的問題
註解/文件寫的好是一種藝術，那需要很多的經驗跟天份
但是，有或沒有是一種態度，程式人該有的責任

為自己的程式負責，能動的不代表完成