<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>I&#039;m CaLendarW Blog &#187; software engineering</title>
	<atom:link href="http://wongkalun.idv.hk/category/software-engineering/feed/" rel="self" type="application/rss+xml" />
	<link>http://wongkalun.idv.hk</link>
	<description>任何時間，都要用內心既一點光，照亮世界</description>
	<lastBuildDate>Wed, 07 Dec 2011 15:39:51 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<item>
		<title>Great software is not built, it is grown</title>
		<link>http://wongkalun.idv.hk/2009/06/18/great-software-is-not-built-it-is-grown/</link>
		<comments>http://wongkalun.idv.hk/2009/06/18/great-software-is-not-built-it-is-grown/#comments</comments>
		<pubDate>Wed, 17 Jun 2009 16:01:43 +0000</pubDate>
		<dc:creator>calendarw</dc:creator>
				<category><![CDATA[architecture]]></category>
		<category><![CDATA[翻譯]]></category>

		<guid isPermaLink="false">http://wongkalun.idv.hk/?p=547</guid>
		<description><![CDATA[作為一個架構師，主要任務是提供了初部結構和安排不段增長和隨著時間而改變的軟件系統，而且幾乎總是在你和利益相關者沒有預見下重做，或者和其他系統溝通。儘管我們是所謂的架構師，我們由建築和工程方面借用了許多隱喻，但偉大的軟件不是建造，而係成長出來的。 唯一最大既避免軟件失敗係軟件規模;由大型系統開始設計幾乎沒有任何好處。然而，在某個時候我們都將受到誘惑而這樣做。除了作為容易附帶的複雜性和慣性，設計大型系統的前期意味著更大的項目，這些項目更有可能失敗，更可能是無法測試，更可能是脆弱的，更可能有不必要的和不使用的部分，更可能是昂貴的，而且更有可能產生不利因素。 因此要抗拒試圖設計一個大型完整的系統，無論是多麼誘人，以“達到或超過”已知的要求和期望的特性。已經是一個宏大的目標，但不一定是一個大的設計。令你同你的系統學習適應環境及不可避免的改變。 如何做到這一點？最佳的途徑係從一開始確保軟件系統可以成長和適應不斷發展。誘導系統成長代表從一個較小的系統運行，做一部分架構既工作 &#8211; 做最簡單而最有可能完成的部份。這初生的的系統將有很多可取的性能和能教育我們了解更多大型系統的架構，或者更糟的一堆架構文件。你更有可能參與了其實現方法。而細小的介面將可更輕鬆地進行測試，因此不容易耦合。這只需要一個較小的團隊，間接降低協調項目的成本。而且其特性將會更容易被觀察，更輕鬆地部署。它會教你和你的團隊在最早的時刻知道什麼做到和什麼做不到。它會告訴你的系統不會容易發展、有可能是堅固、或者係脆弱、又或者有可能被破解。也許最重要的是可以從一開始給予利益相關者一些理解和確實的情況，使他們能夠為整體設計成長。 設計最小的系統，您可以幫助實現它，並讓它朝著宏偉構想。雖然這可能會覺得自己放棄了控制，甚至推卸的責任，最終您的利益相關者將會向你表示感謝。不要混淆循序漸進的辦法與不理要求，可怕的逐步，或建設一個將會扔掉的系統。 ############################################## As an architect you are tasked with providing the initial structure and arrangement of software systems that will grow and change over time, will have be to reworked, will have to talk to other systems, and almost always in ways you and your stakeholders did not foresee. [...]]]></description>
		<wfw:commentRss>http://wongkalun.idv.hk/2009/06/18/great-software-is-not-built-it-is-grown/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Software Engineering ≠ Computer Science</title>
		<link>http://wongkalun.idv.hk/2009/06/15/software-engineering-does-not-equal-computer-science/</link>
		<comments>http://wongkalun.idv.hk/2009/06/15/software-engineering-does-not-equal-computer-science/#comments</comments>
		<pubDate>Sun, 14 Jun 2009 16:53:11 +0000</pubDate>
		<dc:creator>calendarw</dc:creator>
				<category><![CDATA[computer science]]></category>
		<category><![CDATA[diary]]></category>
		<category><![CDATA[software engineering]]></category>

		<guid isPermaLink="false">http://wongkalun.idv.hk/?p=620</guid>
		<description><![CDATA[前幾日經 CodeProject 入面既 Email Subscription 介紹, 睇左個 Post 講呢個 Topic, 感覺幾好!!~~ 簡單 d 講就似 Pure Math 同 Apply Math 既分別, Computer Science 主要係研究新科技, 但新科技往往都要經過人來善用, Software Engineering 係包括人既活動. 雖然 Engineering 既原則係想個個人跟住同一套次序, 所做既野都應該差唔多, 但因為個個人唔同, 每個人用唔同心態去做同一樣野都會有好大分別, 所以一組人用一種方法獲得成功, 未必能在另一組人用同一個方法成功, 所以只會用一些 &#8220;通常&#8221; 等等既字眼, Methodology 係咁, Architecture 係咁, 所以先會有 Design Pattern, Anti-Pattern 等等不同技巧既出現, 所以科技係要被正確使用才可以為公司帶來利益, 而何謂正確只能基於使用者對科技既認識, 經驗同思維上. 對我黎講, Computer Science 有些似由零變一既過程, 而 [...]]]></description>
		<wfw:commentRss>http://wongkalun.idv.hk/2009/06/15/software-engineering-does-not-equal-computer-science/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Control of Duplication</title>
		<link>http://wongkalun.idv.hk/2009/05/22/control-of-duplication/</link>
		<comments>http://wongkalun.idv.hk/2009/05/22/control-of-duplication/#comments</comments>
		<pubDate>Thu, 21 May 2009 16:20:46 +0000</pubDate>
		<dc:creator>calendarw</dc:creator>
				<category><![CDATA[database]]></category>
		<category><![CDATA[design]]></category>
		<category><![CDATA[duplication]]></category>

		<guid isPermaLink="false">http://wongkalun.idv.hk/?p=540</guid>
		<description><![CDATA[近期做緊 Application to Database 呢部份, 開始對 Analysis Patterns 一書中既 Knowledge Level 同 Operation Level 多左理解, 除此之外, 仲開始感受既點樣控制重覆!! Duplication, 係 Program 入面係理應避免的, 正如見到重覆既 Code 就應該進行重構一樣, 但在 Database 層面上既管理又可能係另一種講法. 係 Knowledge Level 入面, 儲存既資料應該避免重覆, 因為所做既係最新既資訊, 以最實時既資訊去處理日常既運作, 雖然用既係最新既資訊, 但儲存落 Database 入面就可能要將所有有關既 Value Object 儲存埋, 因為往後既日子如果 Knowledge Level 有所改變, 亦唔應該影響到 Database 入面 Operation Level 完成品既歷史, 方面了解當時既情況, 等同於 Data Mining [...]]]></description>
		<wfw:commentRss>http://wongkalun.idv.hk/2009/05/22/control-of-duplication/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Acceptance Test Driven Development</title>
		<link>http://wongkalun.idv.hk/2009/04/30/acceptance-test-driven-development/</link>
		<comments>http://wongkalun.idv.hk/2009/04/30/acceptance-test-driven-development/#comments</comments>
		<pubDate>Thu, 30 Apr 2009 14:54:11 +0000</pubDate>
		<dc:creator>calendarw</dc:creator>
				<category><![CDATA[requirement]]></category>
		<category><![CDATA[testing]]></category>
		<category><![CDATA[agile]]></category>
		<category><![CDATA[test-driven]]></category>

		<guid isPermaLink="false">http://wongkalun.idv.hk/?p=506</guid>
		<description><![CDATA[Last night, I went to join the meeting of Agile Hong Kong, the topic is Acceptance Test-Driven Development(ATDD), presented by Steven Mark, which look-like great, user friendly, and example-driven concept to improve the software quality and meet the customer expectation, the different between TDD and ATDD is that the TDD is more focus on unit [...]]]></description>
		<wfw:commentRss>http://wongkalun.idv.hk/2009/04/30/acceptance-test-driven-development/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Separation Of Concerns</title>
		<link>http://wongkalun.idv.hk/2009/04/26/separation-of-concerns/</link>
		<comments>http://wongkalun.idv.hk/2009/04/26/separation-of-concerns/#comments</comments>
		<pubDate>Sun, 26 Apr 2009 08:20:24 +0000</pubDate>
		<dc:creator>calendarw</dc:creator>
				<category><![CDATA[architecture]]></category>
		<category><![CDATA[design]]></category>
		<category><![CDATA[SoC]]></category>
		<category><![CDATA[精華]]></category>

		<guid isPermaLink="false">http://wongkalun.idv.hk/?p=477</guid>
		<description><![CDATA[係軟件設計方面, 其實主要都想將唔同既 Concern 分開, 以我做開主要有以下幾個: Flow / Business Logic Input (Import Data, Interface for 3rd Party) Output (User Interface, Report) Database Logging Permission 在以上幾個 Concern 上, 而 Logging 同 Permission 呢兩樣野其實應該可以重用, 而且應該可以視為另一個軟件 / Domain Area. Database 使用方面, 因為市面有不同種類既選擇, 而為左可以應用係唔同 Database 上, 好多人都會加上一個 Data Access Layer, 正常既 implement 手法都係 Object Relational Mapping, 在 .net 主要有 LGPL [...]]]></description>
		<wfw:commentRss>http://wongkalun.idv.hk/2009/04/26/separation-of-concerns/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Why Automate Test?</title>
		<link>http://wongkalun.idv.hk/2009/04/15/why-automate-test/</link>
		<comments>http://wongkalun.idv.hk/2009/04/15/why-automate-test/#comments</comments>
		<pubDate>Wed, 15 Apr 2009 15:19:57 +0000</pubDate>
		<dc:creator>calendarw</dc:creator>
				<category><![CDATA[design]]></category>
		<category><![CDATA[diary]]></category>
		<category><![CDATA[testing]]></category>
		<category><![CDATA[c#]]></category>
		<category><![CDATA[nunit]]></category>
		<category><![CDATA[test-driven]]></category>
		<category><![CDATA[建議]]></category>
		<category><![CDATA[精華]]></category>

		<guid isPermaLink="false">http://wongkalun.idv.hk/?p=444</guid>
		<description><![CDATA[Test Driven Development, 係以測試來驅動程式既設計, 目的係為了提高軟件既質素. 好多人覺得測試對軟件方面只在於用戶接受測試 (UAT), 因為只要通過 UAT, 公司就可以袋袋平安. 不過, UAT 通常都浪費人手, 而且該次 UAT 只計對於該次既軟件需求, 當需求需要更改, 所有既測試都要人手重頭做過, 浪費人力物力. 自動化軟件測試既好處係可以減省人手及時間, 以及提高軟件既質素及完整度. 以下係一個由 NUnit 提供既自動化測試例子: 以上只係其中一個例子用來測試軟件既完成度, 在現實上, Test Case 除左要測驗一般情況外, 仲要測試錯誤情況出來既結果, 保証軟件質素, 所以正常使用既情況係唔會得一個 Test Case 咁少. 要實行 Test Driven Development, 通常要有一個良好既 Object Oriented Design 以及 Design for Test, 如果沒有這兩個設計既技巧, 那測試既質素有可能會受影響. 愈多 Test Case 未必代表軟件的準確率愈高, 正常情況 Test [...]]]></description>
		<wfw:commentRss>http://wongkalun.idv.hk/2009/04/15/why-automate-test/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>97 Things Every Software Architect Should Know</title>
		<link>http://wongkalun.idv.hk/2009/03/29/97-things-every-software-architect-should-know/</link>
		<comments>http://wongkalun.idv.hk/2009/03/29/97-things-every-software-architect-should-know/#comments</comments>
		<pubDate>Sun, 29 Mar 2009 05:08:39 +0000</pubDate>
		<dc:creator>calendarw</dc:creator>
				<category><![CDATA[architecture]]></category>

		<guid isPermaLink="false">http://wongkalun.idv.hk/?p=409</guid>
		<description><![CDATA[近期睇緊 97 Things Every Software Architect Should Know 既 post, 入面有好多被公認 Software Architect 要知既事情, 我想如果要做到專業既話, 入面每一樣野都應該深入了解下!!! 除此之外, 仲有 Other Things Software Architect Should Know, 部份只有標題, 不過都理解到那些標題要深入研究的話係有難道的. dtsv.dtse_post_409_permalink = 'http://wongkalun.idv.hk/2009/03/29/97-things-every-software-architect-should-know/'; dtsv.dtse_post_409_title = '97 Things Every Software Architect Should Know';]]></description>
		<wfw:commentRss>http://wongkalun.idv.hk/2009/03/29/97-things-every-software-architect-should-know/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Why Open Source?</title>
		<link>http://wongkalun.idv.hk/2008/11/17/why-open-source/</link>
		<comments>http://wongkalun.idv.hk/2008/11/17/why-open-source/#comments</comments>
		<pubDate>Mon, 17 Nov 2008 15:15:06 +0000</pubDate>
		<dc:creator>calendarw</dc:creator>
				<category><![CDATA[design]]></category>
		<category><![CDATA[open source]]></category>

		<guid isPermaLink="false">http://wongkalun.idv.hk/?p=287</guid>
		<description><![CDATA[前排同朋友傾, 佢話曾經有做銀行既 client 質疑 Open Source 既 Security, 怕寫果個人係 Cracker, 因而唔安全, 所以唔 prefer 用 Open Source. 我覺得個 Client 完全唔合邏輯, 係正常情況下, 比起相信一個人 (唔理係咪自己公司既人), 我會相信由唔同國家既 developer 共同參與, 觀察, 開發, 試驗過既 Open Source 安全 d, 我覺得就算係自己公司既人, 都有可能會係一個 Cracker, 而因為 Open Source 有多人參與, Crack 唔出樣. 用 Open Source 既原因, 主要係集眾人既力量來提高軟件質素, 如果有 bug, 只要 1 個人 debug 就可以解決, 提高了可重用性, 亦可以提高軟件既完整性. [...]]]></description>
		<wfw:commentRss>http://wongkalun.idv.hk/2008/11/17/why-open-source/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Domain Distilled</title>
		<link>http://wongkalun.idv.hk/2008/09/27/domain-distilled/</link>
		<comments>http://wongkalun.idv.hk/2008/09/27/domain-distilled/#comments</comments>
		<pubDate>Sat, 27 Sep 2008 07:57:54 +0000</pubDate>
		<dc:creator>calendarw</dc:creator>
				<category><![CDATA[design]]></category>
		<category><![CDATA[domain-driven]]></category>

		<guid isPermaLink="false">http://wongkalun.idv.hk/?p=232</guid>
		<description><![CDATA[DDD Charpter 15 講述 Distilled Domain, 入面既野有大部份都以前讀果科 Outsourcing 既理念差唔多, 都係講 Core Competence. Core Competence 係指企業核心能力, 亦都係企業不可代替既競爭力, 等同於 Sony 既電子細小化技術, Mac 既圖象技術一樣, 每間公司能夠待續成長就要有一個 Core Competence!! 而 Distilled Domain 就係個 Core, 經多次程式員同 Domain Expert 討論及詳細理解過後既精華所在, 但如果一個 Core Domain 得不到質量管理, 最後都係發揮唔到佢競爭優勢. Domain-Driven, 因為要解決既問題多數係 Domain Problem, 所以如果 Software Developer 未能理解該 Domain, 其實對軟件既質素長遠都有影響. 而當一個不良既設計存在於一個運行緊既系統內, 作為 Software Developer 係咪真係可以說服到管理層 (通常係 Project [...]]]></description>
		<wfw:commentRss>http://wongkalun.idv.hk/2008/09/27/domain-distilled/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Programming with Domain-Driven Concept</title>
		<link>http://wongkalun.idv.hk/2008/09/24/programming-with-domain-driven-concept/</link>
		<comments>http://wongkalun.idv.hk/2008/09/24/programming-with-domain-driven-concept/#comments</comments>
		<pubDate>Wed, 24 Sep 2008 15:31:13 +0000</pubDate>
		<dc:creator>calendarw</dc:creator>
				<category><![CDATA[design]]></category>
		<category><![CDATA[domain-driven]]></category>

		<guid isPermaLink="false">http://wongkalun.idv.hk/?p=221</guid>
		<description><![CDATA[之前買果本 Domain-Driven Design 都睇到第 15 章, 基本既理念大致上有: Factory Repository Specification Domain Model with Aggregation 而宜家寫既 Code 大部份都會跟呢個方向做, 雖然有時都無寫 Factory 黎生產 Object, 但自己就將 Repository Inherent DAO, 咁加埋 Spring.net 既 NHibernate Template 就可以更快地寫好一個 Program, 而 Validation 呢部份就用 Specification 黎做, 配合埋 Shared Kernel 就可以支援唔同既 Bounded Context. dtsv.dtse_post_221_permalink = 'http://wongkalun.idv.hk/2008/09/24/programming-with-domain-driven-concept/'; dtsv.dtse_post_221_title = 'Programming with Domain-Driven Concept';]]></description>
		<wfw:commentRss>http://wongkalun.idv.hk/2008/09/24/programming-with-domain-driven-concept/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

