話說，剛進入這條不歸路的時候，那時還是用 VB6。
第一次見到師父 ABBY ( 哈哈！！這個英文名字在台灣應該找不到第二個了吧！)
他老人家寫程式碼的時候，我的下巴都快要掉下來啦！！ ( 當時我的表情應該就是這樣子吧！ )
簡直就是用飛的感覺，這是人類可以辦到的嗎？
無論是寫 code 或是 追 Bug 都幾乎沒用到 mouse
他老人家告訴我幾個訣
真的是受用無窮呀！！就跟騎腳踏車一樣
基本條件
一個好用的鍵盤
最好是那種 104 標準+ 的，和自已喜歡按下去的感覺。( 找到那個 fe 是很重要的 )
一定要可以英文盲打！
這是寫 code 的基本原則，而且是要同時「兩隻手」可以迅雷不及掩耳的速度打完 public void main()
工具一定要支援 Interllisense
這一點尤其重要，別再跟我說「這個有跟沒有一樣呀」，能少打幾個字就少打幾個字啦！
記住自已常用的快速鍵
別跟我說不知道啥是 F5
----------- Visual Studio .NET 系列開發平台 通用 ------------------------------------------
廢話不多說啦！馬上來介紹幾個自已很常用的
選取整行的字 [Home] , [Shift]+[End] ( 這個順序沒差 )
選取一個區塊 [Shift] + [↓] or [↑] 有時要搭配 同一行選字時請再 [Shift] + [Ctrl] + [→] or [←]
選取一個區塊 ( 一行一行 ) [Shift] + [Ctrl] + [↓] or [↑]
選取一個單字 [Shift] + [Ctrl] + [→] or [←]
呼叫出 InterlliSense 小視窗 [Ctrl] + [→] or [Ctrl] + [J] ( 要看當初的鍵盤設定 )
執行程式 [F5] ( 其實我還是常常看到很多人用 mouse )
逐行執行程式 [F11] ( VB6 的話印象是 F8 )
設定/去掉 中斷點 [F9]
進入呼叫 method 的程式區塊 [F12] ( 這個很方便喔！一定要試試 ) ( VB6 的話印象是 F10 )
找東西 [Ctrl] + [F] / 取代 [Ctrl] + [H]
--------- 補充 -------------------
快速切換不同工具/ 文件時 [Alt] + [Tab]
在有頁籤時想要快速切換時 [Ctrl] + [Tab]
其實只要以上 10 個幾乎可以適用在大多數的地方 ( 一開始也用不了這麼多啦！ )
原本沒有寫說要寫這方面的，但過了這麼久發現這個部分很多人其實都沒有這麼在意，工具有提供卻沒有用覺得很可惜 ( 這個以前教其他同事就教了至少超過十幾遍了吧 )
這些東西可以供大家參考參考，可以有更多自已的時間 提升平常寫作的效率喔！
2010年11月13日 星期六
經典的一句話「生氣就輸了」
現在在網路的論壇上交流是一件很平常的事！
不過也因為這樣子，當意見相左時常常會有所謂的筆戰。
每次只要一看到，心中可是油然敬佩了起來呀！
任何一種主題都可以吵起來，大到政治小到卡漫都沒有問題！ ( 不過有的時候問題太腦殘，大家就會公x )
而且每每吵起來都可以引經敘述之前誰誰誰講過的話！又是在那裡提過的數據！
自然而然地出現了「沒圖沒真相」 ( 口說無憑 )
相反地，若是擺明就是沒結論的話！大家都會有一個共識
「認真就輸了」
「生氣就輸了」
在談判斷只要動到氣，之後就通通都不用談啦！因為會掉入到對方的圈套中。
轉載自http://www.dotblogs.com.tw/franma/archive/2009/07/13/9406.aspx
不過也因為這樣子，當意見相左時常常會有所謂的筆戰。
每次只要一看到，心中可是油然敬佩了起來呀！
任何一種主題都可以吵起來，大到政治小到卡漫都沒有問題！ ( 不過有的時候問題太腦殘，大家就會公x )
而且每每吵起來都可以引經敘述之前誰誰誰講過的話！又是在那裡提過的數據！
自然而然地出現了「沒圖沒真相」 ( 口說無憑 )
相反地，若是擺明就是沒結論的話！大家都會有一個共識
「認真就輸了」
「生氣就輸了」
在談判斷只要動到氣，之後就通通都不用談啦！因為會掉入到對方的圈套中。
轉載自http://www.dotblogs.com.tw/franma/archive/2009/07/13/9406.aspx
標籤：
經驗分享
2010年11月12日 星期五
我們團隊只用版本管控就夠了嗎？？
一開始小弟待的開發團隊根本沒有所謂的版本管控，要管控？
那就開發人員自已平常多燒香拜拜啦！
定期備份在自已電腦上的檔案不要掛掉，只要最新的程式沒問題就好！
反正老闆和客戶都只看現在交付給他們的程式。
後來，大部分的團隊也已經能接受用「版本管控」管理所有程式碼是件重要且必須的事。
但！這樣子真的就足夠了嗎？？
======= 題外話！===========
小弟的確有看過一些團隊是用「工作單」的數量來決定一個人的績效，光只用數量來決定是一件非常要不得的，畢竟工作(bug) 都有區分成簡單和困難的。若是被分配到困難的成員豈不是很衰？？而且也不公平！ ( 所以日後該團隊的工作追蹤和會議進度形同批鬥大會，超慘的 )
所以大家要麻就是充數量！要麻就是造假！ 這只是增加團隊的 loading 而已。
到最後工作單就沒有人要看！ ( 因為大家都在填心酸的 )
那還不如不要填。
===========================
首先 可以先聽到幾種答案！
是不夠！所以我們有自已寫的系統在記錄所有的工作單
不然就是！我們有用一些免錢的系統在幫我們記錄 ( 通常都是 Bug Tracking System 這一類的 ，這和第一點是一樣的問題 )
覺得只有版控不夠！但完全不知道應該要怎麼解決！
只有版本管控就夠了，反正這個專案都只有我一個人！
前兩種都很好！因為已經有這個習慣了！
但程式碼 和 工作項目 彼此之間沒有關聯，就無法很方便地由單找Code 或是 由 Code 找單
若團隊是 3、4的話！人的改變就會比較辛苦了！
若是能認同想要改善也就罷了！但很多時候可能會有結論就是！
反正沒有我也這樣子過來了！天也沒有跨下來呀！程式還是一樣地出貨！
是的！程式還是照樣可以出貨！小弟也是這樣子過來的！程式一樣照寫 :)
久而久之就會發現！團隊只有你自已一個人寫得好沒用呀！要讓大家都跟你一樣利害才行
有時候會發現！怎麼最常常加班的只有你而已！ ( 因為最利害的人都負責最多的案子 )
不然每次某個東西要改 ( 或有 Bug ) 時都只能找你，因為當初是你寫的。
但現實上不是只有程式碼管理而已，還有很多其他政治因素。 ( 最痛的就是 一人專案 )
因為，程式碼要自已寫以外
要解決客戶所提出來的需求 ( 還不斷地一直修改 Orz ) 和 動不動就會打給老闆抱怨某個功能又掛了
除此之外還要回答老闆什麼時候才能交貨 ( 不然公司就賠錢啦！ )
等等等……
沒錯！現實上不是只有程式開發而已！還包含到管理層面很多很多問題！
只有靠腦子記錄且案子又成功的非人類，實在少之又少。
===========================
若你們家是：「我們家的老闆人超好的！絕對不會壓我們時程，功能隨便我們寫客戶都會買單。 」
記得要多珍惜這種老闆和客戶呀！他們是最棒的衣食父母。( 哭 )
===========================
開發過程的記錄非常的重要，並非只有程式碼而已。
工作單、Bug 都是優先需要記錄的，和程式碼關聯是要幫助我們管理工作成果
有這兩項我們才能知道，目前有那些工作是已知的且還沒有完成的，什麼時候增加的
大約還要花多少時間完成、新產生的 Bug 數量和功能品質量化、程式碼修改是針對那些工作單或 Bug
每次交付工作是完成那些工作項目和Bug、工作單 ( Bug ) 的平均解決速率、等等…
很多時候小弟在講「工作管理」和「版本管控」的關聯時，聽完後覺得我們現在團隊只要有版控就好了呀！
幹麻還要多工作管理？？還不是老闆想要追我們的績效？不然就是 PM 不想讓我們忙裡偷閒？
不然就是上有政策、下有對策 工作單就隨便填，反正單子和程式都是我寫的。
其實，這些都是為了要保護自已和提升管理能力，也可以讓其他同儕協助 ( 或帶人 ) 都有記錄
一方面你可以自我掌控開發狀況，另一方面也學會怎麼預估時間。
所以知道工作單和程式碼關聯的重要性後，選擇適合自已團隊的工具就非常重要
簡單一點的工作追蹤可以用 Excel ( 小弟以前就是學約耳的做法！很快！很直覺！ )
而程式碼關聯則可以透過 Check in policy 來輔助記錄 ( 我們都不想要有人漏填或是明明無法編譯卻還簽入吧 )
小弟自已屁了這麼多，不外乎之前聽到一位先進說。該不會用了什麼 Team Foundation Server 一切都葯到病除吧？
不不不！！流程的改進！主要因素是「人」呀！工具只能讓我們縮短時間而已。
要做的一樣都不會少！ Orz 但團隊工作管理卻一直是大家遇到的問題！
所以，若自已檢視一下自已的團隊
是不是如同小弟講的只有版本管控而已，其他都只記在某一個超人的腦子裡的話！
真的要好好地想想，是不是應該用 Excel 把工作項目記錄到 TFS 上了呢！
小弟自已導入的成果
原本客戶一直抱怨提了需求 ( Bug ) 都沒有人理的情況完全地改善了，因所有的項目都有記錄和排時程。
工作的進度和成果的量化可以提高所有人員的士氣 ( 小弟導入過的團隊都是如此！但這必須是寫真的，而且不是為了績效時才有用 )
人員的支援變得更加容易，可以讓成員在不同專案中調度。因為先前的開發過程都有記錄下來可以供參考。
不用為了交報告而再花很多時間整理，從 TFS 到 Excel 可以馬上弄出我要的報表 ( 包含給客戶看的 加工過報表 )
單子不用擔心會不見！ ( 以前用 「紙」時，有時會發生 單子跑到異次元的情況 )
開發人員可以更了解自已工作的流程怎麼和其他人配合
讓每個人都有機會練習和預估時程的能力提高！ ( 是的！和 gipi 執行長說的一樣，這需要練習 )
可受管理的專案數量增加
…
以前 從 VSS ( 或是有人用 SVN ) 搭配 Excel 或 Email 或 紙 時
不是不能，只是會需要大量人力的管理工作進度，還有「道德」上的勸說。
小弟以上所有的工作都有用過「人力」管理過
現在就真的很幸福了，後來改導入 TFS 後原本需要有「專人」管理的部分節省下來
讓同部門成員 和其他部門的人員也可以知道所有專案的全貌
轉載自http://www.dotblogs.com.tw/franma/archive/2010/08/02/16962.aspx
那就開發人員自已平常多燒香拜拜啦！
定期備份在自已電腦上的檔案不要掛掉，只要最新的程式沒問題就好！
反正老闆和客戶都只看現在交付給他們的程式。
後來，大部分的團隊也已經能接受用「版本管控」管理所有程式碼是件重要且必須的事。
但！這樣子真的就足夠了嗎？？
======= 題外話！===========
小弟的確有看過一些團隊是用「工作單」的數量來決定一個人的績效，光只用數量來決定是一件非常要不得的，畢竟工作(bug) 都有區分成簡單和困難的。若是被分配到困難的成員豈不是很衰？？而且也不公平！ ( 所以日後該團隊的工作追蹤和會議進度形同批鬥大會，超慘的 )
所以大家要麻就是充數量！要麻就是造假！ 這只是增加團隊的 loading 而已。
到最後工作單就沒有人要看！ ( 因為大家都在填心酸的 )
那還不如不要填。
===========================
首先 可以先聽到幾種答案！
是不夠！所以我們有自已寫的系統在記錄所有的工作單
不然就是！我們有用一些免錢的系統在幫我們記錄 ( 通常都是 Bug Tracking System 這一類的 ，這和第一點是一樣的問題 )
覺得只有版控不夠！但完全不知道應該要怎麼解決！
只有版本管控就夠了，反正這個專案都只有我一個人！
前兩種都很好！因為已經有這個習慣了！
但程式碼 和 工作項目 彼此之間沒有關聯，就無法很方便地由單找Code 或是 由 Code 找單
若團隊是 3、4的話！人的改變就會比較辛苦了！
若是能認同想要改善也就罷了！但很多時候可能會有結論就是！
反正沒有我也這樣子過來了！天也沒有跨下來呀！程式還是一樣地出貨！
是的！程式還是照樣可以出貨！小弟也是這樣子過來的！程式一樣照寫 :)
久而久之就會發現！團隊只有你自已一個人寫得好沒用呀！要讓大家都跟你一樣利害才行
有時候會發現！怎麼最常常加班的只有你而已！ ( 因為最利害的人都負責最多的案子 )
不然每次某個東西要改 ( 或有 Bug ) 時都只能找你，因為當初是你寫的。
但現實上不是只有程式碼管理而已，還有很多其他政治因素。 ( 最痛的就是 一人專案 )
因為，程式碼要自已寫以外
要解決客戶所提出來的需求 ( 還不斷地一直修改 Orz ) 和 動不動就會打給老闆抱怨某個功能又掛了
除此之外還要回答老闆什麼時候才能交貨 ( 不然公司就賠錢啦！ )
等等等……
沒錯！現實上不是只有程式開發而已！還包含到管理層面很多很多問題！
只有靠腦子記錄且案子又成功的非人類，實在少之又少。
===========================
若你們家是：「我們家的老闆人超好的！絕對不會壓我們時程，功能隨便我們寫客戶都會買單。 」
記得要多珍惜這種老闆和客戶呀！他們是最棒的衣食父母。( 哭 )
===========================
開發過程的記錄非常的重要，並非只有程式碼而已。
工作單、Bug 都是優先需要記錄的，和程式碼關聯是要幫助我們管理工作成果
有這兩項我們才能知道，目前有那些工作是已知的且還沒有完成的，什麼時候增加的
大約還要花多少時間完成、新產生的 Bug 數量和功能品質量化、程式碼修改是針對那些工作單或 Bug
每次交付工作是完成那些工作項目和Bug、工作單 ( Bug ) 的平均解決速率、等等…
很多時候小弟在講「工作管理」和「版本管控」的關聯時，聽完後覺得我們現在團隊只要有版控就好了呀！
幹麻還要多工作管理？？還不是老闆想要追我們的績效？不然就是 PM 不想讓我們忙裡偷閒？
不然就是上有政策、下有對策 工作單就隨便填，反正單子和程式都是我寫的。
其實，這些都是為了要保護自已和提升管理能力，也可以讓其他同儕協助 ( 或帶人 ) 都有記錄
一方面你可以自我掌控開發狀況，另一方面也學會怎麼預估時間。
所以知道工作單和程式碼關聯的重要性後，選擇適合自已團隊的工具就非常重要
簡單一點的工作追蹤可以用 Excel ( 小弟以前就是學約耳的做法！很快！很直覺！ )
而程式碼關聯則可以透過 Check in policy 來輔助記錄 ( 我們都不想要有人漏填或是明明無法編譯卻還簽入吧 )
小弟自已屁了這麼多，不外乎之前聽到一位先進說。該不會用了什麼 Team Foundation Server 一切都葯到病除吧？
不不不！！流程的改進！主要因素是「人」呀！工具只能讓我們縮短時間而已。
要做的一樣都不會少！ Orz 但團隊工作管理卻一直是大家遇到的問題！
所以，若自已檢視一下自已的團隊
是不是如同小弟講的只有版本管控而已，其他都只記在某一個超人的腦子裡的話！
真的要好好地想想，是不是應該用 Excel 把工作項目記錄到 TFS 上了呢！
小弟自已導入的成果
原本客戶一直抱怨提了需求 ( Bug ) 都沒有人理的情況完全地改善了，因所有的項目都有記錄和排時程。
工作的進度和成果的量化可以提高所有人員的士氣 ( 小弟導入過的團隊都是如此！但這必須是寫真的，而且不是為了績效時才有用 )
人員的支援變得更加容易，可以讓成員在不同專案中調度。因為先前的開發過程都有記錄下來可以供參考。
不用為了交報告而再花很多時間整理，從 TFS 到 Excel 可以馬上弄出我要的報表 ( 包含給客戶看的 加工過報表 )
單子不用擔心會不見！ ( 以前用 「紙」時，有時會發生 單子跑到異次元的情況 )
開發人員可以更了解自已工作的流程怎麼和其他人配合
讓每個人都有機會練習和預估時程的能力提高！ ( 是的！和 gipi 執行長說的一樣，這需要練習 )
可受管理的專案數量增加
…
以前 從 VSS ( 或是有人用 SVN ) 搭配 Excel 或 Email 或 紙 時
不是不能，只是會需要大量人力的管理工作進度，還有「道德」上的勸說。
小弟以上所有的工作都有用過「人力」管理過
現在就真的很幸福了，後來改導入 TFS 後原本需要有「專人」管理的部分節省下來
讓同部門成員 和其他部門的人員也可以知道所有專案的全貌
轉載自http://www.dotblogs.com.tw/franma/archive/2010/08/02/16962.aspx
標籤：
經驗分享
一個團隊最少應該要多少人？
無論是 台灣 還是 大陸的工程師，都會覺得說 寫程式是低階的人在幹的！
所以往往都會覺得要往上爬就是要往管理階段走！ PG—>SD—>SA—>PM 等等… ( 中間還有其他角色我們省略 )
而，當然 高層也不是幹假的！即然要這樣子的話！
最後就很容易變成！「一人專案」
放心！從專案時間規劃到程式開發！絕對都可以碰得到！
名義上好聽的是 讓你可以獨立作業、可以讓你操控整個專案！
實際上卻是一人當三人用！
7、8 年前時小弟以前的主管不知去那裡看到的「一條鞭」的管理方法 ( 很怪！這個到現在還是很流行 )
硬是套在「軟體開發」的團隊中，而且覺得就是要一個人搞到底，因為這樣子可以節省溝通成本
所以呢！硬是把 一個團隊共同在維護的專案 ( 同時有 5 個 ) 拆散給 5 個不同的工程師 ( PG )
當然最後的下場很慘！原因有很多！因為 並不是每個人都有辦法可以同時要做 規劃 又要開發、又要顧品質 ( 當然 老闆覺得即然溝通時間省掉了！那麼上線的時間也可以濃縮一下吧！ )
導致某些專案客訴問題特多！
因為很容易弊端！比如 原本某些功能測試明明就是有問題，卻硬是要上線！
這個是不是好方法？
小弟覺得這跟本無法解決問題！因為校長兼撞鐘 怎麼可能「忠實地」反應問題出來呢？？
所以 一人專案真的不太適合在 軟體的開發作業上 ( 某些神人等級例外 ，各位都知道小弟在說啥 )
無論是自已實作過的團隊 或是 MSF 上所說 真的最少是 三個人
分別是
PM 負責時程規劃、客戶需求
PG 負責程式開發 / 設計
Test 負責產品的品質
也許就會有人說「不行！我們的人力資源有限，不可能因為 10 個案子我們就要統統乘以三 」
沒關係！換個角度想！可以讓 這三個人同時負責 三個專案 不就解決了嗎？？ ( 當然會依 數量、性質、人員 的差異而有所不同 )
若是所有的專案都已經進維護階段 且 產品的性質都是一樣 又有 OO 架構的話！ 3 個人同時維護 10 個案子也不是不可能的！
而在這裡面最重要的是
如何讓 這三個人可以共同作業、又不會干擾到對方！
這個問題也是困擾了我好久！
比方說 只要一有 bug ，我就要被測試人員 打斷 我開發中的工作，因為他要跟我說發生了什麼 bug
所以，即使是小團隊 也不能忽視這個問題
建置團隊自已的溝通平台是很重要的！
所以 Team Foundation Server 在這個部分幫節省很多建置平台的時間
PM 用 Excel / project 進行管理 和 客戶之間的需求 並且 隨時掌控進度 以便讓其他人員可以專心做份內的事
PG 在 VS 2010 中將這些需求 分幾個大的項目來決定 要執行那些工作 並 將開發好的程式碼可以連結到 需求
Test 依據 PM 所談好的需求 使用 Lab Management 規劃 測試案例 並在每一次 版本測試所找到的 Bug ，開立 Bug 單並記錄發現過程 以便讓 PG 日後可以找得到
爾後，即使團隊需要老闆 增加人手時 也可以很容易讓 新成員 上手 ，因為所有的開發經驗 通通都會在 TFS 中！
所以，並不是小團隊就不需要 開發流程！而是 更需要重視它！因為 人變少了就代表 做事的效率要提高！
( 事情不會變少 )
Orz
轉載自 http://www.dotblogs.com.tw/franma/archive/2010/01/24/13262.aspx
所以往往都會覺得要往上爬就是要往管理階段走！ PG—>SD—>SA—>PM 等等… ( 中間還有其他角色我們省略 )
而，當然 高層也不是幹假的！即然要這樣子的話！
最後就很容易變成！「一人專案」
放心！從專案時間規劃到程式開發！絕對都可以碰得到！
名義上好聽的是 讓你可以獨立作業、可以讓你操控整個專案！
實際上卻是一人當三人用！
7、8 年前時小弟以前的主管不知去那裡看到的「一條鞭」的管理方法 ( 很怪！這個到現在還是很流行 )
硬是套在「軟體開發」的團隊中，而且覺得就是要一個人搞到底，因為這樣子可以節省溝通成本
所以呢！硬是把 一個團隊共同在維護的專案 ( 同時有 5 個 ) 拆散給 5 個不同的工程師 ( PG )
當然最後的下場很慘！原因有很多！因為 並不是每個人都有辦法可以同時要做 規劃 又要開發、又要顧品質 ( 當然 老闆覺得即然溝通時間省掉了！那麼上線的時間也可以濃縮一下吧！ )
導致某些專案客訴問題特多！
因為很容易弊端！比如 原本某些功能測試明明就是有問題，卻硬是要上線！
這個是不是好方法？
小弟覺得這跟本無法解決問題！因為校長兼撞鐘 怎麼可能「忠實地」反應問題出來呢？？
所以 一人專案真的不太適合在 軟體的開發作業上 ( 某些神人等級例外 ，各位都知道小弟在說啥 )
無論是自已實作過的團隊 或是 MSF 上所說 真的最少是 三個人
分別是
PM 負責時程規劃、客戶需求
PG 負責程式開發 / 設計
Test 負責產品的品質
也許就會有人說「不行！我們的人力資源有限，不可能因為 10 個案子我們就要統統乘以三 」
沒關係！換個角度想！可以讓 這三個人同時負責 三個專案 不就解決了嗎？？ ( 當然會依 數量、性質、人員 的差異而有所不同 )
若是所有的專案都已經進維護階段 且 產品的性質都是一樣 又有 OO 架構的話！ 3 個人同時維護 10 個案子也不是不可能的！
而在這裡面最重要的是
如何讓 這三個人可以共同作業、又不會干擾到對方！
這個問題也是困擾了我好久！
比方說 只要一有 bug ，我就要被測試人員 打斷 我開發中的工作，因為他要跟我說發生了什麼 bug
所以，即使是小團隊 也不能忽視這個問題
建置團隊自已的溝通平台是很重要的！
所以 Team Foundation Server 在這個部分幫節省很多建置平台的時間
PM 用 Excel / project 進行管理 和 客戶之間的需求 並且 隨時掌控進度 以便讓其他人員可以專心做份內的事
PG 在 VS 2010 中將這些需求 分幾個大的項目來決定 要執行那些工作 並 將開發好的程式碼可以連結到 需求
Test 依據 PM 所談好的需求 使用 Lab Management 規劃 測試案例 並在每一次 版本測試所找到的 Bug ，開立 Bug 單並記錄發現過程 以便讓 PG 日後可以找得到
爾後，即使團隊需要老闆 增加人手時 也可以很容易讓 新成員 上手 ，因為所有的開發經驗 通通都會在 TFS 中！
所以，並不是小團隊就不需要 開發流程！而是 更需要重視它！因為 人變少了就代表 做事的效率要提高！
( 事情不會變少 )
Orz
轉載自 http://www.dotblogs.com.tw/franma/archive/2010/01/24/13262.aspx
標籤：
經驗分享
訂閱：
文章 (Atom)