Posts Tagged by Test Driven Development
Refactoring toward smaller methods
| September 8, 2011 | Posted by roofimon under Practice |
ขนาดเป็นเรื่องสำคัญและเราทุกคนต่างมีความพอใจในขนาดที่ไม่เท่ากัน ใหญ่ของคนนี้อาจจะเล็กสำหรับคนนั้นแต่สำหรับหนังสือเล่มนี้ขอตั้งมาตรฐานไว้สำหรับความใหญ่คือ 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 ทันใดเราจะพบว่าไม่มีข้อผิดพลาดใดๆ ลองนึกภาพดูว่าถ้าเราไม่มี…
Let’s not forget to refactor
| June 13, 2011 | Posted by roofimon under Clean Code |
ที่ผ่านมาเราเขียนโค้ดไปเพียบๆแต่ยังไม่ได้ 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 ที่ถูกเราเรียกจิกใช้งานเยี่ยงทาสเพื่อส่งเข้าไป…
เลือก test แรก
| April 12, 2011 | Posted by roofimon under Clean Code, Practice |
เกริ่น นำรำวงมานานหลายตอนมาถึงตอนนี้เป็นตอนที่จะได้เห็นโค้ดจริงๆสักที โดยอ้างถึงตอนที่แล้วเราตั้งใจกันว่าจะเขียน สิ่งที่เรียกว่า 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…
เริ่มต้นกับ Test Driven Development
| March 30, 2011 | Posted by roofimon under Clean Code, Practice |
ใคร เคยหลงทางในสนามบินบ้าง? คำตอบคือน่าจะยากมากเพราะอะไรเพราะในสนามบินเราจะพบกับการใช้ป้ายสัญลักษณ์ มากมาย ทุกครั้งที่เราเริ่มงงว่าจะเดินไปทางไหนเราจะเริ่มมองหาป้ายที่บอกทางไป Gate ของเราก่อนเลยเช่น “Gate 42: continue straight forward.” ตัวอย่างนี้สามารถเอามาประยุกต์ใช้กับการพัฒนาซอฟท์แวร์ในชีวิตประจำวันได้ เช่นกันลอง หลับตาคิดดูว่าถ้าเราอยู่ที่สนามบิน Heatthrow เราก้าวผ่านด่านตรวจคนแล้วพบป้ายใหญ่ๆที่เขียนว่า “โชคดี” แล้วก็ไม่เห็น ป้ายอะไรอีกเลยเราจะเดินไปทางไหน? หลงแน่นอน !!! ดังนั้นป้ายบอกทางเป็นสิ่งจำเป็นในสนามบินเช่นเดียวกันในโลกของการทำซอฟท์ แวร์เราพบว่าการทำ Test Driven Development ที่มีข้อ ปฏิบัติที่เรียบง่ายสามข้อนั้นเป็นเหมือนกับป้ายบอกทางหลายร้อยป้ายที่มี อยู่ที่สนามบินที่ช่วยนำเรา ไปในทิศทางที่ถูกต้องและสามารถไปถึงจุดหมาย ได้ตรงเวลาและอย่างที่เราได้อ่านกันมาหลายรอบแล้วว่าการทำ TDD คือการกลับการบวนการทำงานจาก design-code-test ที่ไม่สนุกเสียใหม่ให้เป็น test-code-refactor อันแสนสนุกแทนและ ใครจะเชื่อว่าไอ้กระบวนการอันแสนธรรมดาสามข้อนี้จะช่วยให้เราสร้างซอฟท์แวร์ ที่มีคุณภาพสูงออกมาได้อย่างที่เรา ไม่เคยทำได้มาก่อน นอกจากคุณภาพจะดีแล้วเรายังได้ระบบทีีถูกปรับเข้าหา requirement ตลอดเวลาทำให้ไม่หลงหรือพลาดไปจากสิ่งที่ลูกค้าต้องการ ค่าใช้จ่ายในการซ่อม defect ก็ต่ำกว่าเพราะมีกระบวนการตรวจสอบความถูกต้องที่ดีกว่า (automate test suite) นอกจากนี้มันยังช่วยให้เรามี productivity ที่สูงขึ้นอีกด้วยและเหนือสิ่งอื่นในการทำงานจะเต็มไปด้วยความมันส์ ใน บทนี้เราจะได้เรียนรู้ต่อไปอีกว่าอะไรคือ…
เวิร์คแน่นอน(Making sure the software still works)
| March 18, 2011 | Posted by roofimon under Clean Code, Practice |
จาก แนวคิดของ TDD ที่มุ่งเน้นว่าเราต้องสามารถสร้างซอฟท์แวร์ที่ทำงานได้จริงตั้งแต่วันแรกของ การทำงาน ไอ้ตอนคิดน่ะ ง่ายแต่ทำน่ะยากไม่ใช่เล่นเพราะเราจะเห็นว่าเราต้องแก้ไข design ตลอดเวลาทุกวัน มันมีคำถามว่าของที่เราใส่เข้าไปใหม่ นั้นไม่ไปป่วนโค้ดเดิมและนี่คือความน่ากลัวของการขยับโค้ด แบบที่ไม่มีกรอบหรือตัววัดที่ชัดเจนแต่เราไม่ได้ทำแบบนั้น เราทำ TDD เรามีเครื่องมือที่สามารถตรวจสอบความถูกต้องได้ทำให้เรามั่นใจได้ว่างานของ เรายังถูกต้องอยู่เสมอ การ ทำงานแบบนี้อาจจะดูขัดแย้งกับชาวบ้านตรงที่ คนทั่วไปอาจคิดว่า test ไม่น่าจะมาเป็นภาระขัดขวางการทำงานขนาดนี้ แต่อย่างไรก็ตามเราพบว่าการทำ test แบบ manual นั้นเป็นเรื่องที่หลอนมากและทำได้ช้ามากและเราพบเสมอว่าถ้าเรา ปล่อยให้ developer รับหน้าที่ test เราจะพบกับการ test แบบพิศดารคือมันจะ test เฉพาะสิ่งที่มันแน่ใจว่าผ่านแต่อะไรที่ test ยุ่งยากๆมันจะข้ามไปทำเป็นไม่เห็นดังนั้นถ้าเราคิดและทำแบบเดิดเราก็จะพบ ปัญหาเดิมๆ ดังนั้นเราจะเปลี่ยนใหม่ เปลี่ยนให้การ test เป็นแบบ automate ที่สุดเพราะต้องการแก้ปัญหาแบบเก่าๆเดิมๆ หลาย คนคงชินและคุ้นเคยกับการทำ regression มันเป็นเรื่องที่เกิดขึ้นเสมอในการพัฒนาซอฟท์แวร์เช่นถ้าเราเพิ่ม feature ใหม่เข้าไปแล้วระบบพัง นั่นหมายความว่าระบบเราถอยหลังจากสถานะที่ทำงานได้ดีกลับไปหาสถานะที่ไม่ สามารถทำงาน ได้เหมือนภาพประกอบที่ 1.11 การเกิด…
เขยิบทีละนิด (Evolutionary Design)
| February 28, 2011 | Posted by roofimon under Practice |
เนื้อหาแปลมาจาก Test Driven PRACTICAL TDD AND ACCEPTANCE TDD FOR JAVA DEVELOPERS จากบทความที่แล้วเราได้เห็นจังหวะของการทำ TDD มาบทนี้เราจะมาดูเรื่อง Evolutionary Design กัน มาจะกล่าวบทไปถึงแอจไจล์เสียเล็กน้อยว่าหนึ่งในแนวคิดหลักของแอจไจล์คือทีมต้องพยายามทำให้งานที่เราทำอยู่ในสภาพ ที่เรียกว่า deployable ได้เร็วที่สุด(ซึ่งมันจะสะท้อนไปสู่การทำงานของปัจเจกคือการทำงานควรจะเขยิบ ทีละนิด) และทีมจะต้องทำให้สภาพ deployable นั้นคงอยู่ตลอดจนจบโปรเจคหรือแบบเข้าใจง่ายคือถ้าเช้ามาเราทำงานอยู่สบายๆ อยู่ๆเจ้านายโทรมาว่าลูกค้าอยากดูเดโมเราต้องสามารถดึงโค้ดของเมื่อวานที่ stable แล้วออกมา build และ deploy ได้เลยอย่างรวดเร็วและด้วยแนวคิดนี้จำทำให้เรามั่นใจว่าเรามีงานที่พร้อมส่ง และทำงานได้จริงเสมอ(อย่างหล่อส์) โดยที่ของที่เรามีมันอาจจะไม่ครบถ้วนทุกฟีเจอร์ที่ลูกค้าต้องการแต่อย่าง น้อยก็มีอะไรที่ทำงานได้จริงๆนะ
จังหวะรัก test-code-refactor
| February 23, 2011 | Posted by roofimon under Practice |
เนื้อหาแปลมาจาก 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…
Test Driven Development ตอนที่ 1
| February 20, 2011 | Posted by roofimon under Practice |
ที่มาของเนื้อหาเกือบทั้งหมดเอามาจาก TDD@Wikipedia เริ่มเรื่องก่อนผมมีความเชื่อส่วนตัวว่าซอฟท์แวร์จะมีคุณภาพดีในองค์รวมได้ก็ต่อเมื่อส่วนที่เล็กที่สุดของมันต้องถูกสร้างออกมาอย่างมีคุณภาพเท่านั้น ถ้าส่วนที่เล็กที่สุดถูกสร้างออกมาอย่างไม่ตั้งใจไร้ระเบียบมันจะส่งผลให้ภาพรวมของมันออกมาดูแย่มากไม่ว่าเราจะเอา technology บ้าบออะไรมาช่วยก็ตาม ผมเองก็ตั้งใจจะแปลเรื่องนี้มานานมากแต่ไม่รู้จะเอาไปลงที่ไหน ไม่แน่ใจว่าจะเหมาะกับ agile66 หรือป่าวด้วยแต่หลังจากได้เสวนากับ Hyper Productivity Seeker แล้วก็พบว่า TDD เป็นเรื่องของปัจเจก นั่นแปลว่าไม่ว่าเราจะถูกส่งไปทำงานกับทีมประเภทไหนก็ตามเราก็สามารถ ที่จะแอบทำ TDD ของเราคนเดียวได้เสมอคนอื่นจะทำอะไรก็ช่างเขาแต่เราจะ TDD นั่นคือจุดเริ่มต้นของความมั่นใจว่าเรื่องของการทำ Test Driven Development น่าจะมาอยู่ในเว็บ code-66 นี้ ก่อนที่จะไปไกลกว่านี้เรามาดูรูปกันก่อน
This is the default footer layout. You can easily add or remove columns in the footer.
Recent Comments