分類彙整: 編程技巧

讀取 Trello 任務看板的資訊

最近同人發現原來可以匯出 Trello 看板的任務與階段資料的 Trello Dump 已經不能用了,同人只好動手以 jQuery 寫程式用來讀取 Trello 任務看板資訊。程式完成後想到可以分享這支程式,除了為自己留下記錄外,也供有需要的人當做參考。 閱讀全文

分類: 利害關係人, 品質文化, 問題解決, 專案團隊, 專案監控, 溝通, 編程技巧, 職場, 開發流程, 領導 | 5 則留言

測試驅動開發的步驟

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

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

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

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

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

測試驅動開發的精神

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

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

Java 泛型複雜嗎?

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

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

以字元串列常數當索引鍵值

最近同人在開發資料剖析的程式時,碰到一個很奇怪的現象。我使用 map 容器來存放 … 閱讀全文

分類: 問題解決, 編程技巧, 職場 | 發佈留言

降低資料存取的重覆性

程式碼的重覆性使程式不容易維護、以及增加系統出錯的機率,同時使得程式的再用性難以 … 閱讀全文

分類: 分析設計建模, 問題解決, 學習, 編程技巧, 設計原則 | 1 則留言

訊息交易的抽象化思考

在〈開發者的 common sense〉的留言中,同人看到一些網友的批評。我發現 … 閱讀全文

分類: 分析設計建模, 品質文化, 問題解決, 思考, 易經思維, 生活感觸, 編程技巧, 設計原則 | 9 則留言

再談程式設計的迷思

昨天同人在〈又見少了概括性論點〉提到〈必須面對的真相─五大程式設計迷思〉在文章結 … 閱讀全文

分類: CNet/ZDNet, 分析設計建模, 問題解決, 學習, 思考, 編程技巧, 職場, 設計原則 | 2 則留言

穩定的程式是偶然?

如果穩定的程式真的是偶然的,程式的穩定似乎只能依賴運氣而不是人為努力,事情真的是這樣嗎?其實這位噗友太過強調環境變化的隨機性,卻忽略了適應環境變化,程式開發必然會經歷複雜演化的過程。穩定的程式是演化而來的,雖然演化的過程是偶然、但其最後結果卻是必然。換句話說,穩定的程式是偶然下的必然。 閱讀全文

分類: 學習, 專案監控, 專案規劃, 專案風險, 思考, 編程技巧, 職場, 設計原則, 開發流程 | 2 則留言