cc :: somkiat

Screen Shot 2559-01-01 at 9.45.34 PM

อ่านบทความเรื่อง Scrum does not work here in Asia แล้วพบว่ามีประเด็นต่าง ๆ ที่น่าสนใจอย่างมาก สำหรับการนำเอา Agile และ Scrum มาปรับใช้งาน ว่าทำไมบริษัทส่วนใหญ่ในเอเชียถึงไม่ค่อยประสบความสำเร็จ โดยเฉพาะองค์กรใหญ่ที่มีอายุเยอะ ๆ มาเริ่มกันเลย

ใช้ได้ดี เฉพาะในส่วนของการพัฒนา software เท่านั้น !!

ส่วนฝ่าย management ยังคงทำงานในรูปแบบเดิม ๆ อยู่ เนื่องจากมีความใจผิด ๆ ว่ามันใช้กับการพัฒนา software เท่านั้น ไม่ได้เกี่ยวข้องกับส่วนอื่น ๆ เลย !! รวมไปถึงวัฒนธรรมของคนเอเชียด้วย ซึ่งมันขัดแย้งกับแนวทางของ Agile และ Scrum อย่างมาก ทำให้ฝ่าย management มักจะต่อต้าน การนำเอา Agile และ Scrum มาใช้งาน แต่ก็ยังมีบริษัทในเอเชียบางส่วน ที่ประสบความสำเร็จในการนำมาใช้งาน โดยบริษัทเหล่านั้นมักจะมีคุณสมบัติดังนี้

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

ทางผู้เขียนสรุปเกี่ยวกับ Asian culture ไว้อย่างน่าสนใจดังนี้

บริษัทส่วนใหญ่นั้นจะมีโครงสร้างเป็นลำดับชั้นที่ลึกมาก ๆ

โดยมี programmer อยู่ล่างสุด !! แน่นอนว่าเงินเดือนก็ต่ำสุดนั่นเอง นี่เป็นสาเหตุหลักที่ทำให้คนทำงานส่วนใหญ่ ไม่เคยฝันอยากจะเป็น programmer กันเลย !! และมันทำให้ programmer ส่วนใหญ่เฉื่อยชา ไม่กระตือรือล้นมากนัก ดังนั้น ถ้ามีปัญหาอะไร มักจะถามว่าต้องทำอย่างไรเสมอ ดังจะเห็นได้ตามใน community เกี่ยวกับ Agile/Scrum ว่า คนในเอเชียจะถามเกี่ยวกับ career path ของ Scrum Master, Developer ใน Agile/Scrum เยอะมาก ๆ บ่อยครั้งที่เข้าใจว่า Scrum Master คือ Manager นั่นเอง บ่อยครั้งที่เรามี Product Owner ที่ไร้ซึ่งอำนาจในการตัดสินใจ บ่อยครั้งที่เรามี Product Owner ที่ไม่สามารถควบคุมอะไรได้เลย บ่อยครั้งที่เรามี Product Owner ที่ไม่เคยว่าง หรือ ยุ่งมากเสมอ และไม่สามารถทำงานกับทีมพัฒนาได้

คนในเอเชียชอบประนีประนอม ไม่ชอบความขัดแย้ง

มักจะหลีกเลี่ยงข้อขัดแย้ง หรือ ปัญหาต่าง ๆ อยู่เสมอ ถามว่าผิดไหม ตอบได้เลยว่าไม่ผิด แต่ว่ามันตรงข้ามกับทางฝั่งตะวันตก ที่ไม่กลัวความขัดแย้ง ไม่ว่าจะระหว่างหัวหน้ากับลูกน้องก็ตาม จากนิสัย หรือ พฤติกรรมแบบดังนี้ ทำให้มันกระทบ และ ขัดแย้งกับแนวทางของ Agile/Scrum อย่างมาก เช่น ใน Sprint Retrospective มันจะน่าเบื่ออย่างมาก เนื่องจากแต่ละคนในทีม จะบอกว่าใน Sprint ที่ผ่านมากไม่มีปัญหาอะไรเลย !! แต่เมื่อมีใครสักคนหนึ่ง พูดถึงปัญหาขึ้นมาแล้ว คนอื่น ๆ มักจะพูด หรือ โยนปัญหาต่าง ๆ มาอีกมากมาย ใน Sprint Planning นั้น มักจะเป็นการนั่งฟัง จากคนที่มีอำนาจสูงสุด หรือเสียงดังสุดเท่านั้น ไม่มีข้อมูล หรือ รายละเอียดอะไร ไม่มีการต่อรองใด ๆ ทั้งสิ้น ซึ่งมันไม่ต่างอะไรกับการทำงานเช่นเดิม ตาม Waterfall เลยนะ !! ใน Sprint Review นั้น จะเป็นการ demo ระบบแบบทางเดียว และการ update สถานะของ project ให้ฝ่าย management เท่านั้น

นี่มันคือการทำงานเช่นเดิมนะเนี่ย !! เพียงแค่เปลี่ยนชื่อของการประชุมหรือเปล่านะ ?

ต่อมาคือ เรื่องของระบบการศึกษา

มันเป็นเรื่องละเอียดอ่อนจริง ๆ จึงสรุปด้วยประโยคนี้ดีกว่า

Asian education system is all about high grades and ranks, not about experimenting, self-discovery and making mistakes, which is what Agility is all about.

นั่นคือการระบบศึกษาในเอเชียส่วนใหญ่ มันตรงข้าม และ เป็นอุปสรรคต่อ Agile/Scrum ทั้งนั้นเลย ไม่ว่าจะเป็น

การทดลอง
การเรียนรู้จากความผิดพลาด

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

Educating Asian about self-organisation and self-discovery means undoing what people have been taught in school and university for almost sixteen years.

สิ่งสุดท้ายที่มันโดนใจมาก ๆ คือ Outsourcing !!

พูดได้เลยว่า เอเชียคือสวรรค์ของธุรกิจ Outsourcing กันเลยทีเดียว เป็นอุปสรรคที่สำคัญของการนำ Agile/Scrum มาปรับใช้งานเลย ทำไมล่ะ ? เนื่องจากบริษัทในยุโรป อเมริกา นั้น ทำการ outsource งานไปยัง เอเชีย เพื่อลดค่าใช้จ่าย แต่ในความเป็นจริง มันคือการเพิ่ม cost !! นั่นคือ การลดค่าใช้จ่ายสำหรับการพัฒนา ไม่ได้หมายความว่า การสร้างวัฒนธรรมแบบ Agile/Scrum มันจะถูกนะ ดังนั้น การจะสร้างทีมที่แจ่ม ๆ การจะสร้างนักพัฒนาที่แจ่ม ๆ มันไม่ถูกเลยนะ มันคงไม่ใช่เพียงส่งไปเรียน ไปสอบนะ หลาย ๆ คนคิดว่า Scrum มันคือวิธีการหนึ่งของ project management !! เพียงแค่นำ framework มาใช้งานเลย ไม่ต้องใช้ความพยายามอะไรมาก แล้วทุกสิ่งอย่างมันจะถูกแก้ไข และ ดีขึ้นมาเอง ซึ่งผิดอย่างมากมาย !!

คำถาม คุณคิดว่าในประเทศไทยมีปัญหาตามบทความนี้หรือไม่ อย่างไร ?

Screen Shot 2559-01-02 at 9.20.14 AM

วันนี้มีคนถามว่า ในการพัฒนา Mobile application นั้นควรเลือกภาษาอะไรดี ? ถ้าให้ตอบง่าย ๆ แบบว่าถนัดสุด ๆ ก็คงเป็นภาษา Java สำหรับการพัฒนา Android application นั่นเอง แต่คิดว่ายังมีภาษาอื่น ๆ ที่ได้รับความนิยมอีกนะ ดังนั้นมาดูกันว่ามีภาษาอะไรบ้าง

1. Java

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

2. HTML 5

ถ้าต้องการพัฒนาระบบ web สำหรับทำงานบน mobile ได้อย่างดี แนะนำ HTML 5 เลยครับ ถ้าใครไม่รู้จักถือว่าแย่มาก ๆ แต่ปัญหาของ HTML 5 คือ เรื่องของ standard นั่นเอง ทำให้การพัฒนา และ การรองรับจาก browser ต่าง ๆ เป็นไปอย่างเชื่องช้า และ หลากหลายลีลามาก แต่ในปัจจุบันมันก็ก้าวเข้ามาเป็นสิ่งที่จำเป็น สำหรับ web developer ไปอย่างหลีกเลี่ยงไม่ได้นะ แน่นอนว่ายังรวมไปถึง CSS และ JavaScript อีกด้วย !!

3. Objective-C และ Swift

ถ้าต้องการพัฒนา iOS application แล้ว ภาษา Objective-C และ Swift คงเป็นภาษาหลัก และ ภาษารองตามลำดับ ในปัจจุบันภาษา Swift กำลังก้าวเข้ามาแทนที่ Objective-C แบบช้า ๆ แล้วนะ และสามารถ shared library จาก Objective-C มาใช้ได้ ส่วนตัวผมชอบภาษา Swift มากกว่า เนื่องจากมันมีรูปแบบ และ โครงสร้างของภาษาที่เข้าใจได้ง่ายกว่า แต่ library ต่าง ๆ ยังคงน้อยอยู่ เมื่อเทียบกับ Objective-C

4. C++

ถ้าคุณต้องการพัฒนา Mobile application ที่ทำงานร่วมกับ hardware เพื่อเพิ่มประสิทธิภาพการทำงานแล้ว ทั้ง Android และ Windows phone แนะนำภาษา C++ เลยครับ เป็นภาษาที่ทรงประสิทธิภาพในการทำงานสุด ๆ แต่ก็ต้องแลกมาด้วยความพยายามด้วยเช่นกัน

5. C#

มาถึงการพัฒนา application สำหรับ Windows phone บ้าง ซึ่งอาจจะไม่ค่อยได้รับความนิมยมมากนัก แต่ก็ยังมีอยู่ในตลาดของ Mobile อยู่ ซึ่งเราสามารถพัฒนาด้วยภาษา C# เป็นภาษาที่ดี และ เสถียร เลยนะ

สุดท้ายแล้ว

ไม่ว่าคุณจะเลือกพัฒนา Mobile application ด้วยภาษาโปรแกรมอะไรก็ตาม สิ่งที่หลาย ๆ บริษัท สิ่งที่หลาย ๆ ทีม สิ่งที่หลาย ๆ คน ตามหาก็คือ คนที่รู้ และ เข้าใจ รวมทั้งสามารถพัฒนา application ได้อย่างมีคุณภาพ ปล. เลือกภาษาโปรแกรมให้เหมาะสมกับงานกันด้วยนะครับ

big-hero-six-e1415145924663

Hero Driven Development มันเป็นอย่างไร ?

อาจจะเรียกว่า Fire Fighting อาจจะเรียกว่า Dragon Slayer อาจจะเรียกว่า Strong code ownership อาจจะเรียกว่า 10x Developer เป็นคนที่เก่งมากกว่าคนปกติ สามารถเขียน code ได้มากกว่าค่าเฉลี่ย ทุก ๆ บริษัทชอบที่จะจ้างคนเหล่านี้ เพราะว่าคนเหล่านี้สามารถทำงานได้ทุกอย่าง เพราะว่าคนเหล่านี้สามารถทำงานได้ทุกที่ทุกเวลา และเชื่อว่าคนเหล่านี้แก้ไขได้ทุกอย่าง

แล้ว Hero Driven Development มันดีหรือไม่ดี ?

ลองมองกลับไปดูที่บริษัท ที่ทีม ดูสิว่า เมื่อเกิดปัญหาขึ้นมา คนที่จะถูกส่งไปแก้ไขปัญหาคือ ใครบ้าง ? คนเหล่านั้นมักจะถูกเรียกว่า Hero ( The man called Hero ) ในระหว่างการแก้ไขปัญหานั้น อาจจะมีทีมงานมานั่งด้วย เพื่อศึกษาการแก้ไขปัญหา เพื่อมานั่งดูว่า Hero เขาทำงาน และ แก้ไขอย่างไร แต่เชื่อเถอะว่า ไม่รู้เรื่องหรอกนะ ถ้ารู้เรื่องคงแก้ไขเองไปแล้ว !! เมื่อปัญหาถูกแก้ไขเสร็จแล้ว ทีมงานเดิมก็จะทำงานในรูปแบบเดิมต่อไป จนกว่าจะเจอปัญหา แล้วจะเรียก Hero เข้ามาแก้ไขอีกครั้ง และจะเป็นแบบนี้ไปเรื่อย ๆ ไม่รู้จักจบจักสิ้น !!

รูปแบบของทีมที่ต้องการ Hero เป็นอย่างไร ?

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

สาเหตุที่เราต้องการ Hero คืออะไร ?

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

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

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

แล้วจะแก้ไขปัญหาเหล่านี้อย่างไรดี ?

เริ่มต้นอย่างแรกคือ ต้องเชื่อมันในทีม (Trust) มันคือปัญหาของทีม มันคือสิ่งที่ทีมสร้างกันขึ้นมา ดังนั้นให้ทีมช่วยกันแก้ไข โดยหัวหน้า และ ฝ่าย business/management และส่วนที่เกี่ยวข้อง ต้องคอยให้ความช่วยเหลือ หรือ สนับสนุนเมื่อทีมต้องการ แต่ทีมต้องเป็นส่วนหลักในการแก้ไขปัญหา หรือเป็นเจ้าของนั่นเอง แน่นอนว่า สามารถให้ Hero เข้ามาช่วยทีมแก้ไขปัญหาได้ แต่ให้เข้ามาให้ประเมิน และ ให้ความคิดเห็นในแง่มุมของผู้เชี่ยวชาญ ส่วนการตัดสินใจ และ การแก้ไขให้ทีมจัดการ ซึ่งเป็นรูปแบบของการทำงานร่วมกัน ไม่ใช่เข้ามาเพื่อดับไฟ หรือ ให้ผ่านไปที แต่ถ้า Hero เข้ามาช่วยแก้ไขด้วยการเขียน code ก็ต้องผ่านตามขั้นตอนที่ทีมได้ตกลงกันไว้ เช่น coding standard, code review เป็นต้น หรือให้ตรงตาม Definition of Done (DoD) ไม่มีข้อยกเว้นใด ๆ ทั้งสิ้น เพื่อทำให้คนในทีมได้เรียนรู้ และ ปรับปรุงต่อไป นั่นคือกระบวนการ Inspect and Adapt นั่นเอง ลองคิดดูสิว่า ถ้าทุก ๆ คนในทีมคือ Hero มันน่าจะดีกว่ามี Hero เพียงคนเดียวที่ต้องแก้ไขทุกปัญหานะ !!

Collaboration is a key !!

Reference Website http://highlevelbits.com/2014/08/hero-driven-development.html http://scottberkun.com/2007/asshole-driven-development/ http://carlokruger.com/?p=35 http://www.alphadevx.com/a/423-Hero-driven-development

Screen Shot 2559-01-04 at 9.54.48 AM

จากหนังสือ The Developer’s Code ได้อธิบายสิ่งต่าง ๆ ที่ developer ควรทำ ซึ่งหนึ่งสิ่งที่น่าสนใจคือ ก่อนเริ่มทำงานทุกวัน ควรทำการทดสอบระบบของคุณก่อนเสมอ ยิ่งหยุดกันมาแบบยาว ๆ มันคือสิ่งแรกที่คุณต้องทำ ก่อนจะเริ่มทำงาน หรือ เริ่มเขียน code นะ จึงนำมาแปล และ สรุปนิดหน่อย

บ่อยครั้ง developer มักจำไม่ได้ว่า

เมื่อวานทำอะไรไป ? หนักกว่านั้นคือ วันนี้จะเริ่มทำอะไร ตรงไหน ?

บอกได้เลยว่า developer มักจะลืมในสิ่งที่ตัวเองทำ แต่ของคนอื่นจำได้แม่น !!

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

เมื่อเข้าช่วงบ่าย ๆ เย็น ๆ ก็ยิ่งเหนื่อยล้า

ความเหนื่อยล้านี่เอง ก่อให้เกิดความผิดพลาดเล็ก ๆ น้อย ๆ ขึ้นมา เป็นต้นเหตุของปัญหาใหญ่ ๆ ต่อไป ยิ่งทำงานยาว ๆ หรือทำ OT (Over Time) อีก ยิ่งก่อให้เกิดปัญหาใหญ่ขึ้นไปอีก แน่นอนว่า มาถึงตรงนี้ developer ไม่รู้หรอกว่าตัวเองทำอะไรไปบ้าง ทั้งการคิดและตอบคำถามต่าง ๆ ไม่ได้เลย หรือถ้าตอบได้ก็ไม่ดีเท่าที่ควร เช่น

Feature นี้ควรอยู่ที่ตรงไหนดี ?
เราควรย้าย หรือ refactor function นี้ไปยังไฟล์ หรือ class อื่น ๆ ดีไหม ?
ทำแบบนี้มันจะดีหรือไม่ ?

ถึงตรงนี้ควรกลับไปพักผ่อนเถอะนะ !!

หลังจากที่พักผ่อน และ ตื่นมาทุกอย่างมันจะดีขึ้น

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

ลองทำกันดูนะครับ มาทำการทดสอบระบบงาน ก่อนเริ่มทำงานในทุก ๆ เช้ากัน

Screen Shot 2559-01-06 at 10.31.16 AM

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

อย่าละเลยการ refactor code ด้วยการผลัดวันประกันพรุ่ง

Developer มักจะเขียน code ให้มันทำงานได้ไปก่อน Developer มักจะบอกว่า code มันดีอยู่แล้ว อย่าไปยุ่งกับมันเลย Developer มักจะบอกว่าเดี๋ยวจะกลับมาแก้ไข Developer มักจะบอกว่า ... สุดท้าย code เหล่านั้นจะเป็นอย่างไร ? น่าคิดนะ

มาดูตัวอย่างจากหนังสือ Refactoring กันหน่อย

ต้องการสร้างระบบคำนวณเงินโบนัสของพนักงานแต่ละแผนก ซึ่งบริษัทนี้มีเพียง 2 แผนก คือ IT กับ Sales เท่านั้น โดยแต่ละแผนกก็มีการคำนวณที่แตกต่างกันไปตามจำนวนปีของการทำงาน ดังนั้นเมื่อเข้าใจความต้องการแล้ว Developer ก็จะลงมือเขียน code ทันที ดังนี้ [gist id="b84d756ac75738677dac" file="BonusCalculator.java"] แน่นอนว่า code ชุดนี้มันสามารถทำงานได้อย่างถูกต้องตามความต้องการ เพียงแค่โยน employee เข้ามาเท่านั้นเอง ดังนั้นงานเราเสร็จแล้ว !!

แต่เดี๋ยวก่อนนะ !!

บางคนอาจจะบอกว่า ถ้ามีแผนกอื่นเพิ่มเข้ามา code ชุดนี้มันน่าจะเพิ่มยากนะ ดังนั้นลองปรับ code ให้มันอ่านง่าย ๆ สวย ๆ หน่อยไหม ? ด้วยการเปลี่ยนจาก if-else ไปเป็น switch-case ซึ่งเป็นการ refactoring แบบเล็ก ๆ เพื่อให้ developer คนอื่น ๆ อ่านง่าย เข้าใจง่าย เขียน code ได้ดังนี้ [gist id="b84d756ac75738677dac" file="BonusCalculator2.java"]

แต่เดี๋ยวก่อนนะ !! ต่อมาบริษัทมีแผนกเพิ่มเข้ามาเป็น 10 แผนก จะทำอย่างไรดี ?

คำถาม Developer จะยังคงใช้ switch-case ต่อไปอีกไหม ? คำตอบ สำหรับ developer ส่วนใหญ่ก็จะบอกว่าใช่แล้ว ใช้ต่อไป เนื่องจาก code ก่อนหน้ามันเป็นแบบนี้ เนื่องจาก code มันเป็น standard ของเรา อย่าไปแก้ไข เนื่องจาก code มันยังทำงานได้ดีอยู่ ดังนั้น code ที่ได้ออกมาจึงเป็นดังนี้ [gist id="b84d756ac75738677dac" file="BonusCalculator3.java"] คำถาม Code ชุดนี้คุณคิดว่ามันดีแล้วหรือ ? คำตอบ ใช่แล้ว code ชุดนี้มันดี และ ทำงานได้อย่างถูกต้องด้วย แต่ Develoepr ลองมาดูกันหน่อยไหมว่า code ชุดนี้มันมีความซับซ้อนมากน้อยเพียงใด ? ตอบได้เลยว่า มาก แล้วยังจะทำกันแบบนี้อีกหรือไง ? ดังนั้น มันน่าจะได้เวลาของการ refactor code ก่อนที่จะเพิ่มการคำนวณ bonus ของแผนกอื่น ๆ ถ้าปล่อยไว้มันจะกลายเป็น Legacy code ที่ใคร ๆ ก็ไม่อยากแตะต้อง !! มันน่ากลัวมาก ๆ เลยนะ มันจะนำมาสู่ปัญหา มันจะนำมาสู่ความปวดหัว มันจะนำไปสู่หายนะ ในการดูแลรักษาต่อไป กลับมาที่ code กันหน่อย เราจะทำการ refactoring อย่างไรดีล่ะ ? มาถึงตรงนี้เราพบแล้วว่า code มันเกิดรูปแบบการทำงานซ้ำ ๆ แตกต่างเพียงแค่ logic ของการคำนวณโบนัสเท่านั้น นั่นคือ ความต้องการของเรา ตรงนี้แหละ เราสามารถนำเอาความรู้เกี่ยวกับ design pattern มาประยุกต์ใช้ได้ เพื่อนำมาแก้ไขปัญหาตามที่เราต้องการ มันน่าดูเข้าท่าเข้าทางกว่าเยอะนะ ซึ่งผมแนะนำให้อ่านหนังสือ Refactoring to Patterns เพื่อทำให้เข้าใจในการนำ design pattern มาประยุกต์เพื่อใช้งาน โดยตัวอย่างนี้เราสามารถนำเอา Design pattern มาใช้ได้ แต่ว่าทำอย่างไรล่ะ ? เช่น Strategy pattern, Template Method pattern เป็นต้น ตัวอย่างของ Strategy pattern เราจะทำการแยกส่วนการคำนวณโบนัสของแต่ละแผนกออกจากกัน รูปแบบการทำงานจะเหมือนกัน มาดู code ดีกว่า [gist id="b84d756ac75738677dac" file="CalculationStrategy.java"] จากนี้ต่อไป ก็ทำการสร้างการคำนวณของแต่ละแผนกต่อไป จะแยกออกจากกันอย่างชัดเจน ทำให้ง่าย และ สะดวกต่อการจัดการทั้ง การเปลี่ยนแปลงสูตรการคำนวณ การเพิ่ม และ ลบ แผนก รวมถึงอ่าน และ ทำความเข้าใจได้ง่ายกว่าเดิม และแน่นอนว่า ความซับซ้อนของระบบน้อยลงไป แต่ข้อเสียก็คือ จำนวนไฟล์ และ class เยอะขึ้น ซึ่ง developer หลาย ๆ คนกลัว

จงกลัว code ที่หนึ่งไฟล์มี code หลายร้อย หลายพันบรรทัด !!

ข้อควรจำสำหรับการนำ design pattern มาใช้คือ

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

ถ้าคุณจะหา Best Practice สำหรับปัญหานั้นปัญหานี้ บอกได้เลยว่า มันไม่มีหรอกนะครับ มีแต่เหมาะสม และ ทำให้ code ดีขึ้นเท่านั้นเอง และที่สำคัญคือ คนในทีมเข้าใจไหม ?

slide3_bg1

ในการพัฒนา software ถ้าถาม developer ว่า ใช้เวลาส่วนใหญ่ทำอะไร ? ส่วนใหญ่น่าจะตอบว่า เขียน code ไงล่ะ !! แต่เมื่อลองไปนั่งสังเกตการทำงานของ developer จะพบว่าใช้เวลาส่วนมากไปกับ การพยายามทำความเข้าใจกับ code จากนั้นก็ทำการแก้ไข code เดิม ส่วนที่น้อยมาก ๆ คือ การเขียน code ใหม่เข้าไป !! แสดงดังรูป 6a0120a85dcdae970b0120a86d7477970b-pi

จากหนังสือ Implement Pattern ทำการอธิบายเกี่ยวกับค่าใช้จ่ายในการพัฒนา software ไว้ดังนี้

Total cost = develop cost + maintain cost โดยที่ maintain cost นั้นมาจาก Maintain cost = understand cost + change cost + test cost + deploy cost

Understand cost ถ้า code ที่เขียนขึ้นมามันสามารถอธิบายได้ดี เข้าใจได้ง่าย ดังนั้นน่าจะใช้ง่าย แก้ไขง่าย และลดค่าใช้จ่ายในการดูแล
Change cost ถ้าเราลดความซับซ้อน และ ซ้ำซ้อนของ code ลงไป มันก็จะทำให้เข้าใจง่าย แน่นอนว่ามันทำให้เราแก้ไขได้รวดเร็วขึ้น นั่นคือลดค่าใช้จ่ายในการดูแล
Test cost ถ้า code มันสามารถทดสอบได้ง่าย ยิ่งทดสอบได้แบบอัตโนมัติ แล้วจะลดค่าใช้จ่ายในการดูแล
Deploy cost ถ้าเราสามารถ deploy ระบบงานแบบอัตโนมัติได้ เช่นการนำแนวปฏิบัติ Continuous Delivery มาใช้แล้วจะลดค่าใช้จ่ายในการดูแล

ดังนั้นเราควรสร้างสมดุลระหว่าง develop cost และ maintain cost หรือพยายามทำให้ maintain cost ให้น้อยที่สุดเท่าที่จะทำได้ ด้วยการพัฒนา code ของระบบให้มีคุณภาพที่ดี

แต่เรากลับพบว่า code ของระบบงานส่วนใหญ่ มักจะมี maintain cost ที่สูงมาก !!

ทั้งเข้าใจได้ยาก ทั้งแก้ไขได้ยาก ทั้งทดสอบได้ยาก ทั้ง deploy ได้ยาก มันยังไงกันนะ รู้สึกแปลก ๆ กันไหม ? แสดงดังรูป maintenance_costs

และนี่คงเป็นสาเหตุว่าทำไม developer ใช้เวลาส่วนใหญ่ไปกับ การทำความเข้าใจกับ code ที่ developer เขียนขึ้นมาเอง !! คำถาม แล้วเราจะช่วยกันแก้ไขปัญหาเหล่านี้อย่างไรกันดี ?

Reference Websites http://readwrite.com/2013/04/25/how-software-developers-really-spend-their-time http://blog.codinghorror.com/when-understanding-means-rewriting/ https://github.com/cezarcoca/sonar-toxicity-chart/blob/master/README.md

Screen Shot 2559-01-08 at 9.55.36 PM

จากบทความเรื่อง To be a star programmer in 2016, learn Javascript and move to Utah เนื่องจากความต้องการ programmer ในปัจจุบันสูงขึ้นอย่างมาก และองค์กรต่าง ๆ ต้องการคนที่มีความรู้ความสามารถ หลายที่ต้องการแบบ ready to use เลย ดังนั้นจึงมีคำแนะนำสำหรับ programmer ทุกคนว่า ในปี 2016 นั้นจำเป็นต้องปรับปรุงตัวเอง เพื่อให้ได้งานที่ต้องการ มาดูว่ามีคำแนะนำดี ๆ อะไรบ้าง

1. Programmer ต้องสื่อสารด้วยภาษาคนเป็นด้วย !!

หลาย ๆ คนมักจะบ่นว่า programmer มันพูดกับใครไม่รู้เรื่อง ตอบได้เลยว่า ส่วนใหญ่จริงแท้แน่นอน ดังนั้นเพียงแค่ technical skill อย่างเดียวมันยังไม่เพียงพอสำหรับ programmer นะ ต้องมีความสามารถอื่น ๆ ด้วย เช่น

การเขียน
การอ่าน
การพูดคุยสื่อสารกับคนอื่น ๆ

ดังนั้นเรื่อง technical skill มันของแน่ที่ต้องมี และ ปรับปรุงอยู่เสมอ ส่วนเรื่องsoft skill ก็อย่าให้ขาดนะ

2. เรียนรู้การทำงานเป็นทีม

การทำงานร่วมกันเป็นทีมมันสำคัญมาก ๆ เนื่องจากระบบงานในปัจจุบันในมีความซับซ้อนสูงมาก ดังนั้น ทำเพียงคนเดียวไม่น่าจะรอด !!

3. เตรียมตัว เตรียมใจไว้สำหรับการเปลี่ยนแปลง

เรื่องของการเปลี่ยนแปลง มันคือสิ่งที่กดดัน programmer ทุกคน เพราะว่า เดี๋ยวก็เปลี่ยน เดี๋ยวก็เปลี่ยนอีก !! ดังนั้นก่อนอื่น programmer ต้อง ทำความเข้าใจก่อนว่า สิ่งที่ทำทำมันไปทำไม ? ทำความเข้าใจก่อนว่า ภาพรวมของระบบเป็นอย่างไร ? และ programmer ต้องเข้ามามีส่วนร่วมเสมอ ต้องทำการ update สิ่งที่ทำในทุก ๆ วัน ต้องแสดงสิ่งที่ทำให้คนอื่น ๆ เห็นทุกวัน เพื่อทำให้หัวหน้า และ business เห็นว่า กำลังอะไรอยู่บ้าง ? สิ่งที่สร้างมันเป็นอย่างไร ? สิ่งที่สร้างมันตรงกับ business goal หรือไม่ ? เพื่อให้พร้อมกับการเปลี่ยนแปลงอยู่อย่างเสมอ

4. อย่าไปยืดติดกับภาษาโปรแกรมใด ๆ เลือกให้เหมาะสมกับงาน

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

5. ถ้าคุณต้องการค่าตอบแทนมากขึ้น ต้องปรับปรุงความสามารถอยู่อย่างเสมอ

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

สุดท้ายโครงสร้างขององค์กรต้อง flat ให้มากที่สุด หรือ ลดลำดับชั้นที่ซับซ้อนซะ

โดยที่ management คือความสามารถที่ทุกคนต้องมี มิใช่ตำแหน่ง หรือ แผนก !! programmer ควรมีความรู้สึกเป็นเจ้าของ project ที่ได้รับมอบหมาย ถ้าทำไม่ได้ ก็ต้องเข้าไปส่วนร่วมกับทาง management เยอะขึ้น !! ยากเนาะ !!

วันนี้ programmer พร้อมแล้วหรือยัง ? ถ้ายังก็ลงมือปรับปรุงกันได้แล้วนะ

Screen Shot 2559-01-09 at 5.37.01 PM

ปัญหาหนึ่งของการพัฒนา Android application ก็คือ เวลาในการ build project ด้วย gradle มันนานมาก ๆ ยิ่ง project มีขนาดใหญ่ขึ้น ยิ่ง project มี module จำนวนมาก ยิ่ง project ใช้ library จำนวนมาก คำถามคือ จะแก้ไข หรือ ปรับปรุงอย่างไรดี ? เพื่อทำให้เวลาการ build มันต่ำลงให้ได้มากที่สุด เรามาค้นหาวิธีการไปพร้อม ๆ กันเลย

นักพัฒนาอย่างเรา ต้องเริ่มต้นด้วยการค้นหาที่ Google สิ !!

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

แต่ก่อนอื่นแนะนำให้ดูสถานะปัจจุบันของการ build ของ project ก่อนนะ

โดย Environment ที่ผมใช้ในการทดสอบคือ

Macbook Pro, RAM 8GB แบบเหลือนิดเดียว, CPU 2.4 GHz
Android Studio 2.0 Preview 4
Grade 2.8

ขั้นแรกใช้ profile มาช่วยดูเวลาการ build ในปัจจุบัน $./gradlew clean assembleDevDebug --profile และ $./gradlew assembleDevDebug --profile ข้อสังเกต

การใช้ clean task นั้นเป็นการ build from scratch เป็นการ build ใหม่ทั้งหมด
แต่ถ้าไม่ใช้ clean จะเรียกว่า incremental build สำหรับการ run ซ้ำ จะทำให้ build เร็วขึ้น ซึ่งใช้งานบ่อยกว่าสำหรับการพัฒนา

ได้ผลการทำงานดังนี้ เป็นข้อมูลที่ทุกคนควรจดบันทึก และ จดจำไว้เลย มันเป็นข้อมูลตั้งต้น ก่อนทำการปรับปรุงส่วนอื่น ๆ ปล. ให้ทำการ run อย่างน้อย 3 ครั้งนะ เพื่อทำให้มั่นใจว่าผลที่ได้มันถูกต้อง และ ใกล้เคียงกันมากที่สุด

ได้เวลาการทำงานที่แย่ที่สุด คือประมาณ 2 นาที 30 นาที ส่วนของ incremental build ใช้เวลาประมาณ 1 นาที 30 วินาที

ผลจาก Build from scratch Screen Shot 2559-01-09 at 11.59.29 AM

ผลจาก Incremental build Screen Shot 2559-01-09 at 1.07.05 PM

จากรายงานที่ได้จาก profile พบว่าการ build ประกอบไปด้วย 3 ส่วน คือ

1. Configuration โดยปกติมันจะเร็วมาก ๆ จะช้าก็คือ build.gradle มีความซับซ้อนมาก ๆ 2. Dependency Resolution จะทำการตรวจสอบ และ download dependency ต่าง ๆ ที่ใช้งาน ปกติจะดึงข้อมูลจาก cached เครื่องก่อน ถ้าไม่มีจะทำการ download ผ่าน internet ซึ่งเวลาการทำงานโดยรวมจะน้อยมาก ๆ 3. Task Execution !! เป็นส่วนที่ใช้เวลาการทำงานสูงมาก ๆ เพราะว่าใน gradle จะมีงานย่อย ๆ เยอะมาก เช่น

Compiling
Dexing
Testing

จากเวลาการทำงาน หรือ build ของระบบงานตัวอย่าง พบว่า Task Execution มันสูงที่สุด นั่นคือ ปัญหา และ เป้าหมายที่ต้องการแก้ไขต่อไป !!!

มาเริ่มปรับปรุงเวลา build project กันเลย

อย่างแรกที่ให้ลองทำการปรับ ใน gradle ทำการแนะนำมาดังนี้

This build could be faster, please consider using the Gradle Daemon: https://docs.gradle.org/2.8/userguide/gradle_daemon.html

นั่นคือเรื่องของ Gradle Daemon พูดง่าย ๆ คือ มี background process หลาย ๆ ตัวมาช่วยทำงานนั่นเอง เชิงทฤษฎีน่าจะ build ได้เร็วขึ้นสิ แน่นอนว่าใช้ RAM เพิ่มขึ้นเช่นเดียวกัน !! มาดูกันเลย ทำการกำหนดค่าในไฟล์ gradle.properties org.gradle.daemon=true หรือใส่ใน command line ได้เลย $./gradlew clean assembleDevDebug —daemon --profile จากผลการทดสอบพบว่า

Build from scratch ใช้เวลาประมาณ 1 นาที 30 - 50 วินาที หรือลดลงไป 10-15%
Incremental build ใช้เวลาประมาณ 1 นาที 15 วินาที หรือลดลงไป 5% บางครั้งไม่ได้ช่วยอะไรเลย !!

แสดงผลการ Build from scratch ดังรูป Screen Shot 2559-01-09 at 12.22.52 PM

และเรื่องอื่น ๆ ที่มักจะเขียน และ แนะนำมา เช่น

Parallel building สำหรับ multiple project
Configuration on demand สำหรับ multiple project
Offline mode
JVM arguments สำหรับ daemon

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

ข้อมูลเพิ่มเติม

ใน project มีการแยก code ออกเป็น module ย่อย ๆ แต่มันกลับทำให้การ build ช้าลงไป ซึ่งบางคนแก้ไขปัญหาด้วยการ build แบบ parallel แต่สำหรับผมจะแยกออกไปเป็น library แทนนะครับ ซึ่งลดเวลาการ build ไปได้เยอะกว่ามาก จากที่ทดสอบ และ ใช้งานจริงพบว่าลดเวลาการ build ไป 50% แต่ก็ยังทำงานช้าอยู่ดี เนื่องจากยังทำงานในระดับนาที !!

มาดู Task ใน gradle ที่ทำงานช้า ประกอบไปด้วย

transformClassesWithDex
compile
transformClassesWithMultidexlist
package
transformClassesWithJarMerging

จะลดเวลาการ build ของ task เหล่านี้อย่างไรกันดี ?

มาลองวิธีการต่อไปดีกว่า นั่นก็คือ เปลี่ยนค่า minSdkVersion เป็น 21

เป็นวิธีการเพิ่มประสิทธิภาพการ build ของ project ใหญ่ ๆ แน่นอนว่า ต้องการใช้งาน multidex แน่นอน และจะ build ช้ามาก ๆ ถ้าค่า minSdkVersion ต่ากว่า 21 เนื่องจากใน SDK 21 หรือ Lollipop ได้เปลี่ยนแปลง และ ปรับปรุงขั้นตอนการ build ใหม่ เพราะว่ามี runtime ตัวใหม่คือ ART (Android Runtime) มาแทน Dalvik ซึ่งมีผลให้การ dexing ดีขึ้น อ่านเพิ่มเติมเกี่ยวกับ multidex ได้ที่นี่ Android MultiDex ถ้าไม่เชื่อก็ลองเปลี่ยนกันหน่อยสิ ดังนั้นลองเปลี่ยนค่า minSdkVersion เป็น 21 ก่อน เพื่อความสะดวกจะกำหนดใน productFlavor dev จากนั้นลอง build ดูใหม่ ได้ผลดังนี้

Build from scratch ใช้เวลาไม่ได้แตกต่างจากเดิมสักเท่าไร
Incremental build เป็นส่วนที่เวลาลดลงไปอย่างมาก เหลือไม่ถึง 30 วินาที หรือลดลงไป 50-70% กันเลย แต่ถ้ามี memory เหลือเยอะหน่อย จะใช้เวลา build 20 วินาที !!

โดยทดลองทั้งแบบ daemon และ non-daemon ซึ่งผลต่างกันพอสมควร ซึ่งแนะนำให้ run แบบ daemon ไปเลย ปล. ต้องเตรียม RAM ให้เยอะ ๆ หน่อยนะครับ

มาดูผลการทำงาน ซึ่งได้ผลเป็นที่น่าพอใจเลยนะ Screen Shot 2559-01-09 at 4.02.50 PM

สิ่งที่เห็นได้ชัดเจนก็คือ compileDevDebugJavaWithJavac นั่นคือการ compile code JAVA ด้วย Java Compiler นั่นเอง ขั้นตอนนี้ใช้เวลาที่สูงสุด ซึ่งน่าจะลดลงได้อีกนะ !!

ยังมีวิธีการการอื่น ๆ อีกนะ เช่น

ใช้ Jack และ Jill ซึ่ง Jack ใช้สำหรับการ compile code Java ไปยัง Dex format แต่ว่ามันไม่สนับสนุน Data Binding จึงไม่ได้ทำการทดสอบ
เพิ่ม Hardware เช่น RAM จะดีต่อการ build แน่นอน
แยก code ที่ไม่ค่อยเปลี่ยนแปลง ออกไปเป็น library หรือ dependency แทน จะได้ไม่ต้องเสียเวลามา build ใหม่ ดังนั้น Small is better นะครับ
ใช้ Buck สำหรับการ build แทนไปเลย

สุดท้าย ขอเน้นย้ำว่า

ก่อนจะทำการปรับปรุงอะไรก็ตาม ควรที่จะทำการเก็บข้อมูลเริ่มต้น และ ทำ profiling ก่อนเสมอ เพื่อทำให้เรารู้สถานะเริ่มต้นของระบบ กับทำให้เรารู้ถึงปัญหา เพื่อจะทำการแก้ไขได้ตรงจุด แต่ละปัญหา ย่อมใช้วิธีการแก้ไขที่ต่างกัน (No Silver Bullet)

ดังนั้น จงหาปัญหาของตัวเองให้เจอก่อนเสมอ มิเช่นนั้น คุณจะไม่สามารถแก้ไขปัญหาได้ หรือถ้าได้ก็ไม่ตรงจุด !!

จากปัญหาที่ผมพบเจอ สามารถลดเวลาการ build แบบ incremental จาก 1 นาที 30 วินาที มาจนเหลือเวลาไม่ถึง 30 วินาที ก็น่าจะทำให้เรามีกำลังใจในการ build มากขึ้น รวมทั้งเป็นสิ่งบ่งบอกว่า เราแก้ไขปัญหามาถูกทางแล้วนะ แต่ยังต้องลดเวลาลงไปอีก เป้าหมายต่อไปคือ ต่ำกว่า 10 วินาที !!

Fast Feedback มันคือหัวใจสำคัญของการพัฒนา software นะ ขอให้สนุกกับการพัฒนา Android application ครับ

Reference Websites http://blog.octo.com/en/reduce-android-build-duration/ https://medium.com/@erikhellman/boosting-the-performance-for-gradle-in-your-android-projects-6d5f9e4580b6#.me0d9b7bm http://kevinpelgrims.com/blog/2015/06/11/speeding-up-your-gradle-builds/ http://stackoverflow.com/questions/23367769/how-to-speed-up-android-studio-compilation-process http://android-developers.blogspot.nl/2015/11/android-studio-20-preview.html http://jimulabs.com/2014/10/speeding-gradle-builds/ https://www.timroes.de/2013/09/12/speed-up-gradle/ https://docs.gradle.org/2.8/userguide/gradle_daemon.html http://gradle.org/why/high-performance-builds/ http://tools.android.com/tech-docs/new-build-system/tips

Screen Shot 2559-01-12 at 10.44.32 AM

สิ่งหนึ่งที่ได้เรียนรู้ในการพัฒนา software ที่มีคุณภาพ คือ อย่าแบ่งการพัฒนา software ออกเป็น

การพัฒนา feature
การปรับปรุงคุณภาพ

เนื่องจากมันส่งผลเสียตามมามากมาย !!

คุณสมบัติของ code ที่ยืดหยุ่นต่อการแก้ไขในอนาคต

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

อ่านเข้าใจได้ง่าย
สามารถเพิ่ม และ แก้ไขได้ง่าย โดยส่งผลกระทบน้อย
มีจำนวน test coverage ที่ดี หรือครอบคลุมส่วนการทำงานหลัก ๆ

แต่ถ้า Developer ทำการเขียน code ที่แย่ ๆ หรือ คุณภาพแย่ ๆ ออกมา

แล้วรอเวลาสำหรับกลับมาแก้ไข code เช่น หลังจากทำการ deploy ไปยัง production แล้ว สิ่งที่ต้องกลับมาทำ มักจะประกอบไปด้วย

ทำการเขียนเอกสารเพื่ออธิบาย code
เขียนชุดการทดสอบ
ทำการแก้ไข และ refactor code ในส่วนที่มันยุ่งเหยิง
ทำการ review code

แปลกดีนะ เรามักจะทำแบบนี้กัน นั่นคือ ทำให้มันเสร็จ ๆ ไปก่อน แล้วเดี๋ยวค่อยกลับมาแก้ไข ซึ่งเราก็พบอีกว่า ไม่เคยกลับมาแก้ไขเลย นั่นคือ Later is Never !!

สาเหตุที่ทำให้เราแยกกิจกรรมเกี่ยวกับคุณภาพออกมา?

ในการพัฒนา software นั้นมักจะ ได้รับความกดดันมาจากฝั่ง business ที่ต้องการให้ส่งมอบ feature ให้เร็วที่สุด เป็นงานที่ยากมาก สำหรับการต่อรองเรื่องเวลากับทาง business ว่าต้องเพิ่มเวลาสำหรับเรื่องของคุณภาพ เนื่องจากค่าใช้จ่ายมันถูกกำหนดไว้แล้ว เพิ่มไม่ได้ ลดได้อย่างเดียว !! รวมทั้งเรื่องของเวลาที่เพิ่มเข้ามานั้น มันจะช่วยเพิ่มผลประโยชน์ทาง business อย่างไร ? มันวัดยากมาก ๆ นะ !! ดังนั้นแทนที่จะทำการต่อรอง เรื่อง scope และ เวลากับทาง business ซึ่งมันยากมาก ๆ ก็มาต่อรอง หรือ ลดในส่วนของการพัฒนาดีกว่า (Technical Practices) นั่นคือ พัฒนาให้มันเสร็จ ๆ ไปก่อนนั่นเอง (Good Enough Software) !!

โดยปกติการทำงานของ developer จะมีขั้นตอนดังนี้

เขียน code เพื่อพัฒนาแต่ละ feature ให้เสร็จตามความต้องการ
ทำการ clean up code, refactor code เพื่อทำให้ code ดีขึ้น ว่าด้วยเรื่องของคุณภาพ

ซึ่งแยกออกจากกันอย่างชัดเจน แต่ในการพัฒนา software เราจะพบกับสิ่งหนึ่ง คือ Dead Line นั่นคือ เราไม่มีเวลาแล้วนะ ดังนั้นสิ่งที่ developer ส่วนใหญ่จะทำคือ การตัดเรื่องของคุณภาพออกไปไงล่ะ !! และสนใจเพียงการพัฒนาระบบตาม functional requirement โดยไม่สนใจ non-functional requirement เลยแม้แต่น้อย !!

คำถามที่น่าสนใจคือ

สิ่งที่ developer บอกว่า งานเสร็จแล้ว ในความเป็นจริงมันเสร็จจริง ๆ หรือไม่ ? เช่น

ทำการทดสอบ code ที่เขียนหรือไม่ ?
ทำการทดสอบระบบทั้งหมดหรือไม่ ว่าสิ่งที่สร้างมันกระทบระบบหรือไม่ ?
ทำ regression test หรือไม่ ?
ทำการทดสอบทุก ๆ feature ของระบบหรือไม่ ?

ถ้ายังไม่ทำแล้ว จะบอกออกมาได้อย่างไรว่า งานเสร็จแล้ว !! อย่าส่งมอบงานที่มันยังไม่เสร็จนะ

โดยสรุปแล้ว

สิ่งที่แนะนำคือ อย่าแยกการพัฒนา กับ คุณภาพออกจากกัน มันต้องเดินไปด้วยกันเสมอ ตัวอย่างเช่น Test-Driven Development (TDD) นั่นคือ เราเขียน code และเขียน test ไปด้วยกันเสมอ ส่งผลทำให้เรามั่นใจได้ว่า code ทุกส่วนที่เราเขียนมันถูกทดสอบอยู่เสมอ และแน่นอนว่า มันย่อมมีจำนวน test coverage ที่สูงด้วย

สุดท้ายขอเน้นย้ำว่า Scope ของงานนั้นตัดได้ แต่เรื่องของคุณภาพนั้น ตัดไม่ได้นะครับ

mutation-testing-pyramid-of-software-quality

จากบทความ Mutation testing and the quest for quality ทำการอธิบายถึงความแตกต่างระหว่าง Mutation testing และ Code coverage ซึ่งมีเป้าหมายเพื่อปรับปรุงคุณภาพของ software โดยมีเรื่องหนึ่งที่น่าสนใจ คือ Pyramid of Software Quality จึงนำมาสรุปไว้ดังนี้

โดยปกติแล้วผู้ใช้งานจะเห็นเพียงว่า ระบบที่ใช้งานมีคุณภาพหรือไม่

แต่เบื้องหลังของคุณภาพเหล่านั้น ยังมีอีกหลายส่วนที่มักถูกมองข้ามไป ซึ่งสามารถสรุปได้ด้วย Pyramid of Software Quality แสดงดังรูป mutation-testing-pyramid-of-software-quality

mutation-testing-pyramid-of-software-quality

จากรูปจะเห็นว่าส่วนของ Software Quality หรือ คุณภาพของ software มันคือยอดของภูเขาน้ำแข็ง ซึ่งคนทั่วไปจะเห็นเพียงส่วนนี้เท่านั้น ดังนั้นมาดูส่วนอื่น ๆ กันบ้าง

1. Code Quality หรือ คุณภาพของ code

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

2. Test Quality หรือ คุณภาพของการทดสอบ

ถ้าคุณต้องการให้คุณภาพของ code สูงแล้ว จำเป็นต้องทำการ refactor code อยู่เป็นประจำ ซึ่งคุณจะมั่นใจในการ refactor code ได้อย่างไรถ้าไม่มีการทดสอบ แน่นอนว่า manual test คงไม่พอ และ เหนื่อยเกินไป เป็นที่มาของ Automated test นั่นเอง ดังนั้นเรื่องคุณภาพของการทดสอบ จึงความสำคัญต่อ Code Quality อย่างมาก ถ้า code ส่วนไหนที่สำคัญ แต่ไม่มีชุดการทดสอบครอบคลุมแล้ว คุณควรจะสร้างชุดการทดสอบส่วนนั้นขึ้นมาซะ อย่ารอช้า !! ลงมือทำเลย

3. Mutation testing

เพื่อเพิ่มความมั่นใจว่า ชุดการทดสอบที่เราสร้างขึ้นมานั้น มันช่วยลดความผิดพลาดของ code บน production server คุณต้องมีจำนวน Mutation test coverage ที่สูงมาก ๆ

4. Craftsman programmer

มันคือพื้นฐานที่สำคัญสุด ๆ ของ Software Quality ถ้าต้องการเพิ่มคุณภาพของ software ให้สูง จำเป็นต้องทำการปรับปรุงทั้ง production code และ test code เสมอ เนื่องจากพวก test coverage ที่มันสูง ๆ ไม่ได้ตอบโจทย์อะไรเลย มันเพียงแค่บอกว่า code ส่วนไหนไม่ถูกทดสอบเท่านั้นเอง ลองคิดดูสิว่า ถ้า test code มันแย่ ถ้า production code มันแย่ แต่จำนวน test coverage มันสูง แล้วเราจะได้ code ที่อ่านยากมานะสิ แน่นอนว่า ค่าใช้จ่ายในการดูแลย่อมสูงมากมาย !!

จากหนังสือ Clean Code เขียนไว้ว่า Clean code always looks like it was written by someone who cares

คำถาม วันนี้คุณใส่ใจใน code ที่คุณเขียนหรือไม่ ?

Screen Shot 2559-01-15 at 9.53.52 AM

เมื่อวานมีโอกาสได้ไปแบ่งปันความรู้พื้นฐานเรื่อง Docker ในงาน Docker Bangkok Meetup ซึ่งจัดเป็นครั้งแรกที่ Kaidee Ofiice จึงทำการสรุปเรื่องที่แบ่งปันดังนี้ โดยจะเป็นเรื่องของการใช้งาน Docker ในมุมมองของ Developer ทั้งการทำความเข้าใจเกี่ยวกับ Container และ Docker เนื่องจากผู้เริ่มต้นมักเข้าใจว่า Docker == Container แต่สิ่งที่ถูกต้องคือ Docker มันเป็นตัวจัดการ container ซึ่งมีการจัดการหลัก ๆ เช่น

การจัดการ image

การสร้าง image เพื่อนำมา run หรือสร้าง container ต่อไป โดย image เทียบง่าย ๆ ในโลกของการเขียนโปรแกรมคือ Class ส่วน container นั่นคือ instance ของ Class ดังนั้นจาก image แต่ละตัว เราสามารถสร้างได้หลาย container นั่นเอง โดย image ต่าง ๆ จะถูกเก็บไว้ที่ DockerHub

การจัดการ application ด้วย Docker compose

โดยปกติการจัดการจะอ่านค่าจาก Dockerfile ใช้สำหรับการกำหนด environment พื้นฐานของระบบ เช่น Operating System, ภาษาโปรแกรม และ library ต่างๆ และจะมีไฟล์ .yml สำหรับกำหนด service ต่าง ๆ ของ application หรือ ทำการกำหนดโครงสร้างการทำงานของระบบนั่นเอง เช่น

Frontend
Backend
Database
Caching
Proxy

ซึ่งทำให้การใช้งาน Docker ง่าย และ สะดวกมากยิ่งขึ้น

การ provisioning เครื่องที่จะใช้ Docker จัดการด้วย Docker machine

มันคือ การสร้างเครื่อง หรือ สร้างโลกของ Docker นั่นเอง ถ้าเราไม่สร้าง จะไม่สามารถจัดการ container ผ่าน docker ได้ โดยเราสามารถกำหนดชื่อ และ ปลายทางของเครื่องได้ หรือเรียกว่า Driver เช่น

Generic
Virtual Box
Amazon Web Service

ดูข้อมูลเพิ่มเติมได้ที่ Docker Machine Driver แต่ก่อนที่จะเริ่มต้นทำอะไรกับ Docker อย่าลืมติดตั้ง Docker Toolbox นะ

ปัญหาที่ Developer มักเจอคือ Docker มันยาก มันซับซ้อน

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

เรื่องของการติดตั้ง software และ library ต่าง ๆ บนเครื่อง
เรื่องของการจัดการ dependency ของ library ต่าง ๆ
เรื่องการจัดการ version
เรื่องของการจัดการ environment ทั้ง dev, test และ production

แต่ก่อนอื่นต้องมีความรู้พื้นฐาน

แต่ก่อนอื่นต้องเข้าใจการทำงานของ Docker แต่ก่อนอื่นต้องลองผิดลองถูกจนเข้าใจ และที่สำคัญต้องเข้าใจปัญหาของตัวเองด้วย ก่อนจะนำเครื่องมือใด ๆ มาแก้ไขนะครับ สุดท้ายนี้ ขอขอบคุณพื้นที่ในการแบ่งปัน เจอกันครั้งต่อไปครับ ข้อมูลต่าง ๆ ของการแบ่งปัน Source code ตัวอย่างอยู่ที่ Github.com::Docker 101 Slide :: Docker 101 [slideshare id=57049624&doc=docker-meetup-101-160114113729&w=600&h=480]

Screen Shot 2559-01-18 at 1.16.10 PM

ช่วงนี้มีโอกาสได้ใช้ git stash ในการเก็บงานที่พัฒนาไม่เสร็จ หรือต้องการ rollback code ที่เปลี่ยนแปลงจำนวนเยอะ ๆ ซึ่งใช้คำสั่งง่าย ๆ ดังนี้


$git stash save --keep-index
$git stash drop

เพียงเท่านี้ก็ rollback code กลับไปได้แล้ว รวมทั้งนำมาใช้ร่วมกับการพัฒนาตามแนวคิด TDD (Test-Driven Development) ได้อย่างดีด้วย จึงนำมาสรุปไว้นิดหน่อย เมื่อลองไปค้นหาใน internet ก็เจอบทความเรื่องเดียวกัน คือ Git Stash-Driven Development เลยใช้เป็นตัวหลักในการอธิบายเลยดีกว่า

ขั้นตอนในการพัฒนาตามแนวคิด TDD ร่วมกับ Git เป็นดังนี้

เขียน test code ที่มัน fail (RED)
เขียน production code เพื่อทำให้ test ผ่าน (GREEN)
ทำการ commit code
ทำการ refactor code
ทำการ commit code
ทำการ push code
กลับไปยังข้อ 1

ถ้าเวลาในการทำงานแต่ละรอบ หรือ lead time น้อย ๆ แล้ว ยิ่งทำให้เราได้รับ feedback ที่เร็ว นั่นส่งผลดีอย่างมาก และสะท้อนให้เราเห็นว่า สิ่งที่เรากำลังทำมันเล็กหรือใหญ่กันแน่ นั่นคือ สอนให้รู้เรื่องการแตกงานนั่นเอง

บ่อยครั้งเมื่อเราเขียน test ใหม่แล้ว พบว่าการเขียน production code มันยากมาก !!

ดังนั้นสิ่งที่เราทำได้คือ

ทำการลบ test
ทำการ ignore test

จากนั้นทำการ commit การเปลี่ยนแปลง แล้วกลับมาทำการ refactor code ต่อ เพื่อทำให้ code มันง่าย และ พร้อมสำหรับ test ชุดใหม่ จากนั้นทำการ commit และ push code เมื่อทุกอย่างพร้อมก็ทำการเขียน test หรือ เอา ignore test ออกไป และเริ่มเขียน production code ต่อไป ซึ่งทำแบบนี้ไปเรื่อย ๆ แสดงดังรูป listening-to-the-tests

แต่ก็มีบางกรณีที่ไม่สามารถ ignore หรือ ลบ test ได้

ไม่ต้องการ commit ignore test ขึ้นไป ไม่ต้องการ commit code ที่ไม่เสร็จ ไม่ต้องการ commit code ที่ refactor ไม่เสร็จ บางครั้งต้องสลับไปพัฒนาระบบอื่น ทั้ง ๆ ที่ code ยังไม่เสร็จ สิ่งต่าง ๆ เหล่านี้ ล้วนก่อให้เกิดอันตรายอย่างมากในอนาคตอันใกล้ !! คำถาม มีวิธีการใดบ้างที่ช่วยบรรเทาความเจ็บปวดเหล่านี้ได้บ้าง ? คำตอบที่ผมได้รับกลับมาจากการลอง คือ ใช้งาน git stash ซะ เนื่องจากเราสามารถซ่อนการเปลี่ยนแปลง ที่เราไม่ต้องการ commit ได้ แต่ในการใช้งาน git stash นั้น ผมมีกฎง่าย ๆ 1 ข้อคือ ห้ามทำการ stash เกินกว่า 1 ครั้ง ไม่เช่นนั้นคุณจะซ่อนการเปลี่ยนแปลงไว้เยอะมาก ๆ

ผลที่ได้คือ การเขียน code ตามแนวคิด TDD

มันลื่นไหล หรือ flow มากยิ่งขึ้น รวมทั้งทำให้ code ที่ commit ขึ้นไป มันมีความสวยงาม และ มี code ที่จำเป็นเท่านั้น นี่คือหนึ่งวิธีการเพื่อปรับปรุงการทำงานให้ดี และ สะดวกขึ้น และเป็นการประยุกต์เครื่องมือต่าง ๆ มาช่วยแก้ไขปัญหาที่เราพบเจออยู่เป็นประจำ ซึ่งแนวคิดนี้มันคือ Git Stash-Driven Development นั่นเอง ลองนำไปใช้ดูครับ เผื่อจะมีประโยชน์บ้าง

Screen Shot 2559-01-19 at 7.20.29 PM

จากบทความเรื่อง Feature Flag-Driven Development ทำการอธิบายถึงพื้นฐาน และ ที่ไปที่มาของ feature flag ได้อย่างน่าสนใจ ตั้งแต่การนำมาใช้งานสำหรับการ rollout ระบบ ไปจนถึงการทำ A/B Testing ดังนั้น จึงนำมาแปล และ สรุปส่วนที่น่าสนใจไว้ดังนี้

ทำความรู้จักกับ Feature Flag กันก่อน

มันมีชื่อเรียกมากมาย เช่น

Feature Flag
Feature Bit
Feature Toggle
Feature Control
Feature Flipper
Feature Rollout
Feature Switch

มีเป้าหมายเพื่อควบคุมการปล่อย feature ของระบบให้ผู้ใช้งานนั่นเอง ทำให้เราสามารถจัดการ และ เลือกได้ว่า จะทำการเปิด หรือ ปิด feature อะไรบ้าง จาก component อะไรให้ลูกค้าใช้ได้บ้าง ตลอดจนสามารถไปใช้กับการเปิด feature ให้กับผู้ใช้งานบางกลุ่ม หรือการทำ A/B Testing อีกด้วย เป้าหมายหลักอีกอย่าง คือ การลดความเสี่ยงของการ rollout ระบบงาน ซึ่งเรามักชอบทำแบบ Big Bang หรือทั้งระบบ และมักพบว่า มีความผิดพลาดตามมาเยอะมาก !! ดังนั้น เราน่าจะหาวิธีการใหม่ ๆ มาแก้ไขกันดีไหม ?

แล้ว Feature Flag มันทำงานอย่างไร ?

มีขั้นตอนการทำงานดังนี้

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

แสดงดังรูป

เราจะสร้าง Feature Flag ได้อย่างไร ?

จากรูปจะเห็นว่า สถานะของ feature มันมีเพียง TRUE กับ FALSE หรือสถานะเปิด กับ ปิด เท่านั้นเอง ซึ่งพัฒนาได้ง่ายมาก ๆ แต่สิ่งที่ยากกว่ามาก ๆ คือ จะทำการออกแบบเพื่อแบ่งการทำงานของแต่ละ feature ออกจากกันได้อย่างไร ? นั่นคือ ความท้าทายของการออกแบบระบบ และเป็นหัวใจของวิธีการนี้ !! ในปัจจุบันมีเครื่องมือ และ framework ในการจัดการ Feature Flag เยอะมาก ๆ สามารถดูได้จาก

มาทำความรู้จักกับ Feature Flag Driven Development กัน

การพัฒนาด้วยแนวคิด Feature Flag นั้น จำเป็นอย่างยิ่งต้องพัฒนาด้วยแนวคิด Test-Driven Development (TDD) เนื่องจากขั้นตอนในการ rollout และ release feature ของระบบมันเร็วมาก รวมทั้งรอบการ rollout และ release feature มันบ่อยมาก ดังนั้นเราจึงต้องมีวิธีการทดสอบที่รวดเร็ว หรือสามารถรู้ความผิดพลาดได้อย่างรวดเร็ว เพื่อทำให้สามารถปรับปรุงการระบบ และ การทำงานได้อย่างรวดเร็วเช่นกัน ขั้นตอนการพัฒนาเป็นดังนี้

เพิ่ม feature flag สำหรับ feature ใหม่ และ feature ที่ต้องการเปลี่ยน
ทำการเขียน code สำหรับพัฒนา feature
ทำการ deploy และ release เพื่อวัดผล
เลือก feature ที่ได้ผลออกมาดี และ เปิด feature ที่ผลไม่ได้
ทำซ้ำ ๆ แบบนี้กับ feature ใหม่ และ feature ที่ต้องการเปลี่ยน

แนวคิดนี้ มันเป็นวิธีการเพื่อให้เราได้ feedback จากลูกค้าได้อย่างรวดเร็ว รวมทั้งทำให้เราสามารถตอบสนองต่อการเปลี่ยนแปลงได้อย่างรวดเร็วเช่นกัน

โดยรูปแบบการทำงานของ Feature Flag Driven Development เน้นที่ feedback จากลูกค้าเป็นหลัก จากนั้นทำการปรับปรุง แก้ไข และทำการ rollout/release และรับ feedback ซ้ำ ๆ แบบนี้ไปเรื่อย ๆ หรืออาจจะเรียกได้ว่า Small is Better และ Rollout at scale

ซึ่งมันจะแตกต่างจากการพัฒนาในรูปแบบเดิม แสดงดังรูป

สุดท้ายแล้ว

ลด ละ เลิก การ rollout/release ระบบแบบ Big Bang กันเถอะนะ ยังไม่พอนะ เราสามารถนำแนวคิดเหล่านี้ไปใช้กับเรื่องอื่น ๆ ได้อีกด้วย ตัวอย่างเช่น

ทำ A/B Testing
ทำการ run Beta program บน production server
ปิด หรือ ลบ feature ที่ไม่มีคนใช้ทิ้งไป
แน่นอนว่า ทำให้การ rollout feature ต่าง ๆ ของระบบทำได้ง่าย และ บ่อย นั่นคือการ scale ใช่หรือไม่
ทำการ block ผู้ใช้งานในแต่ละ feature
ใช้สำหรับการจัดการเรื่อง Subscription plan ของระบบ
จัดกลุ่ม feature ให้เหมาะกับกลุ่มผู้ใช้งาน เช่น beginner และ expert เป็นต้น
สำหรับการปิด maintenance ระบบ

Screen Shot 2559-01-21 at 11.17.18 AM

จาก Newsletter ของคุณ Sandi Metz เป็นผู้เขียนหนังสือ Practical Object-Oriented Design in Ruby (POODR) ได้อธิบายเรื่องของ Code Smell ไว้อย่างน่าสนใจ จึงได้นำมาแปล และ สรุปไว้นิดหน่อย ซึ่งอ่านแล้วมันเจ็บแสบน่าดู แต่ผมเชื่อว่า มันคือเรื่องจริงนะ !!

เรื่องของ code ที่มันยากต่อการทำความเข้าใจ และ ยากต่อการเปลี่ยนแปลง !!

มันน่าจะเป็นเรื่องปกติของ developer เกือบทุกคน ที่มักจะบอกว่า มันก็ปกตินะ ที่มักจะบอกว่า มันก็เป็นแบบนี้แหละ แต่ผมคิดว่า มันผิดปกตินะ แถมมันคือ ต้นเหตุของความวอดวายในอนาคตอีกด้วย หรือใครหลาย ๆ คนน่าจะกำลังเผชิญกับมันอยู่ก็เป็นได้ สิ่งที่น่าสนใจสำหรับ code เหล่านี้คือ มักจะมีรูปแบบคล้าย ๆ กัน (Pattern) นั่นคือ ผิดเหมือน ๆ กัน นั่นคือ ผิดซ้ำ ๆ จนมองว่า มันคือเรื่องปกติ !! โดยรูปแบบเหล่านี้ ถูกเรียกว่า Code Smell

คำถามที่เกิดขึ้นมาในหัว คือ Developer รู้และเข้าใจเกี่ยวกับ Code Smell กันบ้างไหม ?

ถ้าใครบอกว่ารู้ ช่วยบอกชื่อของ Code Smell พร้อมกับเหตุผลด้วยว่า มันมีรูปแบบอย่างไร จงยกตัวอย่าง ? ทำไมมันถึงก่อให้เกิดปัญหา ? จะทำแก้ไขปัญหาเหล่านั้นอย่างไร แบบ step-by-step ? โดยขอสัก 5 อย่างนะ ... จากประสบการณ์ที่ผ่านมา พบว่า developer ตอบได้น้อยมาก ๆ หรือ ไม่รู้นั่นเอง นั่นมันอาจจะแสดงว่า code ที่สร้างจาก developer เหล่านั้นมันคืออะไร ? ไม่ได้ระวังเรื่องของ code smell เลยใช่ไหม ? ดังนั้น ถ้าต้องการปรับปรุง code หรือ refactoring มันจะทำได้หรือ ? เพราะว่า แม้แต่ปัญหาก็ยังไม่รู้ แล้วจะแก้ไขได้อย่างไร ? สรุปแล้ว developer เขียน code อะไรกันอยู่ !!

จาก paper เรื่อง When and Why Your Code Starts to Smell Bad

เป็นการนำข้อมูลการ commit จาก opensource project กว่า 200 project มาทำการทดลอง และ วิเคราะห์ เพื่อหาว่า Code Smell เกิดขึ้นตอนไหน อย่างไร รวมทั้งได้ทำแบบสำรวจเกี่ยวกับ Code Smell พบว่า

Developer ประมาณ 32% ไม่รู้จัก Code Smell หรือรู้เพียงเล็กน้อยเท่านั้น !!

โดยสิ่งเหล่านี้ มันคือปัญหาที่ยิ่งใหญ่มาก ๆ ในการทำงานนั้น developer มักจะพบเจอ code ที่มันยุ่งเหยิง ซึ่งมักเรียกว่า Legacy code หรือ Spaghetti code แน่นอนว่า code เหล่านี้มี Code Smell มากมาย และที่สำคัญมันมี Code Smell มากกว่า 1 รูปแบบแน่นอน ดังนั้นการแก้ไขควรแก้ไขทีละปัญหาไปเรื่อย ๆ เพื่อทำให้ code เหล่านั้นดีขึ้น แต่ถ้า developer ไม่รู้ และ เข้าใจเกี่ยวกับ Code Smell เลย ผลที่ได้คือ จะเห็นแต่ปัญหาใหญ่ ๆ ซึ่งการแก้ไขมันยากมาก ๆ รวมทั้งผลกระทบก็มหาศาล แล้วใครละที่จะกล้าแก้ไข เนื่องจากผลการแก้ไขมักจะเป็นดังรูป Screen Shot 2559-01-20 at 10.37.09 PM

ดังนั้น เหนือสิ่งอื่นใด Developer ควรรู้และเข้าใจเกี่ยวกับ Code Smell ก่อน

จากนั้นจะรู้และเข้าใจ Code Smell แต่ละตัว มีรูปแบบอย่างไร ? ก่อให้เกิดปัญหาอย่างไร ? ทำการแก้ไขอย่างไร หรือ มีขั้นตอนในการ refactor code อย่างไร ? มันจะทำให้ developer สามารถเห็นปัญหา และ ปรับปรุง code ได้ง่ายขึ้น

ในปัจจุบัน developer สามารถเรียนรู้เรื่อง Code Smell ได้ง่ายขึ้นแล้วนะ

ถ้าไม่เชื่อลองเข้าไปศึกษาได้จาก

ยังไม่พอนะ ยังไม่คนแบ่งกลุ่มของ Code Smell ให้อีก ซึ่งทำให้ง่ายต่อการศึกษา และ ทำความเข้าใจอีกด้วย อยู่ที่ Code Smell Taxonomy ดังนี้

Bloaters เช่น long method และ large class (God class)
Object-Oriented Abusers เช่น Switch statement
Change preventer เช่น Divergence change
Dispensable เช่น Lazy class
Coupler เช่น Feature envy

มาถึงตรงนี้ ถ้า Developer คนไหนอ่านแล้วงง ๆ

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

คำถาม คุณต้องการปรับปรุง code ให้ดีขึ้นหรือไม่ ?

Screen Shot 2559-01-22 at 11.06.26 AM

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

แต่ส่วนมากมักจะไม่ค่อยสนใจในเรื่องนี้มากมัก !!

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

1. คุณมี Automated test ในระดับ System/Application test หรือไม่ ?

สิ่งที่ทุกระบบควรจะต้องมี คือ การทดสอบในระดับ system และ application เพื่อใช้ตรวจสอบการทำงานว่าถูกต้องตามที่คาดหวังไว้หรือไม่ ไม่ใช่มีเพียงการทดสอบในระดับ class และ method เท่านั้น ที่สำคัญต้องทำการทดสอบแบบอัตโนมัติอีกด้วย เนื่องจากเราต้องการรู้ว่า มีส่วนใดของระบบที่อาจก่อให้เกิดความเสี่ยง ทำให้เราสามารถปรับปลี่ยน และ แก้ไขได้รวดเร็ว โดยไม่กระทบ หรือ กระทบการทำงานโดยรวมน้อยที่สุด มันจะช่วยลดปัญหาและเวลาในการทำ regression test และลดผลกระทบต่าง ๆ ไปอย่างมาก

วันนี้คุณมี Automated test แล้วหรือยัง ?

2. ห้ามลืมกฎของลูกเสือ หรือ Boy Scout Rule

ท่องจำประโยคนี้ไว้ให้ขึ้นใจ และ ลงมือทำซะ

Leave the code better than you found it

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

ขอให้จำไว้ว่า ลงมือทำ มากกว่า พูด

3. Code เป็นของทุกคน ไม่ใช่เป็นของใครคนใดคนหนึ่ง หรือ ทีมใดทีมหนึ่ง

ตัวอย่างเช่น Developer A ทำการพัฒนา feature A โดยต้องไปใช้งาน Class B ซึ่งไม่เกี่ยวกับการพัฒนา feature A เลย แต่เห็นว่า Class B นั้นมันไม่ดี ต้องได้รับการปรับปรุง Developer A ควรทำอย่างไรดี ? ถ้าตอบว่า ทำไม่ได้หรอกนะ ต้องให้คน หรือ ทีมที่ดูแลแก้ไข นั่นคือ ปัญหาที่ต้องได้รับการแก้ไข มิเช่นนั้น code ที่ไม่ดี จะไม่ได้รับการปรับปรุงเลย ปัญหาเหล่านี้มันเกิดจากกลายกรณี แต่ขอให้ทำการแก้ไขเป็นกรณีไป มิเช่นนั้น จะไม่สามารถนำ Boy Scout Rule มาใช้ได้ดีเท่าที่ควร

4. ทำ Pair programming และ Code review ซะ

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

5. ตั้งคำถามกับตัวเอง หรือ ทีมว่า ทำไมต้องเขียน comment เพื่ออธิบาย code ด้วย

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

สุดท้ายแล้ว

ขอให้ Developer ทุกคนลองนำคำแนะนำทั้ง 5 ข้อนี้ ไปใช้งานดูนะครับ น่าจะช่วยทำให้จัดการ และ ทำงานกับ Technical Debt ได้ง่ายขึ้น

ดังนั้น หยุดพูด หยุดถกเถียง และ ลงมือทำกันเถอะนะ

a-dev-test-ops

ในปัจจุบันคำว่า DevOps (Development + Operation) นั้น ถูกพูด และ นำไปใช้งานกันอย่างมากมายสำหรับการพัฒนา software เพื่อทำให้การพัฒนา software เป็นไปอย่างรวดเร็ว และมีคุณภาพ ให้ตามความต้องการของผู้ใช้งานที่เปลี่ยนแปลงรวดเร็วอย่างมาก เป็นสาเหตุว่าทำไม ต้องมีระบบ Continuous Integration เช่น Jenkins, Bamboo เป็นต้น ต้องมีเครื่องมือพวก Infrastructure as Code เช่น Puppet และ Chef เป็นต้น ต้องมีเครื่องมือเกี่ยวกับ Release Automation หมายความว่า การพัฒนา software กำลังหาแนวทางและกระบวนการใหม่ ๆ เพื่อให้สนองตอบความต้องการของทาง business และ ลูกค้า ให้ได้ดี และ รวดเร็วที่สุด (Quality and Fast)

แต่ปัญหาในการพัฒนา software นั้น ไม่ใช่มีเพียงทีม Development และ Operation เท่านั้น !!

ยังมีปัญหากับทีม Testing/QA อีกด้วย แน่นอนว่ามันจึงเกิด 3 กลุ่มที่แยกออกจากกัน ส่งผลให้เกิดปัญหามากมายตามมา แต่จะขาดส่วนใดส่วนหนึ่งไม่ได้เลย แสดงดังรูป devtestops

ในความเป็นจริงแล้ว เรามักจะขาดเรื่องของ Quality กันไป

ถึงแม้จะนำแนวคิด DevOps มาประยุกต์ใช้เแล้วก็ตาม บ่อยครั้งจะพบว่า กระบวนการทดสอบจะอยู่ในช่วงท้ายของการพัฒนา ซึ่งเป็นสิ่งที่ไม่ถูกต้อง และทำการทดสอบแบบ manual เสียส่วนใหญ่อีก !! ดังนั้น เราควรปรับปลี่ยนกระบวนการพัฒนา ด้วยการนำการทดสอบไปไว้ในทุก ๆ ส่วนของการพัฒนา หรือใช้แนวคิด Test-First มาใช้ นั่นคือ คิดก่อนสิว่า จะทดสอบแต่ละส่วน แต่ละ feature กันอย่างไร ก่อนที่จะเริ่มพัฒนา จากนั้นจึงหาเครื่องมือมาช่วย ที่สำคัญการทดสอบควรจะทำงานแบบอัตโนมัติให้ได้มากที่สุดเท่าที่จะเป็นไปได้ ปล. การทดสอบไม่ใช่เพียงแค่ทดสอบในระดับ code เท่านั้น ควรทำการทดสอบในระดับ requirement ควรทำการทดสอบในระดับ infrastructure ควรทำการทดสอบในระดับ system หรือ end-to-end ควรทำการทดสอบ performance ของระบบโดยรวม

บางครั้งเราอาจจะต้องเปลี่ยนจากคำว่า DevOps ไปเป็น DevTestOps ก็เป็นได้ เรื่องคุณภาพในการพัฒนา software นั้น มันต่อรองไม่ได้นะครับ

สำหรับ Developer ความสามารถทั้งสามก็เป็นสิ่งที่ขาดไม่ได้เช่นเดียวกัน !!

Screen Shot 2559-01-24 at 3.28.10 PM

นั่งทำ slide เกี่ยวกับการทดสอบบน Android application พบว่ามีเครื่องมือ framework และ service ให้ใช้งานมากมาย บางครั้งอาจจะเยอะจนเกินไปอีกด้วย แน่นอนว่า มันยากต่อผู้เริ่มต้นอย่างแน่นอน ปล. สำหรับคนที่มีประสบการณ์มาแล้ว ยังงงเลย !! ดังนั้นจึงทำการสรุปไว้นิดหน่อย พร้อมทั้งข้อดีและข้อเสีย จากมุมมองที่เคยใช้มา เริ่มกันเลยดีกว่า

ส่วนที่ 1 :: Unit Testing

เริ่มด้วย JUnit หรือ Local Unit testing ในปัจจุบันนั้นเราสามารถทำการทดสอบในระดับ Unit Testing ด้วย JUnit ได้แล้วนะ เพื่อทดสอบการทำงานในแต่ละ class และ แต่ละ method ตลอดจนการทำงานระหว่าง class อีกด้วย เป็นการทดสอบที่ทำงานอยู่บน Java Virtual Machine (JVM) ซึ่งทำงานได้อย่างรวดเร็วที่สุด และ ง่ายที่สุด โดยการทดสอบแบบนี้ เหมาะสมกับ code ที่ไม่ได้ยืดติดกับ Android เลย ข้อเสียของ JUnit ก็คือ เราไม่สามารถใช้งาน class ต่าง ๆ ของ Android ได้โดยตรง ถ้าจะใช้งานจำเป็นต้องใช้เครื่องมือเสริม นั่นคือ Mocking framework เช่น Mockito แต่ถ้าใช้มากเกินไปก็ไม่ดีเช่นกัน ต้องระวังเรื่อง Mock Bubble ไว้ด้วย ตัวต่อมา คือ Android Testing Framework หรือ Instrument unit testing เป็น official สำหรับการทดสอบแบบ Unit testing บน Android ทำงานผ่าน Android Unit Runner ทำให้เราสามารถทำการทดสอบได้เหมือนจริง สามารถใช้งาน class ต่าง ๆ ของ Android Framework ได้โดยตรง เหมือนกับการทำงานจริง ๆ ของ Android นั่นเอง แต่การทำงานจะช้ากว่าแบบแรก เนื่องจาก ต้องทำการ compile และ upload app ไปยัง device หรือ emulator ก่อนเสมอ นั่นแสดงว่า การทดสอบด้วย Android Testing Framework ต้องต่อ device หรือ emulator ไว้เสมอนะครับ ซึ่งต่างจากแบบแรกที่ไม่ต้องใช้ อีกตัวที่มีมาก่อนทั้งสองคือ Robolectric เป็น project สำหรับการทดสอบ Android app ที่มีมาก่อนสองตัวแรก เพื่อทำให้เราสามารถทดสอบได้รวดเร็วกว่าแบบที่สอง พร้อมกับใช้งาน class ต่าง ๆ ของ Android Framework ได้ ด้วยการ mock และ stub เอาไว้ให้ก่อน แถมไม่ต้องใช้ device หรือ emulator อีกด้วย โดยทีมพัฒนาของ Robolectric นั้น active มาก แต่ข้อเสียสำคัญเลยก็คือ เอกสารที่แย่มาก ๆ เป้าหมายหลักของ Unit testing คือ

ความเร็ว
ความง่าย
ความถูกต้อง
Clean code
Code ที่ทดสอบได้ง่าย (Testable code)

แต่จะเลือกตัวไหนก็ขึ้นอยู่กับความต้องการของคุณ

ส่วนที่ 2 :: Functional Testing

ถ้าพูดให้เข้าใจง่าย ๆ คือ การทดสอบบน device หรือ emulator นั่นเอง ซึ่งถามว่ามีเยอะไหม ? ตอบได้เลยว่ามาก แต่ตัวที่เคยใช้งานจริง ๆ ประกอบไปด้วย 1. UIAutomator ของดีจากทีมพัฒนา Android จาก Google นั่นเอง สามารถทำการทดสอบ หรือ จำลองการใช้งานของผู้ใช้ตั้งแต่เปิด App ยันปิด App เอง แต่สามารถใช้งานได้กับ Jelly Bean ขึ้นไปเท่านั้น แถมการใช้งานไม่ง่ายอย่างที่คิด แต่สามารถทำการทดสอบ Android app โดยไม่ต้องมี source code เลย โดยใช้งานร่วมกับเครื่องมือชื่อว่า uiautomatorviewer เพื่อดูว่าในหน้าจอของ app นั้นมี element อะไร และ จะเข้าถึงอย่างไร เหมือนกันการดูโครงสร้างของ DOM ของ web page นั่นเอง แน่นอนว่า UIAutomator ไม่เหมาะสมกับผู้เริ่มต้นแน่นอน 2. Espresso เป็นเครื่องมือจากทีมพัฒนา Android จาก Google อีกแล้ว สร้างขึ้นมาจาก Android developer เพื่อ Android developer โดยเฉพาะ เนื่องจากจำเป็นต้องเขียน code สำหรับการทดสอบนั่นเอง แต่การเขียนนั้นไม่ยาก เพราะว่า Espresso ได้เตรียม API ที่ใช้งานได้ง่าย เช่น

การค้นหา element ต่าง ๆ ในหน้าจอของ app
การกระทำต่าง ๆ ต่อ element เช่น การกด การ swipe การกรอกข้อมูล
การตรวจสอบข้อมูลว่าแสดงถูกต้องหรือไม่

สามารถเริ่มทดสอบจาก activity ใด ๆ ก็ได้ ไม่ต้องเริ่มจาก activity แรกอย่างเดียว แต่ว่า Espresso นั้นมีปัญหากับพวก Animation อย่างมาก ดังนั้น device หรือ emulator ควรปิดพวก Animation ก่อนเสมอ กับพวก Custom View ต่าง ๆ ข้อเสียอีกอย่างของ Espresso คือ ไม่สามารถ capture หน้าจอ screen ของแต่ละหน้าจอที่ทำการทดสอบได้ แต่ก็มีเครื่องมือเสริมเช่นกัน เช่น

Spoon จาก Square นั่นเอง ซึ่งพัฒนา Library ต่าง ๆ ขึ้นมาอย่างมากมาย แต่ปัจจุบันดูเหมือนว่าผู้ดูแลหลักจะหยุดพัฒนาไปแล้ว
AWS Device Farm

3. Robotium สำหรับ Android developer ที่รู้จัก และ ใช้งาน Robolectrie มาแล้ว ก็ย่อมรู้จัก Robotium ด้วยเช่นกัน การทำงานนั้นเหมือนกับ Android Testing Framework แต่เพิ่มความสามารถอื่น ๆ อีก ที่สำคัญมันเสถียรอย่างมาก ปัญหาน้อย แนะนำให้ใช้อย่างยิ่ง แต่เมื่อมาเจอ Espresso ผมเลยเปลี่ยนใจเท่านั้นเอง !! 4 และ 5 คือ Calabash และ Appuim โดยส่วนตัวแล้ว Calabash จะติดตั้ง และ ใช้งานง่ายกว่า Appium ทั้งสองตัวมีการใช้งานที่คล้ายกัน ต่างกันเพียงเบื้องหลังการทำงานเท่านั้นเอง โดยทำการทดสอบโดยไม่ต้องมี source code ขอมีเพียง App เท่านั้นก็สามารถทำการทดสอบได้แล้ว แต่ข้อเสียคือ ต้องทำการทดสอบแบบ End-to-End testing เท่านั้น ไม่สามารถเลือก Activity ที่ต้องการจะทดสอบได้ ส่วนการ capture รูปหน้าจอการทำงานสามารถทำได้ง่าย รวมทั้งรูปแบบการเขียน test case ก็จะง่ายขึ้นมา

ส่วนที่ 3 :: เครื่องมืออื่น ๆ ที่น่าสนใจ

ขอแนะนำตัวเดียวก็แล้วกัน นั่นคือ Monkey เป็นเครื่องมือที่มากับ Android framework อยู่แล้ว แต่มี Android developer น้อยคนมากที่รู้จัก และ นำมาใช้งาน ถูกสร้างมาเพื่อทดการทดสอบแบบ Stress testing โดยตัว monkey จะทำการสร้าง event ต่าง ๆ ขึ้นมา เหมือนกับการจำลองการใช้งานขึ้นมาแบบสุ่มขึ้นมา มากเท่าไรก็ได้ตามที่ต้องการ ซึ่งเหมาะมากสำหรับการทดสอบ App ครั้งสุดท้าย ก่อนทำการ upload App ขึ้น Play Store พูดง่าย ๆ เลยก็คือ ของดีราคาถูก (ฟรี) ใช้เถอะครับ

หวังว่าจะมีประโยชน์ต่อ Android developer ทุกคน

ที่ต้องการเพิ่มคุณภาพในการพัฒนา application ทั้งหน้าเก่า และ หน้าใหม่ บ้างนะครับ

วันนี้คุณเขียน Test แล้วหรือยัง ?

Screen Shot 2559-01-28 at 6.28.26 PM

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

การทดสอบมันคือ เครื่องมือการออกแบบชนิดหนึ่ง

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

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

ดังนั้น ถามตัวเราเองสิว่า Code ที่เราเขียนนั้น มันง่ายต่อการทดสอบหรือไม่ ? ถ้าตอบว่าใช่ ลองถามต่อไปสิว่า สามารถทดสอบได้บ่อยเท่าที่ต้องการหรือไม่ ? หรือทดสอบในทุก ๆ ครั้งที่ code มีการเปลี่ยนแปลงนั่นเอง !! ถ้า code มันยากต่อการทดสอบ แนะนำให้ทำการ refactor code เสียแต่เนิ่น ๆ พร้อมกับเขียน test ตามไปด้วย แล้วมันจะนำไปสู่การออกแบบที่ดีกว่าเดิมแน่นอน แสดงดังรูป Screen Shot 2559-01-28 at 6.44.07 PM

ให้เน้นไปที่ Unit testing ก่อนเสมอ

จากเรื่องของ Pyramid Testing นั้น ให้เน้นไปที่ Unit testing ก่อนเสมอ เนื่องจากมันทำให้เรารู้ และ เข้าใจว่า เรากำลังทำอะไรอยู่ เนื่องจากมันทำงาน หรือ ทำการทดสอบได้อย่างรวดเร็ว เนื่องจากเราสามารถรู้ผลการทำงานจากการเปลี่ยนแปลงได้เลย เนื่องจากมันทำให้เรารู้ว่าพฤติกรรมการทำงานมันถูกหรือไม่ ? pyramid (1)

แต่ unit test และการทดสอบพฤติกรรมการทำงาน มันไม่ใช่ feature นะ ดังนั้น การทดสอบควรที่จะมีการทดสอบในระดับ feature หรือในมุมมองของผู้ใช้งานด้วย ไม่เช่นนั้น Developer จะไม่สนใจในภาพใหญ่ ซึ่งเป็นความเข้าใจที่ผิดอย่างมาก ดังนั้น Developer ควรเข้าใจภาพนี้อย่างมาก Screen Shot 2559-01-28 at 5.47.55 PM

ในการเขียนชุดทดสอบ Unit test นั้น ควรเริ่มจาก test case ที่ง่าย ๆ และ เป็น Happy case หรือกรณีที่มันเกิดขึ้นอยู่อย่างเสมอ จากนั้นจึงไปเขียน test case อื่น ๆ เพื่อทำให้เรามั่นใจ ในสิ่งที่กำลังสร้างอยู่อย่างเสมอ จำนวนของ test case มันขึ้นอยู่กับความเชื่อมั่น ของ developer ของทีม ของคนอื่น ๆ ดังนั้นจงสร้างความเชื่อมั่นเหล่านี้ขึ้นมากัน

จงเริ่มสร้างได้แล้วนะครับ !!

Monitor/Measure Everything

ในระบบที่ developer พัฒนาอยู่นั้น คุณมี log หรือไม่ ? คุณมีการ monitoring ในระดับ application หรือไม่ ?

แต่เพียงแค่มีมันยังไม่พอนะ สิ่งต่าง ๆ เหล่านี้มันดีหรือไม่ ?

ถ้าคิดว่ามันดี เมื่อเกิดปัญหาขึ้นมา ทั้ง log และระบบ monitoring มันช่วยระบุจุดของปัญหาหรือไม่ ? ถ้าตอบว่า ไม่ ... มันคือสิ่งที่คุณต้องแก้ไข และ ปรับปรุงแล้วนะ

เน้นเรื่องของการทำงานร่วมกัน (Collaboration)

ในการพัฒนา software นั้น เป็นสิ่งที่ต้องทำงานเป็นทีม หรือ ใหญ่กว่านั้น แน่นอนว่า ย่อมมีคนทำงานมากกว่า 1 คน มีคนเข้า และ ออก อยู่อย่างสม่ำเสมอ

ดังนั้นสิ่งที่คุณกำลังสร้างมานั้น ต้องเอื้อต่อการทำงานเป็นทีม ต้องเอื้อต่อการทำงานร่วมกัน

บางคนบอกว่า เราก็มีเอกสารต่าง ๆ มากมายนะ ทั้ง Requirement specification ทั้ง Design specification ทั้ง Database design ทั้ง Activity diagram ทั้ง Class diagram ทั้ง test case ทั้งหมดที่อยู่ใน Spreadsheet แต่คำถามที่ต้องตอบ คือ เอกสารเหล่านี้มันน่าเชื่อถือหรือไม่ ? เอกสารเหล่านี้มันคือข้อมูลล่าสุดหรือไม่ ? ถ้าตอบว่าเชื่อถือ และ มันคือข้อมูลล่าสุดก็ดีมาก ๆ แต่เท่าที่ผ่านมา พบว่า เอกสารเหล่านี้ทำเพื่อให้มี !! ดังนั้น เชื่อถือไม่ได้เลย ยิ่งเป็น developer ด้วยแล้ว ไม่ชอบอ่าน และ ทำเอกสารเลย !! ดังนั้น สิ่งที่จะช่วยให้ devleoper ทำงานร่วมกันได้ง่ายคืออะไรล่ะ ? หนึ่งในนั้น น่าจะเป็นชุดการทดสอบแบบอัตโนมัติ เพียงแค่ run test ทั้งหมด ก็รู้ว่า สิ่งที่สร้าง สิ่งที่แก้ไข มันทำงานถูกหรือไม่ เป็นแนวคิด แนวทางที่น่าจะเพิ่ม productivity ใช่ไหม ? ส่วนตัวผมคิดว่า ใช่

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

สุดท้ายเป็นเรื่องของความเร็วในการทำงาน (Speed)

สำหรับ developer หรือ คนที่ไม่เคยเขียน test มักจะบอกว่า ถ้าเขียน test แล้วมันจะทำให้การพัฒนาช้าลง ตอบได้เลยว่า ใช่แล้ว แต่มันไม่ได้ลด productivity นะ !! มันเป็นธรรมดาของการเรียนรู้ในสิ่งใหม่ ๆที่คุณจะต้องช้าลง แต่สิ่งที่คุณจะได้รับกลับมาก็คือ productivity ที่ดีขึ้นกว่าเดิม ลดการทำซ้ำ ๆ ลดความผิดพลาด รู้ความผิดพลาด ไม่ต้องมาเสียเวลา debug code ไม่ต้องเสียเวลามาดู log ไม่ต้องมาเสียเวลาทดสอบ

นั่นแสดงว่า มันไม่ได้ลดความเร็วของการพัฒนาเลยนะ เผลอ ๆ มันกลับทำให้คุณเร็วขึ้น และ productivity สูงขึ้นอีกด้วย

แต่ก่อนอื่น ให้เริ่มศึกษา ให้เริ่มลงมือทำ และ เรียนรู้

วันนี้ code ที่คุณเขียน มันง่ายต่อการทดสอบหรือไม่ ?

websecuritybasics

จากบทความเรื่อง The Basics of Web Application Security ได้ทำการอธิบายเกี่ยวกับการพัฒนา web application อย่างไรให้มีความปลอดภัย โดยเน้นไปที่พื้นฐานของการพัฒนา ซึ่งมีความน่าสนใจและสำคัญอย่างมาก สำหรับ developer หน้าใหม่และประสบการณ์ยังไม่เยอะ ดังนั้น จึงทำการแปลและสรุปส่วนที่น่าสนใจไว้นิดหน่อย มาเริ่มกันเลย

ในการพัฒนา web application นั้น มีสิ่งที่ท้าทายเยอะมาก

ความท้าทายในอันดับต้น ๆ ก็คือ เรื่องความปลอดภัย (Security) แต่บ่อยครั้งที่มักถูกหลงลืม หรือ ปล่อยปละละเลยไป !! เรื่องของการพัฒนา web application ให้มีความปลอดภัยนั้น มีเทคนิค หรือ วิธีการมากมายทั้งยากและง่าย แต่ก่อนอื่น Developer ควรเรียนรู้และทำความเข้าใจกับพื้นฐานก่อน เช่น เรื่องการตรวจสอบ input เป็นต้น Developer บางคนอาจจะบอกว่า แค่พัฒนาระบบให้เสร็จตามความต้องการของลูกค้าก็ยากอยู่แล้ว ให้ระบบทำงานรวดเร็วก็ยากขึ้นไปอีก ไหนจะต้องเขียน code ให้ดีอีก ไหนจะต้องเขียน code ให้รองรับการขยายอีก ไหนจะต้อง .... ไหนจะต้องเรื่องความน่าเชื่อถือ ไหนจะต้องเรื่องความเสถียร … มันเยอะไปหมดเลย ส่วนเรื่องของความปลอดภัยมันมักจะอยู่ท้าย ๆ ของ requirment มักถูกละเลย ไม่สนใจ แต่เมื่อใดก็ตามระบบงานมันทำงานผิดพลาด หรือไม่เป็นไปทำที่เราต้องการ เมื่อนั้นแหละ เรื่องความปลอดภัยมันจะสำคัญอย่างมาก ถ้าไม่โดนกับตัวเอง จะไม่รู้สึก และ เข้าใจ !!

ก่อนอื่นต้องเข้าใจก่อนว่า

เรื่องของความปลอดภัยคือ เรื่องของความไว้ใจล้วน ๆ ลองถามตัวเองสิว่า

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

เชื่อได้เลยว่า คุณไม่ค่อยมั่นใจว่าจะไว้ใจได้ !!! เรื่องพวกนี้คือ ความเสี่ยงล้วน ๆ (Risk) ดังนั้นในฐานะของ Developer ต้องลดความเสี่ยงเหล่านี้ลงไป ให้ได้มากที่สุด

สิ่งแรกที่ Developer ทุกคนควรทำก็คือ การจัดการกับข้อมูลเข้า (Input)

ต้องทำการปฏิเสธข้อมูลที่ไม่เป็นไปตามที่ระบบต้องการ หรือ คาดหวังเสมอ Developer บางคนบอกว่า เราทำการตรวจสอบข้อมูลต่าง ๆ จากผู้ใช้งานด้วย JavaScript นะ แต่ในมุมมองของความปลอดภัยแล้ว บอกได้เลยว่า มันไม่มีประโยชน์อะไรเลย เพราะว่า ผู้ใช้งานเพียงปิด JavaScript หรือ ทำการจำลอง request การส่งข้อมูลมายัง server เพียงเท่านี้ JavaScript ก็หมดความหมายไปในทันที ให้เริ่มด้วยการอย่าไว้ใจข้อมูลเข้า (Input) ใด ๆ ทั้งสิ้น HTTPS ก็ช่วยอะไรไม่ได้นะครับ มันคนละเรื่อง ดังนั้น ฝั่ง server ต้องทำการตรวจสอบข้อมูลเข้าเสมอ ลองถามตัวเราเองสิว่า วันนี้ทำการตรวจสอบข้อมูลเข้ากันหรือยัง เช่น

ชนิดของข้อมูลมันตรงตามที่ต้องการหรือไม่ ?
รูปแบบข้อมูลตรงตามที่ต้องการหรือไม่ ?
ข้อมูลมันส่งผลกระทบต่อการประมวลผลของระบบหรือไม่ ?
ข้อมูลมีขนาดใหญ่เกินที่ต้องการหรือไม่ ?

ถ้ายัง รีบกลับไปแก้ไขได้เลย !! เพื่อลดปัญหา และ ลดอันตรายต่าง ๆ ที่จะเกิดขึ้นต่อระบบ นั่นคือ เรื่องของ Input Validation นั่นเอง มันไม่ใช่เรื่องใหม่เลยนะ แต่มักละเลยกันอย่างมาก !!!

Input Validation คืออะไรกัน ?

เป็นกระบวนการเพื่อทำให้มั่นใจว่าข้อมูลเข้า ยังคงเข้ากันได้กับระบบงาน และทำให้ระบบทำงานได้ตรงตามที่คาดหวัง แต่ถ้าข้อมูลเหล่านี้มันผิดปกติ หรือ ไม่เข้ากับการทำงานของระบบ มันย่อมทำให้เกิดผลลัพธ์ที่ไม่เป็นดังหวังเช่นกัน วิธีการตรวสอบข้อมูลเข้ามีหลากหลายวิธีซึ่งมีแนวทางดังนี้ เริ่มจาก Input validation เพื่อตรวจสอบข้อมูลตามชนิดที่ต้องการ เพื่อตรวจสอบข้อมูลตามช่วงที่ต้องการ ตัวอย่างเช่นข้อมูลราคาสินค้า ควรที่จะมีชนิดเป็นตัวเลข ควรที่จะมีค่าไม่ติดลบ ต่อมาเป็นวิธีการกำหนดขอบเขต หรือ จำกัดรูปแบบของข้อมูล เรียกว่า Whitelist หรือ positive validation เช่น

รูปแบบของวันที่
รูปแบบของ URL
ขนาดความยาวสูงสุดของข้อมูล
อักขระพิเศษที่อนุญาต

แต่ถ้าจำนวนของ Whitelist มันเยอะมาก ๆ แนะนำให้เปลี่ยนเป็น Blacklist หรือ negative validation ซะ

จากนั้นพูดถึง feedback หรือ การบอกผู้ใช้งานให้รับรู้ ผลลัพธ์การตรวจสอบข้อมูลเข้าที่ไม่เป็นไปตามความต้องการ มีทางเลือกคือ

แสดงผลการตรวจสอบทั้งหมด
ไม่แสดงผลการตรวจสอบ
แสดงข้อมูลแบบกลาง ๆ ไม่ลงรายละเอียด

จะเลือกทางไหน มันขึ้นอยู่กับความต้องการของแต่ละระบบ แต่อย่างหนึ่งที่ต้องมีคือ เขียนและบันทึกผลการทำงานต่าง ๆ ลงใน logging และ monitoring เสมอ อีกข้อควรระวัง คือ การนำข้อมูลเข้ามาแสดงให้ผู้ใช้งานเห็น ต้องทำการกรองข้อมูล และ ทำความสะอาดข้อมูลก่อนเสมอ มิเช่นนั้นมันก็จะกลายเป็นภัย หรือช่องโหว่ให้โจมตีระบบได้อีก เรามักจะเรียกว่า XSS attack (Cross Site Scripting) นั่นเอง

โดยในปัจจุบันเรื่องของ Input Validation มันไม่ยาก (แต่ไม่ค่อยทำกัน !!)

เนื่องจากมีชุด library และ framework ให้ใช้งานมากมาย ยกตัวอย่างเช่น

Java มี Hibernate Validation และ Spring Bean Validation
Ruby On Rails ก็มี Active Record Validator มาให้ใช้เลย
Node.js มี validator-js

ส่วนวิธีการพื้นฐานสุด ๆ มันก็คือ Regular expression ซึ่ง developer ควรมีความรู้ความเข้าใจนะ

สุดท้ายแล้วฝากไว้ว่า

if you don't control it, you can't trust it. If it violates the contract, reject it!

วันนี้ Developer รู้เรื่องการพัฒนา web ให้ปลอดภัยกันหรือยัง ? ถ้ายัง เริ่มได้แล้วนะครับ

ข้อมูลเพิ่มเติมแนะนำที่

Screen Shot 2559-02-02 at 11.07.49 PM

จาก paper เรื่อง Most Common Mistakes in Test-Driven Development Practice ทำการสำรวจเรื่อง ความผิดพลาดที่มักเกิดขึ้น จากการนำแนวคิด TDD มาใช้งาน จาก developer จำนวนหนึ่ง ซึ่งมีประสบการณ์ที่หลากหลาย ได้ผลลัพธ์ที่น่าสนใจดังนี้ ปล. ข้อมูลนานหน่อย คือตั้งแต่ปี 2010 แต่คิดว่ายังพอใช้ได้นะ โดยผลการสำรวจเรียงลำดับจากความผิดพลาดมากไปน้อย

ต้องการเขียน test scenario ที่ซับซ้อน
ลืมทำการ refactor code
ทำการ refactor code อื่น ๆ นอกเหนือจาก test ที่กำลังทำ
ไม่เริ่มต้นจาก test ที่ง่าย ๆ
ไม่ทำการเขียน code ง่าย ๆ เพื่อทำให้ test ผ่าน
ตั้งชื่อ test case แบบแย่ ๆ
ไม่ดูว่า test ที่ fail มันเกิดจากสาเหตุอะไร
ไม่ทำการ refactor code ของ test
ทำการ run test เฉพาะ test case ที่มัน fail ก่อนหน้า

ลองดูกันหน่อยสิว่า

Developer ที่นำแนวคิด TDD มาใช้งานนั้น ทำความผิดพลาดต่าง ๆ เหล่านี้กันบ้างไหม ?