Everything you care about in one place
Follow feeds: blogs, news, RSS and more. An effortless way to read and digest content of your choice.
Get Feeder
teddy-chen-tw.blogspot.com
搞笑談軟工
Get the latest updates from 搞笑談軟工 directly as they happen.
Follow now 37 followers
Latest posts
Last updated 8 months ago
重構既有系統，邁向整潔架構 （6）：第三回合，在使用案例層讀寫分離
8 months ago
September 18 17:52~18:52 ▲這一集換Eiffel上場 工商服務 想了解本系列文章完整內容，請參考【重構既有系統：邁向整潔架構實作班】。課程介紹與報名網址在此：https://teddysoft.tw/courses/refactor-to-ca/。 *** 前言 上一集<重構既有系統，邁向整潔架構 （5）：第二回合，套用DDD戰術模式>在基本領域模型中套用領域驅動設計（DDD）的戰術模式（Tactical Design Pattern），找出聚合（Aggregate），達到封裝與決定交易邊界的目的。這一集要處理程式碼最多的TaskList。...
重構既有系統，邁向整潔架構 （5）：第二回合，套用DDD戰術模式
8 months ago
September 17 16:20~17:57 ▲被封裝在聚合內部的咪咪 工商服務 想了解本系列文章完整內容，請參考【重構既有系統：邁向整潔架構實作班】。課程???紹與報名網址在此：https://teddysoft.tw/courses/refactor-to-ca/。 *** 前言 上一集<重構既有系統，邁向整潔架構 （4）：第一回合，分層與移除基本型別依戀>已經形成了基本的領域模型，這一集要在領域模型中進一步套用領域驅動設計（DDD）的戰術模式（Tactical Design Pattern），找出聚合（Aggregate），達到封裝與決定交易邊界的目的。...
重構既有系統，邁向整潔架構 （4）：第一回合，分層與移除基本型別依戀
8 months ago
September 16 17:48~18:40；19:49~20:39 ▲從下層爬往上層的咪咪 (by 常玉) 工商服務 想了解本系列文章完整內容為，請參考【???構既有系統：邁向整潔架構實作班】。課程介紹與報名網址在此：https://teddysoft.tw/courses/refactor-to-ca/。 *** 前言 前三集聊了： 重構既有系統，邁向整潔架構...
重構既有系統，邁向整潔架構 （3）：Task List Kata簡介
8 months ago
September 13 20:30~22:07 前言 上一集<重構既有系統，邁向整潔架構 （2）：逆轉重構流程>Teddy提到只要「大膽假設」不管你是開發什麼系統，就是???套用Clean Architecture就對了。如此一來，便可將重構從「由下而上」的設計方法轉變成「由上而下」的設計過程。 接下來這幾集，Teddy將以Task List Kata為例，說明如何將既有系統的架構重構成Clean Architecture。 ***...
重構既有系統，邁向整潔架構 （2）：逆轉重構流程
8 months ago
September 10 07:38~08:08；11:30~11:49 ▲圖1：Ada逆練九陰真經 前言 上一集<重構既有系統，邁向整潔架構 （1）：為什麼透過重構改善軟體架???很困難>Teddy提到重構是一種「由下而上」的設計，而設計本身應該採用「由上而下」的過程，這也是為什麼透過重構改善軟體架構會如此困難的原因。 為了簡化重構軟體架構的難度，要想辦法將重構流程改成「由上而下」。 *** 怎麼做？ 要「逆轉重構流程」，其實很簡單，就是先確定架構目標就可以了。例如，假設鄉民是Uncle Bob的粉絲，不管手邊有什麼軟體，就是要想辦法無條件套用Clean...
重構既有系統，邁向整潔架構 （1）：為什麼透過重構改善軟體架構很困難
8 months ago
September 5 21:02~ ▲Ada：我不會逆轉重構但我可以逆轉自己！ 前言 今年四月Teddy開了一門新課程：【重構既有系統：邁向整潔架構實作班】。以往的開課流程Teddy總是先寫部落格文章，再設計課程，但這門課Teddy卻是直接設計課程而沒寫部落格文章。這系列文章算是「補寫」原本應該出現的文章，第一集先談為什麼軟體架構層級的重構很困難？ *** 重構是一種設計 大部分鄉民應該都知道重構是在不改變程式碼外在行為的前提之下，藉由改變它的結構達到增進設計品質的一種方法。既然重構可以「改善設計」，因此可以將重構視為一種設計方法。 Teddy將設計方法區分為兩種： 由上而下：先決定設計目標，然後由上而下展開子目標，最後展開到一個可以施工的工作單元。例如，傳統的物件導向分析與設計就是一種由上而下的方法。先確定專案願景，然後展開需求、設計領域模型、軟體架構。 由下而上：不確定最終目標是什麼，先從手邊可接觸到的「東西」著手設計，再慢慢將這些「東西」兜成更大的「東西」，透過這種方法完成設計工作。重構本質上就屬於這種設計方法。...
2024 新課程：【重構既有系統：邁向整潔架構實作班】
about 1 year ago
March 10 21:59~23:14 ▲實作Clean Architecture需要了解的「設計模式」 前言 2023年七月Teddy開始每天錄製一則YouTube影片之後就荒廢了部落格寫作，這兩天有鄉民提醒Teddy：「blog也重要，文字也是好東西」。鄉民說得有道理啊，還是要分配點時間給blog才對。 2024年第一篇blog，就先打個廣告，介紹泰迪軟體的最新課程：【重構既有系統：邁向整潔架構實作班】。 *** 課程介紹 Teddy在幾年前開過軟體重構的課，當初的想法是完整介紹Refactoring這本書，從Bad Smells出發，然後舉很多小例子說明不同的重構方法如何移除這些壞味道。這種重構方式固然有用，但Teddy總是覺得有點「小打小鬧」的感覺，對於整個系統的架構改善有限。就好像「你花了時間把家裡整理乾淨，但對於整個市容其實沒什麼影響，還是一樣中華民國美學：斑駁的外牆、陽台外推，以及到處都是鐵皮屋加蓋的違建。」...
使用ezSpec落實行為驅動開發與實例化需求（10）：撰寫自訂報表
about 2 years ago
March 25 12:44~14:18 ▲圖1：ezSpec實作Visitor設計模式類別圖 前言 上一集介紹ezSpec的基本報表功能，這一集介???如何擴充ezSpec，撰寫使用者自訂報表。 *** Visitor設計模式 為了支援自訂報表，ezSpec讓Gherkin keyword實作Visitor設計模式，請參考圖1。在GoF設計模式中，有兩個角色： Element：圖1中的SpecificationElement介面，要接受「拜訪者」的物件需要實做Element介面。該介面有一個accept方法，接受visitor作為參數。該方法的實作會呼叫（callback）visitor.visit，讓visitor可以讀取element的資料。 Visitor：圖1中的SpecificationElementVisitor介面，想要拜訪各個Element的具體拜訪者（concrete...
使用ezSpec落實行為驅動開發與實例化需求（9）：內建報表
about 2 years ago
March 25 10:43~11:48 ▲等待報表功能全部完成，ezSpec就可以開源了 前言 前幾集介紹ezSpec的基本功能以及同步執行???能，今天介紹ezSpec最後一個功能：報表。報表功能是做到Living Documentation（活文件）的核心功能之一，先用ezSpec描述系統行為，然後這些可執行規格變成驗收條件，執行結果透過報表整理，產出與系統現狀同步的Living Documentation。 目前ezSpec支援產生個別Feature file執行結果的報表，報表格式為txt檔與json檔，整合性報表還在開發中。ezSpec支援Visitor設計模式，開發人員也可以自行撰寫Visitor，產生使用者自訂報表。本集先介紹如何產生內建報表，下一集介紹如何擴充ezSpec，撰寫使用者自訂的報表。 *** 產生報表...
使用ezSpec落實行為驅動開發與實例化需求（8）：規範平行行為
about 2 years ago
March 24 21:45~23:14 ▲圖1：電梯的規格範例 前言 ezSpec與Gherkin相關的基本功能已經介紹完畢，???天介紹一個Gherkin沒有的功能：「描述平行行為的規格」。 Gherkin的Given, When, Then, And, But這些Step依據它們出現在Scenario的先後順序依序執行，對於一些天生就具有平行處理能力的系統，例如在IoT系統中，多個sensor或device彼此之間都是獨立且平行執行。在這種情況下，用Gherkin就無法表達這些平行執行的行為。 三月初的時候實驗室一組研究IoT的學生跟我介紹他們開發用python開發的工具—concurrentSpec，它可以擴充Gherkin語意讓開發人員撰寫並執行同步行為規格。原本Teddy開發ezSpec並沒有計畫要支援描述平行處理行為，聽完學生的介紹，花了點時間把ezSpec改成類似concurrentSpec的功能，可以幫同步行為撰寫規格。...
使用ezSpec落實行為驅動開發與實例化需求（7）：將共用步驟寫在Background
about 2 years ago
March 23 21:08~22:20 ▲第七集了，快到山頂了沒XD 前言 前幾集介紹如何撰寫Scenario與Scenario Outline，???本上已經可以處理絕大部分的問題。今天介紹Background，讓鄉民們可以共用不同Scenario之間相同的步驟。 *** Background也是一種Scenario ezSpec將Background也視為一種Scenario，但它身上通常只有Given與And，用來準備不同Scenario中共用狀態的內容。請參考圖1，首先使用第42行newBackground()開啟一個新的Background。與Scenario和Scenario Outline相同，Background一定要隸屬於某一個Story。 新增完Background之後，就可以和寫Scenario一樣，撰寫Step。圖1第44行將backgroundSideEffect這個data...
使用ezSpec落實行為驅動開發與實例化需求（6）：Scenario Outline
about 2 years ago
March 21 18:06~19:30 ▲一個Test Method，N個綠燈 前言 上一集介紹在ezSpec中四種撰寫Scenario Outline的方式（請參考<使用ezSpec落實行為驅動開發與實例化需求（5）：撰寫Scenario Outline的四種方法>），所使用的Examples是比較簡單的單一表格。這一集介紹當Scenario Outline的Examples比較複雜的時候，該如何表達這些Examples。 *** JUnit...