<?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>Code 66</title>
	<atom:link href="http://www.code-66.com/blog/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.code-66.com/blog</link>
	<description>Noble Code</description>
	<lastBuildDate>Mon, 26 Sep 2011 02:36:03 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<div id='fb-root'></div>
					<script type='text/javascript'>
						window.fbAsyncInit = function()
						{
							FB.init({appId: null, status: true, cookie: true, xfbml: true});
						};
						(function()
						{
							var e = document.createElement('script'); e.async = true;
							e.src = document.location.protocol + '//connect.facebook.net/en_US/all.js';
							document.getElementById('fb-root').appendChild(e);
						}());
					</script>	
						<item>
		<title>Refactoring toward smaller methods</title>
		<link>http://www.code-66.com/blog/2011/09/refactoring-toward-smaller-methods/</link>
		<comments>http://www.code-66.com/blog/2011/09/refactoring-toward-smaller-methods/#comments</comments>
		<pubDate>Thu, 08 Sep 2011 08:39:30 +0000</pubDate>
		<dc:creator>roofimon</dc:creator>
				<category><![CDATA[Practice]]></category>
		<category><![CDATA[TDD]]></category>
		<category><![CDATA[Test Driven Development]]></category>

		<guid isPermaLink="false">http://www.code-66.com/blog/?p=288</guid>
		<description><![CDATA[ขนาดเป็นเรื่องสำคัญและเราทุกคนต่างมีความพอใจในขนาดที่ไม่เท่ากัน ใหญ่ของคนนี้อาจจะเล็กสำหรับคนนั้นแต่สำหรับหนังสือเล่มนี้ขอตั้งมาตรฐานไว้สำหรับความใหญ่คือ 10 นิ้วเอ้ย 10 บรรทัดสำหรับ method ถ้ามีอะไรที่ใหญ่กว่านี้ต้องถูกพิจรณาแล้วว่าใหญ่ผิดปกติ เราต้องทำอะไรกับมันสักอย่างไม่ว่าจะเป็นการตรวจสอบดูว่ามันทำงานมากเกินจำเป็นหรือป่าว มีตัวแปรที่เขียนมั่วๆแล้วไม่ได้ใช้หรือป่าว และสำหรับการลดขนาดของ evaluate นั้นสิ่งแรกที่เราจะทำคือการแยกการตรวจหา missingValue ไปเป็น method อันใหม่ Listing 2.16 Extracting the check for missing variables into a method ดูดีขึ้นมาหน่อย แต่ยังไม่ดีพอ evaluate ยังขาดในเรื่องของ balance ไปแต่ก่อนจะไปไกลกว่านี้เราควรรู้จักคำว่า balance กันก่อนว่ามันคืออะไร Keeping methods in balance คุณสมบัติที่สำคัญอีกอย่างหนึ่งของ method คือมันต้องอ่านได้ง่ายและต้องมีความชัดเจนในตัวเองว่ามันทำอะไรดังนั้นเราลองกลับไปดู evaluate กันอีกครั้งว่ายังเหลืออะไรที่ต้องแก้ไขบ้าง เราจะเห็นว่า evaluate ทำงานสองอย่างคือเปลี่ยนค่าของตัวแปลและตรวจสอบความถูกต้องของข้อมูล ซึ่งเราจะเห็นว่ามันเป็นการทำงานในระดับที่แตกต่างกัน ดังนั้นสิ่งที่เราต้องทำคือสร้างเมธอดใหม่เพื่อใช้เป้นการปรับระดับการทำงานให้เท่ากันเวลาอ่านจะได้ไม่รู้สึกกระโดดผลที่ออกมาคือโค้ดด้านล่าง หลักจากปรับโค้ดแล้วเรา run test ทันใดเราจะพบว่าไม่มีข้อผิดพลาดใดๆ ลองนึกภาพดูว่าถ้าเราไม่มี [...]]]></description>
		<wfw:commentRss>http://www.code-66.com/blog/2011/09/refactoring-toward-smaller-methods/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Adding a bit of error handling</title>
		<link>http://www.code-66.com/blog/2011/09/adding-a-bit-of-error-handling/</link>
		<comments>http://www.code-66.com/blog/2011/09/adding-a-bit-of-error-handling/#comments</comments>
		<pubDate>Tue, 06 Sep 2011 04:31:25 +0000</pubDate>
		<dc:creator>roofimon</dc:creator>
				<category><![CDATA[Practice]]></category>
		<category><![CDATA[TDD]]></category>

		<guid isPermaLink="false">http://www.code-66.com/blog/?p=275</guid>
		<description><![CDATA[และเป็นอีกครั้งที่เราต้องเพิ่ม test ใหม่เข้าไปในระบบของเราและสิ่งสุดท้ายที่เราจะทำคือการจัดการแจ้ง error เมื่อเราพยายาม evaluate template ด้วยการส้งตัวแปรที่ไม่มีค่าเข้าไปดังนั้นอย่ารอช้าเรามาดูกันว่าเราจะจัดการกับ error เหล่านั้นได้อย่างไร Expecting an exception คำถามคือเราจะเขียน Unit Test ที่ให้สำหรับตรวจสอบว่า exception ที่เราคาดหวังถูก throw ออกมาจากโค้ดบล๊อก try &#8211; catch ที่เราเขียนไว้ ตัวอย่างของโค้ดในส่วน 2.14 คือรูปแบบพื้นฐานที่เราใช้สำหรับการทดสอบ exception-throwing ใน JUnit สิ่งที่เรานิยมทำกันคือการใส่ fail เมธอดลงไปหลังจากการพยายามเรียก evaluate() ที่จะทำให้เกิด exception โดยการใส่ fail ไว้ด้านหลังแบบนี้แปลว่า &#8220;ถ้าไอ้โค้ด new Template(&#8220;${foo}&#8221;).evaluate(); สามารถทำงานผ่านฉลุยข้ามไปอีกบรรทัดได้แสดงว่ามีบางอย่างผิดปกติไปจากที่มันควรจะเป็นแล้วพี่น้อง&#8221; และส่วนต่อไปที่เราจะใส่ครอบไว้เพื่อจับการทำงานคือการ catch exception ที่เราคาดว่าจะเกิดจากการเรียก evaluate แบบผิดๆนี้ ส่วน error อื่นๆที่ไม่เกี่ยวข้องเราจะไม่สนใจมัน เพราะถ้ามี error [...]]]></description>
		<wfw:commentRss>http://www.code-66.com/blog/2011/09/adding-a-bit-of-error-handling/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Test Driven Development Workshop No. 1</title>
		<link>http://www.code-66.com/blog/2011/06/td-workshop-no-1/</link>
		<comments>http://www.code-66.com/blog/2011/06/td-workshop-no-1/#comments</comments>
		<pubDate>Thu, 30 Jun 2011 10:03:01 +0000</pubDate>
		<dc:creator>roofimon</dc:creator>
				<category><![CDATA[Workshop]]></category>
		<category><![CDATA[Agile]]></category>
		<category><![CDATA[TDD]]></category>
		<category><![CDATA[XP]]></category>

		<guid isPermaLink="false">http://www.code-66.com/blog/?p=255</guid>
		<description><![CDATA[เรื่องของเรื่องเริ่มจากเราได้มีการพูดคุยเรื่อง TDD ในที่สาธารณะกันมาเป็นปีๆว่าดีอย่างนั้นดีอย่างนี้แต่ &#8220;จะเริ่มยังไง ทำได้จริงหรือ?&#8221; คำถามเหล่านี้ตามมามากมายและเนื่องด้วยเหตุผลมากมายทำให้ยังไม่สามารถทำ TDD Workshop ได้สักที จนกระทั่งเรื่องมาเกิดจริงๆหลังที่ผมได้รับโอกาสให้ไปร่วมบรรยายที่ Software Park ในหัวข้อเรื่อง &#8220;เขียนโค้ดอย่างไร ให้สำเร็จ&#8221; ที่จัดโดยชมรม Thailand SPIN ซึ่งก็เป็นอีกครั้งที่ผมไปในฐานะคนที่บูชาลัทธิ TDD และนี่เองก็เป็นเวลาที่ผมได้พบกับ &#8220;คุณ Karan Sivarat&#8221; และหลังจากจบสัมมนาเราก็ยังคงพูดคุยกันเรื่องแนวคิดการทำ TDD แต่เนื่อด้วยเวลามรจำกัดผมก็เลยชวนไปงาน Bug Dat 2011 และคุณ Karan ก็มาจริงๆแล้วก็คงโดนมนต์สะกดแห่ง TDD เข้าไป หลังจากนั้นอีกไม่นานก็ได้รับเทียบเชิญจากคุณ Karan มาว่าสนใจจะเชิญขบวนการมนุษย์ไฟฟ้าห้าสีไปเสวนาเรือง TDD ที่บริษัท GoSoft หนึ่งครั้ง เมื่อได้รับเทียบเชิญมาเราเหล่ามนุษย์ไฟฟ้ามีหรือที่จะบอกว่า &#8220;ไม่&#8221; มีแต่อยากจะไปเลยซะเดี๋ยวนั้นแต่เนื่องจากเป็น Session ที่เป็นทางการมากเราเหล่ามนุษย์ไฟฟ้าจึงต้องเตรียมกันไปเยอะเพื่อการจัดหนักโดยรายการของที่เตรียมไปมีดังนี้ เพื่อให้เห็นภาพในองค์รวมถึงประโยชน์ของ TDD เราต้องเข้าใจแอจไจล์ก่อนแบบกว้างๆ จากนั้นก็มาเข้าใจ eXtreme Programming ที่ถือว่าเป็น Method [...]]]></description>
		<wfw:commentRss>http://www.code-66.com/blog/2011/06/td-workshop-no-1/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Let’s not forget to refactor</title>
		<link>http://www.code-66.com/blog/2011/06/let%e2%80%99s-not-forget-to-refactor/</link>
		<comments>http://www.code-66.com/blog/2011/06/let%e2%80%99s-not-forget-to-refactor/#comments</comments>
		<pubDate>Mon, 13 Jun 2011 06:04:03 +0000</pubDate>
		<dc:creator>roofimon</dc:creator>
				<category><![CDATA[Clean Code]]></category>
		<category><![CDATA[TDD]]></category>
		<category><![CDATA[Test Driven Development]]></category>

		<guid isPermaLink="false">http://www.code-66.com/blog/?p=239</guid>
		<description><![CDATA[ที่ผ่านมาเราเขียนโค้ดไปเพียบๆแต่ยังไม่ได้ refactor เลยเพราะอะไรก็เพราะโค้ดเราเมพส์ขนาดหาที่ปรับปรุง ไม่ได้ อาจจะเป็นอย่างนั้นหรืออาจเป็นเพราะไอ้ที่เราโค้ดไปนั้นมันง่ายจัดไม่มีอะไรซับซ้อน แต่ก่อนที่เราจะทำ อะไรไปมากกว่านี้เราควรหันกลับมาดู test code ของเราก่อนมันแปลกๆอยู่หลายจุด เรามาดูกันเลยว่าตรง ไหนที่น่าจะโดนเปลี่ยนบ้าง โค้ดด้านล่างคือ test ที่เราเพิ่งเขียนเสร็จกันไป Listing 2.12 Our test code up to this point—can you spot anything to refactor? ลองตั้งสติกันดูสิว่ามีอะไรต้องแก้ไขไหมเช่นมี Duplication. Semantic redundancy. หรืออะไรก็ ตามที่น่าจะโดนรือ จดไว้เดี๋ยวเรามาดูกันว่าเราคิดตรงกันไหม Potential refactorings in test code หลังจากนั่งทางในอยู่สักพักเราจะพบจุดที่ต้องแก้สองสามจุด เริ่มจาก Template คลาสที่เรา test มันอยู่เรา ควรจะแยกมันออกมาเป็น instance variable แทนที่เราจะประกาศมันร่ำไป ตัวที่สองที่จะต้องถูกแก้คือ evaluate mothod ที่ถูกเราเรียกจิกใช้งานเยี่ยงทาสเพื่อส่งเข้าไป [...]]]></description>
		<wfw:commentRss>http://www.code-66.com/blog/2011/06/let%e2%80%99s-not-forget-to-refactor/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Breadth-first หรือ depth-first</title>
		<link>http://www.code-66.com/blog/2011/06/breadth-first-or-depth-first/</link>
		<comments>http://www.code-66.com/blog/2011/06/breadth-first-or-depth-first/#comments</comments>
		<pubDate>Sat, 04 Jun 2011 08:42:19 +0000</pubDate>
		<dc:creator>roofimon</dc:creator>
				<category><![CDATA[Clean Code]]></category>
		<category><![CDATA[Practice]]></category>
		<category><![CDATA[TDD]]></category>

		<guid isPermaLink="false">http://www.code-66.com/blog/?p=228</guid>
		<description><![CDATA[ส่วนต่อไปที่เราจะทำคือเราจะหากระบวนท่าในการจัดการปัญหาที่เราเผชิญหน้าอยู่ ดังนั้นเราควรจะย้อนวันเวลากลับไป สมัยเป็นเกรียนมหาลัย ตอนที่เรานั่งหลับในวิชา Data Structure ถ้ายังจำได้เราจะพบว่าการ transverse tree สามารถทำได้มากกว่า 1 วิธีคือ breadth-first และ depth-first วิธีการนี้ใช้ได้กับ TDD เช่นกันตามรูป 2.3 และ 2.4 คือ ถ้าเราตัดสินใจแก้ปัญหาด้วยกระบวนท่า breadth-first ผลคือเราจะเขียน test เพื่อทดสอบการทำงานของ interface ของคลาส Template โดยเราจะ fake การทำงานข้างในมันทั้งหมดและหลัจากนั้นเราจะค่อยๆเขียน test เพื่อทดสอบการ ทำงานของ function ข้างในทีละตัวไปตามภาพ 2.3 มองจากซ้ายไปขวา ภาพ 2.3 ภาพ 2.4 ในทางกลับกันถ้าเราเลือกไปท่า depth-first เราจะ test-implement จากระดับล่างมาก่อนดังนั้น เราจะต้องเขียนรายละเอียด ของ template parsing logic ก่อนแล้วตามมาด้วยการเขียน [...]]]></description>
		<wfw:commentRss>http://www.code-66.com/blog/2011/06/breadth-first-or-depth-first/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>เลือก test แรก</title>
		<link>http://www.code-66.com/blog/2011/04/choose-first-test/</link>
		<comments>http://www.code-66.com/blog/2011/04/choose-first-test/#comments</comments>
		<pubDate>Tue, 12 Apr 2011 03:50:17 +0000</pubDate>
		<dc:creator>roofimon</dc:creator>
				<category><![CDATA[Clean Code]]></category>
		<category><![CDATA[Practice]]></category>
		<category><![CDATA[TDD]]></category>
		<category><![CDATA[Test Driven Development]]></category>

		<guid isPermaLink="false">http://www.code-66.com/blog/?p=217</guid>
		<description><![CDATA[เกริ่น นำรำวงมานานหลายตอนมาถึงตอนนี้เป็นตอนที่จะได้เห็นโค้ดจริงๆสักที โดยอ้างถึงตอนที่แล้วเราตั้งใจกันว่าจะเขียน สิ่งที่เรียกว่า template engine ดังนั้นเพื่อให้สอดคล้องกับแนวคิดเรื่อง TDD นั้นเราจะค่อยๆทำไปทีละนิดเราจะไม่ทำที เดียวหมด ดังนั้นสิ่งแรกที่เราจะทำคือการเน้นไปในเรื่องของ business logic ของตัว template emgine ก่อนโดยที่ให้ตัด ส่วนอื่นๆทิ้งไปก่อนแล้ว template engine คืออะไร “The template engine we’re talking about needs to be capable of reading in a template,which is basically static text with an arbitrary number of variable placeholders mixed in. The variables are marked up using [...]]]></description>
		<wfw:commentRss>http://www.code-66.com/blog/2011/04/choose-first-test/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>เริ่มต้นกับ Test Driven Development</title>
		<link>http://www.code-66.com/blog/2011/03/beginning_tdd/</link>
		<comments>http://www.code-66.com/blog/2011/03/beginning_tdd/#comments</comments>
		<pubDate>Wed, 30 Mar 2011 08:31:50 +0000</pubDate>
		<dc:creator>roofimon</dc:creator>
				<category><![CDATA[Clean Code]]></category>
		<category><![CDATA[Practice]]></category>
		<category><![CDATA[TDD]]></category>
		<category><![CDATA[Test Driven Development]]></category>

		<guid isPermaLink="false">http://www.code-66.com/blog/?p=211</guid>
		<description><![CDATA[ใคร เคยหลงทางในสนามบินบ้าง? คำตอบคือน่าจะยากมากเพราะอะไรเพราะในสนามบินเราจะพบกับการใช้ป้ายสัญลักษณ์ มากมาย ทุกครั้งที่เราเริ่มงงว่าจะเดินไปทางไหนเราจะเริ่มมองหาป้ายที่บอกทางไป Gate ของเราก่อนเลยเช่น “Gate 42: continue straight forward.” ตัวอย่างนี้สามารถเอามาประยุกต์ใช้กับการพัฒนาซอฟท์แวร์ในชีวิตประจำวันได้ เช่นกันลอง หลับตาคิดดูว่าถ้าเราอยู่ที่สนามบิน Heatthrow เราก้าวผ่านด่านตรวจคนแล้วพบป้ายใหญ่ๆที่เขียนว่า “โชคดี” แล้วก็ไม่เห็น ป้ายอะไรอีกเลยเราจะเดินไปทางไหน? หลงแน่นอน !!! ดังนั้นป้ายบอกทางเป็นสิ่งจำเป็นในสนามบินเช่นเดียวกันในโลกของการทำซอฟท์ แวร์เราพบว่าการทำ Test Driven Development ที่มีข้อ ปฏิบัติที่เรียบง่ายสามข้อนั้นเป็นเหมือนกับป้ายบอกทางหลายร้อยป้ายที่มี อยู่ที่สนามบินที่ช่วยนำเรา ไปในทิศทางที่ถูกต้องและสามารถไปถึงจุดหมาย ได้ตรงเวลาและอย่างที่เราได้อ่านกันมาหลายรอบแล้วว่าการทำ TDD คือการกลับการบวนการทำงานจาก design-code-test ที่ไม่สนุกเสียใหม่ให้เป็น test-code-refactor อันแสนสนุกแทนและ ใครจะเชื่อว่าไอ้กระบวนการอันแสนธรรมดาสามข้อนี้จะช่วยให้เราสร้างซอฟท์แวร์ ที่มีคุณภาพสูงออกมาได้อย่างที่เรา ไม่เคยทำได้มาก่อน นอกจากคุณภาพจะดีแล้วเรายังได้ระบบทีีถูกปรับเข้าหา requirement ตลอดเวลาทำให้ไม่หลงหรือพลาดไปจากสิ่งที่ลูกค้าต้องการ ค่าใช้จ่ายในการซ่อม defect ก็ต่ำกว่าเพราะมีกระบวนการตรวจสอบความถูกต้องที่ดีกว่า (automate test suite) นอกจากนี้มันยังช่วยให้เรามี productivity ที่สูงขึ้นอีกด้วยและเหนือสิ่งอื่นในการทำงานจะเต็มไปด้วยความมันส์ ใน บทนี้เราจะได้เรียนรู้ต่อไปอีกว่าอะไรคือ [...]]]></description>
		<wfw:commentRss>http://www.code-66.com/blog/2011/03/beginning_tdd/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>เวิร์คแน่นอน(Making sure the software still works)</title>
		<link>http://www.code-66.com/blog/2011/03/making_sure_still_works/</link>
		<comments>http://www.code-66.com/blog/2011/03/making_sure_still_works/#comments</comments>
		<pubDate>Fri, 18 Mar 2011 09:12:51 +0000</pubDate>
		<dc:creator>roofimon</dc:creator>
				<category><![CDATA[Clean Code]]></category>
		<category><![CDATA[Practice]]></category>
		<category><![CDATA[TDD]]></category>
		<category><![CDATA[Test Driven Development]]></category>

		<guid isPermaLink="false">http://www.code-66.com/blog/?p=200</guid>
		<description><![CDATA[จาก แนวคิดของ TDD ที่มุ่งเน้นว่าเราต้องสามารถสร้างซอฟท์แวร์ที่ทำงานได้จริงตั้งแต่วันแรกของ การทำงาน ไอ้ตอนคิดน่ะ ง่ายแต่ทำน่ะยากไม่ใช่เล่นเพราะเราจะเห็นว่าเราต้องแก้ไข design ตลอดเวลาทุกวัน มันมีคำถามว่าของที่เราใส่เข้าไปใหม่ นั้นไม่ไปป่วนโค้ดเดิมและนี่คือความน่ากลัวของการขยับโค้ด แบบที่ไม่มีกรอบหรือตัววัดที่ชัดเจนแต่เราไม่ได้ทำแบบนั้น เราทำ TDD เรามีเครื่องมือที่สามารถตรวจสอบความถูกต้องได้ทำให้เรามั่นใจได้ว่างานของ เรายังถูกต้องอยู่เสมอ การ ทำงานแบบนี้อาจจะดูขัดแย้งกับชาวบ้านตรงที่ คนทั่วไปอาจคิดว่า test ไม่น่าจะมาเป็นภาระขัดขวางการทำงานขนาดนี้ แต่อย่างไรก็ตามเราพบว่าการทำ test แบบ manual นั้นเป็นเรื่องที่หลอนมากและทำได้ช้ามากและเราพบเสมอว่าถ้าเรา ปล่อยให้ developer รับหน้าที่ test เราจะพบกับการ test แบบพิศดารคือมันจะ test เฉพาะสิ่งที่มันแน่ใจว่าผ่านแต่อะไรที่ test ยุ่งยากๆมันจะข้ามไปทำเป็นไม่เห็นดังนั้นถ้าเราคิดและทำแบบเดิดเราก็จะพบ ปัญหาเดิมๆ ดังนั้นเราจะเปลี่ยนใหม่ เปลี่ยนให้การ test เป็นแบบ automate ที่สุดเพราะต้องการแก้ปัญหาแบบเก่าๆเดิมๆ หลาย คนคงชินและคุ้นเคยกับการทำ regression มันเป็นเรื่องที่เกิดขึ้นเสมอในการพัฒนาซอฟท์แวร์เช่นถ้าเราเพิ่ม feature ใหม่เข้าไปแล้วระบบพัง นั่นหมายความว่าระบบเราถอยหลังจากสถานะที่ทำงานได้ดีกลับไปหาสถานะที่ไม่ สามารถทำงาน ได้เหมือนภาพประกอบที่ 1.11 การเกิด [...]]]></description>
		<wfw:commentRss>http://www.code-66.com/blog/2011/03/making_sure_still_works/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>เขยิบทีละนิด (Evolutionary Design)</title>
		<link>http://www.code-66.com/blog/2011/02/evolutionary-design/</link>
		<comments>http://www.code-66.com/blog/2011/02/evolutionary-design/#comments</comments>
		<pubDate>Mon, 28 Feb 2011 03:31:05 +0000</pubDate>
		<dc:creator>roofimon</dc:creator>
				<category><![CDATA[Practice]]></category>
		<category><![CDATA[TDD]]></category>
		<category><![CDATA[Test Driven Development]]></category>

		<guid isPermaLink="false">http://www.code-66.com/blog/?p=181</guid>
		<description><![CDATA[เนื้อหาแปลมาจาก Test Driven PRACTICAL TDD AND ACCEPTANCE TDD FOR JAVA DEVELOPERS จากบทความที่แล้วเราได้เห็นจังหวะของการทำ TDD มาบทนี้เราจะมาดูเรื่อง Evolutionary Design กัน มาจะกล่าวบทไปถึงแอจไจล์เสียเล็กน้อยว่าหนึ่งในแนวคิดหลักของแอจไจล์คือทีมต้องพยายามทำให้งานที่เราทำอยู่ในสภาพ ที่เรียกว่า deployable ได้เร็วที่สุด(ซึ่งมันจะสะท้อนไปสู่การทำงานของปัจเจกคือการทำงานควรจะเขยิบ ทีละนิด) และทีมจะต้องทำให้สภาพ deployable นั้นคงอยู่ตลอดจนจบโปรเจคหรือแบบเข้าใจง่ายคือถ้าเช้ามาเราทำงานอยู่สบายๆ อยู่ๆเจ้านายโทรมาว่าลูกค้าอยากดูเดโมเราต้องสามารถดึงโค้ดของเมื่อวานที่ stable แล้วออกมา build และ deploy ได้เลยอย่างรวดเร็วและด้วยแนวคิดนี้จำทำให้เรามั่นใจว่าเรามีงานที่พร้อมส่ง และทำงานได้จริงเสมอ(อย่างหล่อส์) โดยที่ของที่เรามีมันอาจจะไม่ครบถ้วนทุกฟีเจอร์ที่ลูกค้าต้องการแต่อย่าง น้อยก็มีอะไรที่ทำงานได้จริงๆนะ ภาพ 1.6 การเขยิบทีละนิด—แบ่งการทำงานออกเป็นขั้นเล็กๆ จะทำให้ช่องว่างระหว่างเรากับ code base ที่ทำงานได้จริงมีน้อย เราจะ integrate งานเรากลับเข้าไปได้ง่ายเป็นการลดความเสี่ยง เพราะงานที่ไม่เสร็จจะมีน้อย นอกจากนี้การ เขยิบทีละนิด ยังช่วยให้เรารับ feedback กลับจากลูกค้าได้ดีและมีประสิทธิภาพเพราะทั้งโปรแกรมเมอร์และลูกค้าจะได้ เห็นซอฟท์แวร์ ที่ทำงานได้จริง อย่าง ที่เราเห็นมาในอดีตว่าโปรเจคการพัฒนาซอฟท์แวร์มักจะเลื่อนวันจบโปรเจค [...]]]></description>
		<wfw:commentRss>http://www.code-66.com/blog/2011/02/evolutionary-design/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>จังหวะรัก test-code-refactor</title>
		<link>http://www.code-66.com/blog/2011/02/tese-driven-development-2-the-beat/</link>
		<comments>http://www.code-66.com/blog/2011/02/tese-driven-development-2-the-beat/#comments</comments>
		<pubDate>Wed, 23 Feb 2011 08:53:10 +0000</pubDate>
		<dc:creator>roofimon</dc:creator>
				<category><![CDATA[Practice]]></category>
		<category><![CDATA[TDD]]></category>
		<category><![CDATA[Test Driven Development]]></category>

		<guid isPermaLink="false">http://www.code-66.com/blog/?p=173</guid>
		<description><![CDATA[เนื้อหาแปลมาจาก Test Driven PRACTICAL TDD AND ACCEPTANCE TDD FOR JAVA DEVELOPERS จากบทความที่แล้วเราได้เห็นแล้วว่า TDD เป็นเทคนิคการเขียนโปรแกรม ย้ำเทคนิคการเขียนโปรแกรมที่ถูกสร้างขึ้นมาบน หลักการง่ายๆ จงเขียนโค้ดเพื่อ ซ่อม test ที่ fail เท่านั้น เขียน test ก่อนเสมอและหลังจากนั้นเราจะเขียน code เพื่อซ่อม test ซึ่งเป็นหลักการที่กลับด้านกับสิ่งที่เราเคยทำมา นั่นคือเราจะชินกับการ design จากนั้น implement design และสุดท้ายเรา test เพื่อหาบั๊กที่เราได้สร้างขึ้นในระหว่างที่เรา implement ตามภาพ 1.3 ภาพ 1.3 TDD กลับด้านการทำงานแบบเดิมๆทีีมีลำดับ design-code-test. โดยการทำงานจะกลับด้านเป็นtest-code-design ภาพ 1.4 Test-code-refactor เป็นมนตราของ test-driven developers มันอธิบายวิธีการทำงานได้ชัดเจนกว่าและดูเท่กว่า เขียน test [...]]]></description>
		<wfw:commentRss>http://www.code-66.com/blog/2011/02/tese-driven-development-2-the-beat/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
	</channel>
</rss>

