<?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/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
	>

<channel>
	<title>@ONE爸爸的隨想手札</title>
	<atom:link href="http://aone.wordpress.com/feed/" rel="self" type="application/rss+xml" />
	<link>http://aone.wordpress.com</link>
	<description>隨便寫, 隨便想, 大家也來捧捧場...</description>
	<lastBuildDate>Thu, 14 Jul 2011 15:35:30 +0000</lastBuildDate>
	<language>zh-tw</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
<cloud domain='aone.wordpress.com' port='80' path='/?rsscloud=notify' registerProcedure='' protocol='http-post' />
<image>
		<url>http://s2.wp.com/i/buttonw-com.png</url>
		<title>@ONE爸爸的隨想手札</title>
		<link>http://aone.wordpress.com</link>
	</image>
	<atom:link rel="search" type="application/opensearchdescription+xml" href="http://aone.wordpress.com/osd.xml" title="@ONE爸爸的隨想手札" />
	<atom:link rel='hub' href='http://aone.wordpress.com/?pushpress=hub'/>
		<item>
		<title>軟體開發永續經營的生存之道 第7回 &#8211; 了解持續整合議題必看的好書</title>
		<link>http://aone.wordpress.com/2011/07/14/%e4%ba%86%e8%a7%a3%e6%8c%81%e7%ba%8c%e6%95%b4%e5%90%88%e8%ad%b0%e9%a1%8c%e5%bf%85%e7%9c%8b%e7%9a%84%e5%a5%bd%e6%9b%b8/</link>
		<comments>http://aone.wordpress.com/2011/07/14/%e4%ba%86%e8%a7%a3%e6%8c%81%e7%ba%8c%e6%95%b4%e5%90%88%e8%ad%b0%e9%a1%8c%e5%bf%85%e7%9c%8b%e7%9a%84%e5%a5%bd%e6%9b%b8/#comments</comments>
		<pubDate>Thu, 14 Jul 2011 15:33:05 +0000</pubDate>
		<dc:creator>Eric Chen</dc:creator>
				<category><![CDATA[專欄文章]]></category>

		<guid isPermaLink="false">http://aone.wordpress.com/?p=338</guid>
		<description><![CDATA[考慮將持續整合觀念導入實務運作時，若能透過研讀專業書籍來了解，也是有效方法之一  持續整合（CI）雖然強調的是作業自動化，但有不少的執行細節及習慣的養成，仍須由人來配合，並藉著管理制度來規範，並非全然依賴系統平臺。而《Software Configuration Management Patterns: Effective Teamwork, Practical Integration》一書，當時彙集軟體團隊開發的有效成功模式，著重在標準化的管理規範及原則，讓軟體專案管理者能有跡可循，期望讓不熟的人也能照本宣科、按表操課。 至於2004年Pragmatic所出版的《Pragmatic Project Automation》，應算是討論建構作業自動化議題較完整的第一本書。 全書強調的基本精神就是所有作業都能予以自動化，以有效提升專案執行的效率。最重要的是將實作的細節一併讓讀者了解，包括如何利用工具來完成建構、安裝、部署等作業。除了讓讀者了解正確的建構作業觀念，強調如何逐步將自動化落實在專案執行。 全書內容，以建構、安裝部署、監測機制的自動化為主軸進行探討。建構部分介紹了軟體專案目錄結構的定義方式、如何以Ant工具來建構專案程式碼、定義專案所需的建構腳本、結合JUnit測試工具合併測試作業、設置排程建構的方式；在安裝作業上，亦介紹利用NSIS（Nullsoft Scriptable Install System）來設計你的安裝程式（Installer）；而在安排部署時所發行的版本，與開發測試時的內容有所差異，這本書也向你說明了，如何透過定義建構腳本的方式來包裝發行版本。 書中以CruiseControl為持續整合平臺為主要解決方案，加上各章節中均依主題搭配Ant腳本範例，可讓讀者快速定義自己的建構腳本檔，導入專案所需的自動化工具。其中部分自動化程序是作者撰寫shell script達成，書中亦直接提供程式碼。 由O’Reilly公司所出版的《Practical Development Environments》一書，則強調建構SCM核心觀念，內容經歷數項成功專案及數個不同開發團隊，適用於不同規模的專案上之實務證明，歸納出本書精華。書中亦提到不少建置自動化開發環境所需工具，讓你可將開發流程的各個環節緊密相扣，讓重覆枯燥的作業程序，透過系統正確並及時執行。 除了介紹軟體開發生命周期的各階段所適合導入的工具外，整個團隊各個角色的扮演，及達到良好的協同合作溝通，更是讓軟體專案成功的主因。 其中的一個章節闡述了人文與政治面的顧慮，像是具備程式碼更動權限的妥善分配，開發人員心中的真正想法，以及團隊紀律的要求等。作者依照過去專案經常發生的狀況提供具參考價值的建議。這樣的問題勢必存在，但能透過良好的互動預知可能的潛在問題發生，亦能降低專案風險。 持續整合的實作 軟體工程學界大師Martin Fowler 2006年時，再度發表Continuous Integration新版論述（http://martinfowler.com/articles/continuousIntegration.html），文中已將持續整合在實作上應該著重的原則，規範得相當清楚，後續在此議題討論的文章，都幾乎將這些原則奉為圭臬。大師的領頭羊效應後，業界陸續對觀注及討論這議題，不少書也開始雨後春筍般出現。 2007年Addison Wesley出版的《Continuous Integration: Improving Software Quality and Reducing Risk》，便是首本以持續整合CI這個名詞為標題的專書，其談論內容的完整度，筆者認為，算是歷年來相關書籍中寫得最好的一本。 本書先介紹CI時空背景及理論規範的演進，再逐步說明如何建立屬於自己的CI系統環境，兼顧理論與實務。作者先讓讀者了解過去開發團隊所面臨的痛苦及風險，掌握持續整合導入時所影響的作業層面，以及主要可解決的核心問題為何。一旦清楚導入的動機及效益後，再分章節介紹而建立CI系統環境所涵蓋的範圍以及組成元素。在介紹每個章節主題時必然搭配導入工具的設計方式，或是需要撰寫的程式代碼亦同步提供，讓讀者更能了解實作方式。像是如何以TestNG工具來撰寫單元測試程式，以及如何將這些任務定義到Ant建構腳本檔中。 而在書末附錄中，作者亦分門別類地整理了與CI有關的相關資源，並提供不同CI解決方案的評估選用考量要點。對於想開始導入CI的讀者而言具有甚高的參考價值，若你對持續整合完全沒概念，本書可以視為打好基礎的入門良書。 資料庫端的CI作業 當然持續整合的應用不只是在主程式的部分，現今應用程度絕大多數都與資料庫有關，跟隨著軟體版本的演進，資料庫的持續整合作業也不容忽視。《Recipes for Continuous Database Integration》，則是著重在資料庫端的持續整合程序，所有的資料庫相關的程式腳本均必須列入版本控管，才能讓程式碼與資料庫的組態一致。而在重複建構及自動化測試程度的進行過程中，對於資料庫的物件及綱要重建、測試資料之清除及準備、主程式版本升級時，對於現有資料庫結構的更新方式，這裡都有專文討論，而本書列示的十五項法則亦能讓讀者在進行資料庫整合自動化時能更順暢。 可協助CI的工具 工欲善其事，必先利其器。O’Reilly出版的《Java Power Tools》一書，對於開發作業過程中所需的工具有著詳盡的介紹，將絕大部分持續整合會用到的開放源碼工具，來個大閱兵，對於想嘗試持續整合實作的讀者，可以省下不少工夫。 書中所涵蓋的包括：建構工具Maven及Ant，版本控管工具Subversion及CVS，CI Server提到了Continuum、CruiseControl、LuntBuild、Hudson，自動化測試工具JUnit、TestNG、Cobertura，整合及效能檢測工具StrutsTestCase、DBUnit、JUnitPerf、JMeter、SoapUI等，軟體品質工具Checkstyle、PMD、FindBugs、Jupiter、Mylyn，問題追蹤工具Bugzilla、Trac，還有技術文件產生工具Doxygen、SchemaSpy等。這些工具的介紹，必然都會提到與建構工具的整合方式，例如定義Ant及Maven的建構腳本內容，讓自動化建構更能多元化，工作更簡單有效率。 與IT管理接軌 2010年Addison Wesley所出版的《Continuous [...]<img alt="" border="0" src="http://stats.wordpress.com/b.gif?host=aone.wordpress.com&amp;blog=72720&amp;post=338&amp;subd=aone&amp;ref=&amp;feed=1" width="1" height="1" />]]></description>
		<wfw:commentRss>http://aone.wordpress.com/2011/07/14/%e4%ba%86%e8%a7%a3%e6%8c%81%e7%ba%8c%e6%95%b4%e5%90%88%e8%ad%b0%e9%a1%8c%e5%bf%85%e7%9c%8b%e7%9a%84%e5%a5%bd%e6%9b%b8/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<georss:point>25.042317 121.565211</georss:point>
		<geo:lat>25.042317</geo:lat>
		<geo:long>121.565211</geo:long>
		<media:content url="http://1.gravatar.com/avatar/3e2f85d189946bf4854adbbb04ff0f98?s=96&#38;d=wavatar&#38;r=G" medium="image">
			<media:title type="html">aone</media:title>
		</media:content>

		<media:content url="http://blog.ithome.com.tw/js/tinymce/themes/advanced/images/spacer.gif" medium="image">
			<media:title type="html">More...</media:title>
		</media:content>
	</item>
		<item>
		<title>軟體開發永續經營的生存之道 第6回 &#8211; 如何規畫軟體品質提升的作法？</title>
		<link>http://aone.wordpress.com/2011/07/14/%e5%a6%82%e4%bd%95%e8%a6%8f%e7%95%ab%e8%bb%9f%e9%ab%94%e5%93%81%e8%b3%aa%e6%8f%90%e5%8d%87%e7%9a%84%e4%bd%9c%e6%b3%95%ef%bc%9f/</link>
		<comments>http://aone.wordpress.com/2011/07/14/%e5%a6%82%e4%bd%95%e8%a6%8f%e7%95%ab%e8%bb%9f%e9%ab%94%e5%93%81%e8%b3%aa%e6%8f%90%e5%8d%87%e7%9a%84%e4%bd%9c%e6%b3%95%ef%bc%9f/#comments</comments>
		<pubDate>Thu, 14 Jul 2011 15:32:04 +0000</pubDate>
		<dc:creator>Eric Chen</dc:creator>
				<category><![CDATA[專欄文章]]></category>

		<guid isPermaLink="false">http://aone.wordpress.com/?p=336</guid>
		<description><![CDATA[當完成建構及測試自動化，若欲進一步提升軟體品質等級，還有那些作業是可以接續落實的？ 要提升軟體品質，可從系統及人文兩個層面來要求：系統面以透過完整的檢測及掃描來確保測試的完整性，而人文面則是透過系統化文件的產出，以及良好的程式碼撰寫風格來讓可讀性提高。前兩回文章所提到的建構及測試自動化，若都能落實在作業程序中，則軟體開發80％的自動化需求大致底定。一般而言，只要能先確保軟體功能正確無誤，行有餘力才會再來求品質的提升。就實務而言，由於時程及人力資源條件的限制，僅著重於功能驗證無誤，即安排版本發布及上線程序，品質強化的部分反倒甚少被重視，然而許多問題在未來系統正式上線後，在使用度及資料量的日益成長之下逐漸浮現──很多都是由這些潛在的品質因素所引發出來的。然而開發的系統時間一久，功能範圍日益擴增，加上開發人員的職務異動，程式碼本身所包含的資訊，是否足夠讓維護接手的人員不中斷地持續開發作業，在文件及程式碼的可讀性即為關鍵性因素。 未雨綢繆、及早預防──程式碼靜態掃描 所謂靜態程式碼掃描，主要用意在於透過問題模式比對的方式，對於已撰寫好的程式碼進行錯誤的先期預防，以及早避免曝露可能的系統弱點，或是隱含的系統錯誤及效能問題，而降低系統上線後才發現問題的風險。多數軟體品質的問題，可以從程式碼的撰寫方式來推出潛在可能引發的問題，而且有許多工具累積了不少問題模式及類型（bug patterns），在執行掃描的過程中便能逐一列出問題的所在。 像是常見Null Pointer Exception的發生可能性、無謂變數的宣告使用、過於複雜的邏輯判別式、重複多餘的程式碼內容、關於密碼變數值的管理方式，或是程式碼可能造成SQL Injection被入侵，及跨站腳本攻擊（XSS）的疑慮等。 這樣的掃描作業，當然也能整合到建構自動化的設定中，在每次建構完畢即產出靜態掃描的結果報表供管理者參考。所發現的問題，會依你所採用的工具，而有詳細程度上的差異，這些問題也會依重要性來分類。而管理者則視其必要性，決定是否列入修復的必要項目。 較常被採用的免費開發源碼工具，像是Findbugs、PMD等，商業套件像是Parasoft、Fortify等，其所著重的掃描問題重點及類別，都有所差異，原則上都可支援與既有的開發環境，並提供與建構工具（像Ant、Maven）密切整合的功能，方便併入建構自動化程序中。像Fortify甚至提供專家知識庫，針對不同問題提出建議做法，協助開發人員進行改善作業，提升不少工作效率。 撰寫程式即撰寫文件 實務上，通常都是開發完畢後，才挪出時間後補文件的撰寫，做為專案驗收的依據，而且，日後文件持續維護的工作並沒有落實，長時間下來，文件的價值也就被忽視。程式即文件的觀念，早在倡導敏捷製程時，就已經被強調，期望開發人員在撰寫程式時，一併將應註記的內容填入，保持內容的可讀性。 自己撰寫的程式若未附上良好的註記說明，一段時間再回頭來修改，常需要花上較長時間了解程式原意，更何況是轉交由其他非原開發者維護，這樣的問題會更加嚴重。若你用Java程式語言開發，透過Javadoc工具，即可自動化產出可供技術開發人員參考使用的文件，應用簡單的撰寫原則，可在開發過程中同步註解程式碼提高可讀性，降低未來維護時重新修改所需投入的成本。 而除了Javadoc產出的API類型文件之後，亦有其他圖形化文件產生工具，讓文件內容的可讀性更高。像是Doxygen、UMLGraph，可依程式原始碼反向產出UML圖表，提供基本的Class Diagram及Collaboration Diagram，來表示其物件階層及相依性，讓開發人員在未經手程式碼之前，透過閱讀圖形化文件先掌握系統全貌，不致於發生直接閱讀程式碼，有見樹不見林的問題。 而SchemaSpy，則是針對資料庫端所提供的文件自動化產出工具，依照目前資料庫中已經建立的物件結構，進行反向工程文件產出，依table、view、relationship、constraint等常見的內容，予以系統化列出，並以E-R Diagram方式，表現資料表之間的關連性──只要在建立這些物件時，一併撰寫備註文字，像是資料表及資料欄位的說明文件，在這裡的文件都能被清楚呈現出來。由於此工具是利用JDBC方式與資料庫連接，它可支援目前業界大多數的資料庫產品，相較於知名商業軟體像是CA的Erwin Data Modeler、Sybase的PowerDesigner和Toad Data Modeler等，不需付出高額成本，即可產出專業化的資料庫規格文件。 這些圖形化文件的優點在於，方便將Diagram與程式碼內容的瀏覽，合而為一，讓閱讀者在追溯物件關係並檢視到原始程式碼的行為上，更為流暢。所提供的文件格式，亦以HTML格式為主，支援全文檢索功能，閱讀者不需額外安裝特殊軟體即可瀏覽。 不過，上述工具雖然能協助快速產出圖形化的專業技術文件，但內容的充實與否，仍須落實平日開發人員的作業上──對於程式碼的註記方式，必須確實養成習慣及規範，否則產出的文件內容參考價值就有待商榷。 另外值得強調的是，這些使文件自動化產生的工具，只是單純輔助事後撰寫文件的效率提升，但針對像是需求規畫分析設計過程所產出的文件，並不會因此而省略掉。這些文件則是配合思考的過程而產出的規畫內容，切勿混淆。 一致化的程式碼撰寫規範 程式碼的撰寫風格一直是被討論的課題，許多原則早在昇陽電腦所定義的程式碼撰寫風格規範（Sun Code Convention）中提到，不外乎是希望每個開發人員能配合一致性的撰寫方式，讓後續維護工作的人員能快速接續處理而降低維護成本。 常見的規範，像是空白字元的數量及出現位置、變數的命名規則、Javadoc中所要求的註解內容必須填寫、程式檔頭的標準說明內容等。不過這樣的要求在實務上，的確不容易，開發人員習慣的程式碼排列方式，與其開發生產力有著直接的關係。此時就會考慮導入程式碼規範工具，來強制將代碼內容規格化。 常見的格式化工具，像是CheckStyle、Jalopy等，可以安裝在你的在開發環境中（像Eclipse），在撰寫程式碼時，編輯器便會在不符規範的程式碼的該行首位置，顯示警訊，即時提醒開發人員遵循規範來寫作，而規範的內容亦可由開發團隊自己定義，調整出適合既有專案開發團隊都可以接受的方式。 在每次建構時，即可將程式碼依指定的規範格式進行內容檢查，或是在CI Server上進行建構自動化程序時，將整個專案的程式碼一併處理，並可強制設定當不符合規範時，即中斷建構作業。規範的嚴重程度，亦可以自行定義。 規範的定義在實務上，也不要太過強硬，導致妨礙整個建構作業的流暢度。畢竟撰寫規範的落實並非必要條件，建議可以先以Jalopy，將程式碼自動調整成期望的格式，再以CheckStyle進一步確認，會更為可行。 實務上，開發團隊常因方便行事，而一般客戶在需求規格中亦甚少提及針對品質部分進行要求，或是將此課題視為非必要性的。軟體品質的提升非一蹴可幾，自動化工具僅能輔助，更重要的需管理者的重視，以及全體開發團隊的配合施行，才能達到應有的水準。 分類:專欄文章<img alt="" border="0" src="http://stats.wordpress.com/b.gif?host=aone.wordpress.com&amp;blog=72720&amp;post=336&amp;subd=aone&amp;ref=&amp;feed=1" width="1" height="1" />]]></description>
		<wfw:commentRss>http://aone.wordpress.com/2011/07/14/%e5%a6%82%e4%bd%95%e8%a6%8f%e7%95%ab%e8%bb%9f%e9%ab%94%e5%93%81%e8%b3%aa%e6%8f%90%e5%8d%87%e7%9a%84%e4%bd%9c%e6%b3%95%ef%bc%9f/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<georss:point>25.042317 121.565211</georss:point>
		<geo:lat>25.042317</geo:lat>
		<geo:long>121.565211</geo:long>
		<media:content url="http://1.gravatar.com/avatar/3e2f85d189946bf4854adbbb04ff0f98?s=96&#38;d=wavatar&#38;r=G" medium="image">
			<media:title type="html">aone</media:title>
		</media:content>

		<media:content url="http://blog.ithome.com.tw/js/tinymce/themes/advanced/images/spacer.gif" medium="image">
			<media:title type="html">More...</media:title>
		</media:content>
	</item>
		<item>
		<title>軟體開發永續經營的生存之道 第5回 &#8211; 持續整合所應用的測試自動化</title>
		<link>http://aone.wordpress.com/2011/07/14/%e6%8c%81%e7%ba%8c%e6%95%b4%e5%90%88%e6%89%80%e6%87%89%e7%94%a8%e7%9a%84%e6%b8%ac%e8%a9%a6%e8%87%aa%e5%8b%95%e5%8c%96/</link>
		<comments>http://aone.wordpress.com/2011/07/14/%e6%8c%81%e7%ba%8c%e6%95%b4%e5%90%88%e6%89%80%e6%87%89%e7%94%a8%e7%9a%84%e6%b8%ac%e8%a9%a6%e8%87%aa%e5%8b%95%e5%8c%96/#comments</comments>
		<pubDate>Thu, 14 Jul 2011 15:30:10 +0000</pubDate>
		<dc:creator>Eric Chen</dc:creator>
				<category><![CDATA[專欄文章]]></category>

		<guid isPermaLink="false">http://aone.wordpress.com/?p=334</guid>
		<description><![CDATA[當建構自動化作業整合到CI伺服器時，為提升軟體品質，接下來便是落實軟體測試作業自動化 &#160; 要達到持續整合中所提到持續且不斷改善，沒有理由不利用自動化方式來進行這些重複且標準化的作業。在《軟體測試之道—微軟測試團隊的成功經驗、方法與技術》一書中提到，光Office 2007這套軟體就包含超過百萬個測試案例，相信微軟工程師勢必結合高效率之自動化方式，才能在有限時間內完成這項偉大的測試工作。 測試自動化對既有作業的影響 記得中學國文課本的《指喻》，意謂著問題修復的成本會因時間歷程愈久而愈高。測試自動化作業便是以化整為零的概念，將過去開發階段所獨立定義的測試階段，打散部分的工作提前到開發建構階段來處理，早期發現早期治療。 要落實測試自動化，接下來必須面臨的現實問題就是需要撰寫額外的測試程式。直接反應到開發人員所需要額外花費的工時。然而實務上常因時程與人力不足的現實限制而讓測試程式碼的撰寫大打折扣，進而讓測試作業無法發揮測試應有的效益。 對於測試程式的撰寫方式，大多是將主程式的元件及服務都撰寫完畢後，再來撰寫測試案例。實務上常會因為時程的壓縮造成撰寫測試案例的時間被省略掉，以致未能達到良好的測試。敏捷（Agile）製程中的測試導向開發（TDD），則是強調先撰寫測試程式，再逐步衍生出主要的核心元件及服務，不斷地改寫原本的主程式來符合測試程式的結果。 是否採用TDD引起不少討論，就筆者面臨的實務經驗及現今企業的組織分工狀況，不見得能順利落實。像是具有專責測試人員或單位編制的企業，其主程式與測試程式的開發人員不是同一人時，就不易進行先測試再寫主程式代碼的方式。 然而開發工具的支援也是相當現實的問題，像目前微軟Visual Studio 2010可支援撰寫測試程式的當下，同時產生尚未開發的主程式類別屬性及方法，就更能貼近TDD的想法，否則只是讓開發人員因為測試無法進行而又回到原始做法。 軟體測試型態及使用時機 在軟體工程中所定義的軟體測試類型的種類繁多，但就實務上因專案時程與人力資源的限制，通常會選擇重要且必然被重複執行的項目來要求。 ● 單元測試（Unit Test） 是針對單一元件本身的設計進行測試，以確保最小單位的處理邏輯是正確無誤。檢測方式主要是針對元件提供的方法進行輸入及輸出的驗證，以確保內部處理邏輯的正確性。就單元測試本身的特性是輕薄短小，為了發揮物件化設計的精神，高內聚力低耦合力的元件架構下，單一元件的測試作業是相當輕快的。而這個測試的執行可以整合於建構平臺中，每當有任何程式被異動交付（commit）時隨即進行，可及時檢測。 ● 功能測試（Functional Test） 它會結合多項元件針對特定功能聯合檢測，範圍會是著重在特定子功能模組或是，其測試步驟可能會有前後相依性，單一測試案例的時間及複雜度都較單元測試為高。視情況在CI伺服器上設置定期排程方式，進行自動測試作業。 ● 系統整合測試（System Test） 由於測試的範圍及花費時間較單元測試為長，一般都在每日建構作業啟動時或下班時間進行，以避免在測試時造成的系統負荷及其他開發作業影響。 ● 迴歸測試（Regression Test） 可以避免既有功能因新版本的釋出而發生錯誤。軟體功能相依性無法完全避免，程式碼只要異動，可能會引發連帶影響，若能在異動當下即能確保相關功能是否通過測試檢驗，由於功能因版本變更而持續增加，這部分的測試程式亦是不斷累積日趨成熟，可被持續重用，除非原本功能及處理邏輯已被異動。 ● 效能壓力測試（Performance and Stress Test） 針對主程式在上述相關測試工作都已經完畢，結合正式環境或擬真環境來進行系統效能及壓力承受度的檢測。此類測試的結果會因系統執行環境的狀況而有不同結果。一般而言是針對每個測試案例或測試計畫來統計平均需要花費的時間有多少，供管理者評判該數值的合理性；而壓力測試則必須以正式環境，所得數據才有參考價值。 ● 測試涵蓋度的監控 （Coverage） 因為軟體功能的日益強化，相關測試程式的數量也是不斷增加，就測試範疇多少會有漏測或是重覆測試的情況出現，搭配測試涵蓋度的工具來同步監控，能清楚掌握主程式被實際測試的廣度及深度為何，進而調整測試程式內容。選用的涵蓋度監控工具必須與你所採用的測試框架能整合互通，才能發揮效益。 測試自動化的實務規畫設計 在撰寫測試程式時如何運用良好的設計思維，來讓繁雜的測試程式代碼更易於使用及管理？ ● 既有開源資源的引用 針對軟體測試的開源框架已經相當成熟，因應不同測試領域而有多種成熟的解決方案可供採用。這些框架容易學習便於上手，亦提供完整的測試結果報告。常見的像是著重在單元及功能測試的JUnit、NUnit，針對資料庫存取進行資料驗證的DBUnit；運用在Web Server測試，檢證XML資料格式的XMLUnit； 模擬瀏覽器操作行為，針對網站應用程式測試的Selenium；還有，HTTP通訊協定測試的HttpUnit、針對J2EE應用程式整合測試的Cactus、提供效能及壓力監測的JMeter、JUnitPerf，以及測試涵蓋度監控的Quilt、Cobertura，與程式碼靜態掃描的Findbugs、Lint等。 ● 測試程式獨立規畫 原則上針對主程式所撰寫的測試程式，亦會依照所測試標的及類別，分別以不同的套件package及類別class來設計撰寫，而不混用在現有的主程式之中，以便於因為不同建構階段執行不同測試自動化內容，及整合建構自動化之管理。例如會以獨立命名一套package；而每個測試案例亦必須都能單獨運作，減少測試程式之間的耦合程度。 ● 測試程式代碼的快速產生 不管你是用何種方式來撰寫測試案例，運用良好的測試框架，結會既有開發工具來輔助測試程式代碼的快速生成是相當重要的。由於撰寫測試程式的代碼實屬枯燥粗活，若可妥善利用程式碼產生工具亦可協助減少撰寫所耗費的時間。例如利用Eclipse IDE內建JUnit plug-in建立單元測試元件；WTTools開源專案裡的UnitTestGen，可整合在建構腳本中自動化產生JUnit對應測試程式碼，並同時進行單元測試作業；商業軟體Parasoft亦針對不同程式語言提供像是JTest或c++ Test等工具以利輔助。 [...]<img alt="" border="0" src="http://stats.wordpress.com/b.gif?host=aone.wordpress.com&amp;blog=72720&amp;post=334&amp;subd=aone&amp;ref=&amp;feed=1" width="1" height="1" />]]></description>
		<wfw:commentRss>http://aone.wordpress.com/2011/07/14/%e6%8c%81%e7%ba%8c%e6%95%b4%e5%90%88%e6%89%80%e6%87%89%e7%94%a8%e7%9a%84%e6%b8%ac%e8%a9%a6%e8%87%aa%e5%8b%95%e5%8c%96/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<georss:point>25.042317 121.565211</georss:point>
		<geo:lat>25.042317</geo:lat>
		<geo:long>121.565211</geo:long>
		<media:content url="http://1.gravatar.com/avatar/3e2f85d189946bf4854adbbb04ff0f98?s=96&#38;d=wavatar&#38;r=G" medium="image">
			<media:title type="html">aone</media:title>
		</media:content>

		<media:content url="http://blog.ithome.com.tw/js/tinymce/themes/advanced/images/spacer.gif" medium="image">
			<media:title type="html">More...</media:title>
		</media:content>
	</item>
		<item>
		<title>軟體開發永續經營的生存之道 第4回 &#8211; 持續整合的核心：建構自動化機制</title>
		<link>http://aone.wordpress.com/2011/07/14/%e6%8c%81%e7%ba%8c%e6%95%b4%e5%90%88%e7%9a%84%e6%a0%b8%e5%bf%83%ef%bc%9a%e5%bb%ba%e6%a7%8b%e8%87%aa%e5%8b%95%e5%8c%96%e6%a9%9f%e5%88%b6/</link>
		<comments>http://aone.wordpress.com/2011/07/14/%e6%8c%81%e7%ba%8c%e6%95%b4%e5%90%88%e7%9a%84%e6%a0%b8%e5%bf%83%ef%bc%9a%e5%bb%ba%e6%a7%8b%e8%87%aa%e5%8b%95%e5%8c%96%e6%a9%9f%e5%88%b6/#comments</comments>
		<pubDate>Thu, 14 Jul 2011 15:28:55 +0000</pubDate>
		<dc:creator>Eric Chen</dc:creator>
				<category><![CDATA[專欄文章]]></category>

		<guid isPermaLink="false">http://aone.wordpress.com/?p=332</guid>
		<description><![CDATA[了解良好版本控管機制的評估及導入注意事項後，本回接續討論持續整合的核心主軸： 建構自動化 &#160; 持續整合期望以集中化的管理平臺，將專案開發過程中所有資訊都能統一控管並透明化，針對建構作業的部分，能提早發掘出整合時會面臨到的問題，進而及早解決，所以將建構予以自動化（Auto-Build）則是落實這想法的重要原因。 建構作業生命周期，在Maven專案中被定義為以下基本階段： ● Validate：確認專案編譯所需資訊，以及相關準備項目均已正確無誤。 ● Compile：編譯專案程式碼。 ● Test：將編譯完畢的程式，結合指定的測試框架進行單元測試。 ● Package：將編譯完畢的程式相關檔案進行封裝，例如產生JAR檔案。 ● Integration-Test：將封裝完畢的套件部署至測試環境，進行整合測試作業。 ● Verify：驗證封裝完畢的檔案，品質符合要求。 ● Install：將封裝的檔案安裝至本地儲存庫（Local Repository），做為其他專案相依性的參照使用。 ● Deploy：在整合測試完畢後，將可部署的版本發布至正式環境 你可依所需搭配建構指令，將這些階段依序進行。目的在於將專案相關的程式碼編譯且封裝成可部署的套件，並完成正確性及品質提升的整合。實務上你只要決定需要的部分，再予以自動化。 建構自動化對既有作業的影響 利用系統設置排程來自動建構，除減少人工介入時間，結合「盡可能持續交付可成功建構的程式碼」，就能夠及早發現整合建構時可能失敗的問題，而立即處理解決，進而降低在整合測試的風險。 而專案經理或技術主管則不需要再手動進行建構及部署指令，這些繁雜的指令都改由系統自動代勞。利用持續整合平臺的機制，依建構自動化的結果來決定是否需要緊急處理。CI伺服器記錄每次建構作業的狀態及細節，可提供開發團隊成員透過Web介面方式即時查得，亦能依建構結果即時通知以利及早處理。 建構自動化設計的多維度思考 就建構作業而言，不僅是將程式碼編譯封裝完成即可，在實務需求上仍需面臨多種維度的思考，才能使建構平臺的優點發揮極致。 ● 針對不同作業環境的需求  因應開發流程中所需的不同環境（像是開發環境，測試環境，正式環境等），以一致性的建構平臺機制來處理，來產出不同的建構結果（像是private build、integrated build、release build），減少重複建置所引發的管理問題。 利用一致化的組態定義檔來決定各種環境建構作業的細節，實務上最常見的就是不同環境必須參照不同的屬性檔（properties），其中包括了資料庫環境（測試與正式環境分隔），內部其他系統（如：ERP），外部介接系統（如：金流付款閘道系統）相關連線參數的對應；另外在不同環境之建構作業，其內容亦會有所差異。例如，在開發測試環境的建構作業會完整執行單元功能測試的測試計畫及案例，而正式環境則會免去此作業。 ● 針對不同任務目的的需求 建構作業除了最基本的編譯封裝成二進位檔之外，為提升軟體品質，可利用建構腳本將其他任務一併加入建構作業中，例如單元功能測試、測試涵蓋度檢驗、靜態程式碼安全性檢測、程式碼內容撰寫規範及文件產生器等。這些作業只要是程式碼一旦異動，就應該重新再次執行確保內容符合規範。 ● 針對不同專案範疇的需求 好的建構平臺可以依不同專案定義出對應的建構計畫，而這裡的專案亦可直接對映到版本控管工具裡的專案定義，前後整合更易管理，對於開發團隊的溝通亦比較有效。 而建構平臺的彈性與選用的解決方案有關，較知名的像開放源碼常用Hudson、CruiseControl，商業解決方案像Microsoft Team Server、IBM Rational Team Concert、Parasoft Concerto。 ● 建置你的持續整合平臺 首先，你需要一個獨立作業環境來安裝CI伺服器平臺，以避免此平臺的運作影響到其他服務的正常運作。Hudson應屬業界採用度最高之免費建構平臺，其安裝快速，系統設置容易，同時提供甚多的延伸外掛工具可供選用，可讓你快速建置持續整合平臺及其他整合機制。 其中不乏知名開放源碼解法方案，像版本控管的Subversion、專案管理的Maven、建構機制Apache Ant、測試框架JUnit等。 建構自動化要能發揮效益，接下來便是了解建構腳本（Build Script）的定義。建構腳本的想法延伸自早期Unix系統中的makefile，透過編輯這樣的檔案內容，來決定編譯的方式及程序為何。然而現今的建構作業的需求範疇愈來愈廣，所有欲被執行的任務（task）均可被定義在建構腳本之中，而任務之間的關連性及先後執行順序，也能一併管理。 [...]<img alt="" border="0" src="http://stats.wordpress.com/b.gif?host=aone.wordpress.com&amp;blog=72720&amp;post=332&amp;subd=aone&amp;ref=&amp;feed=1" width="1" height="1" />]]></description>
		<wfw:commentRss>http://aone.wordpress.com/2011/07/14/%e6%8c%81%e7%ba%8c%e6%95%b4%e5%90%88%e7%9a%84%e6%a0%b8%e5%bf%83%ef%bc%9a%e5%bb%ba%e6%a7%8b%e8%87%aa%e5%8b%95%e5%8c%96%e6%a9%9f%e5%88%b6/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<georss:point>25.042317 121.565211</georss:point>
		<geo:lat>25.042317</geo:lat>
		<geo:long>121.565211</geo:long>
		<media:content url="http://1.gravatar.com/avatar/3e2f85d189946bf4854adbbb04ff0f98?s=96&#38;d=wavatar&#38;r=G" medium="image">
			<media:title type="html">aone</media:title>
		</media:content>

		<media:content url="http://blog.ithome.com.tw/js/tinymce/themes/advanced/images/spacer.gif" medium="image">
			<media:title type="html">More...</media:title>
		</media:content>
	</item>
		<item>
		<title>軟體開發永續經營的生存之道 第3回 &#8211; 持續整合下的版本控管做法</title>
		<link>http://aone.wordpress.com/2011/07/14/%e6%8c%81%e7%ba%8c%e6%95%b4%e5%90%88%e4%b8%8b%e7%9a%84%e7%89%88%e6%9c%ac%e6%8e%a7%e7%ae%a1%e5%81%9a%e6%b3%95/</link>
		<comments>http://aone.wordpress.com/2011/07/14/%e6%8c%81%e7%ba%8c%e6%95%b4%e5%90%88%e4%b8%8b%e7%9a%84%e7%89%88%e6%9c%ac%e6%8e%a7%e7%ae%a1%e5%81%9a%e6%b3%95/#comments</comments>
		<pubDate>Thu, 14 Jul 2011 15:28:04 +0000</pubDate>
		<dc:creator>Eric Chen</dc:creator>
				<category><![CDATA[專欄文章]]></category>

		<guid isPermaLink="false">http://aone.wordpress.com/?p=330</guid>
		<description><![CDATA[版本控管（Version Control）是落實持續整合工作的源頭第一站 &#160; 在軟體開發過程中，程式碼的保存一直是不容忽視的工作事項，而這常受到許多不可抗力因素影響，像是硬碟故障、檔案被誤刪或覆蓋，而造成事後甚高的補救成本。 人有失足，馬有亂蹄，因為程式總會寫錯，需求規畫也可能隨時變更內容，所以，系統總是會需要回復到先前開發的版本。 然而版本控管當然不只是程式碼備份，它可以詳盡記錄程式碼內容異動歷程，是這種工具最基本的功能，以最少的檔案空間記錄最完整的版本資訊，讓開發者可以實際找出所想要的程式碼版本內容。 而為同時能方便維護，版本控管工具也提供了軟體分線管理的概念，讓軟體的管理者可以依特定需求在同一時間發展不同的軟體版本，而將彼此的影響程度降到最低。 另外，軟體開發通常需要多人協同運作，此時就會團隊運作必須解決同一份程式碼同時被多人編輯的問題。版本控管工具提供了成熟良好的機制，發出警訊提醒管理者及相關開發人員及早處理，以避免未預計的狀況不斷發生而延誤開發時程。 版本控管在做什麼？ 一般版本控制軟體的系統架構，以集中式管理為主，而且，系統會以儲存庫（Repository）的方式，將所有欲被控管的檔案內容保存下來，包括在開發過程中所有對程式碼的新增、修改、刪除等動作。 軟體開發人員透過簽出（checkout）的方式，取出指定版本的程式碼內容，在開發環境針對自己的程式碼修改驗證無誤後，即可利用版本控管軟體將修改的程式碼檔案交付（commit）到儲存庫中。一旦交付，版本控管平臺會自動賦予一個修訂版本編號（reversion），做為未來版本管理的主要鍵值。 版本控管平臺允許用專案（project）的方式，來分別定義管理不同範圍的程式碼，而開發人員依其權限的設定，可將指定專案的程式碼內容更新（update）至自己的工作環境（workspace）中，開發者在交付程式碼內容時，版本控管工具會依版本編號來判斷是否可以直接交付，或是出現版本內容衝突（conflict）的警示，讓開發人員進行後續程式碼內容比對（diff）及協調處理。 版本規畫的實務運用 版本控管工具都支援版本標籤（tag）及分支（branch）的機制，以利管理者在軟體發展的生命周期中方便管理。 這兩種方式的使用時機如下： 當軟體開發至可部署發行的版本（release）時，此時就會以標註tag的方式，以利未來快速調出版本內容。標籤的命名方式可結合日期，版控工具的trunk/tags/branches層級編號，對外發布的版本編號，主要發布功能，或是問題編號等資訊以利人為判讀。 然而分支的運用，常見的實務運用像是自有軟體產品的公司，會有預定的產品發展計畫。而實際導入在客戶端時，必然會針對客戶需求進行部分客製化調整，此時這個客製化版本即可利用分支的方式來後續開發管理。規畫出分支的版本，是可以不用再合併（merge）回主版本的。 另一種常見的狀況是同時進行多項需求平行開發時，彼此可能會因為修改在針對軟體加入新功能，而此功能之開發所需時間較長，擔心新功能開發過程中因舊功能發生錯誤需要修復而造成困擾。所以會將較費時的需求，規畫一套獨立分支版本，未來開發完畢再合併回原主版本。 程式碼的合併是有風險的，所發生的內容衝突都會造成不可預期的額外工時，包括了合併程式碼、測試驗證，甚至重新設計等。 相關工具與評估選用的考量點 從早期的CVS，廣泛採用的SubVersion，以及最近較常被討論的Git等，都是活躍於開放源碼界、常用的方案，若你考慮付費的平臺，像IBM Rational Team Concert、Microsoft Team Server等，亦包含版本控管的產品線。 而選用的考量上，有以下幾點： ● 是否與目前開發團隊的開發工具無縫整合？ 版控的相關功能必須要能整合在現有的整合性開發環境（IDE），若在開發過程中切換多個視窗，來處理頻繁的程式修改動作，不易提高工作效率。 ● 版本控管平臺是否支援Web介面操作使用？ 除開發人員會透過client工具直接存取，若平臺也提供Web介面提供相關資訊，非開發人員想要了解內容則可以不用再安裝工具，可直接用瀏覽器的方式查看，應用上會更方便。 ● 管理上的方便性？ 由於大部分版本控管系統採集中化方式管理，當將所有的專案都往上頭一一建置後，其扮演的角色就日益重要。在可用度及備份機制的完整性上也必須一併考量。 另外，由於近期雲端概念的盛行，也可考慮採用既有的服務提供平臺來處理軟體版本控管的需求，除了提供可存取性外，也能節省實體硬體設備及平臺維運的成本。知名的像是Sourceforge、Google Code、github、BerliOS Developer，都有類似服務。 ● 是否支援其他理論規範？ 像CMMI、ITIL、PLM等，大型企業已經逐漸重視，視為企業流程標準化的參考依據。若公司已經計畫導入類似的作業流程，所選擇的解決方案必須要同步考量是否滿足這些規範的需求才行，否則屆時可能會面對系統重新移稙的成本。 ● 是否支援多站點架構（multisite）？ 實務上常見以外包方式進行專案開發，甚至外包對象會是跨企業，甚至跨到對岸去，所以版本控管的架構是否能有效支援多點管理，其中針對不同站點之間的資料複寫及同步、權限控管，都很重要，而且它們都是十分複雜的機制。 除了導入工具，專案團隊還需要…… 系統只是個協助存取程式碼的工具，然而當軟體開發團隊欲應用在實務上時，有一些良好習慣的養成及作業規範，是必須先形成共識的，例如： ● 當開發者接獲需求欲開始進行開發前，必須先利用版本控管工具，取得目前儲存庫中最新版本的程式碼內容再開始作業。 ● 只要開發者撰寫程式碼到一個階段，就將可建構的版本隨時交付至程式儲存庫中，並落實log註解內容的撰寫，以保持儲存庫中的程式碼是最近狀態，且是可被成功編譯建構的。 ● 在交付程式碼時當發生與現有版本內容衝突的情況，從修改歷程記錄中得知前一版修改人員，進而主動與其討論解決。 ● 開發人員每日下班前，必須將工作環境中可建構的版本交付出來，千萬別將程式碼保留在簽出狀態，人就下班了，相信當遇到程式碼內容衝突時，不在場的人常是犧牲的對象。 ● 結合自動化建構工具的整合，專案經理在得知建構作業發生錯誤時，必須立即通知相關程式碼負責人員一起處理即時修復，以利開發作業能持續進行。 [...]<img alt="" border="0" src="http://stats.wordpress.com/b.gif?host=aone.wordpress.com&amp;blog=72720&amp;post=330&amp;subd=aone&amp;ref=&amp;feed=1" width="1" height="1" />]]></description>
		<wfw:commentRss>http://aone.wordpress.com/2011/07/14/%e6%8c%81%e7%ba%8c%e6%95%b4%e5%90%88%e4%b8%8b%e7%9a%84%e7%89%88%e6%9c%ac%e6%8e%a7%e7%ae%a1%e5%81%9a%e6%b3%95/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<georss:point>25.042317 121.565211</georss:point>
		<geo:lat>25.042317</geo:lat>
		<geo:long>121.565211</geo:long>
		<media:content url="http://1.gravatar.com/avatar/3e2f85d189946bf4854adbbb04ff0f98?s=96&#38;d=wavatar&#38;r=G" medium="image">
			<media:title type="html">aone</media:title>
		</media:content>

		<media:content url="http://blog.ithome.com.tw/js/tinymce/themes/advanced/images/spacer.gif" medium="image">
			<media:title type="html">More...</media:title>
		</media:content>
	</item>
		<item>
		<title>軟體開發永續經營的生存之道 第2回 &#8211; 如何實施與導入持續整合</title>
		<link>http://aone.wordpress.com/2011/07/14/%e8%bb%9f%e9%ab%94%e9%96%8b%e7%99%bc%e6%b0%b8%e7%ba%8c%e7%b6%93%e7%87%9f%e7%9a%84%e7%94%9f%e5%ad%98%e4%b9%8b%e9%81%93-%e7%ac%ac2%e5%9b%9e-%e5%a6%82%e4%bd%95%e5%af%a6%e6%96%bd%e8%88%87%e5%b0%8e/</link>
		<comments>http://aone.wordpress.com/2011/07/14/%e8%bb%9f%e9%ab%94%e9%96%8b%e7%99%bc%e6%b0%b8%e7%ba%8c%e7%b6%93%e7%87%9f%e7%9a%84%e7%94%9f%e5%ad%98%e4%b9%8b%e9%81%93-%e7%ac%ac2%e5%9b%9e-%e5%a6%82%e4%bd%95%e5%af%a6%e6%96%bd%e8%88%87%e5%b0%8e/#comments</comments>
		<pubDate>Thu, 14 Jul 2011 15:26:20 +0000</pubDate>
		<dc:creator>Eric Chen</dc:creator>
				<category><![CDATA[專欄文章]]></category>

		<guid isPermaLink="false">http://aone.wordpress.com/?p=328</guid>
		<description><![CDATA[軟體開發永續經營的生存之道 第2回 持續整合的精神在於，將軟體工程的理論進一步落實在專案執行面，大致上，會出現哪些狀況？ &#160; 前一回提到持績整合所帶來的好處，但相信很多人在研究一些軟體工程方法論的書時，心中大都會浮現以下問題，或遭遇一些無法控制的狀況： ●研讀了不少軟體工程的書，像UP、Agile、XP、Scrum等觀念都很棒，但真的專案在進行時，還是不知道要如何套用進來？ ● 軟體工程方法是一回事，實做又是另外一回事？因為專案團隊的成員對方法論都不熟，不斷嘗試錯誤未能全然掌握方法的精髓，常常走許多冤枉路，才有一點點進展。 ● 軟體專案計畫派不上用場，時間上根本不足以允許你妥善規畫，可能老板的一句話就將原有的規畫全盤打破，當專案被時程壓力所限制後，所有的方法論就拋諸腦後。 ● 新方法的導入造成現行作業的衝擊，團隊成員浮現抗拒心態，造成想推也推不動。 持續整合的範疇 持續整合的範疇，可依專案組織的現況及現有可用資源，來決定需要導入的項目。一般而言，可分以下項目分別導入建置： ● 版本控管（Version Control） 於多人開發的專案團隊，版本控管的議題算是最基本，也是最重要的項目，準備一個版本控管資料庫 （Repository） 是必要的。軟體開發的生命周期過程，必然會面臨程式碼版本的分支（Branch）、貼標（Tag）、合併（Merge）、回溯（Revert）、比對（Compare）等需求。良好的版本控管機制可提供好的工具，來協助開發人員面臨這樣多變的需求，以利在短時間內能產出正確可部署的軟體版本發布。 目前坊間常見的版本控管機制，包括付費及免費、集中及分散式控管，種類甚多，評估導入的因素可依專案團隊同時使用人員的多少，開發工具是否能整合，建置成本及時間的長短等因素，來分別思考，來找出適合開發團隊使用的方案。 ● 測試自動化（Auto-Testing） 軟體測試的類型繁多，主要都是為了確保軟體品質而搭配使用，測試作業的繁複常不易在有限的專案時程內被全然落實，有時亦會為了方便行事，忽略了部分測試作業，或是避開重測，但常常事後發生異常的點，都是這些被忽略的地方。 利用人工來進行測試作業是十分累的，所以將繁雜且重要的測試工作自動化是必然的，將各項重要的測試工作及測試範圍涵蓋度的檢測，連同程式碼建構作業時以系統自動執行必要測試的項目一併處理，當出現異常錯誤時再由人工介入處理，才能將時間有效花在刀口上。 不過想到要多寫這些測試程式，相對又增加一定比重的開發時間，對開發人員勢必又造成負擔。當然也可以配合一些測試程式碼的產生工具，來快速生成測試作業時的基本所需。 ● 建構自動化（Auto-Build） 建構自動化的用意在於及早發現程式可能的錯誤，在未擴大影響範圍之前便先行處理，而持續整合的精神亦可以透過設置頻繁自動建構的方式 （例如系統每60分鐘自動執行建構作業的執行），結合自動通知機制，讓開發團隊成員可以得知目前最新版本的建構結果。 建構作業的項目，除整合前項測試外，亦可加入許多提高軟體品質的作業，例如程式碼撰寫風格的格式化，方便後續開發人員撰寫時閱讀；以及，針對程式碼內容反向生成參考文件，以利程式與文件內容一致化；或是利用靜態程式碼掃描工具，一併檢測程式隱含的效能及安全性問題而及早修正等。 ● 錯誤通報及後續追蹤處理機制的整合 軟體開發團隊必然有問題追蹤系統 （Issues Tracking System），其中錯誤問題的來源可能是日常外部單位的通報、系統自動監控的示警、軟體建構過程中發生的編譯錯誤或測試失敗。然而這些事項的分派及後續處理狀況的追蹤，理想上也必須能透過系統自動化的方式來進行，才不致於造成工作分派環節的瓶頸所在。 持續整合對專案團隊各角色的衝擊為何？ 新方法及工具的導入，對既有專案團隊的影響，會歸因於所選擇導入的方式，主要的影響如下： ● 每位開發人員應盡可能不斷地將修改後，可以成功建構（build）的程式碼內容隨時交付（commit）至程式碼資料庫（Repository）中進行整合，相關動作的執行可以每日多次，頻率可以提高。 ● 開發人發必須嚴守交付可成功構建的程式碼，尤其是在每日下班前確保這個動作無誤。 ● 開發團隊必須撰寫額外的測試程式。開發人員需要針對自行開發的元件及服務，完成測試程式的撰寫；而系統設計師也必須針對跨元件或整合服務流程，進行測試程式碼的撰寫，搭配程式碼構建時的測試自動化作業，以確保程式碼品質。 ●整合構建時若出現錯誤、測試自動化過程若出現錯誤結果，亦須立即處理修改。 ●開發人員必須隨時確保自己的工作版本，與目前版本控管資料庫中的程式碼一致。 這些都是作業原則及開發紀律的要求，落實於軟體開發作業更能有效發揮持續整合的精神，執行的方式會因採用的工具不同而做法不一。嚴格說來，對於每個專案成員的現行作業方式並不會有太大的衝擊，也許需要短時間適應一些工具的使用及自動化平臺的建置，但這僅為一次性的短期影響，而且不會投入太高的成本，包括人力及軟硬體需求。 開發團隊每天進行持續整合的作業流程 對於開發人員而言，每天早上上班前會先將版本控管平臺裡最新狀態的程式內容，更新到自己的工作環境中；同時前一天每日建構版本（Daily Build）的作業是否有發出錯誤通知，需要自己立即處理的問題; 接下來隨即進行今日的開發工作進度，檢視問題追蹤系統中被指派的工作項目，進行程式碼的修改及測試。一旦開發好的元件完成自己的單位測試後即交付至版本控管平臺上，若有任何更新交付後的程式碼在自動建構作業過程中有問題，亦會即時收到通知而立即處理。 而專案經理每日亦透過建構平臺所提供的建構結果報告，了解每次建構版本的編譯及測試範圍及結果是否符合預期，當結果出現錯誤時，需及時聯繫涉及的開發人員及時進行問題處理；而在開發進行中，交付程式碼期間出現多人編輯而發生版本衝突時，需要協調相關人員進行程式碼合併作業以利順利交付。而上線版本的決定，則會依據開發進度及測試狀況，部署至其他測試環境，來提供不同的測試目的，以利進行測試。 持續整合的價值何在？ 以上利用持續整合的實務做法，最重要的是從已經被壓縮的專案時程中，以系統自動化的方式擠更多的空間出來，讓專案團隊能更從容地做好原本應該完成的工作，甚至可以應對其他千奇百怪的突發狀況。 [...]<img alt="" border="0" src="http://stats.wordpress.com/b.gif?host=aone.wordpress.com&amp;blog=72720&amp;post=328&amp;subd=aone&amp;ref=&amp;feed=1" width="1" height="1" />]]></description>
		<wfw:commentRss>http://aone.wordpress.com/2011/07/14/%e8%bb%9f%e9%ab%94%e9%96%8b%e7%99%bc%e6%b0%b8%e7%ba%8c%e7%b6%93%e7%87%9f%e7%9a%84%e7%94%9f%e5%ad%98%e4%b9%8b%e9%81%93-%e7%ac%ac2%e5%9b%9e-%e5%a6%82%e4%bd%95%e5%af%a6%e6%96%bd%e8%88%87%e5%b0%8e/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<georss:point>25.042317 121.565211</georss:point>
		<geo:lat>25.042317</geo:lat>
		<geo:long>121.565211</geo:long>
		<media:content url="http://1.gravatar.com/avatar/3e2f85d189946bf4854adbbb04ff0f98?s=96&#38;d=wavatar&#38;r=G" medium="image">
			<media:title type="html">aone</media:title>
		</media:content>

		<media:content url="http://blog.ithome.com.tw/js/tinymce/themes/advanced/images/spacer.gif" medium="image">
			<media:title type="html">More...</media:title>
		</media:content>
	</item>
		<item>
		<title>軟體開發永續經營的生存之道 第1回 &#8211; 用CI面對軟體開發團隊的難題</title>
		<link>http://aone.wordpress.com/2011/07/14/%e8%bb%9f%e9%ab%94%e9%96%8b%e7%99%bc%e6%b0%b8%e7%ba%8c%e7%b6%93%e7%87%9f%e7%9a%84%e7%94%9f%e5%ad%98%e4%b9%8b%e9%81%93-%e7%ac%ac1%e5%9b%9e-%e7%94%a8ci%e9%9d%a2%e5%b0%8d%e8%bb%9f%e9%ab%94%e9%96%8b/</link>
		<comments>http://aone.wordpress.com/2011/07/14/%e8%bb%9f%e9%ab%94%e9%96%8b%e7%99%bc%e6%b0%b8%e7%ba%8c%e7%b6%93%e7%87%9f%e7%9a%84%e7%94%9f%e5%ad%98%e4%b9%8b%e9%81%93-%e7%ac%ac1%e5%9b%9e-%e7%94%a8ci%e9%9d%a2%e5%b0%8d%e8%bb%9f%e9%ab%94%e9%96%8b/#comments</comments>
		<pubDate>Thu, 14 Jul 2011 15:25:13 +0000</pubDate>
		<dc:creator>Eric Chen</dc:creator>
				<category><![CDATA[專欄文章]]></category>

		<guid isPermaLink="false">http://aone.wordpress.com/?p=326</guid>
		<description><![CDATA[軟體開發永續經營的生存之道 第1回  未能有效落實標準自動化的作業程序，使得程式開發期間產生問題，解決這些狀況時，不僅占用負責人原本的工作，也影響其他工作進度  場景一：「咦？Roger，昨天加班到幾點才走呀？」 「唉，搞到很晚，程式在開發環境測試都沒問題，結果在SIT環境上build不過，查半天，才發現開發環境的某個JAR檔版本不對，搞好久……」 場景二：「Kevin很早就來了呀？昨天沒回去？」 「是呀，早上系統要上新功能，這次的需求範圍很大，約異動了一百多支程式，怕動到原有的功能，就也將原有的功能都逐一再測過，測試案例實在太多了，得花很多的時間再確認…」 場景三：「咦？Alex還沒要走呀？」 「唉，臨時被通報系統有問題，還在查問題的原因為何。奇怪，今天上版前還好好的呀，怎麼上了也就掛了，也沒改到什麼程式呀……」 上述場景，身為軟體開發團隊成員的你應該不陌生：工作時間常被突發事項所中斷，或是被一些非主要核心的工作事項所延誤，導致於增加自己的工作時間，搞得身心疲憊，工作品質也每況愈下。 軟體開發長久以來常見的痛 沒錯！致命的痛楚，常常是經年累月未明顯改善後的結果。你是否也遇過以下狀況，讓你傷透腦筋： ● 昨天才改好的程式，在整合時發現問題，原本來其他同仁的檔案內容覆蓋了，最糟的是自己也沒備份，必須從頭再來一次。 ● 新功能都已經正式發布了，需求單位才又要求要回復先前的功能，因為沒有版本控管機制，程式碼已找不回舊的版本內容。 ● 自己已經寫好的程式，在自己的開發環境測都沒問題，但丟到整合測試環境時就狀況連連，又得花上不少時間來找原因，不斷反覆測試花費了不少時間，最終還是沒測完整，一些嚴重的例外狀況或異常問題，都是在正式上線後，才逐一浮現。 ● 當程式碼更新到正式環境後，原本可用的功能卻出現異常，最糟的是開發單位並不曉得，而是等到使用者單位反應才知道。 ● 由於時程的關係，多個修改需求必須同一時間一起進行，多人同時修改相同的程式碼區段，使得版本卡住的問題影響開發順暢度，需花上許多時間調整，才可能更新成功。 ● 只要有修改程式就得重新編譯封裝測試部署，以人工不斷執行這些工作的效率不佳，而且容易因無誤而出錯。 上述問題，不外乎都是該標準自動化的作業程序未能有效落實。這些問題，導致需要花上額外的時間來緊急處理，間接又影響其他已經排定的工作，造成開發人員不斷地加班趕進度，不斷出錯，落入永無止境的無窮迴圈。 持續整合的精神所在 首次聽到持續整合（Continuous Integration，CI）的人，對這名詞應該是一頭霧水，其實就是讓軟體專案順利進行的方法，搭配一些系統自動化的工具，落實在開發、建構、測試、部署各個階段，目的在於不斷地透過持續改善的方式，整合團隊投入的資源，讓軟體品質的成熟度更高。 所以近年來在軟體工程方法往輕量化，成果導向化的方向演進後，快速開發已經是現今軟體專案的最重要訴求，才能隨時因應需求面因為劇烈環境的變化。像是敏捷開發（Agile Software Development）、測試驅動開發（TDD）、極限編程（XP）方法論的實作理念中，皆提出持續整合的重要性，可見這種觀念越來越受到重視。然而「快速」不只是開發時間要快，相關的作業程序必須要能提升效率，否則瓶頸仍然無法突破。 只要程式碼內容有異動便整合，持續進行 以往的軟體專案，都會將整合測試時程定義在開發階段的末段，所以，全部的程式碼也是在那個時間點才來進行建置及整合。尤其大型專案的程式碼異動範圍較廣，所需開發時程較長，在整合測試時所會出現的狀況就會顯得有些失控，直接影響專案時程落實的準確性。 持續整合強調的是，開發團隊一旦進行程式碼修改，即刻進行整合測試驗證，好處在於及早發現及早治療，就不會讓整合遇到的問題被延後發現。 妥善的版本控管，包括程式碼及外部函式庫 只要是多人同時運作，必然會有程式碼共同使用的管理問題，所有更新的內容，均必須集中且完整地記錄下來，隨時因應不時之需。 在軟體的發展過程中，版本的分支、合併、回溯、比對，都會因不同的現實需求而受到要求來執行，所以只要你的軟體專案不只一個人開發，就必須建置良好的版本控管平臺。一併將自己開發的程式碼及外部函式庫版本同步納入管理，就可以確保在每個環境的版本一致，避開無法預期的錯誤。 將繁複的人工作業予以標準化、自動化 早期，任何談論軟體工程方法論都會提及這樣的想法，像是單元、整合、迴歸等測試自動化，以及寫程式時即同步撰寫文件、多人平行開發撰寫程式碼、整合測試環境自動構建作業的理想，只是觀念一直沒有配合適當的工具來落實，僅限於紙上談兵的階段。 軟體工程的「工程」兩個字，應該是盡可能將作業程序自動標準化，才能確保品質。實務上卻沒有充分利用系統自動化的機制或工具，反倒是以人力密集來填補這些不斷發生的問題，時間久了當然也身心俱疲。 持續整合觀念即在於解決上述開發環境及反覆流程所發生的問題，並做到「一指定江山」，理想上是做到只要按一個按鈕，系統就會自動進行軟體建構作業，連測試、分析、作業，都一併處理完畢。這樣的概念，目前已經有協同搭配的自動化工具可以協助落實，大幅提升效率。 軟體品質要求的提升 軟體品質的提升可分兩個層面，包括機器及人文。讓機器能運作順暢的程式碼，必須靠著精準且完整的測試作業才能達成，從開發階段的單位測試及整合測試，到使用者主導的情境測試，測試的項目實在太多，必須將重複進行的測試工作透過系統來落實。否則常因為時程壓力忽略測試作業，造成軟體品質低落。 而在人文方面，程式碼本身的易讀性亦是品質關鍵之因。程式碼是不斷由人所編寫修改，而且同一程式是由多人修改的。結合自動化構建作業、同步整理程式碼撰寫風格，並以一致化規範來格式化，能讓開發人員在最短時間拿到程式碼後即刻著手修改，亦是品質要求後所能達到的成效。 專案團隊協同運作更密切順暢 專案的協同運作上，免不了會有丟球、接球的合作狀況出現，就像大隊接力，除每一棒的跑者自身腳程的鍛練外，著重在能否以最短的時間順利接棒，整體團隊花費的時間才能有效縮減。 利用持續整合中所提到的協同運作系統平臺，專案團隊可藉此集中控管所有開發內容，包括所有外部、內部引用之資源，自行開發之程式碼，所有更新歷程均明確記錄；透過自動化的流程結合人工作業，輔以即時性的訊息通知，就可以節省無謂的等待時間，在建構完畢會將過程中出現錯誤的部分，直接派送到負責工程師，以利立即處理掌握時效。 分類:專欄文章<img alt="" border="0" src="http://stats.wordpress.com/b.gif?host=aone.wordpress.com&amp;blog=72720&amp;post=326&amp;subd=aone&amp;ref=&amp;feed=1" width="1" height="1" />]]></description>
		<wfw:commentRss>http://aone.wordpress.com/2011/07/14/%e8%bb%9f%e9%ab%94%e9%96%8b%e7%99%bc%e6%b0%b8%e7%ba%8c%e7%b6%93%e7%87%9f%e7%9a%84%e7%94%9f%e5%ad%98%e4%b9%8b%e9%81%93-%e7%ac%ac1%e5%9b%9e-%e7%94%a8ci%e9%9d%a2%e5%b0%8d%e8%bb%9f%e9%ab%94%e9%96%8b/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<georss:point>25.042317 121.565211</georss:point>
		<geo:lat>25.042317</geo:lat>
		<geo:long>121.565211</geo:long>
		<media:content url="http://1.gravatar.com/avatar/3e2f85d189946bf4854adbbb04ff0f98?s=96&#38;d=wavatar&#38;r=G" medium="image">
			<media:title type="html">aone</media:title>
		</media:content>

		<media:content url="http://blog.ithome.com.tw/js/tinymce/themes/advanced/images/spacer.gif" medium="image">
			<media:title type="html">More...</media:title>
		</media:content>
	</item>
		<item>
		<title>網站效能分析操作心法 第7回 &#8211; 增進網站效能調校功力的私房祕笈</title>
		<link>http://aone.wordpress.com/2011/07/14/%e7%b6%b2%e7%ab%99%e6%95%88%e8%83%bd%e5%88%86%e6%9e%90%e6%93%8d%e4%bd%9c%e5%bf%83%e6%b3%95-%e7%ac%ac7%e5%9b%9e-%e5%a2%9e%e9%80%b2%e7%b6%b2%e7%ab%99%e6%95%88%e8%83%bd%e8%aa%bf%e6%a0%a1%e5%8a%9f/</link>
		<comments>http://aone.wordpress.com/2011/07/14/%e7%b6%b2%e7%ab%99%e6%95%88%e8%83%bd%e5%88%86%e6%9e%90%e6%93%8d%e4%bd%9c%e5%bf%83%e6%b3%95-%e7%ac%ac7%e5%9b%9e-%e5%a2%9e%e9%80%b2%e7%b6%b2%e7%ab%99%e6%95%88%e8%83%bd%e8%aa%bf%e6%a0%a1%e5%8a%9f/#comments</comments>
		<pubDate>Thu, 14 Jul 2011 15:24:14 +0000</pubDate>
		<dc:creator>Eric Chen</dc:creator>
				<category><![CDATA[專欄文章]]></category>

		<guid isPermaLink="false">http://aone.wordpress.com/?p=324</guid>
		<description><![CDATA[網站效能分析操作心法 第7回  若能自學來提升相關專業領域的深度及廣度，也是練就好功夫的不二法門，我想提出覺得具有參考價值的幾本相關書籍，供你搭配閱讀  要探索系統效能調校最完整的資料來源，必然是研讀該產品原廠所提供的官方技術手冊，掌握產品特性及技術細節。然而原廠文件大都是英文居多，而且大多撰寫的方式較非以實務角度為出發點，閱讀上未免較枯燥無味。所以，我想提出有參考價值的幾本相關書籍。 系統架構 以效能改善的程度來思考，架構性調整所得來的改善效益會遠比軟體開發面要來得高，但少有書專論整合性網站系統的架構規畫及效能分析，寫得好的更是少數。像筆者早期曾接觸像是《Performance Analysis for Java Web Sites》，就會覺得作者所談論的範圍相當全面，同時見樹又見林的撰寫方式，從系統架構到程式開發都有著墨，對於少有機會接觸廣度較高的專案的人，實為難得。 此書中提到許多實務面相當受用的觀念，像是與網站系統效能有關的硬體及軟體的配置，應用系統開發過程中，針對效能要求的項目如何進行測試，以及測試的標準、依據，選用的測試工具為何、到最後上線時的數據收集分析及後續調校，甚至為進行系統擴充如何執行容量規畫，都有專章說明。 最後在書末附註章節中提供的檢核表格文件，包含各式軟硬體系統的容量規畫、系統上線前的前置測試計畫，以及各式軟硬體系統之效能檢測表，對於從事網站開發的從業人員都是相當實用的參考資料。 而Apress出版的《Pro Java EE 5 Performance Management and Optimization》，所描述的內容，就完全著重在效能管理的完整規畫課題，並非只是談論遇到問題如何解決。作者強調應提前在系統開發設計階段就應列入評核標準，將效能檢測視為軟體產品開發生命周期（PLM）的其中一環，定義標準化的檢測程序，早期發現早期治療。 在軟體專案需求中的非功能面需求，必然會定義到關於系統效能所預期的標準，像是網站系統同時可上線人數、網頁回應時間、單位時間可成立訂單數等。本書從如何定義系統效能檢測作業開始，針對檢測結果優化調校應用伺服器平臺及程式碼內容，反覆驗證達到預期需求標準。而在開發設計階段初期，即考量到應使用的架構及運用技術為何，甚至在系統概念驗證（POC）階段，即確保效能達成的技術可行性，同時考慮到未來容量擴增時的架構彈性（Scalability），並在程式碼撰寫方式及品質要求上，以標準化方式進行，期望將效能問題的風險降到最低。 一旦網站系統上線至正式環境後，更不容許因為效能問題造成服務不佳甚至中斷停機等狀況發生，所面臨的課題則更加嚴峻。為落實良好的效能管理，必須在問題發生之前便能事先預防。本書也專章介紹，關於網站維運階段在各項重點工作上應注意的事項，包括效能檢測作業、異常及障礙排除、系統用量的預測及規畫，作者都提供了明確建議做法，供讀者參考。 而本書別出心裁的章節在於第四部分。作者針對J2EE平臺常見的效能問題及分析解法整理在這個章節，像是遇到記憶體不足（Out-of-Memory Errors）、執行緒運作效能問題、資料庫連線問題、資料存取指令及快取運用的相關問題等。這裡的建議並非頭痛醫頭的快速猛藥，作者會詳細介紹技術平臺相關機制的運作原理，以及分析問題可能的原因，並回應到系統參數調校上，讓讀者能清楚了解。 網站系統中，作業系統本身的管理也不容忽視，其為所有服務平臺的基石，在未選用良好的作業系統及適當的調校，則直接影響到系統。像是多核處理器架構之運算效能是否有效發揮、磁碟I/O的存取單位及方式等。O&#8217;Rielly出版的《System Performance Tuning》，即談論作業系統面與硬體資源的配置，協助你揭開底層系統運作架構的神秘面紗、清楚掌握運作原理，並透過有效調校，打好底層環境基礎。 系統設計 不良的系統設計造成未來效能問題的機率甚高，討論系統設計面的專書就較常見，而Addison Wesley出版的Effective系列叢書，能針對不同技術領域提供優化設計的進階建議。較知名的像是Addison Wesley的《Effective Enterprise Java》、《Effective Java，2nd》都討論到系統設計及程式撰寫面如何優化效能。 而軟體專案在為滿足需求功能的同時，亦需同時以具效率的設計方式來實作開發，《Effective Enterprise Java》著重在J2EE平臺軟體架構設計時的實務技巧，分別針對軟體架構、資料傳遞、邏輯運算、資料狀態管理、介面呈現、系統核心及安全等層面探討，舉出共75項設計原則供讀者參考，可算是伺服器端效能改善設計上十分完整的介紹。《Effective Java，2nd》則更著重Java程式撰寫本身應秉持的原則。若要寫出高效能的程式，不但要充分了解程式語言本身的特性，另外便是以良好的演算邏輯來處理問題。這裡廣泛提及JDK套件正確的使用方式、物件設計及操作的方法，以及適當時機運用合適的資料結構及程式語法，總共提出78項建議。 網站優化 像是O&#8217;Rielly先後出版的《High Performance.Web Sites》、《Even Faster Websites》，則是主要探討網頁構成元素如何優化呈現及縮短回應時間的專書，包括程式撰寫要點及網頁伺服器配置時要求。其中《High Performance Web Sites》列出的十四項黃金法則，亦結合在網站效能檢測工具YSlow中，你可以利用這套工具找出效能問題，然後搭配書中的建議解法來改善，有助於實務應用。作者Steve Souders有鑑於新一代網站技術發展的挑戰，再撰寫《Even Faster Websites》針對JavaScript運用方式、網路回應時效、瀏覽器效能提升等三大方面，提出更進階的效能改善建議。書中對於每項提出的建議解法，都佐以實際驗證測試的圖表結果來說明，明確告知實作方式的成效顯著，並非紙上談兵。 目前網站系統使用JavaScript來進行介面設計及資料傳遞的比重大增，雖然不見得會直接影響伺服器效能，但多少也會影響用戶端網頁的反應效率。O&#8217;Rielly出版的《High Performance JavaScript &#8211; [...]<img alt="" border="0" src="http://stats.wordpress.com/b.gif?host=aone.wordpress.com&amp;blog=72720&amp;post=324&amp;subd=aone&amp;ref=&amp;feed=1" width="1" height="1" />]]></description>
		<wfw:commentRss>http://aone.wordpress.com/2011/07/14/%e7%b6%b2%e7%ab%99%e6%95%88%e8%83%bd%e5%88%86%e6%9e%90%e6%93%8d%e4%bd%9c%e5%bf%83%e6%b3%95-%e7%ac%ac7%e5%9b%9e-%e5%a2%9e%e9%80%b2%e7%b6%b2%e7%ab%99%e6%95%88%e8%83%bd%e8%aa%bf%e6%a0%a1%e5%8a%9f/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<georss:point>25.042317 121.565211</georss:point>
		<geo:lat>25.042317</geo:lat>
		<geo:long>121.565211</geo:long>
		<media:content url="http://1.gravatar.com/avatar/3e2f85d189946bf4854adbbb04ff0f98?s=96&#38;d=wavatar&#38;r=G" medium="image">
			<media:title type="html">aone</media:title>
		</media:content>

		<media:content url="http://blog.ithome.com.tw/js/tinymce/themes/advanced/images/spacer.gif" medium="image">
			<media:title type="html">More...</media:title>
		</media:content>
	</item>
		<item>
		<title>網站效能分析操作心法 第9回 &#8211; 從資料庫來調校：資料處理存取篇</title>
		<link>http://aone.wordpress.com/2011/07/14/%e7%b6%b2%e7%ab%99%e6%95%88%e8%83%bd%e5%88%86%e6%9e%90%e6%93%8d%e4%bd%9c%e5%bf%83%e6%b3%95-%e7%ac%ac9%e5%9b%9e-%e5%be%9e%e8%b3%87%e6%96%99%e5%ba%ab%e4%be%86%e8%aa%bf%e6%a0%a1%ef%bc%9a%e8%b3%87/</link>
		<comments>http://aone.wordpress.com/2011/07/14/%e7%b6%b2%e7%ab%99%e6%95%88%e8%83%bd%e5%88%86%e6%9e%90%e6%93%8d%e4%bd%9c%e5%bf%83%e6%b3%95-%e7%ac%ac9%e5%9b%9e-%e5%be%9e%e8%b3%87%e6%96%99%e5%ba%ab%e4%be%86%e8%aa%bf%e6%a0%a1%ef%bc%9a%e8%b3%87/#comments</comments>
		<pubDate>Thu, 14 Jul 2011 15:23:02 +0000</pubDate>
		<dc:creator>Eric Chen</dc:creator>
				<category><![CDATA[專欄文章]]></category>

		<guid isPermaLink="false">http://aone.wordpress.com/?p=322</guid>
		<description><![CDATA[網站效能分析操作心法 第9回  CPU、記憶體及I/O存取效率會影響資料庫系統效能，而這與資料存取的方式大多脫離不了干係  資料庫系統效能出現問題時，追蹤到最後，常會發現是因為某個SQL指令未加以優化而造成。水能載舟亦能覆舟，如何在效能優化的考量下達成資料存取的需求？ 資料可攜性設計考量的迷思 在一些最佳實踐方案的設計建議，或是J2EE架構設計藍圖中，對於資料處理的邏輯設計都會強調可攜性（Portability）考量的重要。可攜性考量的主要觀點，在於將資料處理邏輯實作在商業邏輯層，而不以資料庫特有之機制來處理（像是採用Stored Procedure、Trigger等），以免未來在更換資料庫系統時，保有系統移植的平順度，不會因此而需要重新撰寫資料庫端的邏輯處理作業。這樣的思維立意甚佳，也有不少將之奉為圭臬，將資料庫提供的強大功能棄之不用，而依賴在不易處理複雜資料處理作業的持久層（Persistence Layer）軟體框架上。 透過持久層進行資料庫存取，美其名是表揚物件封裝的精神，符合軟體框架設計的理念，實則有如隔靴搔癢，無法有效掌握資料存取的方式。持久層以未被資料庫系統認定的較佳方式存取資料庫，理所當然在效能表現上必然不會比直接以撰寫SQL指令來得佳。若是需要進行多個資料表關連的查詢時，這樣的問題更會被突顯出來。 就實務上而言，資料處理效能的最佳化，勢必是直接使用資料庫系統所提供自身的執行環境及程式語言，才能將資料處理作業效率提到最高。這樣的設計少了應用伺服器與資料庫之間的資料傳輸時間，降低因連線中斷造成交易作業異常的風險。 找出問題SQL進行改善 在資料庫系統端，最常見造成效能表現瓶頸的原因是起因於SQL指令。目前許多便利的開發工具都提供了SQL指令產生器，該功能方便地幫開發人員快速產生SQL語法，但幾乎都是非最佳化後的結果，若直接拿來使用，常常就會造成效能問題。利用資料庫所提供的管理介面，像是Oracle Enterprise Manager、SQL Server Management Studio都可以找出成本較高的指令，再來進行語法的調整及優化。 針對SQL命令的改善作法，可以搭配資料庫系統所提供的分析工具來先了解主要造成執行效能問題的環節，像是Oracle的Explain Plan，或是MS SQL Server的執行計畫，讓我們可以分析得出SQL命令預計在執行過程中，所進行的處理步驟及可能花費的時間及成本。從這裡得出的分析結果，可以快速找出改善的點，最常見的便是出現Full Table Scan的項目，勢必得建立適當的索引來加速處理。 實務上會避免一些SQL撰寫用法，像是： ● 避免用LIKE方式查詢，會造成資料庫的Full Table Scan，成本甚鉅。 ● 進行多個資料表關連查詢時，在SQL指令中WHERE後的資料表名稱順序，建議資料量由大至小來依列排放。 ● 查詢條件中避免直接使用函式或運算結果當成是過濾條件，在指令處理上會多一些處理程序而造成成本較高。 ● 盡可能不要在同一個SQL指令中，使用多層次查詢（sub-query），若必要時，以增加條件來減少次查詢中回傳資料筆數。 批次處理程式的設計原則 在許多的應用實例上，會設計批次處理的程式來進行資料存取，例如定期報表的產生、未付款訂單的系統取消作業等。而批次作業的特性在於，每次執行時處理的資料量較大，處理上必須考量到資源使用及釋放的時間點，同時是否會影響線上網站正常的使用。所以在設計上必須同時考量到執行的時間何時合適，預估每次執行作業所需的時間，以及影響的資料層面及處理的資料量。 若批次作業主要為查詢報表的產出，需要留意執行時間是否避開網站用量尖峰時間。若為大量資料異動作業，盡可能是每異動一小批資料即回寫乙次（commit），因為異動資料的作業在尚未commit之前，該資料是會被系統進行鎖定處理（data lock），若當時正好有其他程式需要異動同一筆資料時，則會進入等候狀態，就會造成整體處理時間過長。 妥善規畫網站後臺功能 網站的前臺與後臺管理系統，大都會設計成存取同一個資料庫，用意在於提供後臺資料管理的便利性，能即時將任何資料的異動反映到前臺內容中。然而這樣的架構下，後臺管理系統對於資料庫的存取設計，就會直接影響到前臺瀏覽效能的表現。 就設計上而言，網站前臺的頁面瀏覽方式，其對資料庫存取的方法重複性較高，對應到SQL指令的語法也較能在預期的範圍內，所以SQL語法上較比較能享受到因調校後所帶來的效能改善。例如常見的動態網頁設計，會傳入不同的編號代碼來取出對應的文章內容，或是以商品編號來顯示不同商品頁面的購買資訊。以這樣的資料模型架構下，建立對應的索引鍵值，以及查詢快取的機制，都可有效發揮，明顯改善網站的資料存取效能。 而後臺系統必須同時提供CRUD多種資料操控功能，而且為求方便管理人員作業便利，會透過多種join的方式來參照多個資料表，讓使用者可以在較少的點擊數下完成所預期的資料查詢或處理作業。像是提供地址縣市鄉鎮區域的下拉連動選單，點選商品分類時同時呈現屬於該分類下的所有商品，或是查詢某特定會員基本資料時，需要同步查詢其訂單交易資料及客服記錄等。這些資料關連的操作，都遠比前臺提供給一般使用者的頁面功能，成本來得高上許多。 為求對線上資料庫的衝擊降到最低，就實務面的設計上，以下是幾點在設計時可以參考的做法： ● 盡可能不要在單一網頁，呈現過多需要透過資料表關連才能得到的資料。就使用者行為而言，不見得每次頁面呈現，都需要閱讀到頁面上的所有資訊，以額外的連結提供進一步查詢，在真正需要顯示時再進行查詢，可以省下額外處理成本。 ● 較複雜的資料存取功能，以權限控管的方式僅提供少數人員使用。一些特定的複雜操作功能可利用有效管控的方式減少使用者的使用次數及頻率，以免不當操作直接影響資料庫效能。 ● 在管理操作介面上要求輸入較多的查詢條件，才允許進行作業。像查詢功能最忌諱的是，使用者不下任何條件即送出查詢請求。對於像是訂單查詢功能，必須同時提供兩項以上之查詢條件，才允許送出處理，可以避免單次查詢時所回傳的資料量過多，而造成效能不彰。至於查詢條件要多少才允許放行，則需再考量涉及的資料量多寡而定。 ● 運用使用介面上的防呆設計，以免被不當重複執行。實務上常見到使用者因系統反應時間較長，會利用不斷重整網頁或重複按下送出，而造成主機端進行無謂的多次處理。若能套用防呆設計，可以阻擋因無意的點擊而產生的動作。像是在表單資料送出時，原送出按鍵予以失效，或是在按下送出時，利用CSS圖層方式來顯示執行中的提示，以防重複點選。 ● 統計彙整型報表，避免對線上資料庫直接操作。像是周期性報表，需要透過大量彙總運算資源的報表內容，不宜直接利用線上環境的資料庫來產生，建議另外妥善設計資料匯出的功能，提供使用者自行下載原始資料，由他們自行透過Excel等工具製作進階的圖表，可以省去龐大系統代價。 分類:專欄文章<img alt="" border="0" src="http://stats.wordpress.com/b.gif?host=aone.wordpress.com&amp;blog=72720&amp;post=322&amp;subd=aone&amp;ref=&amp;feed=1" width="1" height="1" />]]></description>
		<wfw:commentRss>http://aone.wordpress.com/2011/07/14/%e7%b6%b2%e7%ab%99%e6%95%88%e8%83%bd%e5%88%86%e6%9e%90%e6%93%8d%e4%bd%9c%e5%bf%83%e6%b3%95-%e7%ac%ac9%e5%9b%9e-%e5%be%9e%e8%b3%87%e6%96%99%e5%ba%ab%e4%be%86%e8%aa%bf%e6%a0%a1%ef%bc%9a%e8%b3%87/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<georss:point>25.042317 121.565211</georss:point>
		<geo:lat>25.042317</geo:lat>
		<geo:long>121.565211</geo:long>
		<media:content url="http://1.gravatar.com/avatar/3e2f85d189946bf4854adbbb04ff0f98?s=96&#38;d=wavatar&#38;r=G" medium="image">
			<media:title type="html">aone</media:title>
		</media:content>

		<media:content url="http://blog.ithome.com.tw/js/tinymce/themes/advanced/images/spacer.gif" medium="image">
			<media:title type="html">More...</media:title>
		</media:content>
	</item>
		<item>
		<title>網站效能分析操作心法 第8回 &#8211; 從資料庫來調校：資料規畫設計篇</title>
		<link>http://aone.wordpress.com/2011/07/14/%e7%b6%b2%e7%ab%99%e6%95%88%e8%83%bd%e5%88%86%e6%9e%90%e6%93%8d%e4%bd%9c%e5%bf%83%e6%b3%95-%e7%ac%ac8%e5%9b%9e-%e5%be%9e%e8%b3%87%e6%96%99%e5%ba%ab%e4%be%86%e8%aa%bf%e6%a0%a1%ef%bc%9a%e8%b3%87/</link>
		<comments>http://aone.wordpress.com/2011/07/14/%e7%b6%b2%e7%ab%99%e6%95%88%e8%83%bd%e5%88%86%e6%9e%90%e6%93%8d%e4%bd%9c%e5%bf%83%e6%b3%95-%e7%ac%ac8%e5%9b%9e-%e5%be%9e%e8%b3%87%e6%96%99%e5%ba%ab%e4%be%86%e8%aa%bf%e6%a0%a1%ef%bc%9a%e8%b3%87/#comments</comments>
		<pubDate>Thu, 14 Jul 2011 15:21:57 +0000</pubDate>
		<dc:creator>Eric Chen</dc:creator>
				<category><![CDATA[專欄文章]]></category>

		<guid isPermaLink="false">http://aone.wordpress.com/?p=320</guid>
		<description><![CDATA[網站效能分析操作心法 第8回  資料庫常是網站系統的最後防線，也容易成為所有效能問題的根源點。在設計初期，若能避開造成常犯錯誤，未來改版就能省下可觀成本  現今網站不跟資料庫扯上關係的實在少之又少，而資料庫本身的管理及設計也是常造成效能瓶頸的主因，相關主題實在太多，此篇幅不足涵蓋全數，本篇將針對資料庫設計時在實務面上較常遇到的議題進行探討。 正規化與反正規化設計 就資料庫設計而言，資料正規化在教科書中亦視為重要課題，不外乎在強調資料重複性及一致性的維護；相對地，當正規化得愈徹底，未來資料查詢時需要進行join的頻率就會很高。但就實務而言，過度的正規化反倒是造成效能瓶頸的主因，尤其當個別資料表格內含龐大資料量時，多項資料表格進行join時，所付出的系統資源成本是相當可觀的。 資料正規化固然能解決資料面重複不一致的問題，以達到有效規畫及善用儲存空間的基本精神，但就資料存取的效能考量而言，有時適度的重複資料，反倒能減少因為頻繁join所需付出的系統成本。而重複資料可以透過其他機制來控制，或是由定期的資料維護檢核機制來處理，以磁碟空間換取時間。所以「反正規化」的做法是可接受的，尤其是在系統效能要求較高的環境下。 反正規化的想法也可以結合到非資料庫的儲存媒介，因為不見得網頁上所要呈現的所有內容都必須儲存在資料庫中，適時將部分的資料內容以檔案的方式來配置存放，亦對執行效能有加分效果。尤其是針對內容長度較大的資料，像是購物網站的商品說明內容，就可以透過此種方式設計實作。 資料庫與檔案的設計決策 若你所負責的網站系統是對Internet上的所有使用者提供服務，它的特性在於你永遠無法精準預估可能發生的流量有多大。若將所有網站上所需的資料都以資料庫的方式存取，流量低時不會有什麼問題，而流量高時就有明顯差異了。 就儲存媒介的資料存取效能而言，記憶體優於檔案，檔案勝於資料庫。這些儲存媒介的單位成本與使用時機也都不同，所以若你所規畫的網站系統是對外服務，在同一時間所造訪的人數是無法預估的，而偶爾會有尖峰時段。你可以觀察一些知名高流量的網站，會發現站上大多數的頁面會以靜態頁的方式來處理，也是想解決尖峰流量發生時不會因為系統資源的過度耗用而造成網站效能不佳。 透過以下幾點使用原則來評估，可以協助你資料設計時，去評估使用哪一種儲存媒介較佳： 1. 資料內容被前端使用的方式，是唯讀或是會被異動。若資料內容主要是做為網頁唯讀呈現（像是新聞內容、部落格網站、企業門戶網站等），僅允許由管理後臺進行資料更新，我建議這些內容可以利用檔案的方式來儲存。 2. 資料被異動的來源及頻率。異動的頻率也可視為決定儲存方式的考量點，像是企業網站的服務內容及產品訊息，異動頻率不高，就可以透過簡單的檔案方式來做為主要儲存方式；然而異動資料的來源單純，而非開放式供所有使用者可異動，則可以透過資料流程的設計來控制異動點。 3. 資料未來被管理及操作的方式。所有資料都放在資料庫，主要是方便未來進行資料分析所使用，但實務上的規畫並不會對線上資料庫進行較複雜的報表產出或資料分析，一般都是採用資料庫複寫機制（Replication）抄寫到別的資料庫中，或是將部分資料轉入到另外的系統進行後置報表產生作業，這麼做，主要在於避免線上直接查詢所造成的效能影響。 舉個實例，就內容網站而言，管理者可以透過後臺的管理介面，定義整個網站的內容分類架構，這些資料內容可以儲存到資料庫中，但前臺的網頁呈現，我建議另外產生檔案方式來提供瀏覽網頁的呈現，而不由前臺的網頁程式直接存取資料庫。 另外像是許多網站提供的個人化網頁內容，其內容呈現需要透過資料庫的運算統計得出的數字（像是未讀取的訊息數、未支付的訂單數、累積紅利點數等），在設計上應避免直接即時查詢資料庫運算得出。我建議以檔案儲存這些運算好的結果，來供前臺的快速呈現，而這些檔案內容被異動的時間點，則可以考慮定期批次整體更新，或是當資料庫異動時一併更新的方式，來達到資料異動。 資料表索引建立原則 索引的建立，不外乎是為了加速資料查詢以及排序時處理的效率，而原則主要依據查詢命令所要求的條件，將需要的查詢或排序欄位列入建立索引欄位的關鍵值。而建立為索引的欄位，必須配合前端程式存取資料的行為來建立，才能適時發揮效用。 若資料表本身會發生大量INSERT作業，則過多索引的建立反倒造成較高的效能成本，而且相關資料表必須定期維護，所以要評估資料表存取的方式來建立適當的索引，才不致於造成反效果。而資料表的Join關聯欄位，也是建立索引的重要對象，尤其是被join的資料表含有較大量的資料時，對明顯提升join時比對運算的效能有利。 資料空間的有效管理 資料表在經過長時間不斷插入及刪除動作後，像是購物網站的購物車內容，對該資料表的索引結構與實體磁碟結構的排列及對應位置，會造成不一致的狀況，甚至會有部分空間未能有效運用的狀況，占用較實際資料量為高的磁碟空間，造成索引存取效能低落的現象。 若資料表的資料異動頻率甚高，資料量亦居高不下（一般而言，是同一個資料表超過十萬筆以上的資料量），索引結構的重整，便是系統日常維運時所需重視的定期維護作業。可以透過資料庫系統提供的重建索引命令（rebuild index），或是透過索引移除、再重新建立的方式進行，亦可達到重整索引的效果。 而資料表本身的空間亦會因而無法有效運用，造成空間碎塊（Defragment）。利用資料庫本身的空間壓縮（Shrink）機制，可有效整理出未使用空間以提高空間使用率，而這個動作已成為資料庫備份之前的必要程序，甚至在建立資料庫時就設定成自動壓縮，以保持資料庫的壓縮比在一定的使用水平。 資料量分散移轉作業 網站系統運作一段時間之後，部分功能可能會因為資料量的成長而發生效能上的問題，針對資料量較大的資料表，可以考慮將存取頻率較低的部分，分散到另外的資料表，以有效保持原本資料表的資料存取效能。像是購物網站前臺，若提供會員查詢近半年的訂單資料，所以在訂單主檔的資料表便只保留時間範圍內的資料，其他可移至其他資料表。 不過這是土法煉鋼法，必須自行額外觀察資料的成長量，定出合適的時間範圍區段。若你的資料庫系統支援區段資料表（partitioning table）的機制，這部分的作業就單純許多，僅需要設置該資料表即可，未來該資料表便會依設置進行實體檔案空間的分散配置，以利一定品質的存取效能。就虛擬而言，上述做法仍然是針對同一個資料表進行操作，而實體資料檔案則會依設定時的定義進行切割。好處則是應用程式不需要針對不同的資料表進行存取。 分類:專欄文章<img alt="" border="0" src="http://stats.wordpress.com/b.gif?host=aone.wordpress.com&amp;blog=72720&amp;post=320&amp;subd=aone&amp;ref=&amp;feed=1" width="1" height="1" />]]></description>
		<wfw:commentRss>http://aone.wordpress.com/2011/07/14/%e7%b6%b2%e7%ab%99%e6%95%88%e8%83%bd%e5%88%86%e6%9e%90%e6%93%8d%e4%bd%9c%e5%bf%83%e6%b3%95-%e7%ac%ac8%e5%9b%9e-%e5%be%9e%e8%b3%87%e6%96%99%e5%ba%ab%e4%be%86%e8%aa%bf%e6%a0%a1%ef%bc%9a%e8%b3%87/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<georss:point>25.042317 121.565211</georss:point>
		<geo:lat>25.042317</geo:lat>
		<geo:long>121.565211</geo:long>
		<media:content url="http://1.gravatar.com/avatar/3e2f85d189946bf4854adbbb04ff0f98?s=96&#38;d=wavatar&#38;r=G" medium="image">
			<media:title type="html">aone</media:title>
		</media:content>

		<media:content url="http://blog.ithome.com.tw/js/tinymce/themes/advanced/images/spacer.gif" medium="image">
			<media:title type="html">More...</media:title>
		</media:content>
	</item>
	</channel>
</rss>
