cc :: somkiat

Screen Shot 2559-02-05 at 5.22.49 PM

จาก VDO เรื่อง Test Driven Development(TDD) for iOS (and anything) ของคุณ Jon Reid ได้พูดถึงเรื่องการจัดการ dependency เพื่อทำให้ code ของเรานั้นมันไม่ผูกติดกันมากไป (Loose coupling) และสามารถทดสอบได้ง่าย จึงทำการสรุปไว้นิดหน่อย

สิ่งที่ developer ทุกคนควรทำความเข้าใจกับ TDD ก่อนเสมอ

ซึ่งมี resources ที่ต้องอ่าน คือ

มาถึงเนื้อหาที่น่าสนใจกันบ้าง

เริ่มจากอธิบายเกี่ยวกับ Unit test มี 3 ชนิด คือ

Return value test
State test
Interaction test

1. Return value test คืออะไร

อธิบายด้วย AAA (Arrange-Act-Assert) ได้ดังนี้

Arrange = ทำการกำหนดค่าเริ่มต้นต่าง ๆ ของ object
Act = ทำการเรียก method/function ที่ทำการ return ผลลัพธ์กลับมา
Assert = ทำการตรวจสอบผลการทำงาน กับ สิ่งที่คาดหวังว่าตรงกันหรือไม่

แสดงการทดสอบดังรูป Screen Shot 2559-02-05 at 4.46.14 PM

2. State test

อธิบายด้วย AAA (Arrange-Act-Assert) ได้ดังนี้

Arrange = ทำการกำหนดค่าเริ่มต้นต่าง ๆ ของ object
Act = ทำการเรียก method/function โดยไม่สนใจว่าจะส่งค่าอะไรกลับมา
Assert = ทำการดึงข้อมูล หรือ สถานะจาก object ที่ทำการทดสอบ ว่าทำงานตามที่ต้องการหรือไม่

แสดงการทดสอบดังรูป Screen Shot 2559-02-05 at 4.48.50 PM

3. Interaction test

เป็นการทดสอบสำหรับการทำงานร่วมกันของ object ต่าง ๆ ซึ่งเป็นชนิดการทดสอบที่ถูกใช้งานอย่างมาก และแน่นอนว่าเป็นเรื่องหลักของ VDO นี้ แสดงการทำงานดังรูป Screen Shot 2559-02-05 at 4.52.36 PM

จากรูปอาจดูไม่ค่อยเข้าใจเท่าไรนัก !! ดังนั้นจึงทำการอธิบายด้วยการทำงานของร้านอาหาร ซึ่งประกอบไปด้วย 3 ส่วน คือ

ลูกค้า
พนักงาน
พ่อครัว

ซึ่งในการสั่งอาหารของลูกค้านั้น จะสั่งอาหารกับพนักงาน โดยไม่ต้องสนใจว่า พ่อครัวเป็นใคร นั่นคือ พนักงานต้องไม่ผูกติดกับพ่อครัวนะ (Isolated dependency) แสดงดังรูป Screen Shot 2559-02-05 at 4.55.45 PM

แต่ในการทำงานพบว่า พนักงานต้องต้องทำงานร่วมกับพ่อครัวเสมอ (Interaction) เพื่อทำอาหารตาม order จากลูกค้า โดยในการทดสอบนั้น เราสามารถทำงานจำลองพ่อครัวขึ้นมา เพื่อทำงานตาม order ของลูกค้า แต่เพียงแค่การจำลองอย่างเดียว ไม่สามารถทำงานร่วมกันได้ เพราะว่าทั้งพนักงาน และ พ่อครัวนั้นแยกออกจากกัน ดังนั้น จึงต้องทำการ Injection Dependency หรือส่งพ่อครัวให้ไปทำงานร่วมกับพนักงาน แสดงดังรูป Screen Shot 2559-02-05 at 4.58.42 PM

วิธีการของ Dependency Injection มีหลายวิธี ดังนี้

Extract and Override method
Method injection
Property injection
Constructor injection
Ambient context

จากรูปจะเห็นว่า เราทำการจำลองพ่อครัวขึ้นมา คำถามที่เกิดขึ้นมาเลย คือ จำลองแบบไหน อย่างไร ? คำตอบคือ ใช้ Stub และ Mock ไงล่ะ !!

จากหนังสือ The Art of Unit Testing อธิบายเรื่องของ Stub และ Mock ไว้ดังรูป

ซึ่งผมคิดว่า มันเข้าใจได้ง่ายมาก ๆ ดังรูป Screen Shot 2559-02-05 at 5.05.51 PM

ยังไม่จบนะ ใน VDO ยังมี code ตัวอย่าง

สำหรับการทดสอบการทำงานกับ Network อีกด้วย รวมทั้งการ refactor code เพื่อให้ทดสอบง่าย และ อ่านได้ง่ายอีกด้วย ลองทำการอ่าน ฟัง ดู กันครับ มันมีประโยชน์อย่างมากมาย สามารถดู slide เพิ่มเติมได้ที่ PDF:: Slide ดู VDO กันได้เลย https://www.youtube.com/watch?v=Jzlz3Bx-NzM

Screen Shot 2559-02-06 at 10.01.54 AM

อ่านหนังสือ The 8th Habit: From Effectiveness to Greatness: Miniature Edition แล้วนึกขึ้นได้ว่า ถ้าอยากเป็น Developer ที่ดี ควรต้องฝึกฝน และ ปฏิบัติ อะไรบ้าง จนเกิดเป็นอุปนิสัยของตนเอง

Developer ที่ดีน่าจะ

เขียน code ที่มีคุณภาพสูง
พัฒนาระบบให้อยู่ภายในงบประมาณที่กำหนด
ทำให้ลูกค้ามีความสุข ด้วยการส่งมอบสิ่งที่ลูกค้าต้องการให้ดีที่สุด

แต่ว่า Developer จะต้องทำอย่างไรบ้างล่ะ ? เพราะว่า ในความเป็นจริงมันซับซ้อนมาก ดังนั้นจึงมีคำแนะ 8 อย่างให้ลองทำดูนะ

1. Testing, Testing และ Testing เท่านั้น

มันคือสิ่งที่สำคัญมาก ๆ สำหรับ Developer ทุกคน Code ที่เขียนขึ้นมานั้นต้องถูกทดสอบเสมอ เพื่อทำให้เราค้นพบความผิดพลาดได้รวดเร็วที่สุด และใช้ค่าใช้จ่ายในการแก้ไขถูกมาก ลองคิดดูสิว่า ถ้าไปเจอความผิดพลาดในช่วงท้ายของการพัฒนา มันจะนรกขนาดไหน และค่าใช้จ่ายในการแก้ไขจะสูงมาก !! แต่ถ้าพูดถึง Automated test ในการพัฒนา software แล้ว มันอาจจะเป็นสิ่งที่ไม่น่าสนใจ และ ถูกละเลยไป แต่มันมีประโยชน์มาก ๆ นะ มาทำกันเถอะ

2. Prototype และ Wireframe ต้องทำก่อนเขียน code เสมอ

ก่อนที่ Developer จะลงมือเขียน code ลงไปนั้น สิ่งแรกที่ควรทำก็คือ เข้าใจในสิ่งที่จะทำก่อน ต้องเข้าใจทั้ง Developer, ลูกค้า และผู้ที่เกี่ยวข้อง หนึ่งในวิธีการที่ดี คือ การวาดภาพ ซึ่งมักเรียกกันว่า Prototype และ Wireframe มันทำให้การพูดคุยชัดเจน และ เห็นภาพในสิ่งที่ทุกคนเข้าใจ ดังนั้นต้อง คิด คุย วาด ให้เข้าใจก่อนเริ่มลงมือเขียน code นะ

3. หัดใช้งาน Online community และ forum หรือ web board บ้าง

เป็นสิ่งที่ Developer ขาดไม่ได้เลย การเข้าไปมีส่วนร่วมใน community ต่าง ๆ รวมทั้ง forum หรือ web board ต่าง ๆ เพื่อให้เกิดการแบ่งปัน ทั้งให้ และ รับ ไม่ใช่รับเพียงอย่างเดียวนะครับ เป็นเส้นทางหนึ่งสำหรับการพัฒนาความสามารถของ Developer ให้ดีขึ้น ทั้งการพูดคุย ทั้งการแก้ไขปัญหา ทั้งการตั้งคำถามที่ถูกต้อง ปล. ไม่ใช่เข้าแต่ google เพื่อค้นหาสิ่งที่อยากได้ แล้วก็กด link เข้าไปที่ stack overflow นะ

4. หัดใช้เครื่องมือต่าง ๆ เพื่อทำให้ชีวิตง่ายขึ้น

ตัวอย่างเช่น IDE ที่ใช้งาน ก็ใช้ให้เต็มประสิทธิภาพบ้าง เช่นการใช้ short-key ให้เป็น เช่นการใช้ feature ต่าง ๆ ที่ให้มาบ้าง มิเช่นนั้น ไปใช้ text editor ดีกว่านะ รวมทั้งยังมีเครื่องมืออื่น ๆ อีก เช่น

เครื่องมือสำหรับวิเคราะห์ source code
เครื่องมือสำหรับช่วยหา bug

พยายามลดสิ่งที่ Developer ต้องทำซ้ำ ๆ ลงไปบ้างนะครับ

5. ต้องมีเป้าหมายที่ชัดเจน

ในทุก ๆ product มันต้องมีเป้าหมายที่ชัดเจน ว่าต้องการแก้ไขปัญหาอะไร ว่ามีกลุ่มลูกค้าเป้าหมายเป็นใคร ถ้าไม่มีสิ่งเหล่านี้ จะสร้าง product อะไรออกมา และไม่มีทางจะประสบความสำเร็จได้ แต่ถามว่าในระหว่างการพัฒนาสามารถเปลี่ยนได้ไหม ตอบได้เลยว่า ได้ แต่ปลายทางยังต้องชัดเช่นเดิมนะ เหมือนกันกับ Developer ทุกคนต้องมีเป้าหมายที่ชัดเจน สำหรับการพัฒนาตัวเองนะ

6. อย่าเร่ง อย่ารีบ

ในการพัฒนา software นั้น เราพบว่า ยิ่งเร่ง ยิ่งรีบ ยิ่งก่อให้เกิดความผิดพลาดจำนวนมากมาย บางครั้งการแก้ไขปัญหาในช่วงเร่งรีบ กลับกลายเป็นการสร้างปัญหา และต้องกลับมาแก้ไขต่อไป บ่อยครั้งจะใช้เวลาแก้ไขเยอะมาก ๆ แต่ Developer ที่ดี จะต้องสามารถรับมือ และ จัดการปัญหาเหล่านี้ได้ และต้องส่งมอบงานที่มีคุณภาพสูงอีกด้วย

7. เรียนรู้อยู่อย่างสม่ำเสมอ

ในโลกของ IT นั้น เทคโนโลยีต่าง ๆ มันเปลี่ยนแปลงรวดเร็วมาก ดังนั้น สิ่งที่ Developer ทุกคนต้องทำ คือ การเรียนรู้ และ ติดตามเรื่องใหม่ ๆ อยู่อย่างเสมอ ทั้งจาก blog, feed, social และ forum/web board แต่ปัญหาหลัก คือ ข้อมูลมันเยอะมาก ๆ ดังนั้นให้คัดกรองเฉพาะเรื่องที่สนใจเท่านั้น

8. อย่ากลัวที่จะผิดพลาด

มันเป็นคำพูดที่ใคร ๆ ก็พูดกันนะ แต่ว่ามันทำยากมาก ๆ เพราะว่า ไม่มีใครหรอกที่อยากจะทำผิดพลาด ถ้ามัวแต่กลัว ก็ไม่ได้ทำอะไรกันพอดี ดังนั้น ลงมือทำเถอะนะ แต่ถ้าผิดพลาดแล้ว ขอให้เรียนรู้จากมัน และท่องไว้เลยว่า จะไม่ยอมผิดซ้ำสองกับเรื่องเดิม ๆ อีก และอย่ามัวแต่โทษคนอื่น แล้วจะทำให้ Developer พัฒนาขึ้นอย่างรวดเร็ว

ช่วงวันหยุด Devleoper มันปรับปรุง และ พัฒนาตัวเองกันนะ

Reference Websites https://dzone.com/articles/the-top-8-habits-of-successful-developers http://www.slideshare.net/bright9977/the-8th-habit-by-stephen-r-covey-summary-13483021

Screen Shot 2559-02-07 at 7.03.45 PM

จากการ review code จำนวนหนึ่ง จากการแก้ไขและปรับปรุง code จำนวนหนึ่ง พบว่าการเพิ่ม comment ใน code มันเป็นสาเหตุหนึ่งที่ส่งผลให้คุณภาพของ code แย่ลง ซึ่งมักจะมีรูปแบบดังนี้

1. TODO และ Fix it

ส่วนใหญ่เกิดมาจาก IDE ทำการสร้างให้อัตโนมัติ และ developer เองก็ไม่ได้ลบออก บางครั้ง developer เขียนไว้ เพื่อระบบจุดที่ต้องกลับมาแก้ไข และ ทำต่อ แต่จนแล้วจนรอด ก็ไม่ได้กลับมาทำ สุดท้ายมันจึงเป็น comment ที่ไร้ค่าอย่างมาก ส่วน Fix it จะเขียนไว้ทำไมนะ น่าคิดนะ

2. Comment ในสิ่งที่ code ทำอยู่แล้ว

เช่น [code] return true; //return true //private instance variable to keep age public static int age; [/code] แบบนี้ก็ไม่รู้จะเขียนไปทำแมวอะไร !!

3. เขียนคำเตือนไว้ใน code

ตัวอย่างเช่น อย่ามายุ่งกับ code ส่วนนี้ ถ้าไม่ได้รับอนุญาต พร้อมระบุชื่อ email และ เบอร์ติดต่อ บางครั้งก็เขียนขอโทษกับสิ่งที่ทำลงไป !!

4. เจอการ comment code จำนวนมาก

ถ้าไปถามคนที่ดูแล ว่า ทำไมไม่ลบ code ชุดนี้ไปล่ะ ? ทั้ง ๆ ที่ code ชุดนี้ถูก comment ไว้ ทั้ง ๆ ที่ code ถูกจัดเก็บไว้ใน version control ทั้ง ๆ ที่ ... แต่คำตอบที่ได้คือ อย่าไปลบมันเลย กลัวกระทบ เดี๋ยว code ชุดนี้อาจจะถูกนำกลับมาใช้อีก !! ดังนั้น ปล่อยไว้อย่างนั้นแหละนะ !!

5. อธิบายว่า เขียน code แบบนี้เนื่องมากจากใคร ?

เช่น เนื่องจากนาย A บอกว่าให้เขียนแบบนี้ คำถาม คือ นาย A คือใคร ก็ไม่มีใครรู้ โดย comment เหล่านี้จะใส่มาเพื่ออะไร ? มันไม่ได้เพิ่มคุณค่า หรือ ประโยชน์ใด ๆ ทั้งสิ้น

สุดท้าย คือ Comment ที่ไม่ถูกต้อง ตามการทำงานจริงของ code !!

เป็นสิ่งที่น่ากลัวอย่างมาก สำหรับ developer ที่ต้องเข้ามาดูแล code ชุดนี้ สามารถพูดได้เลยว่า ไม่มี comment ยังดีกว่านะ !! ปล. ผมไม่ได้บอกว่า การเขียน comment ใน code เป็นสิ่งที่ไม่ดีนะ แต่ก่อนจะเขียนควรคิดก่อนว่า code ที่เขียนมันอธิบายตัวมันเองได้ไหม ? ถ้าไม่ได้ ให้ปรับปรุง code ก่อนดีไหม ? ถ้าต้องเขียนจริง ๆ ก็ต้องทำให้มันดี และ update อยู่อย่างเสมอ ตาม code ที่เปลี่ยนแปลง

แล้วคุณล่ะ เจอ comment ใน code แบบไหนกันบ้าง ?

Reference Websites http://www.hongkiat.com/blog/source-code-comment-styling-tips/ http://stackoverflow.com/questions/184618/what-is-the-best-comment-in-source-code-you-have-ever-encountered https://dzone.com/articles/my-commentary-on-code-comments http://code.tutsplus.com/tutorials/top-15-best-practices-for-writing-super-readable-code--net-8118

Screen Shot 2559-02-10 at 7.05.10 PM

ในการดูแลรักษา code ของระบบต่าง ๆ มันไม่ได้ง่ายเลย ยิ่งเป็น Legacy code แล้วยิ่งยากเข้าไปใหญ่ แต่ก่อนอื่นต้องทำความเข้าใจกับ code ก่อน ทั้งเรื่องของ

ข้อมูลทั่วไปของ code เช่น จำนวนบรรทัด จำนวนไฟล์ จำนวน method
ข้อมูลเรื่องความซับซ้อนของ code
ข้อมูลเรื่อง code ที่ซ้ำซ้อน (Duplication)
ความสัมพันธ์ของ code (Dependency)

โดยเรื่องที่มีความสำคัญอย่างมากก็คือ เรื่อง ความสัมพันธ์ของ code (Dependency) ว่าผูกติดกันอย่างไรบ้าง ? เรามักจะเรียกว่า Tight-coupling และ Loose-coupling นั่นเอง ดังนั้นเราลองมาดูใน Android project กันหน่อยสิ

คำถาม ทำไมเราต้องรู้ว่า code มันมีความสัมพันธ์กันอย่างไร ?

คำตอบ เราจะรู้ และ มั่นใจได้อย่างไรว่า code ที่เรากำลังทำการแก้ไขนั้น มันกระทบส่วนไหนบ้าง ? เช่น

มี code ส่วนไหนที่เรียกใช้บ้าง ?
มี code ส่วนไหนถูกเรียกใช้บ้าง ?

ยิ่งถ้าเป็น Developer ที่เพิ่งเข้ามาดู code ชุดนี้ด้วยแล้ว คุณจะทำอย่างไร ? ยิ่งถ้าเป็น Developer ที่มีประสบการณ์น้อย จะทำอย่างไร ? ดังนั้น สิ่งที่ต้องทำให้เห็นภาพชัดก่อนก็คือ รู้และเข้าใจก่อนว่า code แต่ละส่วนมันมีความสัมพันธ์กันอย่างไรนั่นเอง

ระบบตัวอย่าง คือ Android project

ซึ่งทำการ build ด้วย Gradle ส่วน library สำหรับการดูความสัมพันธ์ของ code คือ JDepend โดย JDepend นั้น ทำการสรุปให้ว่า Source code ของภาษา Java ที่เราเขียนขึ้นมาในแต่ละ package นั้น มันไปเรียกใช้งาน class/method จาก package อะไรบ้าง ? มันถูกเรียกใช้งานจาก packagge ไหนบ้าง ? ซึ่งทำให้เราเห็นว่า คุณภาพในการออกแบบ code ของระบบเราเป็นอย่างไร ทั้งในมุมมองของ extensibility ทั้งในมุมมองของ reusability ทั้งในมุมมองของ maintainability ในระดับของ package เพื่อทำให้เราสามารถแก้ไขได้อย่างถูกต้อง

การใช้งาน JDepend กับ Gradle

เนื่องจาก Android project นั้นทำการ build ด้วย Gradle ดังนั้นเราจึงต้องเพิ่ม JDepend เข้าไปที่ Gradle ด้วย ดังนี้ [gist id="78bc992c0d0325145127" file="build.gradle"] คำอธิบาย

เพิ่ม plugin jdepend
ในทำงานหลังจาก task compileDebugSources
เพิ่ม task ชื่อว่า jdepend เข้าไปใน project โดยผลการวิเคราะห์จะอยู่ในไฟล์ build/reports/jdepend.xml

ดังนั้นสามารถใช้งานด้วยคำสั่ง $./gradlew depend หรือสามารถดูว่ามี task jdepend หรือไม่ ด้วยคำสั่ง $./gradlew tasks

แต่ผลการทำงานจาก JDepend นั้นจะเป็นไฟล์ XML ซึ่งอ่านลำบาก

จึงต้องใช้เครื่องมืออื่นมาช่วยเหลือนิดหน่อย ดังนี้ 1. นำไปทำงานกับ Jenkins หรือระบบ Continuous Integration (CI) เนื่องจากมี plugin สำหรับการสร้างรายงานของ JDepend อยู่แล้ว ซึ่งมีผลการทำงานดังรูป Screen Shot 2559-02-10 at 3.19.33 PM

ซึ่งจากรายงานมันมี column ต่าง ๆ ที่ต้องเข้าใจคือ

TC (Total Class) จำนวน class ทั้งหมดในแต่ละ package = CC + AC
CC (Concrete Class) จำนวน concrete class ทั้งหมดในแต่ละ package
AC (Abstract Class) จำนวน abstract class หรือ interface ทั้งหมดในแต่ละ package
Ca (Afferent Coupling) จำนวน package อื่นที่เรียกใช้งาน class จาก package นี้
Ce (Efferent Coupling) จำนวน package อื่นที่ถูกเรียกใช้งาน class จาก package นี้
A (Abstractness) อัตราส่วนระหว่า abstract class/interface กับ class ทั้งหมดใน package
I (Instability) เป็นค่าที่บอกว่าใน package นี้จะเปลี่ยนแปลงบ่อยหรือไม่ ถ้าค่ามาแสดงว่าเปลี่ยนบ่อย หรือ ไม่เสถียรนั่นเอง คำนวณจากสูตร Ce / ( Ce + Ca )
D (Distance from the main sequence) เป็นค่าความสมดุลระหว่าง A กับ I โดยที่ A+I=1 ดังนั้น D = 1 - (A+I)
V (Volatility) โดยปกติมีค่าเป็น true หรือ 1 นั่นคือ เอา package เหล่านั้นมาคิดคำนวณนั่นเอง ถ้าไม่ต้องการมาคำนวณก็กำหนดเป็น false หรือ 0 ได้

2. สามารถนำไฟล์ XML มาแสดงผลในรูปภาพสวย ๆ ด้วย Gephi สามารถเขียน code เพื่อแปลงข้อมูล XML จาก JDepend เพื่อเปิดใช้งาน gephi ได้ด้วย ลองดู code จากที่นี่ Graph Source code analysis แสดงผลการทำงานดังรูป

จากนี้ไปน่าจะทำให้เห็นแล้วว่า code ที่เราต้องดูแลนั้น

มีความสัมพันธ์กันอย่างไรบ้าง น่าจะทำให้ชีวิตดีขึ้นมาไม่มากก็น้อยนะครับ

3566f858-7732-11e5-95aa-a606d4e71aab

Fastlane คือ ชุดเครื่องมือ automation สำหรับ iOS app ที่เริ่มได้รับความนิยมอย่างมาก ซึ่งปัจจุบันเป็นหนึ่งใน project ของ Twiiter Fabric แล้วด้วย พัฒนาด้วยภาษา ruby เป็น project ที่มีอายุได้เพียง 1 ปีเท่านั้น

สำหรับ Mobile developer ทั้ง iOS และ Android ถ้าใครไม่รู้จัก ถือว่า พลาดมาก ๆ ดังนั้น มาเรียนรู้ และ นำไปใช้งานกัน

โดยในบทความนี้ จะแนะนำการใช้งาน Screengrab เพื่อทำการ capture หน้าจอการทำงานของ Android app มาดูกันเลย

ความสามารถหลักนั้นสร้างมาเพื่อ iOS app

ประกอบไปด้วย

Deliver
Snapshot
Frameit
Pem
Sigh
Produce
Cert
Scan
Gym
Match
Pilot
Boarding

ซึ่งมันครบถ้วนและสมบูรณ์อย่างมาก

แต่สำหรับ Android app นั้น เพิ่งจะมีเพียง 2 ตัวเท่านั้น

ประกอบไปด้วย

Supply สำหรับการ update app บน Google Play Store
Screengrab สำหรับการ snapshot หน้าจอของ app

โดยความสามารถที่น่าสนใจคือ Screengrab

เมื่อลงไปดูในรายละเอียดพบว่า มันสามารถทำงานร่วมกับ Espresso test หรือ UI Test ของ Android ได้เลย นั่นคือ ในแต่ละขั้นตอนของการทดสอบ เราสามารถทำการ snapshot รูปในแต่ละขั้นตอนการทดสอบ app เลย ดังนั้น มาดูการใช้งานดีกว่า

1. เริ่มด้วยการติดตั้ง Fastlane และ Screengrab

[code] $sudo gem install fastlane $sudo gem install screengrab [/code]

2. เริ่มใช้งานกับ Android app ด้วยการสร้างไฟล์ต่าง ๆ ของ fastlane

[code] $fastlane init [/code] ผลการทำงานเป็นดังนี้ ทำการสร้าง folder fastlane และ ไฟล์ต่าง ๆ ที่จำเป็น คือ

Appfile ใช้กำหนดข้อมูลต่าง ๆ ของ app เรา เช่น package name และ key file สำหรับการ upload app
Fastfile ใช้กำหนด action ต่าง ๆ สำหรับการ run fastlane

3. มาเริ่มใช้งานกับ Screengrab กันบ้าง

ก่อนอื่นต้องเขียน UI Test สำหรับ Android app ด้วย Espresso ก่อนนะ !! ถ้าไม่เขียน ก็ถือว่า จบกัน ไม่ต้องไปต่อนะ !! แต่ถ้าเขียน Espresso สำหรับทดสอบเรียบร้อยแล้ว และต้องทำงานได้ด้วยนะ ก็เริ่มมาใช้งานร่วมกับ Screengrab กันได้เลย มีขั้นตอนดังนี้ 3.1 เพิ่ม dependency ไปยังไฟล์ build.gradle [gist id="e4de0191fa4de153a511" file="build.gradle"] 3.2 สร้างไฟล์ src/debug/AndroidManifest.xml ขึ้นมา เน้นย้ำว่าอยู่ใน folder debug นะ ต้องสร้างเอง [gist id="e4de0191fa4de153a511" file="AndroidManifest.xml"] 3.3 ทำการแก้ไข code ของการทดสอบที่เขียนด้วย Espresso ดังนี้ ทำการเพิ่ม code

เพิ่ม ClassRule สำหรับจัดการกับ Locale
ทำการเพิ่ม code ของการ capture หน้าจอของ app ด้วยคำสั่ง Screengrab.screenshot();

ตัวอย่าง [gist id="e4de0191fa4de153a511" file="E2EMessageTest.java"]

4. เมื่อทุกอย่างเสร็จเรียบร้อย ให้ทำการ run ดังนี้

เริ่มด้วยการสร้างไฟล์ apk ก่อน ด้วยคำสั่ง [code] $./gradlew assembleDebug assembleAndroidTest [/code] จากนั้นทำการ run Screengrab ด้วยคำสั่ง [code] $screengrab [/code] ผลการทำงานเป็นดังนี้ [gist id="e4de0191fa4de153a511" file="result.txt"]

แต่ก่อนที่จะ run ทั้งสองคำสั่งได้นั้น

ต้องทำการกำหนดค่าของ ANDROID_HOME และ PATH ก่อนนะ เพื่อกำหนด Android SDK และ Platform tool สำหรับการใช้งาน adb นั่นเอง ตัวอย่างการกำหนดค่าใน Mac OS [code] export ANDROID_HOME=YOUR ANDROID SDK PATH export PATH=.:$ANDROID_HOME/platform-tools:$PATH [/code] และรูปที่ได้จาก Screengrab นั้นจะอยู่ใน folder fastlane/metadata ตัวอย่างดังรูป Screen Shot 2559-02-12 at 7.30.18 PM

เพียงเท่านี้ก็สามารถทำการ capture รูปการทำงานของ Android app ได้แล้ว ซึ่งมันง่ายและสะดวกกว่า Spoon เยอะเลย แต่สิ่งที่ยังขาดไปก็คือ ถ้ารวมรูปเหล่านี้ไปไว้ในรายงานของ Espresso เลยจะแจ่มมาก ๆ หรือมีการสร้างรายงานแบบสวย ๆ และแยกตามแต่ละ test case ไปเลย มันจะแจ่มกว่านี้มากมาย และดูรายละเอียดเพิ่มเติมของ Screengrab ด้วยคำสั่ง [code] $screengrab --help [/code] สามารถดู code และตัวอย่าง project ได้จาก Github::Basic Android Testing

ส่วน Fastlane สำหรับ iOS มันแจ่มมาก ๆ เดี๋ยวจะเอามาเล่าให้ฟังต่อไป

Screen Shot 2559-02-13 at 2.27.27 PM

ความสามารถอย่างหนึ่งที่ Developer ในปัจจุบัน จำเป็นต้องมีก็คือ การใช้งาน Google ถ้า Developer ใช้งานได้อย่างถูกต้อง และ มีประสิทธิภาพ จะพบว่า ผลการค้นหาส่วนใหญ่นั้น จะอยู่ที่ StackOverflow.com และ Github.com แต่พบว่า Developer จำนวนหนึ่ง กลับใช้งาน Google ได้ไม่เต็มประสิทธิภาพ ดังนั้น จึงสรุปวิธีการใช้งานที่น่าจะดีมาไว้นิดหน่อย ปล. ปกติก็ใช้เพียงเท่านี้

1. ถ้าต้องการค้นหาประโยค หรือ คำ นั้นจริง ๆ ให้ใส่ Double Quote ไปซะ (Exact Phrase Search)

ซึ่งทำให้เราได้ผลการค้นหาที่ตรงกับความต้องการมาก ตัวอย่างการหาข้อมูล OutofMemoryError Screen Shot 2559-02-13 at 12.25.52 PM

2. ถ้าไม่ต้องการคำ หรือ Term ใด ก็ exclude ไปได้นะ (Exclude Term)

ตัวอย่างหนึ่งที่เพิ่งเจอกับตัวเองคือ ต้องการค้นหาข้อมูลเกี่ยวกับ Spark Java เป็น framework สำหรับสร้าง web application ด้วยภาษา Java แต่ผลการค้นหากลับได้ Apache Spark มาด้วย ซึ่งมันไม่ได้เกี่ยวข้องอะไรกันเลย ดังนั้นเราสามารถ exclude คำว่า Apache ออกไป แล้วจะได้ผลลัพธ์ที่ถูกต้องมากยิ่งขึ้น ดังนี้ Screen Shot 2559-02-13 at 2.06.37 PM

3. ถ้าต้องการรู้ว่า มีเทคโนโลยีอะไรที่เกี่ยวข้องกับสิ่งที่เราใช้งาน สามารถใช้ related ได้นะ

ตัวอย่างเช่น ผมต้องการรู้ว่า mongodb มันมีเทคโนโลยีอะไรที่เกี่ยวข้องบ้าง หรือบางครั้ง เราอาจจะหาเทคโนโลยีอื่น ๆ มาใช้แทนก็ได้ สามารถใช้งาน related ใน google ได้ดังนี้ Screen Shot 2559-02-13 at 2.08.39 PM

4. ค้นหาข้อมูลจาก website ที่เราต้องการเท่านั้น โดยใช้ site

เป็นวิธีการค้นหาหลายคนน่าจะรู้เป็นอย่างดี แต่ถ้าใครไม่รู้ก็รู้ไว้ซะ ตัวอย่างหาข้อมูลใน stackoverflow.com ก็ให้ทำแบบนี้เลย Screen Shot 2559-02-13 at 2.13.51 PM

5. ถ้าต้องการระบบนามสกุลไฟล์ที่ต้องการค้นหา ก็ใช้ filetype ไปเลย

ผมว่า developer หลาย ๆ คนก็ชอบค้นหาพวกเอกสาร และ หนังสือ ดังนั้นเราสามารถระบุ filetype ไปได้เลย ตัวอย่างเช่น ผมค้นหาหนังสือ Refactoring ก็ทำแบบนี้ Screen Shot 2559-02-13 at 2.15.59 PM

6. รู้ไหมว่า แต่ละ website มันมีระบบค้นหาให้นะ ใช้ได้กับ Google Chrome

ตัวอย่างเช่น ผมต้องการค้นหาข้อมูลจาก stackoverflow.com ก็เพียงพิมพ์คำว่า http://stackoverflow.com/ในช่องค้นหาผ่าน Google Chrome จากนั้นก็กดปุ่ม Tab จะเห็นผลการทำงานแบบนี้ จากนั้นก็ใส่คำที่ต้องการหาได้เลย Screen Shot 2559-02-13 at 2.18.05 PM

อยากรู้อะไรเพิ่มเติมก็ ค้นหาสิครับ

เป็นความสามารถที่ Developer ทุกคนควรมีนะครับ แต่ก่อนอื่น ควรจะมีความรู้พื้นฐานในเรื่องนั้น ๆ ก่อน แล้วมันจะทำให้คุณคิดคำค้นหาที่ตรง และ ชัดเจนได้ และผลที่ตามมาก็คือ ผลลัพธ์ที่ตรงใจ Screen Shot 2559-02-13 at 2.20.22 PM

Screen Shot 2559-02-14 at 12.32.58 PM

ผมเชื่อว่า Developer ทุกคนทำการทดสอบสิ่งที่ตัวเองสร้าง แต่ Developer บางคนอาจจะไม่เขียน test ขึ้นมา (Manual test) แต่ Developer หลายคนอาจจะเขียน test ขึ้นมา ( Automated test ) เพื่อทำการตรวจสอบสิ่งที่กำลังแก้ไข ว่าทำงานได้อย่างถูกต้อง เพื่อทำให้มีความมั่นใจต่อระบบที่กำลังพัฒนา แต่ปัญหาที่มักพบเจอมาก ๆ สำหรับ Testa ก็คือ

Developer มักจะไม่ค่อยสนใจ test มากเท่าไร
Developer มักจะไม่ทำการ refactor test เลย
Developer ไปสนใจเพียง production code เท่านั้น

สุดท้าย test มันกลับก่อให้เกิดปัญหาตามมา ดังนั้น เรามา refactor test กันหน่อยดีไหม ?

1. จงจำไว้ว่า Test มันคือ code นะ

อย่าปล่อยให้ test มันเป็น code ชั้น 2 รองจาก production code แต่ให้มองว่าเป็น production code ที่ต้องถูกส่งมอบด้วยเสมอ

มีคำพูดของคุณ Uncle Bob กล่าวไว้ว่า The good tests are more valuable than production code

ดังนั้น test มันจึงมีความสำคัญอย่างมาก อย่าปล่อยให้ test มันรกรุงรังนะครับ

2. Test ควรต้องอ่าน และ ทำความเข้าใจได้ง่าย

เช่นเดียวกับ production code นั่นคือ เราไม่ได้เขียน code เพียงให้ computer เข้าใจและทำงานได้เท่านั้น แต่เราเขียน code เพื่อให้คนอ่าน แต่เราเขียน code เพื่อให้คนเข้าใจได้ง่าย แต่เราเขียน code เพื่อคนอื่นที่จะเข้ามาดูแลรักษาต่อไป ดังนั้น เรื่องของการตั้งชื่อ test เรื่องของการตั้งชื่อตัวแปร เรื่องของการตั้งชื่อ method ต้องใช้ชื่อที่สื่อสารได้ชัดเจน ไม่ใช่ test 1, 2, 3, 4, 5 ...

3. Test ควรต้องง่ายต่อการดูแลรักษา ทั้งการเพิ่ม แก้ไข และ ลบ

โดยปกติ ถ้า production code มีการเปลี่ยนแปลงแล้ว จะพบว่าต้องทำการแก้ไข test จำนวนมาก !! ดังนั้น ปัญหามันจึงเกิด ? บางคนอาจจะบอกว่า ต้องใช้เวลาแก้ไข test มากกว่า production code เสียอีก !! บางคนถึงกับลบ test ออกไปเลย !! ดังนั้นถ้าต้องการลดเวลาในการแก้ไข แสดงว่า test มันต้องแก้ไขง่ายนะสิ แสดงว่า test มันต้องไม่ซับซ้อนนะสิ แสดงว่า test มันต้องไม่มีเงื่อนไขที่เยอะนะสิ แสดงว่า test มันต้องไม่มี loop ทำงานนะสิ แสดงว่า test มันต้อง DRY (Don’t Repeat Yourself) นะสิ แสดงว่า test มันต้องไม่ซ้ำซ้อนนะสิ ยุบไปเป็น method ซะ ใช่ไหม ?

Developer ลองกลับไปดู test ของระบบสิ

ว่าเป็นไปตาม 3 ข้อข้างต้นหรือไม่ ? ถ้าไม่ ก็น่าจะต้องลงมือ refactor test ได้แล้ว หรือต้องทำอะไรให้มันดีขึ้นแล้วนะ สามารถทำได้ทั้ง manual test และ automated test

อย่าลืมว่า การ refactoring นั้น ต้องทำทั้ง test และ production code เสมอ

Blue Green_BB

ช่วงหลังไปงาน meetup มักจะได้ยินคำแปลก ๆ ใหม่ ๆ เยอะมาก หนึ่งในนั้นก็คือ Blue-Green Deployment จาก Docker Meetup ดังนั้น มาทำความรู้จักกันหน่อยสิ ว่ามันคืออะไร ? ว่ามันมีขั้นตอนการทำงานอย่างไร ? ว่ามันมีประโยชน์อย่างไรบ้าง ?

มาดูรูปแบบการ deploy และ release ระบบงาน แบบเดิม ๆ กันก่อน

เมื่อต้องการ deploy ระบบงานใหม่ ๆ ขึ้นไปยัง production server มักจะมีขั้นตอนดังนี้

ต้องหยุดให้บริการระบบงานเดิมก่อน นั่นคือต้องปิดระบบกันก่อน
ทำการ deploy ระบบงานใหม่ขึ้นไป
ต้องทำการทดสอบภายในกันก่อน ว่าทำงานถูกต้องหรือไม่ ถ้าระบบซับซ้อนก็ใช้เวลานานหน่อย
เมื่อทุกอย่างพร้อม ก็เปิดใช้งานระบบกันเลย (Release)

สิ่งที่เราจะได้รับจากวิธีการนี้คือ เวลา Downtime นั่นเอง เราพยายามที่จะปรับปรุงขั้นตอนการ deploy ให้ใช้เวลาน้อยสุด ๆ แต่อย่างไรก็ตามในโลกของระบบงานที่เป็น Monolithic หรือทุกอย่างของระบบรวมกันอยู่ที่เดียวกันแบบใหญ่ ๆ ก็ต้องพบปัญหา Downtime เป็นปกติ แถมหนักขึ้นทุกวันไปอีก เนื่องจากระบบมีความซับซ้อนขึ้นในทุก ๆ วัน ดังนั้นจึงมีแนวคิดในการ deploy งานแบบใหม่ ๆ ขึ้นมา เพื่อลดเวลา Downtime ของการ deploy ลงไป นั่นก็คือ Blue-Green Deployment

มาดูแนวคิดของ Blue-Green Deployment

เป็นแนวคิดที่เรียบง่ายมากคือ เมื่อต้องการ deploy ระบบงานใหม่ ๆ ก็ไม่ต้องปิดระบบเดิม ก็ปล่อยให้ระบบเดิมทำงานไป และทำการ deploy ระบบใหม่ขึ้นไปแบบขนานเลย โดยที่

Blue คือ ระบบเดิม หรือ New Green
Green คือ ระบบใหม่

แสดงดังรูป immutable-microservices-only

จะสังเกตุได้ว่า พวก service หรือระบบงานต่าง ๆ ต้องถูกกั้นด้วย proxy/router/load balance ซะ เพื่อง่ายต่อการปรับเปลี่ยนการใช้งาน service ต่าง ๆ โดยข้อดีของวิธีการนี้ประกอบไปด้วย

ลดเวลา Downtime
ลดความเสี่ยงในการ deploy
สามารถทดสอบได้นานเท่าที่ต้องการจนกว่าจะมั่นใจ

แต่สิ่งที่ตามมา และ สิ่งที่ต้องปรับปรุง ก็มีเยอะเช่นกัน ตัวอย่างเช่น

Environment ของระบบที่เพิ่มขึ้น
กระบวนการทดสอบระบบที่รวดเร็วขึ้น เช่น Automated testing
การออกแบบ service ในรูปแบบของ Microservice และ SOA เป็นต้น เพื่อให้แต่ละ service แยกออกจากกันอย่างชัดเจน เพื่อลดความซับซ้อนของระบบ และ ผลกระทบต่าง ๆ

ยิ่งในปัจจุบันมีทั้ง VM และ Docker ก็ยิ่งทำให้ การ deploy ระบบแบบ Blue-Green Deployment ทำได้ง่าย และ สะดวกมากยิ่งขึ้น สิ่งที่น่าสนใจ และ สำคัญมาก ๆ คือ Database บ่อยครั้งเราต้องการ update โครงสร้างของ database ทั้ง 2 version ปัญหามักจะเกิดจากการ deploy และ release แต่ละครั้งนานจนเกินไป ทำการทั้ง 2 version แตกต่างกันมากไป และนั่นก็คือ ปัญหาใหญ่ !! ดังนั้น การแก้ไขที่ง่าย และ ดีมาก ๆ คือ ให้ทำการ deploy และ release database บ่อย ๆ สิ จะทำให้เราสามารถดูแลและจัดการการเปลี่ยนแปลงของ database ได้ง่ายมากขึ้น

จำไว้เลยว่า ยิ่งเวลาแต่ละ deploy แต่ละ release บ่อย ๆ ก็ยิ่งดีครับ

ปิดท้ายด้วย ขั้นตอนการทำงานของ Blue-Green Deployment

โดยใช้ตัวอย่างของ Microservice ซึ่งถูกบรรจุไว้ใน container มีขั้นตอนการทำงานดังนี้ 1. เริ่มจากระบบการทำงานของระบบปัจจุบัน จะเรียกว่า Blue ซึ่ง traffic การใช้งานจะผ่าน Proxy เสมอ แสดงดังรูป immutable-microservices-01

2. เมื่อต้องการ deploy ระบบใหม่ หรือเรียกว่า Green จะทำการ deploy ระบบใหม่ขึ้นมาให้ทำงานแบบขนานกับของเดิมไปเลย ซึ่งต้องทดสอบด้วยว่า ต้องไม่มีการใช้งานจากที่อื่นนะ แน่นอนว่า ต้องไม่ส่งผลกระทบต่อระบบเดิมด้วย แสดงดังรูป immutable-microservices-02

3. เมื่อทดสอบระบบใหม่จนมั่นใจแล้ว ก็จะทำการ release ระบบงาน ด้วยการเปลี่ยน configuration ที่ Proxy เพื่อให้ traffic การใช้งานมายังระบบใหม่ แสดงดังรูป immutable-microservices-03

4. เมื่อทุกอย่างเรียบร้อยก็ทำการ stop การทำงานของระบบเก่า หรือ ลบไปซะ บางครั้งอาจจะยังไม่ลบออกไป เนื่องจากเผื่อเอาไว้ใช้ rollback เมื่อระบบใหม่ทำงานผิดพลาด แสดงดังรูป immutable-microservices-04

นี่คือความรู้พื้นฐานสำหรับการ deploy ระบบงานแบบ Blue-Green Deployment

น่าจะพอมีประโยชน์บ้างสำหรับการพัฒนา software ซึ่ง Deployment != Release นะครับ Reference Websites http://technologyconversations.com/2016/02/08/blue-green-deployment/ https://docs.pivotal.io/pivotalcf/devguide/deploy-apps/blue-green.html http://martinfowler.com/bliki/BlueGreenDeployment.html

Screen Shot 2559-02-16 at 12.29.04 AM

จากงาน 1st conference ที่กรุง Melbourne ประเทศ Australia มีการสัมภาษณ์คุณ Tarcio Saraiva และ Adam Crough ในหัวข้อ Crafting Quality Software ซึ่งเป็นหัวข้อที่น่าสนใจอย่างมาก จึงนำมาแปลตามความเข้าใจนิดหน่อย มาเริ่มกันเลย โดยคำถามต่าง ๆ ในการสัมภาษณ์จะเน้นในเรื่อง

มุมมองเรื่องของคุณภาพในการพัฒนา software
อธิบายประโยชน์ต่าง ๆ ทางธุรกิจ ที่มาจากการดูแลคุณภาพของ software
เกี่ยวกับบทบาทในการทดสอบระบบงานของ Deliver team เกี่ยวกับการเพิ่มคุณภาพ
การนำ Continuous Integration มาใช้งาน เพื่อเพิ่มคุณภาพของ software
การส่งมอบงานที่มีคุณภาพสูง

คำถามที่ 1 :: มุมมองเกี่ยวกับ Software Quality เป็นอย่างไร ?

มันคือเป้าหมายของทีม เพื่อทำให้ทีมพัฒนาเตรียมวิธีการสร้าง software ให้

มี bug น้อย ๆ
มี function การทำงานที่ดีขึ้น
สร้าง code ที่ง่ายต่อการทำความเข้าใจ

ซึ่งจะทำให้ให้ดีนั้น ต้องมาจาก 2 เส้นทาง คือ

จากภายใน เช่น developer
จากภายนอก เช่น feedback จากผู้ใช้งาน

เรื่องของคุณภาพ (Quality) นั้น ใช้สำหรับการกำหนดบางสิ่งบางอย่างว่า มันดีหรือไม่ดีอย่างไร โดยปกติแล้ว แต่ละคนจะต้องถือครองเรื่องคุณภาพเสมอนะ นั่นแสดงว่า developer ต้องมองกลับไปดู code ที่สร้างขึ้นมา ว่า code ที่สร้างขึ้นมามันดีหรือไม่ ทั้งทำงานได้อย่างถูกต้อง ทั้งดูแลรักษาง่ายหรือไม่ และผู้ใช้งานชื่นชอบหรือไม่

คำถามที่ 2 :: ทำไมองค์กรต่าง ๆ ต้องสนใจเรื่อง Quality ด้วยล่ะ ? มีประโยชน์อย่างไร ?

โดยปกติเรื่องของคุณภาพมันถูกจัดการ และ ควบคุม ในกิจกรรมต่าง ๆ และ การสร้างสิ่งต่าง ๆ อยู่แล้ว เพื่อสร้างคุณค่าให้กับฝ่าย business ดังนั้น ถ้ามีขั้นตอนการทำงานที่ดี และ เหมาะสมแล้ว การสร้างระบบงานที่มีคุณภาพ ช่วยทำให้ง่ายต่อการทำงานร่วมกับฝ่าย business พร้อมรับต่อการเปลี่ยนแปลง รวมทั้งทำให้ทีมสามารถปรับเปลี่ยนวิธีการ และ เทคโนโลยีได้ง่ายอีกด้วย ในแต่ละระบบงานต้องลงทุน และ จัดการเรื่อง Quality เสมอ ทั้งเรื่องของ

Return on Investment (ROI)
Robustness
Reliability
ลดเวลาของ Time to market
เพิ่มความพึงพอใจของลูกค้า

คำถามที่ 3 :: คิดอย่างไรเกี่ยวกับการจัดการ Quality ที่มีคำว่า Quality Assurance และ Quality Control ?

เชื่อว่า Quality นั้นมันต้องสามารถวัดผลได้เสมอ มันจึงนำไปสู่การจัดการนั่นเอง หนึ่งในการจัดการที่ดีก็คือ Continuous Integration (CI) จะช่วยบอกทีมว่า มีอะไรที่ทำงานผิดพลาดบ้าง ทำให้ทีมเห็นปัญหา และ ช่วยกันแก้ไขปัญหาซะ แน่นอนว่า มันส่งผลดีต่อทีม และ business นั่นคือ ส่งผลดีต่อองค์กรนั่นเอง

คำถามที่ 4 :: อธิบายเกี่ยวกับบทบาทของการทดสอบว่าเป็นอย่างไร ?

การทดสอบต้องเปลี่ยนจาก การให้ใครคนใดคนหนึ่ง หรือ ทีมใดทีมหนึ่งทำการทดสอบ ไปเป็น ทดสอบเลยสิ !! นั่นคือ ทุกคนช่วยกันทดสอบสิ ซึ่งเป็นผลมาจากแนวคิดที่ว่า จะทำอย่างไรให้คุณภาพของ software มันดีขึ้นนั่นเอง ตัวอย่างของแนวปฎิบัติจากแนวคิดนี้ เช่น

Test-Driven Development (TDD)
Exploratory Testing

การทดสอบมันคือเรื่องของความเชื่อมั่น และ มั่นใจ โดยแนวปฎิบัติต่าง ๆ ช่วยทำให้เกิดความเชื่อมั่นมากขึ้น และทำให้เราเดินไปข้างหน้าอย่างต่อเนื่อง ไม่ใช่พายเรือในอ่างกันอีกต่อไป Testing ควรอยู่ในทุก ๆ การพูดคุย ตั้งแต่กระบวนการคิด ไปจนถึงการลงมือทำ และให้อยู่ในรูปแบบที่เรียบง่าย ไม่ซับซ้อน

รวมทั้งหน้าที่ในการทดสอบระบบงาน ต้องเป็นหน้าที่หนึ่งของทุกคนในทีมพัฒนา และเป็นกิจกรรมที่ควรเกิดขึ้นอยู่ตลอดเวลา

แต่ถ้าต้องการ feedback ต่าง ๆ จากผู้ใช้งาน จำเป็นจะต้องส่งมอบระบบที่มีคุณภาพดี ไปยังลูกค้าให้รวดเร็ว และ บ่อยที่สุดนั่นเอง

คำถามที่ 5 :: ยกตัวอย่างของการนำ Continuous Integration เพื่อจัดการเรื่อง Quality

โดยระบบงานที่พัฒนาทำการประยุกต์ Continuous Delivery มาใช้งาน และที่สำคัญคือ Zero Downtime อีกด้วย แต่จะทำไม่ได้เลย ถ้าไม่มี Continuous Integration มาช่วย เนื่องจากมาช่วยให้การพัฒนาระบบงานมีคุณภาพมากยิ่งขึ้น และช่วยทำให้ทีมสามารถนำเอาแนวคิด และ เทคโนโลยีอื่น ๆ มาใช้งานได้ง่ายขึ้น โดยในทุก ๆ การเปลี่ยนแปลงของ code ระบบ Continuous Integration จะทำการตรวจสอบการทำงานของระบบ เพื่อค้นหาว่าส่วนใดของระบบก่อให้เกิดปัญหา นั่นแสดงว่า เราสามารถรู้ปัญหาได้อย่างรวดเร็วนั่นเอง เป็นกระบวนการพัฒนาอย่างต่อเนื่อง ดังนั้นมันทำให้ทีมพัฒนามีความมั่นใจ ทีม business มีความมั่นใจต่อระบบ และ ทีมพัฒนา ผลดีย่อมส่งผลถึงองค์กรนั่นเอง

คำถามที่ 6 :: ถ้าต้องการส่งมอบ software ที่มีคุณภาพสูง จะต้องทำอย่างไรบ้าง ? มีคำแนะนำไหม ?

ในเรื่องของ Quality มันไม่ได้มีสูตรสำเร็จตายตัว อาจจะทำการสร้าง Qulity จากข้างใน คือ คน และ ทีมพัฒนา และให้สนใจ feedback ที่มาจากข้างนอก เช่น จากผู้ใช้งาน รวมทั้งให้ทีมพร้อมรับต่อการเปลี่ยนแปลง หรือสามารถแบ่งเรื่องของ Quality เป็น 2 ส่วนคือ ส่วนที่ 1 คือ จากภายนอก (External) ต้องเข้าใจว่าลูกค้าเป็นใคร ต้องฟังว่าลูกค้าต้องการอะไร และส่งมอบ product ที่มีคุณค่าไปยังลูกค้า ส่วนที่ 2 คือ จากภายใน (Internal) องค์กรต้องมีวัฒนธรรมที่ดี ทั้งเรื่องของการทดลอง และ ไม่กลัวการทำผิด แต่มันคือโอกาสสำหรับการเรียนรู้ ทั้งในระดับบุคคล และ ทีม รวมทั้งแต่ละคน แต่ละทีม ต้องรับฟังความคิดเห็นซึ่งกันและกัน และต้องทำงานร่วมกันเป็นอย่างดี สามารถอ่านแบบเต็ม ๆ ได้ที่ Crafting Quality Software

คุณล่ะ คิดอย่างไรกับคำว่า Crafting Quality Software ?

Screen Shot 2559-02-17 at 8.12.59 PM

วันนี้ได้อ่านบทความเรื่อง Kill your dependency อธิบายเกี่ยวกับการตัด และ ลบ dependency หรือ libary ต่าง ๆ ที่เราไม่ต้องการใช้ออกไป ซึ่งปิดท้ายด้วย สิ่งที่นักพัฒนาควรต้องเข้าใจไว้เลย ประกอบไปด้วย

No code runs faster than no code. No code has fewer bugs than no code. No code uses less memory than no code. No code is easier to understand than no code.

ดังนั้นให้ตัดสิ่งที่ไม่จำเป็นออกไปซะ ซึ่งเท่าที่ผมพบเจอมา น่าจะเป็นภาษา Golang ที่ใส่ใจในเรื่องนี้อย่างมาก บางภาษาก็มีเครื่องมือสำหรับลบ code ที่ไม่ถูกเรียกใช้งานกันเลย ดังนั้น Developer ลองถามตัวเองสิว่า เราตัด dependency ที่ไม่จำเป็นอกไปกันบ้างไหม ? เราตัด library ที่ไม่ได้ใช้ออกไปกันบ้างไหม ?

Screen Shot 2559-02-18 at 8.13.07 PM

ก่อนจะมาเรียน Course The Whole Team Approach to Agile Testing ที่สิงคโปร์ สอนโดยคุณ Janet Gregory ผู้ร่วมเขียนหนังสือ Agile Testing และ More Agile Testing

มีคำถามที่ถามตัวเองอยู่เสมอว่า Agile Testing มันคืออะไร ? มันคือ methodology หรือ ระเบียบวิธี หรือ ขั้นตอนวิธีหรือไม่ ? มันคือ กลุ่มของ principle หรือ แนวคิดหรือไม่ ? มันคือ กลุ่มของ practice หรือ แนวปฏิบัติหรือไม่ ? มันคือ framework หรือ กรอบของการทำงานหรือไม่ ?

เมื่อผ่านวันแรกของการเรียน พบว่ามีรายละเอียดต่าง ๆ เยอะมาก ซึ่งทำให้ตอบคำถามของตัวเองได้บ้างแล้ว

เริ่มจากเรื่องของ Agile ก่อน

มันประกอบไปด้วย 4 core value มันประกอบไปด้วย 12 principle ดังนั้น Agile ไม่ใช่ methodology อย่างแน่นอน Extreme Programming หรือ XP Programming มันคือ method หรือ framework หนึ่งในการพัฒนา software แน่นอนว่า ต้องมีแนวคิดตาม Agile ทั้ง core value และ principle และมีกลุ่มของ practice เฉพาะ เพื่อให้ปฏิบัติตาม ส่วน Scrum มันคือ project management framework ที่ปฏิบัติตามแนวคิดของ Agile เช่นเดียวกัน ต่างจาก XP Programming ก็คือ กลุ่มของ practice เท่านั้นเอง

กลับมาที่ Agile Testing กันบ้าง มีความหมายอย่างไร ?

ถ้าแปลกันตามตรง ก็สามารถตีความได้สองแบบ คือ

การทดสอบ Agile project นะสิ เป็นสิ่งที่คนส่วนใหญ่คิด
การทำให้การทดสอบใน project อะไรก็ได้ มีความเป็น Agility หรือ กระฉับกระเฉง ว่องไว

ซึ่งไม่มีข้อใดผิด แต่ Agile Testing ไม่ใช่ methodology อย่างแน่นอน เนื่องจาก Agile Testing มันคือ แนวทางหนึ่งของการการทำงาน เนื่องจาก Agile Testing มันคือ แนวทางหนึ่งของการทดสอบระบบ เนื่องจาก Agile Testing มันคือ กระบวนการคิด สามารถนำไปใช้ในวิธีการพัฒนาแบบไหนก็ได้ ไม่ว่าจะเป็น Agile, Scrum, Kanban และ XP Programming เนื่องจาก Agile Testing มันคือ การพูดคุย และ ทำงานร่วมกันของ Whole Team หรือ Delivery team โดยการทดสอบนั้นจะเป็นกิจกรรม (Activity) ที่เกิดขึ้นขึ้นตลอด มิใช่เป็น phase หรือ แยกทีมไปทดสอบอีกแล้ว เนื่องจาก Agile Testing เน้นในเรื่องของการป้องกันไม่ให้เกิด defect หรือ ข้อผิดพลาดเกิดขึ้น มิใช่การค้นหา defect ให้ได้มากที่สุด ดังนั้นเรื่อง mindset สำคัญอย่างมาก จะต้องทำการปรับเปลี่ยนด้วยทั้งตัวเราเอง ทีม และ องค์กร เนื่องจากเมื่อใดก็ตาม มีการจับวัดด้วยตัวเลขแล้ว วิธีการทำงานของคนเราจะเปลี่ยนไปทีนที ซึ่งมันไม่ใช่แนวทางการทำงานที่ดีเลย ตัวอย่างเช่น ถ้าเกิด defect จากงานที่ทำในรอบนี้ ไม่ต้องบันทึก defect ไม่ต้องสรุปผล แต่ให้ทำการแจ้ง defect กับทีมทันที ใครจะรู้ปัญหาได้ดีกว่าคนสร้างมัน เพื่อจะได้ทำการแก้ไขทันที ซึ่งเป็นวิธีการที่มีค่าใช้จ่ายถูกที่สุดแล้ว โดยขั้นตอนการแก้ไข defect ที่ดีเป็นดังนี้

เมื่อเจอ defect ให้ทำการเขียนชุดการทดสอบเพื่อให้เกิด defect นั้นจริง ๆ
ทำการแก้ไข
ทำการทดสอบด้วยชุดการทดสอบที่สร้างขึ้นมา (ได้ชุดของ Automate test มาแล้ว)
ถ้าผ่านทั้งหมดแล้ว ให้ลืม defect นั้นไปซะ เพราะว่า มีชุดการทดสอบครอบคลุมไว้แล้ว เอาเวลาไปคิดอย่างอื่นที่มีประโยชน์ดีกว่านะ

เนื่องจาก Agile Testing เน้นเรื่องการทำงานร่วมกันของทีม และร่วมกันสร้าง automate regression test ขึ้นมา เพื่อทำให้ทีมรับรู้ feedback ของการทำงานได้อย่างรวดเร็ว (Fast Feedback) มันทำให้ทีมสามารถรับรู้ถึงปัญหา และ ทำการแก้ไขได้อย่างรวดเร็ว และพร้อมรับต่อการเปลี่ยนแปลงอีกด้วย เมื่อทีมทั้งหมดทำงานร่วมกัน สิ่งที่สมาชิกทุกคนในทีมต้องรู้คือ การ testing จะต้องมาคู่กับการ coding เสมอ นั่นหมายความว่า งานที่เสร็จ (Done) หมายถึงงานที่ต้องผ่านการ testing และ coding เสร็จนั่นเอง ไม่มีการตามมาทดสอบในภายหลัง มิเช่นนั้น จะเกิดการทำงานแบบ mini-Waterfall ซึ่งไม่ควรทำอย่างเด็ดขาด !! เนื่องจาก Agile Testing เปิดเผยให้ทีม และ องค์กร เห็นถึงสถานะของการทดสอบระบบว่าเป็นอย่างไร โดยที่ Agile tester นั้นจะช่วยยกปัญหาต่าง ๆ ของการทดสอบระบบขึ้นมา เพื่อให้ทีมรับรู้ และให้ทีมช่วยกันคิดวิธีแก้ไข เพื่อเรียนรู้ที่จะปรับและเปลี่ยนการทำงานให้ดีขึ้นกว่าเดิม (Make it Better) นี่มันคือ Visibility และ Transparency ของการทำงานเลยนะ ตัวอย่างเช่น ทาง Tester อาจจะยกปัญหาของการทำ manual regression test ขึ้นมา ว่าต้องใช้เวลาการทดสอบนานมาก ๆ แถมเป็นการทดสอบแบบช้ำ ๆ มากมาย ดังนั้น ทีมช่วยออกความคิดเห็นหน่อยว่า จะแก้ไขอย่างไรดี ? ซึ่งหนึ่งในวิธีการก็คือ

สร้าง Automate regression test สิ
ช่วยกันการทดสอบสิ

ไม่ว่าจะเป็นทางไหน มันดีขึ้นกว่าเดิมแน่นอน ยังไม่พอนะ ยังมีการใช้ Test Pyramid มาเพื่อ ช่วยให้ทีมพูดคุยกันว่า ในแต่ละชั้นของการทดสอบทั้ง Unit test, Functional test, UI test และ Manual Test นั้น จะทำการทดสอบเรื่องอะไรบ้าง ซึ่งทำให้แต่ละคนในทีมมีความรู้ความเข้าใจเรื่องของการทดสอบตรงกัน สุดท้ายแล้ว ไม่ใช่เพียงแค่ทำงานเสร็จเท่านั้น ไม่ใช่เพียงแค่ทดสอบเสร็จเท่านั้น แต่ยังช่วยให้เราสร้างระบบงาน หรือ product ที่แจ่ม และประสบความสำเร็จตามมาอีกด้วย

คุณล่ะ คิดอย่างไรกับ Agile Testing บ้าง ?

decorator-crowborough

ผมเคยเขียน blog อธิบายเรื่อง Defensive Programming ไว้แล้ว หนึ่งในเรื่องที่พูดไว้ก็มีหลายเรื่อง แต่มีเรื่องที่น่าสนใจก็คือ การตรวจสอบค่า NULL เราจะลดจำนวนการตรวจสอบลงได้หรือเปล่านะ ? วันนี้อ่านเจอ blog เรื่อง Why You Shouldn't Check Input Parameters for Validity อธิบายแนวทางหนึ่งของการตรวจสอบข้อมูล โดยนำแนวคิดของ Object-Oriented Programming และ Design Pattern มาใช้งาน ซึ่ง code ตัวอย่างเป็นภาษา Java ดังนั้น จึงทำการสรุปไว้ศึกษาหน่อย

ตัวอย่าง code เป็นระบบการ export file รายงาน

โดยมักจะเขียน code ใน method การ export ดังนี้ [gist id="c45429f2ec73c6ccdc33" file="Report.java"] คำอธิบาย จะเห็นได้ว่าทำการเขียน code ตรวจสอบ 2 เรื่องคือ

ตรวจสอบว่า file มันมีค่าเป็น NULL หรือไม่ ?
ตรวจสอบว่า มี file อยู่จริง ๆ หรือไม่ ?

สาเหตุที่ต้องทำการตรวจสอบ 2 ครั้ง เนื่องจาก ไม่แน่ใจว่าผู้ใช้งาน method export() นั้น ทำการส่งค่ามาหรือไม่ ? ไม่แน่ใจว่าผู้ใช้งาน method export() นั้น ทำการส่งค่าที่ถูกต้องมาหรือไม่ ? และทำให้เรามั่นใจว่า การทำงานจะไม่พังไป หรือบางครั้งอาจจะก่อให้เกิดปัญหาอย่างร้ายแรงต่อระบบอีกด้วย ซึ่งเป็นการเขียน code แบบ Defensive programming อย่างหนึ่ง ถามว่า มันไม่ดีหรืออย่างไร ? ตอบได้เลยว่า มันก็ดีนะ มันทำงานถูกต้อง แถมอ่านง่าย แถมเข้าใจง่าย

ลองมาคิดใหม่สิว่า ถ้าไม่อยากตรวจสอบค่าของ file เป็น NULL แบบตรง ๆ จะทำอย่างไรดี ?

จากบทความได้แนะนำให้ใช้ Decorator Pattern หรือ Wrapper Pattern โดยนำมาใช้เพื่อทำการตรวจสอบข้อมูลแทนซะเลย ถ้าอธิบายง่าย ๆ คือ การสร้าง wrapper class ขึ้นมานั่นเอง แสดงการทำงานดังรูป Screen Shot 2559-02-19 at 9.20.39 PM

ซึ่งสามารถเขียน code ใหม่ได้ดังนี้ [gist id="c45429f2ec73c6ccdc33" file="NewReport.java"] ส่วนการเรียกใช้งาน ก็ทำการเรียกใช้งานแบบ composition โดยเริ่มจาก class NotNullReport หรือ Decorator class นั่นเอง ไม่ต้องมานั่งเขียน code ตรวจสอบกันอีกต่อไป เนื่องจากเราทำการซ่อนการทำงานไว้แล้วนั่นเอง ดังนี้ [gist id="c45429f2ec73c6ccdc33" file="CallReport.java"]

ผลที่ตามมาก็คืออะไรบ้าง ?

ผู้ใช้งาน Report ไม่ต้องมาตรวจสอบข้อมูลแบบยาว ๆ เยอะ ๆ อีกแล้ว จำนวน class เยอะขึ้น ซึ่ง developer หลาย ๆ คนกลัว !! สิ่งที่ได้กลับมาก็คือ ในแต่ละ class นั้นมีขนาดเล็ก ง่ายต่อการดูแลรักษามากขึ้น รวมทั้งเปิดโอกาสให้เราทำการ reuse code ได้ง่ายขึ้น สังเกตุได้จาก class DefaultReport มันคือ class หลักสำหรับขั้นตอน export file ซึ่งมี code เฉพาะการ export file เท่านั้น !! และนี่คืออีกวิธีการหนึ่งในการตรวจสอบข้อมูลที่น่าสนใจ ลองฝึกฝน และ ใช้งานกันดูครับ มันสนุกดีนะ

automation

จาก Course The Whole Team Approach to Agile Testing ที่สิงคโปร์ มีสิ่งที่น่าสนใจมากมาย หนึ่งในนั้นคือ

เรื่องอุปสรรคที่มักพบเจอจากการนำเอา Automate Test เข้ามาประยุกต์ใช้งาน

ดังนั้น ก่อนจะนำเอา Automate Test มาใช้งาน ลองกลับมาดูตัวเราเอง ทีม และ องค์กร ว่า มีอะไรที่อาจจะเป็นอุปสรรคบ้าง ?

1. เรื่องทัศนคติของ Programmer

คำถามที่ Programmer จะถาม หรือ คิดอยู่ในใจคือ ทำไมต้อง Automate ด้วยล่ะ ? มีทีม Tester/QA ทำหน้าที่ทดสอบอยู่แล้วมิใช่หรือ ? มี function ตั้งเยอะ ทดสอบได้ไง !! ถ้าขั้นตอนการพัฒนาเป็นแบบเดิม ต้องใช้เวลานานมากกว่าจะทำการทดสอบ และกว่าจะได้ผลการทดสอบกลับมายัง programmer ก็นาน ส่งผลให้การแก้ไขช้าไปอีก !! ดังนั้น เราจึงตัดสินใจกันว่า จะไปแก้ไขใน release ต่อไปล่ะกัน !! หรือ Programmer บางคนดีขึ้นมาหน่อย ทำการทดสอบ code ของตัวเอง ด้วยการนำแนวคิด Test-Driven Development (TDD) มาใช้งาน แต่ก็สนใจเพียงการทดสอบในระดับ Unit test โดยไม่ได้สนใจการทดสอบระดับที่สูงกว่า หรือ ภาพใหญ่ เช่น Functional test และ Acceptance test อีก ดังนั้น สิ่งที่ต้องแก้ไข และ ปรับปรุงก็คือ การให้ความรู้เรื่องความสำคัญของ Automate test การให้ความรู้ความเข้าใจของ Automate test แก่ programmer ซะ อย่าเพียงแต่สั่ง สั่ง สั่ง และ สั่ง

2. เรื่องของ Learning curve ที่สูง และ น่ากลัว !!

เนื่องจากการทดสอบมันคือเรื่องที่ยาก ยิ่ง Automate test มันยากยิ่งกว่า ยิ่งถ้าต้องทำให้มันดี มีประโยชน์ มันจึงยากกว่ามากมาย ซึ่งกว่าจะได้ผลลัพธ์ที่ต้องการ ต้องลงทุนทั้งแรง ทั้งเวลา และ เงิน โดยแสดง Learning curve ของการเรียนรู้ Automate test ด้วย Hump of Pain hump-of-pain

อธิบายว่า หลาย ๆ ทีมมักจะต้องใช้ความพยายามอย่างมากในช่วงแรก สำหรับการนำ Automate test มาใช้งาน ตัวอย่างเช่น ต้องเรียนรู้ TDD, Refactoring รวมทั้งเลือกเครื่องมือ แน่นอนว่า มันยากมาก ๆ ดังนั้น ถ้าทีมขาดความรู้ในเรื่องต่าง ๆ จำเป็นต้องให้เวลาในการเรียนรู้ จำเป็นต้องได้รับการสนับสนุนฝ่าย management หรือไม่เช่นนั้นก็ต้องหาผู้เชี่ยวชาญมาช่วย เมื่อความรู้ในเรื่องต่าง ๆ ของ Automate test เริ่มดี และมีความเชี่ยวชาญในวิธีการ และ เครื่องมือแล้ว ทุก ๆ อย่างมันจะดีขึ้นตามลำดับ

ดังนั้น การลงทุนในช่วงเริ่มต้นจึงมีความสำคัญอย่างมาก

ลองดูสิว่า ทีมของคุณอยู่ตรงไหน ?

3. เพราะว่า Code มันเปลี่ยนแปลงบ่อย การทดสอบมันจึงไร้ประโยชน์

สำหรับ code ในส่วนการสร้าง User Interface นั้น เป็นส่วนที่มีการเปลี่ยนแปลงบ่อยมาก ๆ ดังนั้นการสร้าง Automate test สำหรับ User Interface มันจึงไร้ค่าอย่างมาก คำถามว่า ต้องทำอย่างไรดีล่ะ ? คำตอบคือ การนำ Automate tool พวก record and playback มาใช้น่าจะเหมาะสมกว่ามาก ส่วน code ในส่วนอื่น ๆ ที่ทำงานอยู่หลัง User Interface ควรออกแบบและเขียนให้สามารถทดสอบได้ง่าย รวมทั้ง programmer และ tester ต้องทำงานด้วยกันนะ

4. ทำงานกับ Legacy code มันยากนะ !!

แน่นอนว่ามันยากมาก ๆ แต่สิ่งที่ต้องการอย่างมากสำหรับทีมคือ เวลาในการเรียนรู้ ความเข้าใจจากฝ่าย management เนื่องจาก Legacy code นั้น มันไม่ได้ถูกสร้างมาให้ทดสอบง่ายเลย ไม่ว่าจะเป็น unit test และ functional test ดังนั้น สิ่งที่ต้องการอย่างมาก คือ เวลาในการทำความเข้าใจการทำงาน เวลาในการ refactor code เพื่อให้ทดสอบได้ง่าย ดังนั้น ต้องให้ความรู้เรื่องต่าง ๆ ให้ทั้ง programmer, tester และฝ่าย management

ไม่เช่นนั้น จะไม่มีใครใส่ใจกับ Legacy code เลย ทั้ง ๆ ที่มันสร้างรายได้ให้กับองค์กร !!

5. ความกลัวต่อ Automate test

เนื่องจากมันคือของใหม่ ! Programmer อาจจะเขียน production code ได้อย่างดี แต่ไม่มีประสบการณ์ในการเขียน Automate test เลย Tester แน่นอนว่ามีความรู้พื้นฐานเรื่องของ programming ไม่มาก อาจจะไม่เชื่อใจ ไว้ใจ การทำงานของ Automate test อีก ยิ่ง Tester บางคนที่ไม่มีความรู้เรื่อง programming เลย ก็มักจะบอกว่า ตัวเองไม่พร้อมหรอกนะ แต่ในความเป็นจริง แล้วมันไม่เกี่ยวเลยนะ

แต่ปัญหาเรื่อง Automate test นั้น มันคือ ปัญหาของทีม ไม่ใช่ปัญหาของใครคนใดคนหนึ่งนะ

Tester ก็ทำในสิ่งที่ตนเองถนัด นั่นคือ การทดสอบ และ สอนแนวคิดการทดสอบให้ programmer สิ นั่นคือ ทำงานร่วมกันไปเลย หรือ pair programming กันซะ มันก็ช่วยทำให้ทุกอย่างดีขึ้นกว่าเดิมแล้วนะ เมื่อใดก็ตามที่เกิดความกลัว อย่าเดิน หรือ ทำเพียงคนเดียว แต่ให้ทำกันเป็นทีม

6. เรื่องของนิสัยเดิม ๆ ที่ชอบทำกัน !!

เมื่อใดก็ตาม ที่เราเผชิญกับคำว่า Deadline เรามักนำนิสัยเดิม ๆ หรือ ความคิดเดิม ๆ มาใช้ นั่นคือ การละทิ้งทุกสิ่งทุกอย่างที่เรามองว่าไม่จำเป็น หนึ่งในนั้นคือ ไม่เขียน Automate test และทำการทดสอบแบบ manual test ไปเลย และเรามักใช้เวลาทดสอบนาน พร้อมด้วยความหวังว่า มันจะดี มันจะทำงานได้อย่างถูกต้อง และค่อยกลับไปสร้าง Automate test ตามหลัง (Later is Never) หรือถ้าทำแล้วก็ยังไม่ทัน ดังนั้น ก็ลดจำนวน feature หรือลดคุณค่าที่จะส่งมอบให้ทาง business ก็แล้วกัน และเราก็จะทำแบบนี้ไปทุก ๆ รอบของการทำงาน ไปเรื่อย ๆ แล้วเราก็จะได้ข้อสรุปว่า มันก็เหมือนเดิมนะ !! โดยผลที่ออกมา มันก็แย่เหมือนกับที่เคยทำมานั่นเอง !!

adam-grant-give-and-take

ในการเรียนรู้สิ่งใหม่ ๆ เราทุกคนเชื่อว่า มันยากเสมอ ซึ่งมันก็ยากจริง ๆ ยิ่งเป็น Developer แล้ว มีเรื่องให้ศึกษามากมาย เช่น แนวคิดในการเขียนโปรแกรมแบบใหม่ ๆ เช่น Functional programming ภาษาโปรแกรมใหม่ ๆ ที่ได้รับความนิยม เช่น JavaScript แน่นอนว่า เราทุกคนทำการเรียนรู้ด้วยการอ่าน และ ทำตาม พวกเอกสาร, tutorial และ course ต่าง ๆ แต่เชื่อเถอะว่า มันยังมีบางสิ่งที่ยังขาดหายไป หนึ่งในนั้น คือ การสอนผู้อื่น ซึ่งมันคือ สิ่งที่บอกได้ว่าคุณเรียนรู้ได้ดีเพียงใด รวมทั้งช่วยปรับปรุงความสามารถที่การสื่อสารกับผู้อื่นอีก

ผมมีความเชื่อว่า ถ้าเราอยากปรับปรุงการเรียนรู้ของตัวเราเอง

เราจำเป็นต้องสอน หรือ แบ่งปันเรื่องนั้นไปให้คนอื่น ๆ ด้วย และมันยังเป็นเส้นทาง ที่ช่วยทำให้เราสามารถเรียนรู้ได้อย่างรวดเร็ว ที่ช่วยทำให้เราสามารถจะเชี่ยวชาญได้อย่างรวดเร็ว แต่ข้อเสียของการสอนคือ ต้องใช้เวลานาน ทำให้คุณไม่สามารถสอน และ แบ่งปันในทุกเรื่องไม่ได้ แต่เราสามารถเลือกเรื่องที่มันสำคัญกับตัวเราเอง และเรื่องที่เราต้องการจะใช้มันจริง ๆ

จากประสบการณ์ในการสอน เรามักจะพบเจอปัญหาที่แปลก ๆ เสมอ

ตอนที่เราศึกษาอาจจะเจอปัญหาไม่มากเท่าไร หรือบางคนอาจจะพบเจอปัญหามากมาย !!

แต่เมื่อคุณลองมาสอน มักจะพบเจอ ปัญหาที่แปลกประหลาด ปัญหาที่คุณไม่เคยเจอ ปัญหาที่คุณไม่สามารถแก้ไขได้

โดยปัญหาเหล่านี้ มันจะช่วยทำให้เราหยุดคิด เพื่อหาทางแก้ไข หรือ ผ่านมันไปให้ได้ ด้วยการหยุดคิด และ เริ่มคิดแบบมีขั้นตอนเล็ก ๆ ไปเรื่อย ๆ เพื่อให้เรา และ คนเรียนเห็นภาพที่ชัดยิ่งขึ้น และมันทำให้เราเห็นข้อผิดพลาด รวมทั้งให้เห็นขั้นตอนการสอน ว่ามีความผิดพลาดอย่างไร ข้าม หรือ ลัดขั้นตอนอะไรไปบ้าง จากนั้น เราก็ลงมือแก้ไขมันซะ

ดังนั้น กระบวนการสอน มันจึงเป็นกระบวนการที่ต้องปรับปรุงอยู่อย่างเสมอ

เนื่องจากในการสอนช่วงแรก ๆ เราไม่รู้ว่าต้องสอนอย่างไร ? เราไม่รู้ว่าสอนไปแล้ว คนเรียนจะรู้เรื่องหรือไม่ ? แต่สิ่งที่ทำได้ คือ เตรียมตัวให้มากที่สุดเท่าที่จะทำได้ ในทุกขั้นตอนนั้น ให้ลองถามกับตัวเองว่า เข้าใจหรือไม่ ? คิดว่า แต่ละขั้นตอนจะเกิดปัญหาอะไรบ้าง ? คิดว่า แต่ละขั้นตอนมันชัดเจนหรือไม่ ? และให้เชื่อเถอะว่า สิ่งที่เราสอนออกไปนั้น มันต้องมีประโยชน์บ้างแหละ อย่างน้อยก็ต่อตัวคุณเอง ^_^

สิ่งที่คุณทำได้ คือ ปรับปรุงการเรียนรู้ให้ดีขึ้น ปรับปรุงการสอนให้ดีขึ้น

ดังนั้น ถ้าอยากสอนที่เรารู้ให้แก่ผู้อื่น สามารถเริ่มทำได้ดังนี้

เริ่มง่าย ๆ ด้วยการเขียน blog, tutorial และ guildline ต่าง ๆ
ทำการแบ่งปันความรู้ต่าง ๆ ให้กับทีมของคุณ
ทำการแบ่งปันความรู้ต่าง ๆ บน open source project
ทำการบันทึก podcast, vdo สั้น ๆ เพื่อแบ่งปันให้กับผู้อื่น
ไปพูดตามงาน meetup และ conference ต่าง ๆ เมื่อมีโอกาส

สุดท้ายแล้ว ถ้าต้องการพูด และ สอนให้ดี

เราจำเป็นต้องพูดคุยกับคนให้ดีก่อน !!

เมื่อทำการสอน สิ่งที่มีค่าอย่างมากคือ คำถามจากผู้เรียน

เนื่องจากผู้เรียนมักจะมีประสบการณ์ในเรื่องนั้น น้อยกว่าผู้สอน ดังนั้น คำถามจากผู้เรียน ช่วยทำให้ผู้สอน เข้าใจเรื่องนั้น ๆ ดีขึ้น รู้ว่ายังขาดความรู้ในเรื่องอะไรบ้าง รวมทั้ง วิธีการแก้ไขปัญหาต่าง ๆ จากผู้เรียนอีกด้วย อย่าลืมว่า ยิ่งให้คุณยิ่งได้รับ

วันนี้คุณแบ่งปันความรู้ให้ผู้อื่นแล้วหรือยัง ?

code-coverage

สำหรับ developer ที่เขียน automated test ในระดับ unit test บางคนอาจจะบอกว่า ถ้าค่าของ Code Coverage มันต่ำ แสดงว่า ควรที่จะเขียน test เพิ่มเติม ซึ่งเป็นสิ่งที่ถูกต้องแล้ว แต่ยังไม่ครบ !! ถ้าค่าของ Code Coverage สูงล่ะ มันบอกอะไรเราบ้าง ? มันบอกว่า จำนวน test เพียงพอแล้วหรือ ? มันบอกว่า test ที่เขียนไปนั้นถูกต้องแล้วหรือ ? บอกได้เลยว่า มันไม่ได้บอกเราเลย มันเป็นเพียงการ execute code จาก test เท่านั้นเอง มันไม่ได้บ่งบอกถึง คุณภาพ มันไม่ได้ทำการตรวจสอบว่า เรากำลังทำในสิ่งที่ถูกต้องอยู่หรือไม่ !!

ดังนั้นสิ่งที่เราขาดไป ก็คือ สิ่งที่จะช่วยบอกเราว่า จุดไหนของ test ที่มันไม่ดี

โครงสร้างที่ดีของ test มีหลายแนวคิด เช่น แนวคิดของคุณ Gerard Meszaros

ประกอบไปด้วย 4 ขั้นตอน ดังนี้

การ setup
การ execute code จาก test
การตรวจสอบพฤติกรรม และ ผลการทำงาน
ทำการคืนสถานะต่าง ๆ ของระบบกลับสู่สภาวะเดิมก่อนทำการทดสอบ

คำถาม เราสามารถเขียน test โดยให้มีค่า Code Coverage 100% แบบง่าย ๆ ได้อย่างไร ? คำตอบ ก็ทำการเขียน test โดยไม่ต้องทำขั้นตอนที่ 3 ไงล่ะ นั่นคือ ไม่ต้องทำการตรวจสอบพฤติกรรม และ ผลการทำงาน แต่เราก็ไม่รู้หรอกนะ ว่า ระบบทำงานถูกต้องหรือไม่ !! ถ้า developer คนไหนทำแบบนี้ ขอบอกเลยว่า ใจร้ายสุด ๆ น่าจะเน้นไปที่ KPI หรือ ค่า Code Coverage สูง ๆ เพียงอย่างเดียว

มาดูตัวอย่างการเขียน test แบบง่าย ๆ กันดีกว่า

[gist id="135c238e25c52735634d" file="MyOperationTest.java"] จากตัวอย่างการทดสอบ ถ้า method operation() มันมีค่าความซับซ้อนเท่ากับ 3 แล้ว จำนวน test 3 test case มันก็สมเหตุสมผล ซึ่งน่าจะเพียงพอสำหรับการทดสอบ และ เพิ่มความมั่นใจให้เรา ตลอดจน เรื่องของ Code Coverage แต่ถ้า method operation() มันทำงานร่วมกับระบบอื่น ๆ อีกล่ะ แน่นอนว่า การทดสอบเพียง 3 test case มันย่อมไม่เพียงพอ เนื่องจาก เราจะยังไม่ตรวจสอบพฤติกรรมการทำงาน เมื่อต้องทำงานกับระบบอื่น ๆ เลยนะ ว่ายังคงทำงานได้ถูกต้องตามที่คาดหวังหรือไม่

สุดท้ายแล้วค่า Code Coverage หรือ Matrix ต่าง ๆ มันสำคัญนะ

แต่ว่ามันมีความสำคัญเท่ากับ ความเข้าใจต่อ Code Coverage ว่าอะไรคือสิ่งที่ต้องทำบ้าง ? ว่าอะไรคือสิ่งที่ไม่จำเป็นต้องทำบ้าง ? อย่าไปสนใจเพียงจำนวน Line of Code ที่ถูกทดสอบ แต่ให้คิดว่า

เราจะรู้ได้อย่างไร ว่าแต่ละงานมันเสร็จแล้วนะ
การทดสอบมันเพียงพอแล้วหรือยัง ?
ให้ทีมตัดสินใจร่วมกันว่า จำนวน coverage มันเพียงพอหรือยัง ?
ให้คำนึงถึงเรื่องความเสี่ยงต่าง ๆ โดยเฉพาะความเสี่ยงของเหตุการณ์ที่อาจจะเกิดขึ้นกับลูกค้า
ครอบคลุมการทำงานอย่างน้อยทุก ๆ feature แล้วหรือยัง ? (Minimal Feature Coverage)

มันหมายความว่า คุณในฐานะ developer ให้ความสนใจ ใส่ใจต่อสิ่งที่กำลังสร้างมาก หรือ น้อยเพียงใด

ปล. ผมเคยเขียนอธิบายเรื่อง Code Coveage หรือ Test Coverage ไว้ที่ blog เรื่อง Test Coverage สูงๆ มันดีจริงหรือไม่ Reference Websites http://martinfowler.com/bliki/TestCoverage.html https://dupdob.wordpress.com/2014/02/21/the-secret-for-100-test-coverage-remove-code/ http://www.renaissancesoftware.net/blog/archives/273 http://stackoverflow.com/questions/90002/what-is-a-reasonable-code-coverage-for-unit-tests-and-why

test-matrix

จาก Course The Whole Team Approach to Agile Testing ที่สิงคโปร์ มีการอธิบายถึงที่มาที่ไปของ Agile Testing Quadrant มีการอธิบายถึงเป้าหมายหลักของ Agile Testing Quadrant มีการอธิบายถึงการใช้งานที่ถูกต้องของ Agile Testing Quadrant ดังนั้น เรามาดูรายละเอียดในแต่ละข้อกันดูนะ

ที่มาที่ไป และ การใช้งานของ Agile Testing Quadrant

มาจาก Agile Testing Direction Matrix ของคุณ Brian Marick ดังรูป test-matrix

โดยในแต่ละช่อง แต่ละสี จะเรียกว่า Quadrant ประกอบไปด้วย 4 ส่วนที่จำเป็นดังนี้

Technology facing ต้องรู้จัก และ เข้าใจเทคโนโลยี
Support Programming ต้องทำการเขียน code ในการทดสอบ
Business facing ต้องเข้าใจเรื่องของ business domain
Critique product

ใช้สำหรับการตัดสินใจ และ แบ่งกลุ่มกลุ่มการทดสอบ

โดยในฝั่งซ้าย สำหรับการป้องกัน หรือ prevent เพื่อไม่ให้เกิดข้อผิดพลาด ส่วนด้ายขวา สำหรับการค้นหา หรือ detect ข้อผิดพลาด

ซึ่งถือว่าเป็นหัวใจอย่างหนึ่งของ Agile Testing แสดงดังรูป Agile-Testing-Quadrants

การใช้งาน Agile Testing Quadrant

ไม่ได้เรียงลำดับตาม Q1, Q2, Q3 และ Q4 แบบ Waterfall นะ เนื่องจากมีไว้เพื่อแบ่ง และ ตัดสินใจว่า การทดสอบแต่ละชนิดควรจะอยู่ตรงไหน

เพื่อทำให้ทีม มีความรู้ความเข้าใจเกี่ยวกับการทดสอบที่ตรงกัน

ตัวอย่างเช่น ใน Q1 นั้นจะหมายถึง การทดสอบที่จำเป็นต้องมีความรู้ความเข้าใจเทคโนโลยี และต้องการการเขียน code อีกด้วย ที่ผ่านมาพบว่า แต่ระบบงานส่วนใหญ่มักจะเริ่มที่ Q2 เพราะว่า ส่วนใหญ่แล้วเรามักจะเริ่มคุยกันที่ specification + example ของแต่ละ feature จากนั้นจึงเริ่มด้วยการคิดว่าจะทดสอบกันอย่างไร ? และลงมือเขียน code ต่อไป แต่ก็มีบางระบบงานที่ต้องเริ่มจาก Q4 เช่น Performance testing เนื่องจากต้องทำการทดสอบว่า สถาปัตยกรรมของระบบงานนั้น มันรองรับการใช้งานตามความต้องการหรือไม่ ? ซึ่งเป็นเป้าหมายที่สำคัญมากของระบบงาน อีกส่วนหนึ่งที่อาจจะเข้าใจผิดก็คือ Q3 และ Q4 ต้องเขียน code ด้วยนะ เนื่องจากรูป Agile Testing Quadrant นั้นไม่ได้บอกว่าต้องเขียน code แต่ในการทำงานจริง ๆ แล้วต้องการการเขียน code บ้าง เช่นการ deploy แบบอัตโนมัติ เพื่อทำให้ทีมได้รับ feedback จากการทดสอบท่ีรวดเร็ว ของแต่ละการเปลี่ยนแปลง

สุดท้ายแล้ว Agile Testing Quadrant นั้น

มันเป็นเครื่องมือช่วย ให้ทีมเข้าใจตรงกันเกี่ยวกับการวางแผน ให้ทีมเข้าใจตรงกันเกี่ยวกับการทดสอบ ให้ทีมเข้าใจว่า ต้องทำอะไรบ้าง เพื่อให้การพัฒนาระบบงานประสบความสำเร็จ โดยที่แต่ละ Quadrant ไม่ได้มีกฎตายตัวอะไร

แต่เน้นให้ทีมคิดก่อนว่า ในแต่ละ release ต้องทำอะไรบ้าง ในแต่ละรอบทำงานต้องทำอะไรบ้าง ในการแวางแผนต้องวางแผนอะไรบ้าง หนึ่งในนั้น คือ คิดก่อนว่าจะต้องทำการทดสอบอะไรบ้าง ?

มาถึงตรงนี้ น่าจะทำให้เข้าใจเกี่ยวกับ Agile Testing Quadrant มากขึ้นแล้ว

junit5

เมื่อประมาณปลายปี 2015 ทีมพัฒนาได้เปิดตัวโปรเจค JUnit Lambda โดยในปัจจุบันได้เปลี่ยนชื่อมาเป็น JUnit 5 และได้ทำการเปิด alpha version ในเดือนกุมภาพันธ์นี้เอง ดังนั้น Java Developer มาทำความรู้จัก และ คุ้นเคยกับมันหน่อย

JUnit เป็น test library สำหรับการเขียน test ด้วยภาษา Java

ส่วน Unit 5 นั้น มีเป้าหมายเพื่อทำให้การเขียน test ง่าย และ สะดวกยิ่งขึ้น โดย feature ใหม่ ๆ จะทำงานได้บน Java 8 ขึ้นไปเท่านั้น แต่ยังสามารถทำงานร่วมกับ version ต่ำกว่านั้นได้นะ (Backward compattability)

มาลองใช้งาน JUnit 5 กันดีกว่า

โดยตอนนี้เป็น Alpha version ซึ่ง deploy ไว้ที่ Sonatype snapshots repository โดยแบ่งเป็น library ย่อย ๆ ทำให้ผู้ใช้งานสะดวกมากขึ้น แต่ก็แลกมาด้วยการศึกษา และ เรียนรู้เพิ่มเติมเช่นกัน ดังนี้

junit-commoms
junit-console
junit-engine-api
junit-gradle
junit-launcher
junit4-engine
junit4-runner
junit5-api
junit5-engine
surefire-junit5

ตัวอย่างของการเขียน test ด้วย JUnit 5 โดยจะเป็น Apache Maven project ซึ่งในไฟล์ pom.xml เป็นดังนี้ [gist id="b8b85155e80c031fa8b4" file="pom.xml"]

จากนั้นเริ่มเขียน test กันเลยดีกว่า

ซึ่งจะเขียนในรูปแบบเดิม แต่สิ่งที่เปลี่ยนไปคือ package ที่ใช้งานจะเป็น org.junit.gen5 ทำให้ไม่เกิดข้อขัดแย้ง หรือ ตีกับ JUnit 4 นั่นแสดงว่า ทีมพัฒนาก็ยังคิดถึงผู้ใช้งานอยู่นะ

โดย code เป็นดังนี้ [gist id="b8b85155e80c031fa8b4" file="HelloWorldTest.java"] ทำการ run test ด้วย Apache Maven ด้วยคำสั่ง [code]$mvn clean test[/code] แต่จากการเขียนแบบแรกนี้ จะไม่สามารถใช้ใน IDE ได้ !! เนื่องจาก IDE ส่วนใหญ่ยังไม่สนับสนุน ดังนั้น ถ้าต้องการให้สามารถ run ได้ใน IDE แนะนำให้ใช้ RunWith annotation เข้าไปด้วย โดย code เป็นดังนี้ [gist id="b8b85155e80c031fa8b4" file="HelloWorldTestRunWithJUnit5.java"] แต่ก็ยังมี Bug อยู่อีก !! นั่นคือ ใน IDE ไม่สามารถเลือก run test case ที่ต้องการได้ ซึ่งต้องรอให้ IDE ต่าง ๆ สนับสนุน JUnit 5 ก่อน แสดง Error ดังรูป โดยผมใช้ IntelliJ IDE Screen Shot 2559-02-24 at 11.30.12 AM

มีบาง feature ที่เพิ่มเข้ามา และ เปลี่ยนไป

ยกตัวอย่างเช่น เปลี่ยนจาก BeforeClass และ AfterClass annotation เป็น BeforeAll และ AfterAll เปลี่ยนจาก Before และ After annotation เป็น BeforeEach และ AfterEach ซึ่งผมคิดว่า ชื่อมันสื่อสารถึงหน้าที่การทำงานได้ชัดเจนขึ้นนะ Tag และ Tags annotation มีไว้เพื่อแบ่งกลุ่มของ test ซึ่งใน JUnit 4 จะใช้งาน Categories นั่นเอง Screen Shot 2559-02-24 at 11.41.03 AM

Disabled annotation สำหรับข้าม หรือ ไม่ทดสอบ Test และ Test case ซึ่งใน JUnit 4 ใช้งาน Ignore Screen Shot 2559-02-24 at 11.43.29 AM

สามารถแก้ไขชื่อของ Test และ Test case ด้วย DisplayName annotation Screen Shot 2559-02-24 at 11.51.03 AM

รวมทั้งในส่วนของ Assertion นั้น สามารถใช้งาน Java 8 Lambda ได้อีกด้วย เยอะใช้ได้เลยนะ !!

ส่วนเรื่องของ Compatability หรือ ความเข้ากันได้กับ version เก่า ๆ

ตอบได้เลยว่า ยังคงทำงานร่วมกับ version เก่า ๆ ได้ รวมทั้งสามารถทำงานร่วมกับ library อื่น ๆ ได้เช่นเดิม ยกตัวอย่างเช่น Mockito และ Hamcrest เป็นต้น

สุดท้ายแล้ว JUnit 5 มันกำลังมา

สำหรับ Java Developer ควรทำความรู้จัก และ คุ้นเคยกับมันได้แล้วนะครับ อ่านเอกสารเพิ่มเติมได้ที่ JUnit 5 documentation สามารถดูตัวอย่าง source code ทั้งหมดได้ที่ Github::Up1::JUnit5-Demo Reference Websites http://junit.org/junit-lambda.html http://junit-team.github.io/junit5/ https://dzone.com/articles/junit-5-setup https://github.com/CodeFX-org/demo-junit-5 http://blog.codefx.org/libraries/junit-lambda-prototype/

Screen Shot 2559-02-25 at 9.33.25 PM

จากบทความเรื่อง The RedMonk Programming Language Rankings: January 2016 จึงนำมาแปลบางส่วนที่น่าสนใจ ข้อมูลหลัก ๆ ในการวิเคราะห์จาก Github.com และ StackOverflow.com เพื่อทำการดูว่าภาษาโปรแกรมอะไรที่ได้รับความนิยมทั้งในปัจจุบัน และ อนาคต ดังนั้นมาดูว่าภาษาโปรแกรมไหนมีความนิยมอย่างไร รวมทั้งผลการวิเคราะห์ที่น่าสนใจ

ใน 10 อันดับแรกนั้น ยังคงไม่มีการเปลี่ยนแปลงมากนัก

เนื่องจากไม่มีภาษาโปรแกรมใหม่ ๆ เลย ดังนี้

JavaScript
Java
PHP
Python
C#
C++
Ruby
CSS
C
Objective-C

คำอธิบาย JavaScript และ Java ยังคงได้รับความนิยมสูงสุดเช่นเดิมอย่างยาวนาน นั่นคงบ่งบอกได้อย่างชัดเจนว่า เป็นภาษาโปรแกรมที่ developer ทุกคนควรมีไว้ติดตัว เพราะว่า แต่ละภาษาโปรแกรมก็มีข้อดีและข้อเสีย และความเหมาะสมตามแต่ละระบบงานไป ส่วนอันดับอื่น ๆ นั้น ไม่ได้เปลี่ยนแปลงอะไรมากนัก แสดงว่า ภาษาใหม่ ๆ ยังไม่ค่อยได้รับความนิยมในกลุ่มใหญ่ หรือใช้อยู่ในกลุ่มเล็ก ๆ และ เฉพาะทางเท่านั้น ถ้าลองไปดูจำนวนภาษาโปรแกรม มันจะเยอะมาก ๆ แต่ไม่ได้ติดอันดับเลย นั่นหมายความว่า ภาษาโปรแกรมใหม่ ๆ มันเกิดมาเฉพาะงานมากขึ้น !! ซึ่งเป็นแนวโน้มต่อไปในอนาคตอย่างแน่นอน

แต่ก็มีภาษาโปรแกรมที่น่าจะก้าวเข้ามาใน 10 อันดับแรกในไม่ช้า คือ Go และ Swift

แสดงดังรูป

ส่วนภาษาที่น่าจับตามองมาก ๆ มีดังนี้

Elixir
Julia
Rust
Swift
Typescript

ปิดท้ายด้วยกราฟข้อมูลตั้งแต่ปี 2012 จนถึงปัจจุบัน

codemania11

วันนี้มีโอกาสไปแบ่งปันในงาน Code Mania 11 :: Raise the bar จัดโดยสมาคมโปรแกรมเมอร์ไทย โดยพูดเรื่อง บุกป่าฝ่าดงอีฟฟฟ เพื่ออธิบายวิธีการปรับปรุง code ที่มันยุ่งเหยิงให้ดีขึ้น รวมทั้งความรู้ต่าง ๆ ที่ได้รับกลับมา จึงทำการสรุปไว้นิดหน่อย

เริ่มจากสิ่งที่ได้แบ่งปัน คือ บุกป่าฝ่าดงอีฟฟฟ

เป้าหมายของการพูดครั้งนี้ คือ

มิใช่บอกว่าห้ามใช้ if/else หรือ switch/case แต่เราจะจัดการอย่างไรดี ให้แก้ไขง่าย
เริ่มต้นที่ mindset ที่มีต่อ Legacy code และ code ที่มันยุ่งเหยิงใหม่ซะ นั่นคือ ถ้าเห็นว่าไม่ดี ให้ลงมือแก้ไขให้ดีขึ้น

เริ่มต้นด้วยการนำ code รูปแบบต่าง ๆ ซึ่งข้อมูลมาจาก blog เรื่อง ว่าด้วยเรื่อง ป่าดงอีฟ

จากนั้นทำการอธิบายขั้นตอนการจัดการกับ Legacy code

โดยเริ่มจากทำความเข้าใจ code เหล่านั้นเสียก่อน แต่โชคไม่ดีที่ code เหล่านั้น มันยุ่งเหยิง และ ซับซ้อนเหลือเกิน แล้วเราจะทำอย่างไรดีล่ะ ? ปล. code เหล่านี้มันทำงานถูกต้องตาม requirement นะ !! สิ่งที่แนะนำ คือ ถ้าอยากเข้าใจ Legacy code ให้ทำดังนี้ เริ่มด้วยต้องรู้ว่า code ในปัจจุบันเป็นอย่างไรบ้าง ในเชิงตัวเลขที่จับต้องได้ ซึ่งผมแนะนำให้ใช้ SonarQube เพื่อวิเคราะห์ code จะทำให้รู้ว่า code เป็นอย่างไรบ้าง เช่น

มี Line of Code เท่าไร
มีความซับซ้อนของ class, method เท่าไร
มี code smell ตรงไหนบ้าง เช่นพวก Magic Number, Magic String, Issue ต่าง ๆ และ Duplication code เป็นต้น

มาถึงตรงนี้เราจะได้ค่าตัวเลขเริ่มต้น เพื่อเอาไว้ใช้วัดผลหลังจากการแก้ไข ว่าการแก้ไขมันช่วยอะไรเราหรือไม่ อย่างไร

จากนั้น เริ่มทำความเข้าใจการทำงานของ code

ด้วยการเขียนชุดการทดสอบ (Test cases) ซึ่งแต่ละ test case ประกอบไปด้วย Input และ Expected result หรือ ผลลัพธ์ที่คาดหวัง หรือค่า Example สำหรับการทดสอบนั่นเอง ยังไม่พอนะ เพื่อเพิ่มความมั่นใจ และ น่าเชื่อถือของ test case ต้องทำการวัดค่าของ Test coverage หรือ ตัวเลขที่บอกว่า test case ทั้งหมดมันครอบคลุม production code มากน้อยเพียงใด โดยจาก demo ของผมนั้น เขียน test case ไปจนกว่า Test coverage = 100% เครื่องมือที่ใช้ตรวจสอบคือ Cobertura ซึ่งชุดการทดสอบมันมีข้อดีคือ

ขจัดความกลัว
ทำให้รู้ว่าอาจจะมีบาง feature ที่ไม่เสร็จ !!

ขั้นตอนต่อมา ก็เข้าสู่การแก้ไข code หรือ Refactor code กัน

เนื่องจากเราได้สร้างความมั่นใจ และ ขจัดความกลัวจากการแก้ไขไปแล้วนั่นเอง โดยแนะนำให้ทำแบบ step-by-step หรือตามกลุ่มการทำงานจาก test case นั่นเอง ให้เริ่ม refactor code ไปทีละกลุ่ม ซึ่งแนวคิดที่ใช้คือ

แยกออกมาเป็น method เล็ก ๆ (Extract to new method) หลังจากการแก้ไขแล้ว อย่าลืม run test case ทั้งหมดนะครับ !!

ผลที่ได้คือ สามารถลดค่าความซับซ้อนของแต่ละ method จาก 19 ไปเป็น 4 รวมทั้งทำให้เราเห็น code ที่อาจจะ duplicate ได้ง่ายอีกด้วย นี่เป็นหนึ่งในแนวคิด ของการแบ่งการทำงานเป็นส่วนเล็ก ๆ แน่นอนว่า มันดีกว่า method ขนาดใหญ่แน่นอน !!

ตามจริงมันยังไม่จบนะครับ เนื่องจาก เราต้องแก้ไข duplication code อีก !!

Slide เรื่อง บุกป่าฝ่าดงอีฟฟฟฟฟ

[slideshare id=58787251&doc=if-if-if-if-160227081304&w=640&h=480] ส่วน Source code ทั้งหมดอยู่ที่ Github::Kata GildedRose โดยแบ่งออกเป็น 3 branch ตามขั้นตอน ดังนี้

01_legacy_code เป็น code เริ่มต้น ซึ่งไม่มีชุดของการทดสอบ
02_add_testcases เป็น code ที่เพิ่มชุดการทดสอบเข้ามา ซึ่งมีค่า test coverage 100%
03_refactor_to_small_method เป็น code ที่ทำการ refactoring ด้วยการสร้าง method ใหม่

สิ่งที่ได้รับจากงาน Code Mania 11 มีดังนี้

ช่วงเช้าไม่ค่อยได้ฟังเท่าไร เนื่องจากเผา slide อยู่ !! แต่ก็แอบฟังเป็นบางช่วง ที่ได้ยินประโยคแจ่ม ๆ เช่น

ถ้าเราหลีกเลี่ยงปัญหาใดปัญหาหนึ่งไม่ได้แล้ว ก็ต้องควบคุมมันให้ได้
ใช้ของที่ทีมมีความรู้ความเข้าใจจะดีกว่า
ถ้าวิธีการใหม่ ๆ มันดี แต่ไม่ได้ทำให้ business ดีขึ้น หรือ ไม่มีความจำเป็นต้องทำ ก็ไม่ต้องทำ

ส่วนในช่วงบ่ายหลังจากพูดเสร็จ ก็พยายามหาห้องที่พูดเรื่อง Spark แต่กว่าจะหาเจอก็ถึง slide หน้าสุดท้าย

สรุปได้ว่า Big Data + Spark = คู่จิ้นฟินเวอร์

จากนั้นเข้าไปฟังเรื่อง Building and Maintaining Open-source Project ซึ่งทำให้เห็นแนวคิด มุมมองของคนพัฒนา Opensource project ว่ามันไม่ธรรมดาจริง ๆ ทั้งเรื่องของโครงสร้างของ community ทั้งเรื่องการแก้ไขข้อขัดแย้งต่าง ๆ ทั้งเรื่องของการขยาย community ทั้งเรื่องจรรยาบรรณ ทั้งเรื่องขั้นตอนการทำงาน และ พัฒนา เป็นเรื่องที่มีคุณค่าต่อผมอย่างมาก มันเปิดโลก เปิดกะโหลกของผมอย่างมากมาย มีประโยคที่สำคัญมาก ๆ คือ

Technology doesn't make the better world. People do !!

ปิดท้ายด้วยการเข้าฟังเรื่อง Functional Reactive Programming โดยใน session นี้มันใหม่สำหรับผมอย่างมาก ซึ่งทำให้เห็นมุมมองต่าง ๆ ของ Functional programming และต่อจากนั้นตามมาด้วย Reactive ได้รับฟังถึง keyword ต่าง ๆ มากมาย อาจจะทำให้ใครหลาย ๆ คนธาตุไฟเข้าแทรกได้ !! ตัวอย่างเช่น Iterator vs Observer pattern รวมทั้งมี resource ต่าง ๆ ให้ไปดูเพิ่มเติมมากมาย เช่น

มีประโยคที่น่าคิด คือ Everything is a Stream

สุดท้ายขอขอบคุณทีมจัดงาน Code Mania 11

ที่จัดงานดี ๆ สนุก ๆ ครับ แถมให้โอกาสได้ไปแบ่งปัน และ เก็บความรู้อีก ครั้งหน้าเจอกันใหม่ครับ ปล. ทีมงานเขาเอา VDO ทั้งหมดขึ้น youtube แล้วนะ เร็วมาก ๆ https://www.youtube.com/watch?v=PxGDIBwzSFE

docker-swift

หลังจากที่ Swift เปลี่ยนมาเป็น Opensource แล้ว ซึ่งทำให้สามารถนำไปใช้งานได้หลาย platform เปิดโอกาสให้นักพัฒนาทั้งหลายศึกษา และ นำไปใช้งานได้ง่ายขึ้น แต่ถ้าติดตั้งเอง มันก็ดูจะเหนื่อยนิดหน่อย ดังนั้น จึงทำการติดตั้งบน Docker ดีกว่า น่าจะสะดวก และ ลดปัญหาเรื่อง dependency ต่าง ๆ ไปได้เยอะ เมื่อไปค้นหาใน Docker Hub ก็เจอ SwiftDocker จึงลองนำมาใช้งานนิดหน่อย และทำการสรุปขั้นตอนการใช้งานไว้ดังนี้

1. เพื่อความง่ายต่อการใช้งานก็สร้าง Dockerfile ขึ้นมาดังนี้

[gist id="6aee94e7c275bc2867d9" file="Dockerfile"] คำอธิบาย ทำการ map path ชื่อว่า src ใช้สำหรับเก็บ file ที่เขียนด้วยภาษา swift

2. สร้าง image ขึ้นมาจาก Dockerfile ของเรา

ตัวอย่างสร้าง image ชื่อว่า swift [code] $docker build -t swift ./ [/code] ผลการทำงานเป็นดังนี้ [code] Step 1 : FROM swiftdocker/swift:latest ---> 42c6e7564143 Step 2 : ADD src /src ---> Using cache ---> f15185a5cb7a Successfully built f15185a5cb7a [/code] แต่ถ้าไม่มี image swiftdocker/swift:latest ก็จะทำการ download จาก Docker Hub ให้เอง ซึ่งใช้เวลานานพอสมควร !! สามารถทำการตรวจสอบ image ว่าถูกสร้างขึ้นมาจริงหรือไม่ ด้วยคำสั่ง [code] $docker images swift [/code]

3. สร้าง container ขึ้นมาจาก image ชื่อว่า swift และเข้าไปใช้งาน

ด้วยคำสั่ง [code] $docker run -it swift /bin/bash [/code] เมื่อเข้ามายัง container แล้ว ทำการตรวจสอบ version ของ swift หน่อยสิ [code] $swift -version [/code] ผลการทำงานเป็นดังนี้ [code] Swift version 3.0-dev (LLVM b361b0fc05, Clang 11493b0f62, Swift fc261045a5) Target: x86_64-unknown-linux-gnu [/code] จากนั้นให้ทำการ run โปรแกรมที่เขียนด้วยภาษา swift ใน container ด้วยคำสั่ง [code] $swift src/fibonacci.swift [/code] เพียงเท่านี้ เราก็สามารถติดตั้งและใช้งาน รวมทั้งการพัฒนาโปรแกรมด้วยภาษา swift ได้แล้ว สะดวกดีจริง ๆ ด้วยนะ ตัวอย่างของ sourcecode ต่าง ๆ อยู่ที่ Github::Demo docker swift

ในปัจจุบัน community ของภาษา Swift เติบโตอย่างรวดเร็ว

รวมทั้งหลาย ๆ บริษัทก็เริ่มนำเอา Swift ไปทดลองใช้งานแล้ว แม้แต่ในฝั่ง Server ก็นำไปใช้งานเช่นกัน ดังนั้น ควรศึกษาเพิ่มเติมกันได้แล้ว Reference Websites https://hub.docker.com/r/swiftdocker/swift/ https://github.com/swiftdocker/docker-swift https://developer.ibm.com/swift/2015/12/15/running-swift-within-docker/ https://developer.ibm.com/swift/2016/02/22/building-end-end-cloud-apps-using-swift-kitura/ https://github.com/IBM-Swift/Kitura