Spirit
52 位追蹤者
在業界打滾多年，本來想開發遊戲，想想還是打遊戲比開發遊戲輕鬆，曾想當敏捷傳教士，但後來發現，好的產品品質跟健全心態的團隊比用什麼流派重要，所以，這幾年比較隨心所欲，但不隨波逐流，仍想做出值得驕傲的好產品。
52會員
102內容數
這是從 Medium 開始的一個專題，主要是想用輕鬆閒談的方式，分享這幾年軟體開發的心得，原本比較侷限於軟體架構，但這幾年的文章不僅限於架構，也聊不少流程相關的心得，所以趁換平台，順勢換成閒談軟體設計。
由新到舊
書摘《設計重構》本書大多數的內容都以 OO 的概念出發，詳列了許多設計的臭味道，也有大量的例子。個人雖然不會這樣寫程式，但仍是覺得受益良多，至少在 code review 時能更清楚知道該怎麼描述問題。不過，即便不是用 OO 的概念，有些章節還是可以帶來一些想法，用 OO 概念寫程式的人更不該錯過這本好書。
2024-05-23
6
書摘《從需求到設計》實際就業後，會發現收集與分析需求，通常都不是工程師在做，會有另一群人，以非工程的角度收集及分析需求，然後在開發過程中蹦出不同的火花，於是很好奇另一群人的想法是什麼？我不敢說這本書能完全代表另一群人的想法，但確實能夠得到很多有用的思維。推薦給所有的軟體工程師。
2024-05-11
5
書摘《領域驅動設計學習手冊》本書介紹了戰略設計、管理領域複雜度、實際應用領域驅動設計等主題。透過對核心子領域、支持子領域、限界上下文等概念的探討，提供了領域驅動設計的相關知識。這篇文章中還涉及了微服務、事件驅動架構和資料網格等相關主題，提供了設計系統和應用領域驅動設計的指導。
2024-05-09
4
書摘《Clean Architecture 實作篇》這本書如果是剛看完《Clean Architecture》這本書，想要直接看答案怎麼實作，是可以當作一個起始點，但我會比較建議，自己循著書中前幾個章節提到的 principles，思考看看怎麼設計出一個符合大多數 principles 的方案，這會比較有趣。
2024-05-08
4
書摘《團隊之美》- Part 1本文介紹了建立高效的工作團隊所需的要素，從激勵和溝通到目標設定和團隊文化。團隊中最有影響力的人通常是真誠且善於聆聽的人，而不一定是經理或領導者。透過激勵、測試、測試再測試和克服人為障礙的過程，可以建立一支高效的團隊文化，這對團隊的成功至關重要。
2024-04-27
6
關於 Swift & Java 中 Optional 的設計只是 Swift 以 language level 支援 Optional 確實比用 API level 支援的 Java 要簡潔和更具可讀性。Swift 作為一個全新的語言，從一開始的設計就將許多好的語言特性加入，確實讓人驚豔。
2024-04-27
1
希望 Java 未來能新增的特性這幾年新出的語言都強打在少寫 code 和提高可讀性，更重要的是能更容易發展出 domain specific language，就這一點 Java 確實有點顯得疲態了。其實文中列的特性大多是一些語法糖衣，但對程式的可讀性和抽象度都能提昇不少，我覺得挺實用也很划算的。
2024-04-26
2
Java 8 初探 - Parallel Array Sort很明顯可以看到 parallelSort(T[], Comparator<T> 大概可以帶來 2.5 倍到接近 3 倍的效能增益 (和數量無關)。所以，結論是當需要處理大量資料的排序時，真的可以考慮使用 parallelSort(T[], Comparator<T>。
2024-04-26
1
Java 8 初探 - Base64Java 8 有了 Base64 編解碼器，方便不少，不過 Apache Commons Codec 提供更多常用的編解碼器，其實是更方便的，但如果你的應用程式中只需要 Base64 編解碼器，在有 Java 8 的環境中確實不需要將 Apache Commons Codec 和專案一起打包。
2024-04-26
1
Java 8 初探 - Default Methodsdefault methods 似乎也引起不小的討論，因為 default methods 加上可以實作多個介面，已經有點像 C++ 的多重繼承了，只差在沒辦法繼承成員變數而已，是好是壞就看怎麼使用了。我個人覺得還蠻方便的
2024-04-26
0
Java 8 初探 - Lazy Evaluation & Parallel StreamLazy evaluation 的效益必須是在 pipe 的組合上有最佳化過的，若組合的不好反而更糟糕，且在 I/O 上幫助似乎也不大。parallel stream 要能發揮效果必須看資料的來源類型，不過要注意的是 parallel stream 也會使記憶體的使用量增加，使用上也要小心。
2024-04-26
1
Java 8 初探 - Stream老實說，看到 Java Sream API 讓我感到相當親切，這應該跟我研究所多年的研究題目是 visual dataflow language 有關，Java Stream API 把迴圈給內化了，每個 operation 的重點是要做什麼，大大提高了程式的抽象化程度和可讀性。
2024-04-25
1
Java 8 初探 - Closure最後，Java 8 雖然支援 Lambda，但我覺得 Closure 某種程度上還不稱不上是 Java 的第一級居民，我還是比較喜歡寫一些小而易測的 class，而不是使用 Lambda，至於捕捉變數，透過建構子將變數帶入物件也是一種方式。
2024-04-25
0
Java 8 初探 - LambdaJava 8 終於在 2014 的 3 月 18 日正式釋出了，不過自從用 Objective C 開發 iOS App後，我已經有好一陣子沒碰 Java，期間曾經有短暫寫一點點，但卻沒有時間去用 beta 版的 Java 8，直到最近才又開始玩一下。
2024-04-25
0
書摘《高品質微服務》內容十分精實，一百多頁很薄的一本書，但含了很多有用的資訊，就算不是開發微服務，書中的內容也可以用在很多雲端服務的開發與維運上。中文版唯一可惜的地方，翻譯非常不通順，很多不像中文的句子，會看到好幾個「與」連在一起用，標點符號的用法也有點怪，閱讀的痛苦指數有點高...
2024-04-24
3
書摘《從 0 到 1》今天的任務是找到獨一無案的方法創造新事物，不只讓未來變得不一樣，而且要更好，所以我們要從 0 到 1。最重要的第一步是自己獨立思考。唯有重新看待世界，像古人首次見到它那樣覺得新鮮古怪，我們才能重新創造，並將更好的未來留給後世。
2024-04-24
2
書摘《程式設計守則》這陣子比較有空可以去天瓏書局晃晃，正好看到這本剛上市不久的書，整體上大多數守則，也是我自己一直在遵循的，是相當不錯的一本總結書。但真的要仔細看每一節的內容，理解每個原則背後的情境與想要改善的問題是什麼。如果只是把每一節的標題拿來使用，很容易就會發現衝突的部分。
2024-04-23
5
2024 四國行 Day 5今天完全沒有行程，就只有去機場搭飛機回台灣，飯店的自助式早餐依舊是很豐盛，甚至還有一區是可以自由組裝海鮮丼，我沒裝飯，只拿了幾樣海鮮。飛機是 11:05 起飛，所以，雖然離機場很近，提早兩小時到機場，意味著九點多該到機場了。
2024-04-13
1
2024 四國行 Day 4行程簡述
天空海盧飯店 -> 小豆島土庄港 -> 四國高松港 -> 栗林公園 -> 金刀比羅宮參道午餐 -> 道後溫泉車站、本館和商店街 -> 彩朝樂
2024-04-13
3
2024 四國行 Day 3行程簡述
岡山國際飯店 -> 四國高松港 -> 小豆島土庄港 -> 土淵海峽 -> 小豆島國際飯店吃午餐 -> 橄欖公園 -> 寒霞溪 -> 二十四瞳映畫村 -> 便利商店 -> 天空海盧飯店 -> 天使之路 -> 天空海盧飯店晚餐 & 休息
2024-04-07
3
2024 四國行 Day 2今天行程有點特別，因為要離開四國到本州島去。行程簡述：金治國際飯店 -> 跨海大橋 (瀨戶內海) -> 倉敷美觀 -> 岡山後樂園 -> AEON Mall -> 7-11 便利店 -> 岡山國際飯店。
2024-04-07
1
2024 四國行 Day 1上次四國的團沒開成，這次旅行社是包機且保證成團，加上日本氣象廳的預測，應該有很高的機率能看到滿山遍野的櫻花，於是就報名了。
桃園機場 -> 長榮包機 -> 松山機場 -> 纜車上松山城 -> 天守閣 -> 購物中心午餐 & Shopping -> 今治毛巾美術館 -> 今治國際飯店 -> 居酒屋晚餐
2024-04-06
3
閒談軟體設計：技術債是選擇來的這篇文章探討了在軟體開發中的技術債可能來自哪些原因，以及如何自動化偵測與修復技術債。作者透過分享不同情境下的技術債選擇，提供了對於技術債的思考與建議，針對開發人員在需要做出無奈的技術決策時，提供了一些建議。此外，還提供了一些在做出技術決策時的方法，如保留抽象層和避免vendor lock-in。
2024-03-23
5
書摘《分散式系統設計》這本書從 docker 的角度出發，介紹很多可重複使用的 pattern，除了翻譯某些地方有點怪之外，算是很有趣的一本書，後面很多的 pattern 可以想成是 sidecar 的進階使用方式，在不改變應用程式的情況下，增加不同的功能，相當實用。
2024-03-16
4
閒談軟體設計：Database Driven Design?今天來聊個最近很夯的主題 DDD，但不是 DDD 的本尊 Domain Driven Design，而是無所不在的 Database Driven Design，Database Driven Design 不是不好，只是你的模型容易變成貧血模型，邏輯都集中在 service 層等等。
2024-03-09
5
閒談軟體設計：Model Model Model有趣的是，Model 其實沒什麼嚴格的定義，所以每個人對 Model 的解讀也不盡相同，有人覺得資料怎麼儲存屬於 Model 的一部份 (受 ORM 工具的影響)，有人覺得工作流程 (workflow) 是 Model 的一部份，我個人也有自己的想法，而且隨專案的規模和特性，也不是總是一樣的。
2024-03-02
5
閒談軟體設計：再來一碗起源是當時 Facebook 有篇文章討論不少人分不清楚上述二者的差別，當時寫了首部曲《閒談軟體設計：API Naming Style》，接著是《閒談軟體設計：內部函式庫》，但始終沒談到 library 和 framework 的差別，主要是沒有好的例子，這次這例子還蠻不錯的。
2024-02-24
3
書摘《與熊共舞》這本與《人月神話》都是軟體工程領域知名的書籍，曾從學校圖書館借來看過，但說真的，還沒進入業界，其實很難體會風險是什麼？但... 在業界打滾幾年後，再次回來看這本書時，你會發現風險... 不好說 XD
這本書不厚，就像開場說的，為進入職場前沒什麼感覺，現在卻是收穫滿滿，推薦給軟體開發相關從業人員。
2024-02-17
9
書摘《一人公司：起步的思維與挑戰》在博客來意外發現到這本書，這本比較像是前傳，距離看完本傳讀後感《一人公司》已經是好幾年前的事了，說心中沒有芽是騙人的，只是就像這本書提到的，大多數人都是被內心的恐懼把芽給摘了，如果您心中的芽還在，這本書就蠻適合您的。
2024-02-10
2
閒談軟體設計：Cache, Repository style我自己偏好用 Repository 搭配 decorator 來管理 cache，而不是在 controller 層或是到處都有快取的邏輯，如果程式都是透過 Repository 更新資料，Repository 就會是一個不錯的地方更新快取，邏輯也就不會散亂在各處了。
2024-02-03
7
書摘《約耳續談軟體》 下篇第一次看這本書時，後面幾個章節其實比較無感，畢竟那時還是無憂無慮的學生，頂多擔心自己的資格考會不會沒過。但工作幾年後再回來看這幾個章節，真的是超級有感，點頭如搗蒜，是一本很有趣的好書，推薦給大家。
2024-01-27
4
書摘《約耳續談軟體》 上篇用 Google 找此書的封面，意外找到我還在痞客邦時的舊文章，裡面滿滿的就回憶，主要是研究所到遊戲橘子這段時間的雜記之類，這本書其實讀過很多次，最早是從學校圖書館借出來看的，後來趁出版社兩本書套裝優惠時就買回來收藏，那時又看了一次，這次為了寫書摘再看了一次，真的是很有趣，最近換出版社重新翻譯出版，
2024-01-20
5
閒談軟體設計：多種 work 類型提到後端工程師，似乎就只是開發 API，但一個複雜的系統其實不太可能只透過 API 就能完成，例如一個簡單的功能，註冊會員，其實是由好幾個不同類型的工作互相配合，您才能收到開通信，才確保資料庫不會有一堆未開通帳號等。所以今天就來聊聊一個系統有幾種不同執行方式的工作。
2023-11-18
3
閒談軟體設計：State 與語言最近隨著 FP 的流行，immutability 一直被提倡，物件有狀態，會被修改好像是一種惡，但真是如此？immutability 很好，但所謂的狀態就是會隨著操作變動，差別只在於變動發生在哪裡？
2023-11-17
3
閒談軟體設計：Deploy on Friday針對這議題，從 devOps 的角度看，團隊應抱有持續不斷地改進的精神，努力降低上版的風險，最後，哪一天上版就僅僅是風險控管的問題了。風險控管除了考量到損失，當然還要考慮到團隊要怎麼 on-call，on-call 的資源夠不夠應付上版後的突發狀況，才能做出適當的決策。
2023-11-10
6
2023 京都行 Day 5由於班機時間的關係，加上網友都建議提早到機場，第五天沒有安排任何行程，就是去機場準備飛回台灣。
第五天的早餐依舊是在飯店吃，第一盤選了這幾天我覺得好吃的幾樣料理，京煮、地瓜天婦羅、雞肉天婦羅、英式煎蛋、溫泉蛋，以及偽裝成水煮蛋的豆腐，說真的，這幾天早餐吃的比平時還要豐盛許多。
最後收拾完，準備
2023-11-04
8
2023 京都行 Day 4由於昨天的行程真的有累到，所以昨晚討論了一下，決定把介於稻荷大社與清水寺中間的祉園、八版神社和園山公園等行程移掉，另外，稻荷大社也決定不爬到山頂，千鳥居稻中間就折返，讓今天的行程輕鬆一點。
2023-11-04
2
2023 京都行 Day 3第二天晚上回到飯店後看了一下 Facebook，很多人都建議提早 2.5 到 3 小時到關西機場，因為人實在太多了，本來第五天早上有安排去東寺，擔心去了會趕不上火車，於是調整了第三天的行程，把第五天要去的東寺改成第三天，這是自由行的好處，但功課還是要多做一些比較好。
早上依然是六點就起床梳洗，六
2023-11-03
3
閒談軟體設計：Singleton這文章來自網友在 在 Medium 上的留言 (有人幫忙想題目也挺不錯的)，問到：Singleton 對於好的架構來說是否能避免就避免呢？我簡單地回了一下我的想法 ，但 Singleton 其實很有趣，所以就寫篇文章來聊聊吧！
2023-11-03
4
2023 京都行 Day 2回顧 2013 年的行程，有幾個景點當初有安排，但因為某些點逛太久了，因此也就捨棄掉了，天龍寺便是上次經過但沒有進去的景點之一。所以便特地安排進去，不希望二次來京都時又錯過了。
2023-11-02
14
2023 京都行 Day 1前幾年遇到疫情，完全沒出去，距離上次出國整整有四年了，帶長輩出國，跟團老實說是最方便的，七月多本來是報名四國的團，但苦等不到成團通知，但畢竟假都請了，九月決定放棄跟團，規劃一下帶長輩去京都走走吧！
2023-11-01
3
讓 Scrum 團隊有更好的預估之三在上回提到一些應該要避免的措施，以及時時梳理 product backlog 讓團隊有較好的估算，這回則是作為一位 scrum master，我們該如何自省與發現估算的問題，也是以自我反省的方式完結這個系列。
2023-11-01
5
閒談軟體設計：Single Responsibility真的要符合 single responsibility，通常會得到很多很小的類別或是函式，各別完成一個小的功能，然後在某個地方被聚合起來完成一個使用案例 (use case)，而不是一個很大的類別，包山包海，然後最後變成一個狀態超複雜，超級難測試的類別。
2023-10-27
6
讓 Scrum 團隊有更好的預估之二在上回討論 Scrum 對於估算的精神與常見的估算單位，這回就來討論一些應該避免的事項，讓團隊能有更好的估算，下回則是過去的自省與感想。要讓團隊有較高品質的估算，agile coach 或 scrum master 可以觀察一些徵兆，若有發現盡早排除，免得讓團隊成員有壞習慣或是對估算這件事有陰影。
2023-10-25
5
閒談軟體設計：架構師難尋？這是幾年來我對於軟體架構師的心路歷程，上述不保證讓你成為軟體架構師，但希望會對軟體工程師職涯有幫助。也希望台灣的軟體公司能稍微多注重一下軟體架構，甚至能像 91App 不只工程師團隊，還有軟體架構團隊。
2023-10-19
4
讓 Scrum 團隊有更好的預估之一這同是 2016 年的舊文，根據現在的閱讀習慣重新整理，文章分成三回陸續發布，本回先談談在 Scrum 中，為什麼要估時，然後談談比較常見的單位與用法。下回則是幾個小方法，讓團隊能有更好的估算。最後一回，則是一些過去的自省與感想。
2023-10-18
6
閒談軟體設計：Developer eXperience我覺得好的體驗，大多不需要 production code 有對應的修改或調整，主要來自工具的優化，像是 IDE、CI/CD 等。但接下來討論的體驗，須對 production code 進行修改，甚至影響到撰寫，但帶來的體驗我覺得是有待商榷的。
2023-10-15
4
閒談軟體設計：Switch 壞味道我個人是盡可能不寫 switch statement，但觀察這幾年程式語言的趨勢，會發現許多語言把 switch statement 擴充成為實作 pattern matching 的工具，說不定以後 switch statement 會越來越廣泛使用也說不定。
2023-10-13
9
用 GitHub 與其他服務進行軟體生命專案管理這是 2016 年的舊文重新整理，這幾年應該很少聽到軟體生命週期管理了，裡面的部分概念被其他更夯的詞取代了，像是 DevOps，所以我在一開頭便選了張比較接近潮流的圖片，不過說真的，在這個領域，常常有很多新名詞出現，但真正落實的又有多少呢？
2023-10-11
5
閒談軟體設計：內部函式庫長遠的角度來看，內部函式庫還是值得投資的公司資產，只是它需要時間、人力與管理才能做得好。若有不錯的內部函式庫也可以回饋給open-source社群，畢竟，現在開發軟體已經不太可能沒有用到任何open-source的東西。雖然說是將公司資產以 open-source 釋出，但換取的利益卻不見得是零。
2023-10-06
8
【看板方法】課後心得 之四在上回，探討 WIP Limit 的設置，但如果當被 WIP Limit 卡住時，直覺的想法是放寬 WIP Limit 而不是想著如何協助他人讓工作順利完成，那就失去使用看板方法的意義了，這回將探討如何讓團隊自覺與改善。
2023-10-04
5
閒談軟體設計：API Naming Style整結來說，受到幾種語言的影響，我個人設計 API 時，除了合乎該語言的 convention、上述的穩定性及一致性外，大致還會注意幾點：語意清楚、相近的顆粒度、簡單的文件、讓程式能像文章般閱讀。
2023-09-29
6
【看板方法】課後心得 之三在上回，我們已經把工作視覺化成看板，但這只是第一步，要想用看板方法優化工作的流程，我們得設置 WIP 限制，讓團隊開始知道瓶頸在哪裡，然後才能開始改善，這一回就來看 WIP 限制的設置。
2023-09-27
2
《人月神話》讀後感意外的是這本書中提到蠻多首席設計師或是架構師的重要性，他確保系統的概念整體性，定義規格但對實作持開放讓開發者能夠發揮創意，自己的工作經驗中，第一份工作有和一位頗厲害的架構師合作過，第二份工作後來自己也當上架構師，甚至在另一家公司還曾經有過首席架構師的頭銜，但說實話，自己仍在摸索怎麼當一個好的架構師？
2023-09-25
8
書摘《約耳趣談軟體》 下篇這本書裡很多的內容是寫於千禧年世代，現在回頭看很多內容的發展方向已經大不相同，像是訂閱制慢慢開始興起，App 在手機上崛起，Web 大鳴大放，但讀起來還是很有滋味，很推薦給大家。
2023-09-23
2
閒談軟體設計：Java virtual thread第三方套件用了Promise或是Reactive，導致所有business logic都要做調整，這就違反「只能有對內的相依方向」的原則。business logic大多數情況下與效能優化無關，通常需要優化的是I/O的存取，這些既然都在外層，就應該在外層做優化，外層的優化不該影響核心，這才是好架構。
2023-09-22
4
【看板方法】課後心得 之二在上一回 說明看板方法相關的精實精神與原則與實務，這一回則是來設計看板，包含看板的範圍應該多廣、有哪些狀態、工作的顆粒度，以及 DoD 的呈現。
2023-09-20
5
《鳳凰專案》讀後感這本書以小說形式，把建構管理、看板方法、限制理論、三步工作法及 DevOps 以活靈活現的例子串在一起，十分有趣。很推薦給所有從事 IT 相關產業的工程師。
2023-09-18
3
書摘《約耳趣談軟體》 上篇這本書和《約耳續談軟體》，以及 Teddy 學長的《例外處理設計的逆襲》，應該算是我開始想寫技術部落格的原點吧，這幾本書都是原先的網路文章，最後收集成書。中文翻譯本原本應該是絕版書了，最近看到另一個出版社重新取得授權出版 (譯者也換人了)，於是又把這兩本書從書架上拿下來拍拍灰塵 (笑~)
2023-09-17
3
閒談軟體設計：Offline first (Server 篇)如果您以為上一篇 已經是所有需要考慮的眉角，那可就錯了，實作 offline first 不是只有 client 要注意，server 也需要下功夫的。
2023-09-16
2
閒談軟體設計：Async everything？任何語言特性用與不用，其實要看是否提升了生產力？是否提升可讀性？是否提升可維護性？這些都是在三個月甚至半年後回來修改程式時，才能明顯感受到的，而不是寫程式的當下。Java 8 的 CompletableFuture、Stream 和 Optional 都很好，但用的不好反而畫蛇添足又沒提高可讀性。
2023-09-15
3
【看板方法】課後心得 之一當初上完課，很激勵地寫下當時的心得，不太符合現在閱讀的習慣，所以重新整理成較適合閱讀的系列作，這篇將主要分享看板方法的精神與原理，後續會陸續更新，第二篇則是視覺化的作法，第三篇是 WIP Limit 的使用，最後是落實與其他感想。
2023-09-13
7
書摘《Executable Specifications with Scrum》Both, R&D and agile tackle the uncertainties in a nontraditional manner influenced by the trial-and-error process.
2023-09-11
2
閒談軟體設計：發生關係不管用哪種語言開發軟體，除非是那種一個 function 寫個幾萬行的人 (來人啊，把這種人拖去砍了)，不然，一般都會根據某些因素，切割成模組或是特定功能的區塊 (一個 class 或是一個 function)，但要完成一個特定功能，這些模組或區塊勢必要一起合作，因此這些模組與區塊就發生了關係。
2023-09-08
19
書摘《原來你才是絆腳石》這本書其實是參加 Agile Taipei 2018 時買的，還跟作者簽名合照，回到家後很『不』快地看完，大概是因為自己喜歡待在新創公司，有點難體會『大』企業的轉型困難點，現在回頭看一下當年畫的筆記，多了不少感受。
2023-09-07
5
世紀帝國與 Agile 軟體開發以前是學生，玩遊戲時不會有什麼特別的想法，現在玩著玩著卻發現，其實這遊戲的過程跟 Agile 軟體開發的過程有些地方很像。
2023-09-06
5
書摘《激發員工潛力的薩提爾教練模式：學會了，你的部屬就會自己找答案！》這書是在 Agile Meetup 2016年二月聚會聽完作者本人的演講才知道的，但手上的書一堆，也就一直沒有再買進，最近碰巧想試著練練鋼筆字養心，就跟著練字帖一起買回來看，因為已經聽過演講，看起來也就很快，但這次感觸卻更多，因為裡面很多內容都可以套用在自己身上，試著去分析自己的盲點，挺有意思的。
2023-09-04
5
書摘《全員敏捷》工作中，Scrum 跑的對不對，不是最重要的事了。在看這一本書時，想到的大多是 2016 在某公司推廣 Scrum 的經歷，很多是在這本書都提到了，很適合想要推廣敏捷前，先讀的一本好書。
2023-09-03
2
閒談軟體設計：友善的距離不重新造輪子，我們使用第三方函式庫，聽起來很合理，但每個被引入的函式庫意味著一種 coupling，看到套件管理工具下載眾多第三方函式庫，意味著不用重寫這些東西，開發效率能提升數倍甚至數百倍，但我們真的都能掌握這些 coupling 嗎？當這其中任何一個環節出錯，我們的系統架構真的很優雅地應付嗎？
2023-09-01
4
閒談軟體設計：Offline first (Client 篇)Offline first 的設計最近有越來越多的感覺，但好的 Offline first 設計要解決蠻多的問題，是否使用 offline first 設計真的需要好好思考，不然可能得不到好處，反而還引起一堆 bug，本篇先探討在 client 端可能會遇到的問題與一些可能的解法。
2023-08-30
0
軟技能會後，我與其中一位創辦人聊聊他們 scrum 怎麼跑，以及程式、美術與企劃，這三種技能差異甚大的成員怎麼合作，他也苦笑，其實他們也花了很多時間磨合，但我們都提到，要引導團隊需要的不是 process，而是很多的軟技能，讓團隊自己能夠成長。
2023-08-30
2
書摘《敏捷與 Scrum 軟體開發速成》老實說，從中文書名無法聯想回原文書是《The Elements of Scrum》，雖然書名翻譯沒有太離譜(和內容無關之類的)，但總覺得貼近原意會好一點。『Scrum團隊週記』這一章，整個讀完，其實就差不多可以了解Scrum的大部分，所以，若要讀這本書，又沒有太多時間，就先看這一章吧！
2023-08-28
2
閒談軟體設計：Immutable Interface Immutable interface 讓封裝更有彈性，不用擔心 setter 的過度開放。當不希望物件被不允許的對象修改時，只需讓對方取得 getter 的介面即可，反之，讓能夠允許修改的對象取得有 setter 的物件即可。
2023-08-25
7
User Story Refinement創業團隊就會很在意story的內容，會有相當多的意見，refinement meeting就是一個很好的場合讓大家把對需求的想法提出來，否則讓成員失去參與感，這對創業團隊是很大的傷害。
2023-08-23
1
讀後感《一人公司》書中畫了滿滿的筆記，不過我想每個人看這本書的想法應該都不會一樣，像是創業不一定需要創投，創投的目標是將獲得的股票回收最大化，和您的創業目標不見得一致，沒有創投可以取得最大的自主權。用既有的利潤來推動成長，而不是預期的利潤來推動成長。
2023-08-21
13
閒談軟體設計：UUID 之三部曲RFC 4122 文件中，版本 3 和版本 5 比較特殊，是以名字產生 UUID，在特定條件下，每次產生的 UUID 都應該是一樣的。當時的情境用不到 v3 或 v5，但現在的情境就非常合適用 v3 或 v5，因為我們希望的是對同一筆資料，不管是 email 或是交易紀錄，都能產生同樣的 UUID。
2023-08-18
4
從 1 到 5 scrum teams 的心得文第一次參加 Agile community in 內湖辦的社群活動 (2017 年)，同一天其實也是 C.C. Agile #59，當初報名時想了一下，C.C. Agile 從開始到現在，幾乎快要場場都到，似乎有點在同溫層打滾，是否該換個客場，看看其他地方的社群活動，加上這次的主題很有意思
2023-08-16
4
書摘《建構微服務》這本書大概花了一個禮拜的零碎時間看完，其實收穫很多，很多原則不僅僅適用於微服務，也適用在單體式應用被部署在很多節點上，加上跟過去的經驗比較，更能體會到書中的觀點
2023-08-14
4
閒談軟體設計：再聊 UUIDUUID 有個致命的缺點是，它實在太長了，128 bits 用 Hex 表示法，至少要 32 個字元，如果再加上分隔符號，就要 36 個字元，把這放在面向使用者者的頁面上，應該不會有人會記得住吧！但 UUID 就真的只能這麼長嗎？其實是可以再短一點的。
2023-08-11
6
意志力不是萬能丹為了業務的短期目標，工程師靠著意志力加班，勉強達成目標，但大家都知道，這段期間不只完成目標也累積龐大的技術債，本來承諾短期目標達成後，會有時間調整，像是整理技術債，或是讓菜鳥工程師能獲得技術訓練，但想也知道，馬上又會有下個短期目標...
2023-08-09
3
書摘《精實開發與看板方法》這本書是在 Agile Tour 2015 聽完作者本人演講後買的，不過，還真的沒挪出什麼時間把它看完，直到最近因為一些因素終於有時間把它看完了，所以上述很多摘錄都是心有戚戚焉。看是看完了，也別因為我上面都把好處寫出來就覺得看板方法好棒棒，一定也可以適用在你的團隊，真的嗎？
2023-08-07
1
閒談軟體設計：UUID這是 UUID 三部曲的首部曲，接下來兩周陸續更新第二部與第三部，首部曲先聊聊 UUID 的前世今生，二部曲會聊聊如何縮短 UUID 的長度，第三部曲則是聊聊特殊應用，希望能幫助到大家。
2023-08-04
3
Waterfall 陰魂不散隨著團隊組織方式的改變，個人在團隊中的角色也有了改變，改變至今大概有三個多月，從不同的角度在看事情時，也能得到許多有趣的想法，加上幾次參加C.C. Agile也都能得到意外的驚喜，讓自己反省：自己真的Agile了嗎？真的了解scrum？
2023-08-02
4
書摘《Implementation Patterns》這本書在書單中很久了，前陣子有空繞去天龍書局發現有中譯版就買回家來翻翻 (沒錯，買中譯版 XD)，一看很合胃口，很快就翻完了，心有戚戚焉的句子很多，特別是在最後一章關於框架設計的部分。
2023-07-31
2
閒談軟體設計：Client Server在大型主機的年代 (這裡要澄清一下，本人沒有歷經那個年代，不然都把自己講老了)，就已經有 clent server 的概念：由 client (計算能力較差的終端機) 向 server (計算能力較好的大型主機) 請求服務，幫助理解與管理分散式系統程式的複雜度。
2023-07-28
2
Scrum Bad Smells: Stop finishing, start starting這名字是刻意取Stop starting, start finishing的相反，有一陣子在觀察團隊時發現，story/task 的 burn-down線圖會發現到task幾乎都完成了，但story卻還懸在半空中，甚至在sprint結束前一天，還是有不少stories接近完工卻還沒完工。
2023-07-27
2
Scrum Bad Smells: No DoD or steady DoDAcceptance criteria 確保 do the right things，DoD 則是確保 do the things right，兩者合在一起，才會 do the right things right。
2023-07-27
0
Scrum Bad Smells: Estimated performance一般來說，會斤斤計較估算的數字，一個可能的潛在原因是來自管理層，忘記從哪看來的一句話：總是會得到想要的 KPI。意思是當制定一個指標，總是能得到期望的數字卻不一定能達到預期的效果。
2023-07-27
0
Scrum Bad Smells: Overcare about estimation過去擔任 Scrum Master 時，曾觀察團隊用 planning pork 估時超過三或四輪仍無法取得共識，但點數或時數有時只差一點點 (2 or 3)，或是差距很大 (3 or 8)，若仔細聽他們的討論會發現，之所以會沒有共識，是因為成員都帶入一個心態：如果我做這個 task 要多久？
2023-07-27
0
Scrum Bad Smells: No more calculation如果工作的預估和實際的執行是一致的，就不會有《人月神話》中那一句話：用人月的前提必須是人力與工時可以互換的情況下。我並不是說反正執行結果都不會跟預估的一樣，所以團隊成員在 planning meeting 裡可以亂估，而是要回頭想一下，Scrum 裡 planning meeting 的本質是什麼？
2023-07-27
2
Scrum Bad Smells之前讀《Refactoring: Improving the Design of Existing Code》，書中提到了若干個smells，用來聞出程式設計不太理想的地方，那在用Agile或Scrum方法時，是否也能聞出哪裡有些問題呢？可以的，我把過去參與過的經驗整理成幾個 smells。
2023-07-25
3
書摘《瘋狂改變世界：我就是這樣創立Twitter的！》每個人成功的方式都不同，其實不需要去追隨誰成功的方式，因為那絕對不會再次在自己身上成功，但如果自己不試著去找適合自己的道路，那就跟很多人一樣：原地踏步。
2023-07-23
2
Agile is Dead?給在考慮是否導入 agile 方法的人建議的話，先熟悉自己的 context 與要面對的 forces，思考後再決定是否導入，不需要為了那個名字而導入。不然就很容易進入覺得練功無用，抱怨 XXX 已死的狀態。
2023-07-22
4
閒談軟體設計：休息時間每次看到 REST 就讓我想起以前念研究所和老師一起想論文題目時，曾提過國外常會玩這種文字遊戲，像是將 Representational State Transfer 變成一個很簡單的單字 REST，但我的東西不管怎麼想，卻想不出什麼有趣的東西 Orz
2023-07-21
2
閒談軟體設計：Query Object稍微複雜一點的 query 其實代表著某些商業邏輯，若把這一段程式放到 repository 的實作層，會變成這些商業邏輯被隱藏起來了，如果有個好的描述語言，我倒覺得很好讀，也可以清楚知道背後的商業邏輯是什麼，是很好的一件事。
2023-07-15
3
閒談軟體設計：Repository簡單說，Repository 提供像是 array 或是 dictionary 的容器，對程式來說，就好像記憶體中有所有的物件，不用去想物件其實是從資料庫來的。作法是在 data mapping layer 之上再提供一個 collection 的介面來存取物件，將資料庫的細節從商業邏輯層抽離。
2023-07-08
2
閒談軟體設計：Plug-in不是在軟體建置之初就決定所有一切的行為，而是執行時根據配置 (configuration) 或執行時的環境 (例如：特定目錄有什麼 plug-in) 決定有哪些行為，話是這麼說，但要實作一個可以載入 plug-in 的軟體 (以下稱作 host application) 倒是有不少事情要考慮。
2023-07-01
2
閒談軟體設計：例外處理基本上就是這樣，例外處理是可以在軟體架構設計時就考慮進去，或者說，在軟體架構設計時就該考慮進去，制定方針讓團隊有一個原則可以遵循，透過設計讓例外的處理較容易與一致，最終讓軟體的品質可以更好。
2023-06-24
2
閒談軟體設計：Android App Architecture設計時的考量主要有：(1) App 是 Internet App，在考量 UI 體驗和網路頻寬的消耗，多數資料需以某種形式儲存部分資料在行動裝置上；(2) 因此會需要同步伺服器端和行動裝置端之間資料狀態；(3) 但行動裝置網路的穩定性不如一般網路可靠，要有足夠的自動化測試驗證正常的流程與異常的流程。
2023-06-17
3
閒談軟體設計：設計抉擇的因素程式開發有趣的地方，同樣的目標，不同的團隊會因不同的因素做出不同的設計抉擇。而這往往也是為什麼一個資深的工程師在開發速度上不一定比較快的原因之一，一個越是資深的工程師，思考的因素會更多，不過，不是考慮得越多就結果就一定越好，有時還會變成 over design 較糟的結果。
2023-06-10
3
