作者彙整: jim yeh

測試驅動開發的步驟

敏捷開發並不是教條式的照本宣科,開發者要懂得變通最重要的是用心思考,而非把必要的思考都看成精神層面的問題,這並非適用於敏捷開發的心智模式。以下是同人在 Facebook 的 Scrum community in Taiwan 的回應,但文辭有略為做過一番修飾,可以用來澄清我對測試驅動開發步驟的看法。 閱讀全文

分類: 問題解決, 專案管理, 思考, 溝通, 生活感觸, 編程技巧, 職場, 衝突, 設計原則, 開發流程, 閱讀 | 1 則留言

測試驅動開發要徹底重構?

對 David Ko 提出 Kent 認為 Red/green/refactor 是 TDD 的三字箴言的說法,同人倒是覺得有探討的必要。以下分享我在 Facebook 回應 David Ko 的觀點,這些觀點應該可以解釋為什麼測試開發不需要徹底重構;其實重構並不是問題,而是到底什麼叫做徹底?而且如果 TDD 可以徹底重構,那麼一開始就可以讓設計一次到位,那寫好的測試程式以後也用不著了,不正是多此一舉? 閱讀全文

分類: 問題解決, 專案管理, 思考, 溝通, 生活感觸, 編程技巧, 開發流程 | 2 則留言

測試驅動開發的精神

測試驅動開發的精神,不應該用一般機械論的觀點來進行工作或任務的化約,而是基於複雜理論的重要觀念;維持穩定與變化的動態平衡,不在於掌握系統核心而在於邊緣,讓變動限定在人們可以掌握的範圍內,這或許才是測試驅動開發最關鍵的精神吧! 閱讀全文

分類: 問題解決, 專案監控, 思考, 編程技巧, 職場, 設計原則, 開發流程 | 3 則留言

再談技術經理當教練

技術經理當教練如果對公司是不好的徵兆,問題應該還是出在領導上,誠如同人過去發表過的文章所講的:強將手下無弱兵,但也不會有強將。沒有辦法訓練培養人才的教練,還是因為技術經理不諳教練之道呀! 閱讀全文

分類: 品質文化, 問題解決, 專案團隊, 思考, 溝通, 生活感觸, 職場, 領導 | 發佈留言

在 2009 年的最後一天

今天是 2009 年的最後一天。計劃未來一直不是同人擅長的項目,隨性的個性也讓我不喜歡依照目標來做事,喜歡把重點放在當下。然而,最近在回顧這一年的經歷卻感受到,在 2009 年的最後一天,很想寫下自己對來年努力方向的期望。2009 年對同人來說,是「清理過去」的一年。 閱讀全文

分類: 占星, 寫作, 新時代, 生活感觸 | 發佈留言

技術經理的教練角色

在觀念上,以上的討論已經將技術經理擔任教練的動機及基本觀念,詮釋地相當清楚。但從自己實際從事技術工作的經驗來看技術經理當教練這件事,事情卻好像並不如以上討論到的那麼簡單。同人認為 MaoYang 兄提到的這個主題,可以從兩方面來探討,一個是技術經理要教練的東西為何,另一個則是技術經理擔任教練的目的為何。 閱讀全文

分類: 問題解決, 專案團隊, 思考, 溝通, 生活感觸, 職場, 領導 | 2 則留言

買到海砂屋存證信函怎麼寫?

這一年來,看到很多朋友都是發現買到海砂屋之後,才看到同人的文章。從文章的留言與 email 的詢問中,關心最多的應該就是詢問存證信函該如何寫的問題,這似乎提醒我應該再寫一篇文章來分享我如何寫解除海砂屋契約的存證信函。 閱讀全文

分類: 問題解決, 生活感觸 | 6 則留言

月亮星座的反應

月亮星座的反應僅限於內心情感的情緒層面,而不會讓命盤主採取行動。或者用更精確的說法是,命盤主會選擇用行為來處理他的情緒反應,是因為其它星體的性格而非月亮星座。 閱讀全文

分類: 占星, 學習, 思考, 生活感觸 | 發佈留言

Java 泛型複雜嗎?

表面上看起來好像實作泛型可以讓某一段程式碼重複使用,但 Java 在泛型的限制,也增加他重構程式碼的困難度與複雜度。這麼說來,假如石頭成的想法是正確的,用 Java 的泛型來重構程式碼,只會讓程式員沒事自討苦吃。然而,同人在仔細研究他的程式碼之後,發現可以用更簡潔的方式來使用 Java 的泛型。 閱讀全文

分類: 分析設計建模, 品質文化, 問題解決, 學習, 編程技巧, 職場, 設計原則, 軟體開發 | 發佈留言

名牌數位相機的維修服務

一件商品在正常使用之下,在保固期內廠商竟然會拒負保固服務的責任。在這近幾年來,同人還是第一次意識到台灣會發生這樣的現象。不過有趣的是,有朋友認為消費者碰到這種情形不應該生氣,以免因為憤怒而喪失理智,但同人認為這樣的想法反而會助長劣質服務的氣焰。 閱讀全文

分類: 問題解決, 溝通, 生活感觸, 組織, 職場, 衝突 | 1 則留言