cc :: somkiat

Screen Shot 2558-11-07 at 5.52.34 PM

วันนี้ได้อ่านบทความเรื่อง How to prevent eventual crappiness ซึ่งได้อธิบายไว้ว่า

Eventual crappiness – eventually all software will become crap

มาดูกันว่ามันคืออะไร ? มีข้อเสียอะไรบ้าง ? และเราสามารถป้องกันได้อย่างไร ?

Eventual crappiness คืออะไร ?

มาจากคำว่า Eventual consistency ซึ่งมีความหมายว่า ข้อมูลอาจจะยังไม่ update ค่าล่าสุดแบบ realtime แต่ผ่านไปช่วงเวลาหนึ่งข้อมูลจะ update ค่าล่าสุดแน่นอน ส่วนคำว่า Crap แปลว่า ขี้ หรือ ของที่ไร้ประโยชน์ เมื่อนำมารวมกันก็ได้คำว่า Eventual craziness มันก็คือ ถ้าคุณยังพัฒนา code แย่ ๆ ออกมา ซึ่งมันทำงานได้นะ เชื่อเถอะว่าเมื่อผ่านไปช่วงเวลาหนึ่งแล้ว code เหล่านั้นแหละมันจะกลับมาทำร้ายคุณ เชื่อหรือไม่ว่า ? ในตอนแรกที่เราเริ่มสร้างระบบขึ้นมา มันเป็นอะไรที่แจ่ม ยอดเยี่ยมกระเทียวดองมาก ๆ แต่เมื่อเวลาผ่านไปสักระยะ คุณกลับพบว่าสิ่งที่สร้างขึ้นมามันเริ่มส่งปัญหา จากนั้นคุณจะทำอย่างไรดีล่ะ ? ก็กลับไปสร้างใหม่ไงล่ะ !! และเมื่อเวลาผ่านไปมันก็กลับแย่อีก วนเวียนแบบนี้ไปตลอด ซ้ำแล้วซ้ำอีก !! มันยังไงกันนะ ?

ดังนั้น เรามาหยุด เพื่อใช้เวลามาคิด และ คุยกันหน่อยดีไหม ?

ลูกค้าของคุณคิดอย่างไรกับสิ่งที่คุณสร้าง ? น่าคิดนะ แต่ถ้าคุณดันไปบอกลูกค้าว่า ขอเวลาไปคิดก่อนว่า สิ่งที่สร้างมันดีไหมล่ะ ? ลูกค้าคงจะบอกว่า คุณจะบ้าหรอ เราจ้างคุณมาเขียน code และส่งมอบระบบงานนะ ไม่ใช่มานั่งคิด !! ดังนั้นถ้าลูกค้าไม่มีเวลาให้ สิ่งที่ชอบทำกันคืออะไรล่ะ ? ถามได้ งั้นเราก็เผื่อเวลามันทุก ๆ งานเลย หรือหลาย ๆ คนเรียกว่า Buffer ซึ่งอาจจะใช้เกิน หรือ ไม่ใช้เลยก็ได้ แต่สุดท้ายก็ลงเอยเช่นเดิม คือ ความล้มเหลวไม่เป็นท่า !! นั่นคือ สิ่งที่ส่งมอบให้ลูกค้าหรือ ? ดังนั้น ก่อนอื่นแนะนำให้สร้าง TRUST หรือ ความเชื่อมั่น ความไว้ใจ ให้กับทางลูกค้าอยู่อย่างเสมอ นั่นคือ ก่อนที่สร้างแต่ละ feature ควรทำการพูดคุยกับลูกค้าก่อนว่า สิ่งที่ลูกค้าต้องการคืออะไร พร้อมกับให้คำแนะนำ เพื่อปรับปรุงให้ดีขึ้น ที่สำคัญมันทำให้ต่างฝ่ายต่างเข้าใจในสิ่งที่กำลังจะทำ จากนั้นให้ทำการสร้าง checklist การทำงานขึ้นมาซะ ว่าจะต้องสร้างอะไรบ้าง อย่าลืมว่าเป็นงาน และ ภาษา ที่ลูกค้าเข้าใจนะ เพราะว่า ตอนนี้คุณกำลังคุยกับลูกค้าอยู่ จากนั้นให้ลูกค้าทำการ review ว่าครบไหม ? จากนั้นให้คนอื่น ๆ ในทีมทำการ review ว่าพร้อมกับการสร้างหรือไม่ ? เพื่อจะได้ไม่ต้องสร้างสิ่งที่ไม่จำเป็นขึ้นมา เพื่อจะได้ไม่ต้องเกิดสิ่งที่เรียกว่า งานงอก ขึ้นมา นี่คือ การคิด ก่อน ทำ (THINK before DOING) จากนั้นก็ทำการ เขียน code ที่มันสามารถอธิบายตัวเองได้ เขียน code ที่มีการออกแบบที่ดี เขียน code ที่ทำการทดสอบได้ง่าย แต่ code ดี ๆ เหล่านี้จะเกิดขึ้นมาไม่ได้ ถ้าไม่ได้ทำสิ่งต่าง ๆ เหล่านี้

1. ทำการ review พร้อมให้คำแนะนำในการแก้ไข

จาก blog เรื่อง ทำไมต้องทำ Code Review ด้วยล่ะ ? จำไว้ง่าย ๆ ว่า เมื่อเราได้ feedback ที่มันแย่ ( มาจากความจริงนะ ) มันจะทำให้เราดีขึ้น ถ้าเรายอมรับ และ แก้ไขมันซะ ซึ่งมันทำให้เราดีขึ้น แน่นอนว่า ย่อมส่งผลให้ระบบดีขึ้นด้วยเช่นกัน

2. งานอะไรที่ต้องทำซ้ำ ๆ ก็ให้มันทำงานแบบ Automate มันซะ

ปกติทำการ deploy อย่างไร ทั้ง development, test server ? ยังทำแบบ manual หรือไม่ นั่นคือ packaging และ deploy เอง ? ปกติยังใช้ FTP/SCP ในการส่งไฟล์หรือไม่ ? ปกติยัง restart web server เองเมื่อมีการแก้ไขไฟล์หรือไม่ ? ปกติการเขียน release note ยังทำแบบ manual หรือไม่ ? และอื่น ๆ อีกมากมายที่ต้องทำเอง ซ้ำแล้วซ้ำเล่า !!

ลด ละ เลิก เถอะนะ เพราะว่า อะไรก็ตามที่ทำแบบ manual หรือให้คนทำนั้น มักเกิดข้อผิดพลาดได้เสมอ

ซึ่งขั้นตอนการทำงานควรเป็นดังนี้ coding -> commit -> push -> DONE คำว่า DONE นั้นหมายถึง ขั้นตอนต่าง ๆ ที่ทำงานแบบอัตโนมัติ เช่น การ build, test และ deploy แล้วคุณจะพบว่า เราได้เวลากลับมามากจนน่าตกใจ !!

3. ทำการ refactor code ของระบบอยู่อย่างเสมอ

ลองถามตัวเราเอง และ ทีมสิว่า ระบบที่กำลังสร้างนั้น มันง่ายต่อการเพิ่มความสามารถใหม่ ๆ เข้าไปหรือไม่ ? มันเหมือนกับการต่อ jigsaw หรือไม่ ? ถ้าตอบว่าไม่ แสดงว่าควรหยุด แก้ไข ปรับปรุง code เดิมให้ดีก่อน code เดิมให้ง่ายต่อการเพิ่มเติม code เดิมให้ง่ายต่อการแก้ไข ไม่เช่นนั้น คุณจะพบว่า เมื่อเวลาการพัฒนาผ่านไปนาน ๆ จะพบว่า สิ่งที่สร้างมันก่อให้เกิดปัญหาอย่างรุนแรง แต่เรามักจะไม่หยุด เพื่อแก้ไข ส่วนใหญ่ ชอบเพิ่มคนมากกว่า ... แต่ปัญหายังคงอยู่ สุดท้ายสิ่งที่สร้างไป ก็ยังสร้างปัญหาอยู่เช่นเดิม ดังนั้นควรทำการแก้ไข และ ปรับปรุง code หรือ refactor code ซะ แต่ไม่ใช่เพียงแค่ code เท่านั้นที่ต้องปรับปรุง ขั้นตอนการทำงาน และ เครื่องมือก็ต้องปรับปรุงด้วยเช่นกัน คนก็เช่นกัน !! ลองดูสิว่า แบบ form ต่าง ๆ เราจำเป็นต้องกรอกหรือไม่ ? ลองดูสิว่า เราต้องการการ tracking เวลาการทำงานต่าง ๆ หรือไม่ ? สุดท้ายก็มากรอกวันสุดท้ายก่อนส่ง !! ลองดูสิว่า ขั้นตอนการทำงานแบบ Automate ของเรามันดีหรือยัง ? เช่น สามารถสรุปรายงานแต่ละวันได้หรือเปล่า ว่าทำอะไรบ้าง และ เสร้จอะไรบ้าง ? นี่คือ คำถามง่าย ๆ เพื่อดูว่าขั้นตอนการพัฒนาของคุณ ว่ามันมี Waste หรือ เสียเวลาให้กับสิ่งที่ไม่จำเป็นมากน้อยเพียงใด ? คุณอาจจะพบว่า เราเสียเวลาไปแบบไร้ค่าเยอะมาก ๆ ก็เป็นได้

4. คำว่า TEAMWORK มันสำคัญสุด ๆ

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

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

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

สิ่งต่าง ๆ เหล่านี้ นำมาใช้เพื่อสร้างระบบที่มีคุณภาพ

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

java_9

จากงาน Java One 2015 ที่ผ่านมานั้น ทีมของ Jigsaw project ได้มาพูดเรื่องต่าง ๆ ที่น่าสนใจของ JDK 9 ไม่ว่าจะเป็น

Prepare for JDK 9
Introduction to Modular Development
Advance Modular Development
Project Jigsaw: Under the Hood

ซึ่งเป็นเนื้อหาที่ Java Developer ทุก ๆ คนต้องดู ต้องรู้กันนะ

มาดูเรื่องแรกกันก่อนดีกว่า คือ Prepare for JDK 9

สามารถดู VDO และ Slide ได้เลย สามารถสรุปเนื้อหาได้ดังนี้ หลัก ๆ คือ ถ้าจะทำการย้ายจาก JDK 8 ไป 9 นั้นต้องเตรียมตัวอย่างไรบ้าง ? เนื่องจากมันมีการเปลี่ยนแปลงจำนวนมาก ทั้งสิ่งที่เพิ่มเข้ามา ทั้งสิ่งที่กำลังจะถูกลบออกไปใน JDK 10 ทั้งสิ่งถูกลบออกไปจาก JDK 9

APIs ที่จะถูกลบออกไปใน JDK 10 หรือ Deprecated ใน JDK 9

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

sun.misc.Unsafe
sun.misc.{Signal,SignalHandler}
sun.misc.Cleaner
sun.reflect.Reflection::getCallerClass
sun.reflect.ReflectionFactory

APIs ที่ถูกลบออกไปจาก JDK 9

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

java.util.logging.LogManager::addPropertyChangeListener
java.util.logging.LogManager::removePropertyChangeListener
java.util.jar.Pack200.Packer::addPropertyChangeListener
java.util.jar.Pack200.Packer::removePropertyChangeListener
java.util.jar.Pack200.Unpacker::addPropertyChangeListener
java.util.jar.Pack200.Unpacker::removePropertyChangeListener

โครงสร้างของ JDK และ JRE ที่เปลี่ยนไป

แสดงดังรูป javaone-project-jigsaw-jdk-structure

โดยรวมแล้ว Java Developer ต้องเตรียมตัวให้พร้อม

ไม่ว่าจะเป็น

ใช้งาน jdeps tool สำหรับการตรวจสอบว่า code ของเราใช้งาน JDK APIs อะไรบ้าง ?
ตรวจสอบ code ว่า identifier ใช้ underscore หรือไม่ เพราะว่าจะไม่อนุญาตแล้วนะ !!
ถ้าใช้พวก IDE ในการพัฒนา ให้ดูด้วยว่ามีการใช้งานพวก rt.jar และ tools.jar หรือไม่ ?
ทำการทดสอบ และ ทดลองใช้ JDK 9 EA และ Jigsaw project ซะ อย่าช้า !!

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

ทาง Oracle จะเลิก support Java 8 เมื่อไร ? คำตอบที่ได้คือ ไม่มีใครรู้คำตอบที่แท้จริง แต่ถ้าไปดูที่ Oracle Update Policy จะได้คำตอบตอนนี้ว่า Support ไปจนกว่าจะถึงสิ้นเดือนกันยายน 2017 แน่นอน !!

ดังนั้นจงเตรียมพร้อมกับ JDK 9 กันเถอะนะ

Reference Websites http://openjdk.java.net/projects/jigsaw/j1/ http://blog.codefx.org/java/dev/javaone-2015-prepare-for-jdk-9/ http://blog.takipi.com/java-9-code-tools-a-hands-on-session-with-the-java-microbenchmarking-harness/

Screen Shot 2558-11-09 at 10.09.35 AM

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

ปล. พักผ่อนบ้างนะ

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

แต่ในความเป็นจริง มันกลับโหดร้าย !!

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

เราสนใจแต่การส่งมอบที่ตรงตามเวลา และ ครบถ้วน มากกว่า คุณภาพ !!

และเราก็พบว่า ของที่ไร้คุณภาพมันเยอะมาก ๆ มันหมายความว่าอย่างไรกันนะ ? เรากำลังสร้างของที่มันแย่ ๆ ออกมากันหรือ ?

ดังนั้นจึงขอแนะนำแนวคิด 2 แบบ เพื่อทำให้คุณใส่ใจ code มากขึ้น

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

1. The Broken Window Theory

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

คุ้น ๆ ไหมว่า ปัญหาในการพัฒนา software ก็เป็นแบบนี้เสมอ !!

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

2. The Boy Scout rule

ทีมที่ดีควรทำตามกฎของลูกเสือ นะ

Always leave the campground cleaner than you found it

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

แต่แปลกนะว่า เรามักไม่หยุดแก้ไข ทำตาม ๆ กันไปก็พอ !!

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

นี่คือ ความใส่ใจที่ Devleoper ต้องพึงมี และ พึงกระทำ

พอมองย้อนกลับมาในงานที่เราทำ พบว่า ปัญหามันเยอะมาก ๆ

ไม่รู้จะเริ่มแก้ไขตรงไหนเลย เพราะว่า มองไปทางไหนก็เจอแต่ปัญหา เพราะว่า มองไปทางไหนก็เจอแต่กระจกที่มันร้าว พร้อมจะระเบิดออกมา ดังนั้น ถ้าคุณต้องการให้ระบบมันดีขึ้น เริ่มต้นด้วยการพูดคุยกับทีมเดี๋ยวนี้เลย เช่น เริ่มต้นด้วยการพูดถึงชื่อ และ คำต่าง ๆ ที่ใช้ใน code ที่สื่อถึงความหมาย และ การทำงาน เริ่มต้นด้วยการพูดถึงสถานะของ code ในปัจจุบัน ซึ่งให้อยู่ในกรอบเวลาสั้น ๆ นะ เริ่มต้นด้วยการระบุรูปแบบ code ที่มันแย่ ๆ ออกมา ว่ามีอะไรบ้าง เริ่มต้นด้วยการ refactor code ในส่วนที่ทีมต้องเข้าไปยุ่งเกี่ยวด้วย ซึ่งมันทำให้เกิด การนำแนวคิดของ The Boy Scout rule มาใช้แบบอัตโนมัติ

ดังนั้น มาเริ่มใส่ใจ code กันเถอะครับ

Screen Shot 2558-11-09 at 9.34.17 PM

คำถาม ถ้าต้องการกำหนดให้แต่ละ Sampler ใน Apache JMeter ให้ทำงานตามที่ต้องการแบบนี้ล่ะ

URL ที่ 1 ให้ทำการทดสอบ 40% จากจำนวนการทดสอบทั้งหมด
URL ที่ 2 ให้ทำการทดสอบ 30% จากจำนวนการทดสอบทั้งหมด
URL ที่ 3 ให้ทำการทดสอบ 20% จากจำนวนการทดสอบทั้งหมด
URL ที่ 4 ให้ทำการทดสอบ 10% จากจำนวนการทดสอบทั้งหมด

จะต้องทำอย่างไร ? คำตอบ ใน Apache JMeter นั้นสามารถทำได้หลายวิธี เช่น

แยก Thread Group
ใช้ Throughput Controller
ใช้ Switch Controller

โดยทำการทดสอบบน Apache JMeter 2.13 มาดูแต่ละวิธีกันว่าทำอย่างไร ?

1. แยก Thread Group

น่าจะเป็นวิธีการที่ง่ายที่สุดแล้ว และเหมาะสำหรับระบบที่มี logic การทำงานง่าย ๆ สามารถกำหนดให้แต่ละ Sampler แยกกันอยู่ในแต่ละ Thread Group ซะ เช่น ถ้าทำการทดสอบด้วยผู้ใช้งาน 100 คน สามารถกำหนดจำนวนผู้ใช้งานในแต่ละ Thread Group ได้ดังนี้

URL ที่ 1 ให้ทำการทดสอบ 40% = 40 คน
URL ที่ 2 ให้ทำการทดสอบ 30% = 30 คน
URL ที่ 3 ให้ทำการทดสอบ 20% = 20 คน
URL ที่ 4 ให้ทำการทดสอบ 10% = 10 คน

แสดงดังรูป Screen Shot 2558-11-09 at 8.03.55 PM

ผลการทดสอบเป็นดังรูป Screen Shot 2558-11-09 at 8.06.56 PM

2. ใช้ Throughput Controller

เป็น Logic controller หนึ่ง ซึ่งใช้กำหนดการทำงานของ Sampler ที่อยู่ภายใต้ controller ว่าจะให้ทำงานบ่อยเท่าไร ? โดยใน Thread Group กำหนด Number of Thread หรือผู้ใช้งานเป็น 100 สามารถเพิ่ม Throughput Controller ใน Thread Group ดังรูป Screen Shot 2558-11-09 at 8.12.32 PM

โดยแต่ละ Controller สามารถกำหนดให้เป็น Percent Executions และกำหนดค่าดังรูป Screen Shot 2558-11-09 at 8.20.55 PM

ผลการทดสอบเป็นดังรูป Screen Shot 2558-11-09 at 8.22.21 PM

3. ใช้ Switch Controller

ทำการกำหนดค่าของ Switch controller ได้ว่าจะให้ทำงานที่ URL ไหนบ้าง ซึ่งน่าจะเป็นวิธีการที่ยากที่สุดแล้ว ซึ่งค่านั้นจะอยู่ใน Switch value แสดงดังรูป Screen Shot 2558-11-09 at 8.41.22 PM

สิ่งที่ยากก็คือ แล้วใน Switch value มันมีค่าอะไรได้บ้าง ? ตอบได้เลยว่า เป็นได้ทั้ง integer และ string จากรูปข้างบน ถ้าเราต้องการให้ URL 1 ทำงาน จะกำหนดค่าเป็น 0 หรือ URL 1 ถ้าเราต้องการให้ URL 2 ทำงาน จะกำหนดค่าเป็น 1 หรือ URL 2 คำถาม แล้วเราจะกำหนดค่าอย่างไรให้มัน dynamic หรือ กระจายผู้ใช้งานไปแต่ละ URL ล่ะ ? คำตอบ มันยากนะ แต่ลองงคิดหน่อยสิ ว่า สิ่งที่ทำได้คือ การ Random ตัวเลข และ กำหนดน้ำหนักซะ โดยการให้น้ำหนักจะเป็นดังนี้

URL ที่ 1 ให้ทำการทดสอบ 40% ดังนั้นกำหนด 0000
URL ที่ 2 ให้ทำการทดสอบ 30% ดังนั้นกำหนด 111
URL ที่ 3 ให้ทำการทดสอบ 20% ดังนั้นกำหนด 22
URL ที่ 4 ให้ทำการทดสอบ 10% ดังนั้นกำหนด 3

ดังนั้นจะได้ข้อมูลดังนี้ 0000111223 จากนั้นทำการเขียน script ใน Apache JMeter นิดหน่อย เพื่อ Random ค่าใน Switch value ดังนี้


${__javaScript( var s="0000111223"; new Number(s.charAt( Math.floor(Math.random()*s.length) )) )}

ผลการทดสอบเป็นดังรูป ซึ่งแน่นอนว่าผลไม่ถูกต้องตามที่เราต้องการ เนื่องจากเป็นการ Random ให้ให้น้ำหนักเท่านั้นเองนะ แต่ก็ใกล้เคียงกับสิ่งที่ต้องการเช่นเดียวกัน Screen Shot 2558-11-09 at 9.10.48 PM

ลองดูว่าทั้งสามวิธีนี้ วิธีไหนที่เหมาะกับ use case มากที่สุด

Screen Shot 2558-11-10 at 7.24.17 PM

ในบทที่ 12 เรื่อง Go Faster! จากหนังสือ UX for Lean Startups ซึ่งได้แนะนำว่า ถ้าต้องการทีมที่เร็ว และ ตอบรับการการเปลี่ยนแปลงของผู้ใช้งานได้ดี จะต้องเป็นทีมแบบ Cross-functional team ดังนั้น มาดูกันหน่อยว่า Cross-functional team หมายความว่าอย่างไร ? และทำงานกันอย่างไร ?

ในหนังสือได้อธิบายว่า

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

Lean UX is not working in a waterfall style, where each group works independently of the others.

เนื่องจากการพัฒนาแบบเดิม หรือ traditional นั้น ทาง product manager จะเป็นคนคิด เป็นคนเขียน specification ต่าง ๆ ของ product ที่ต้องการออกมา จากนั้นจึงส่งไปให้ทีมออกแบบ สุดท้ายได้ technical specification ออกมา เพื่อให้ทีมพัฒนาลงมือสร้าง ซึ่งแน่นอนว่า ขั้นตอนการทำงานแบบนี้มันช้ามาก !!

ดังนั้นเราน่าจะมีรูปแบบการทำงานใหม่ ซึ่งหนึ่งในนั้นคือ Cross-functional team

มันเป็นการปรับเปลี่ยนที่ไม่ง่ายเลย สำหรับคนที่ทำงานแบบส่วนใครส่วนมัน สำหรับคนที่ทำงานแยกตามฝ่ายต่าง ๆ นั่นคือ การทำงานที่เรียกว่า Silo ซึ่งการทำงานแบบนี้ มันส่งผลที่ไม่ดีนัก !! ดังนั้น Cross-functional team นั้น จะนำคนที่เกี่ยวข้องกับ product นั้น ๆ มาทำงานร่วมกัน อยู่ในทีมเดียวกัน เรียกว่า Product team

เมื่อนำคนที่เกี่ยวข้องกับการพัฒนา product มารวมกัน

เช่น

Product manager
Product owner
Designer
SA
BA
QA
Customer service
Sales
Engineer

ทุกคนทำงานช่วยกันตั้งแต่เริ่มคิด สร้าง product ส่งผลให้การทำงานต่าง ๆ รวดเร็วขึ้น ไม่ว่าจะในทางที่ดี หรือ ทางที่ร้ายก็ตาม ทีมพร้อมที่จะปรับเปลี่ยนเสมอตามตัวชี้วัดต่าง ๆ แถมลดปัญหาเรื่องการติดต่อสื่อสารอีกด้วย ในการทำงาน แทนที่ feature ต่าง ๆ ใน product จะถูกคิดมาจากกลุ่มคนเดียว และมโนขึ้นมา ว่าฉันอยากได้นั่น อยากได้นี่ ก็เปลี่ยนมาเป็นการคิด feature ตามปัญหา หรือว่ามีการกำหนดตัวชี้วัดต่าง ๆ ว่าทำอะไร ? ว่าทำไปให้ใคร ? ว่าทำไปทำไม ? แล้วมีตัวชี้วัดอย่างไร ? เพื่อทำให้เรารู้ว่า สิ่งที่กำลังจะสร้างมานั้นแก้ไขปัญหาอะไร ? และจะทำการปรับปรุงอย่างไร ? คุ้มค่ากับการลงทุนหรือไม่ (Return of Investment) ?

เมื่อเข้าใจถึงปัญหาต่าง ๆ เรียบร้อยแล้ว

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

จะเห็นได้ว่า Cross functional team นั้น

หัวใจคือ การทำงานร่วมกัน (Whole team approach) นั่นเอง ทุกคนจะช่วยกันทำงาน ทุกคนมีหน้าที่รับผิดชอบในการคิด ออกแบบ สร้าง ดูแล และ monitoring ระบบ ทุกคนช่วยกันดูว่า สิ่งที่สร้างมันตรงตามตัวชี้วัดหรือไม่ ถ้าไม่ ก็ช่วยกันเรียนรู้ คิด และ แก้ไขปัญหาว่าจะทำอย่างไร เป็นการทำงานแบบ iteration และ incremental

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

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

ดังนั้นสมาชิกในทีม

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

Working as a TEAM Working as a Cross Functional Team

Screen Shot 2558-11-11 at 12.47.45 PM

มาดูกันหน่อยว่า ข้อมูลแนวโน้มของเทคโนโลยี และ เครื่องมือต่าง ๆ จาก ThoughtWorks Technology Radar ประจำเดือนพฤศจิกายน 2015 มันเป็นอย่างไรบ้าง โดยมีสิ่งที่สำคัญ ๆ ดังต่อไปนี้

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

มาดูรายละเอียดกันหน่อยดีกว่า

Technology Radar นั้นจะแบ่งออกเป็น 4 หมวด คือ

Techniques
Platforms
Tools
Languages และ Frameworks

ในแต่ละหมวดประกอบไปด้วย 4 กลุ่มย่อย คือ

Adopt ควรนำมาใช้ได้แล้ว
Trial มันแจ่มมาก ๆ ให้ลองนำมาใช้งาน แต่ต้องรับกับความเสี่ยงหน่อยนะ
Assess ต้องทำความรู้จัก และ เข้าใจมันก่อน ว่ามันมีผลอย่างไรบ้าง
Hold เป็นสิ่งที่ควรระวังเป็นอย่างมาก ( Process with caution )

มาดูสิ่งที่น่าสนใจของแต่ละหมวดกันดีกว่า

1. Techniques

การ implement ระบบ Continuous Delivery ยังเป็นเรื่องท้าทาย และ สำคัญมาก ๆ ของทุก ๆ องค์กร ดังนั้นจึงมีเทคนิคที่เป็นประโยชน์เกิดขึ้นมาตลอดเวลา ตัวอย่างเช่น Decoupling deployment from release ซึ่งให้แยกกันระหว่างคำว่า Deployment และ Release

Deployment ใช้สำหรับการ deploy เพื่อเปลี่ยนแปลง component และ infrastructure
Release ใช้สำหรับการเพิ่ม เปลี่ยนแปลง feature สำหรับผู้ใช้งานโดยตรง ซึ่งกระทบกับ business เป็นหลัก

โดยเทคนิคที่ใช้ประกอบไปด้วย feature toggle และ dark launch นั่นหมายถึงเราสามารถทำการ deploy ได้บ่อยเท่าที่ต้องการ โดยไม่ทำการ release feature ใด ๆ ออกไปเลย

การ deploy บ่อย ๆ จะช่วยลดความเสี่ยงในการแก้ไขได้มาก รวมทั้งฝั่ง business สามารถควบคุม feature ที่จะ release ออกไปได้อีกด้วย

Just In Time Design หรือ NoPSD เป็นเทคนิคในการออกแบบระบบ ที่พยายามบอกเราว่า ไม่จำเป็นต้องออกแบบระบบทั้งหมดตั้งแต่เริ่มต้น หรือเรียกว่า Big Design Upfront ส่วนเครื่องมือในการออกแบบให้ใช้แบบที่ lightweight ที่สุด เพื่อการเรียนรู้ที่ง่าย และ รวดเร็ว ซึ่งส่งผลดีต่อการทำงาน การสื่อสารของทีมอีกด้วย

แต่จำไว้ว่า ยังต้องเห็น และ เข้าใจภาพใหญ่ทั้งหมดของระบบนะ

สิ่งที่ชอบมาก ๆ คือ Products over Projects เป็นเวลาอันยาวนานสำหรับการพัฒนา software ที่เราจะคิดว่าเป็นการพัฒนา project ซึ่งมันหมายความว่า สิ่งที่ส่งมอบต้องอยู่ภายใต้งบประมาณเสมอ สิ่งที่ส่งมอบต้องอยู่ภายในเวลาที่กำหนดเสมอ ซึ่งแนวคิดดังกล่าว มันไม่ได้สอดคล้องกับ modern business เลย ดังนั้น เราต้องเปลี่ยนแนวคิดใหม่ว่า สิ่งที่เราพัฒนาคือ Product ซึ่ง product จะไม่มี final delivery เหมือนกับ project แต่ยังคงพัฒนา ปรับปรุงต่อไปเรื่อย ๆ เพื่อสนับสนุน business โดยแนวคิดนำมาจาก Agile และ Lean Startup นั่นเอง

ลองกลับมามองระบบที่สร้างสิว่า มันคือ project หรือ product กันแน่ ?

สิ่งที่ควรระมัดระวัง หรือ อย่าใช้เลย ประกอบไปด้วย

Gitflow ซึ่ง branch ที่เยอะ ๆ และมีอายุที่ยาวนาน มันไม่ดีเลยทั้งต่อคนพัฒนา และ ระบบ Continuous Integration
SAFe เนื่องจากวิธีการนี้นำไปสู่การ release ที่ใหญ่มาก ๆ ซึ่งมันขัดแย้งกับ Agile ดังนั้นแนะนำให้นำแนวคิด Lean มาใช้น่าจะเหมาะสมกว่า ค่อย ๆ ฝึก ค่อย ๆ ปรับปรุงอย่างสม่ำเสมอ น่าจะเป็นวิธีการที่เหมาะสมกว่า
Separate DevOps Team การแยก DevOps มาเป็นทีมมันน่ากลัว และ อันตรายมาก ๆ อย่าทำ !!

2. Platforms

เรื่องของ password security ยังคงเป็นเรื่องที่ถกเถียงกันไม่รู้จบ ใช้ password ที่ง่ายไป ก็ไม่ปลอดภัย ใช้ password ที่ยากไป ก็กลับลืมง่ายอีก โดย password กลายมาเป็นจุดอ่อนในเรื่องของ security ดังนั้นจึงขอแนะนำ Two-factor authentication แบบใหม่ ซึ่งช่วยปรับปรุงให้ security ดีขึ้น นั่นก็คือ TOTP ( Time-based One-Time Password ) สิ่งที่ควรระมัดระวัง หรือ อย่าใช้เลย ประกอบไปด้วย

Application Server ซึ่งมันมี feedback loop หรือขั้นตอนการทำงานที่ช้า รวมทั้งหลายคนได้รับความเจ็บปวดจากมันมาเยอะ ซึ่งปัจจุบันมันเข้าสู่โลกของ container, phoenix server และ Continuous Delivery กันแล้ว มาทำอะไรที่มันง่าย ๆ ดีกว่าไหม ?
SPDY ซึ่งแนะนำให้ไปใช้ HTTP2 ดีกว่า
Superficial Private Cloud

สิ่งที่แนะนำให้ลองนำมาใช้งาน มีสิ่งที่น่าสนใจ ส่วนใหญ่เกี่ยวข้องกับ Cloud, Distributed system และ Big Data ทั้งนั้น

Apache Mesos
Apache Spark
Cloudier Impala
AWS Lambda
Fastly

3. Tools

เครื่องมือที่แนะนำให้ใช้เลย ประกอบไปด้วย

Composer เป็นตัวจัดการ dependency library ของ PHP
Mountebank เป็นเครื่องมือสำหรับการสร้าง stub และ mock การทำงานผ่าน HTTP, HTTPS, SMTP และ TCP
Postman เป็น REST client ผ่าน Google Chrome extension ซึ่งมันช่วยอำนวยความสะดวกอย่างมาก

สิ่งที่ควรระมัดระวัง หรือ อย่าใช้เลย คือ Citrix for development หรือการพัฒนาโดยใช้ offshore development team หรือ distributed team เปลี่ยนมาทำงานร่วมกัน ที่เดียวกัน ทีมเดียวกันดีกว่า ซึ่งมันช่วยลดเวลา และ ค่าใช้จ่ายลงไปอย่างมาก รวมทั้งส่งผลดีต่อระบบที่ทำการพัฒนาอีกด้วย สิ่งที่แนะนำให้ลองนำมาใช้งาน มีสิ่งที่น่าสนใจ คือ

BrowserSync ช่วยสำหรับการทดสอบ browser ผ่าน device ต่าง ๆ
Carthage สำหรับจัดการ dependency ต่าง ๆ ของ iOS และ OSX project
Docker Toolbox ซึ่งมาแทนที่ boot2docker นั่นเอง
GitUp เป็นเครื่องมือบน Mac สำหรับช่วยให้การใช้งาน git ง่ายขึ้น และ เข้าใจง่ายขึ้น
Gitrob สำหรับการตรวจสอบเรื่อง security ของสิ่งต่าง ๆ ที่อยู่ใน git repository

4. Languages และ Frameworks

ในช่วงหลายปีที่ผ่านมา JavaScript เป็นภาษาโปรแกรมที่ได้รับความนิยมสูงมาก ๆ แต่ด้วยปัญหาของตัวภาษาเอง ทำให้มีความพยายามในการสร้าง library ใหม่ ๆ เพื่อมาแก้ไขปัญหาเหล่านั้น โดยมีรูปแบบภาษาเป็นของตัวเอง แต่ยังทำงานอยู่บน JavaScript ไม่ว่าจะเป็น CoffeeScript และ ClojureScript ปัจจุบันมี ECMAScript 6 ซึ่งเป็น version ใหม่ของ JavaScript ออกมา ซึ่งได้ทำการแก้ไขปัญหาของ version เดิมไปเยอะมาก ๆ แถมยังสามารถทำงานกับ browser เก่า ๆ ได้อีกด้วย ซึ่ง ณ วันนี้แนะนำให้นำ ECMAScript 6 มาใช้ได้แล้ว ส่วนภาษา Swift 2 กลายเป็นตัวเลือกหลัก ของการพัฒนาใน Apple ecosystem ไปแล้ว สิ่งที่แนะนำให้ลองนำมาใช้งาน มีสิ่งที่น่าสนใจ คือ

Enliven เป็น template framework สร้างด้วยภาษา clojure ซึ่งแยกส่วนของ code และ HTML ออกจากกันอย่างชัดเจน
React.js
SignalR คือ library สำหรับการสร้างระบบ realtime web application บน .Net
Spring Boot คือ standalone Spring application ช่วยให้สามารถสร้างระบบแบบ micro service ได้ง่าย และ สะดวก

สามารถอ่านเพิ่มเติมได้ที่ Technology Radar หรือ Download PDF ได้

inversion_wasteland_w1

จากหนังสือ Lean Software Development: An Agile Toolkit ได้ทำการสรุปความสิ้นเปลือง 7 อย่างในการพัฒนา software ( 7 Wastes in Software Development ) นำมาจากความสิ้นเปลือง 7 อย่างจาก Lean ในโรงานอุตสาหกรรม ซึ่งมีความน่าสนใจอย่างมาก มาดูกันว่ามีอะไรบ้าง ? มาดูกันว่าเราจะลด ความสื้นเปลือง เหล่านี้ได้อย่างไร ?

จากหนังสือ Lean Software Development ในหัวข้อ Seeing Waste

เขียนไว้ว่า

อะไรก็ตามที่ทำไปแล้ว ซึ่งไม่ได้สร้างคุณค่าให้กับลูกค้าโดยตรง ถือว่า เป็นความสิ้นเปลือง (Waste) ทั้งหมด

ในปี 1970 นั้นคุณ Winston W. Royce เขียนไว้ในเอกสารวิชาการ เรื่อง Managing the Development of Large Software System ไว้ว่า

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

ดังนั้นผู้เขียนหนังสือจึงตีความใหม่ว่า

ทุก ๆ ขั้นตอนในการพัฒนา software ยกเว้น Analysis และ Coding ล้วนเป็นความสิ้นเปลืองทั้งนั้น !!

สิ่งที่ควรถามกับตัวเราเอง ทีม และ องค์กร คือ ขั้นตอนต่าง ๆ ที่เราสร้างขึ้นมา สำหรับการพัฒนา software นั้น มันช่วยเพิ่มคุณค่าต่อลูกค้าหรือไม่ ? หรือมันช่วยทำให้คุณสบายขึ้นกันแน่ ?

ความสิ้นเปลือง 7 อย่างในการพัฒนา software ประกอบไปด้วย

Partially Done Work
Extra process
Extra feature
Task switching
Waiting
Motion
Defect

มาดูรายละเอียดของแต่ละข้อกันว่าเป็นอย่างไร ?

1. Partially Done Work

มาจากคำว่า Inventory ใน Toyota Production System (TPS) คืองานที่อยู่ในกลุ่ม Work In Progress หรือ ยังไม่เสร็จนั่นเอง คืองานที่ไม่ได้มีคุณค่าอะไรเลย จนกว่าจะทำการ เสร็จจริง ๆ และ ทำการ deploy ไปยัง production server เช่น

ออกแบบเสร็จแล้ว แต่ยังไม่ coding
coding เสร็จแล้วแต่ไม่ทำการทดสอบ
ทดสอบเสร็จแล้วแต่ยังไม่ทำการ deploy

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

ใช้เวลานานมาก กว่าจะรวม code หรือ merge code ซึ่งปัญหาที่ตามมากนั้นมากมายใช่ไหม ?
มี code จำนวนมากที่ไม่ถูกทดสอบ หรือ ไม่ทำการเขียน unit test เลย นั่นคือ ก่อให้เกิด bug อยู่อย่างเสมอ
code ที่มันแย่ ๆ และ code ที่ไม่สามารถอธิบายตัวมันเองได้
code ที่ยังไม่ทำการ deploy สักที บางระบบอาจจะ deploy ปีละครั้ง !! มันมีความเสี่ยงสูงมาก ๆ เราชอบการ deploy แบบ Big Bang !! ผลที่ได้คือ ระบบตัวเองล่มยังไม่พอ ดันพาระบบอื่น ๆ ล่มไปอีกด้วย ผลเสียตกที่ใคร ?
code และ feature ที่ไม่เคยให้ผู้ใช้งานเข้ามาใช้งานเลย นั่นคือ เรื่อง feedback ของงานที่สร้างขึ้นมา มันมีคุณค่า ประโยชน์ต่อลูกค้าหรือไม่ ?
เอกสารที่ไม่เคยตรงกับ code เลย !!

ดังนั้นมาลดจำนวนงานเหล่านี้ดีกว่านะครับ จะช่วยลดความสิ้นเปลืองต่าง ๆ รวมทั้งช่วยลดความเสี่ยงอีกด้วย

แปลกนะว่า หลาย ๆ ทีม หลาย ๆ องค์กร ชอบความเสี่ยงเยอะ ทั้ง ๆ ที่ก็ทำ Risk management นะ !!

2. Extra process

มาจากคำว่า Extra processing ใน Toyota Production System (TPS) หมายถึง process หรือ activity ที่ไม่ได้เพิ่มคุณค่าให้กับ software หรือ product ที่พัฒนาเลย ดังนั้นลองตั้งคำถามไปยังทีมพัฒนา และ ตัวเราเอง ดูสิว่า มี process หรือ activity อะไรบ้างที่มันจำเป็นต่อ product ? มีเอกสารอะไรบ้างที่มันจำเป็นต่อ product ? เอกสารที่ทำมีไว้เก็บแบบนี้หรือเปล่านะ ? documentation

ลองคิดดูสิว่า ถ้าเราเขียน customer test หรือ Acceptance test มาแทนที่ requirement มันน่าจะดีกว่าไหมนะ ? มันจะช่วยลดงานเอกสารลงไปไหมนะ ? มันน่าจะช่วยเพิ่มคุณค่าให้กับ product หรือเปล่านะ ?

มีกฎง่าย ๆ หนึ่งข้อ คือ Keep it short Keep it high level Keep it off line

3. Extra feature

มาจากคำว่า Over production ใน Toyota Production System (TPS) หมายถึง feature ต่าง ๆ ที่ถูกเพิ่มเข้ามาในระบบ ดูเหมือนว่า จะเป็นสิ่งที่ดี เพราะว่า เราสามารถเพิ่ม feature ได้เท่าที่เราต้องการ ซึ่งมันคือ การเพิ่ม code และเทคนิคใหม่ ๆ เข้ามายังระบบ แต่ในความเป็นจริงแล้ว สิ่งที่เราเพิ่มเข้าไปส่วนใหญ่มักจะเป็นความสิ้นเปลืองเสมอ เนื่องจากเมื่อใดก็ตาม ที่เราแตะต้อง code จะต้องทำการ compile จะต้องทำการ integrate จะต้องทำการ ทดสอบ จะต้องทำการ deploy จะต้องทำการ maintain และทุกครั้งที่เราเพิ่ม code เข้าไป เราได้เพิ่มความซับซ้อนของระบบขึ้นไปอีก และนั่นคือ ต้นกำหนดของสิ่งเล็ก ๆ ที่เรียกว่า BUG หรือก่อให้เกิดข้อผิดพลาดได้ ดังนั้น Developer ควรลดจำนวน code ที่ไม่จำเป็นออกไปบ้าง ถ้าไม่ยังไม่จำเป็นตอนนี้ ก็ไม่ต้องเผื่อไว้หรอกนะ

4. Task switching

มาจากคำว่า Transportation ใน Toyota Production System (TPS) ในการให้คนคนหนึ่งทำงานหลาย ๆ project มันคือ บ่อเกิดความสิ้นเปลืองสุด ๆ ของการพัฒนา software ใครทำอยู่บ้าง ยกมือขึ้น ? การสลับไปทำงานแต่ละ project มันย่อมเสียเวลา และเวลาการทำงานแต่ละ project มีขอบเขตอีกด้วย ดังนั้น คุณค่าที่จะส่งมอบได้รวดเร็วไหม ? มันขัดแย้งกับ Lean principle ที่บอกไว้ว่า Deliver as fast as posible ซึ่งเคยเขียนอธิบายไว้ใน blog เรื่อง Developer ทำงานช้า ! ตอนนี้คุณเป็น Multi-Tasker หรือเปล่านะ ? blog-office-assistant

5. Waiting / Delay

มาจากคำว่า Waiting ใน Toyota Production System (TPS) หมายถึงการรอสิ่งต่าง ๆ ไม่ว่าจะเป็น

รอเริ่ม project
รอประชุม
รอ requirement ที่ชัดเจน
รอเอกสารที่ครบถ้วน
รอทีมอื่น ๆ ที่เกี่ยวข้อง
รอการพัฒนาให้เสร็จทุก ๆ feature
รอการ review
รอการ approve
รอการทดสอบ
รอการ deploy

การรอ และ delay สิ่งต่าง ๆ เหล่านี้มันคือ ความสิ้นเปลืองทั้งนั้น และดูเหมือนจะเป็นความสิ้นเปลืองที่เยอะมาก ๆ สำหรับการพัฒนา software เนื่องมาจากขั้นตอนการพัฒนาที่เทอะทะ เยอะเกินไป !! ดังนั้นเราควรลดขั้นตอนสิ้นเปลืองเหล่านี้ออกไป เพื่อส่งมอบของที่มีคุณค่าให้กับลูกค้า ให้บ่อยที่สุดเท่าที่จะเป็นไปได้ นั่นคือ การทำงานแบบ iterative และ incremental value นั่นเอง

ทางที่ดีที่สุด ในการจัดการสิ่งที่ไม่แน่นอน ก็คือ การส่งมอบบ่อย ๆ นั่นเอง

6. Motion / Flow

มาจากคำว่า Motion ใน Toyota Production System (TPS) คำถาม

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

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

7. Defects

มาจากคำว่า Defects ใน Toyota Production System (TPS) มันหมายถึง Bug, Error, Incident หรือความผิดพลาดต่าง ๆ ที่เกิดขึ้นมา โดยผลการทำงานไม่เป็นไปตามที่คาดหวังนั่นเอง ความสิ้นเปลือง ที่เกิดจาก defect มันมาจาก

ผลกระทบที่เกิดขึ้นจาก defect นั้น ๆ
เวลาในการหาต้นเหตุของ defect นั้น ๆ
เวลาในการแก้ไข defect นั้น ๆ

ถ้าใช้เวลาในการหา และ แก้ไข น้อย ๆ ก็ สิ้นเปลืองน้อย แต่ถ้าใช้เวลามาก ก็สิ้นเปลืองมาก ดังนั้น แทนที่จะเสียเวลาไปกับการหา defect เรามาแก้ไขที่ต้นเหตุของ defect ดีกว่าไหม ? เรามาแก้ไขเพิ่มหา defect ได้อย่างรวดเร็ว ดีกว่าไหม ? นั่นคือ เราควรมีการทดสอบอยู่บ่อย ๆ ทั้ง unit test ทั้ง integration test ทั้ง system test ทั้ง acceptance test ทั้ง user interface test ทำการ deploy และ release ให้เร็ว ให้บ่อยที่สุดเท่าที่จะทำได้ เพื่อลด ความสิ้นเปลือง เหล่านี้ลงไป

สุดท้ายแล้ว

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

Screen Shot 2558-11-13 at 9.52.25 AM

ข้อมูลจาก BizReport ได้ทำการสรุปสิ่งที่เว็บ e-commerce ทุก ๆ ที่ ควรต้องทำก่อนช่วงวันหยุดยาว หรือ ช่วงที่มีกิจกรรมต่าง ๆ นั่นก็คือ Performance testing นั่นเอง ซึ่งแนะนำให้ทำการทดสอบอย่างน้อยที่สุด คือ 4 หน้า มาดูกันว่ามีหน้าไหนบ้าง ? แน่นอนว่า ถ้าหน้าเว็บมัน load หรือ แสดงข้อมูลได้ช้า ย่อมส่งผลที่ไม่ดีต่อเว็บ หรือ brand นั้น ๆ อย่างหลีกเลี่ยงไม่ได้ ยิ่งในช่วงวันหยุด เทศกาลต่าง ๆ รวมทั้งช่วงมีกิจกรรม โปรโมชันต่าง ๆ ด้วยแล้ว ยิ่งกลายเป็นปัญหาที่ใหญ่มาก ๆ ลองคิดดูสิว่า ถ้าระบบต้องสูญเสียลูกค้าไปเพราะว่า ไม่สามารถเข้าใช้งานระบบได้ ระบบไม่สามารถแสดงข้อมูลได้ คุณจะสูญเสียรายได้ไปสักเท่าไร ? รวมทั้งอาจจะต้องโดนคู่แข่งแย่งลูกค้าไปอีก ? มันคงเป็นสิ่งที่ไม่มีใครยอมรับได้ใช่ไหม ? ดังนั้น เว็บ e-commerce ควรต้องทำ performance testing ของระบบอยู่อย่างเสมอ แต่จะทดสอบทั้งระบบคงเป็นไปได้ยาก สำหรับระบบที่ไม่เคยทำการทดสอบเลย ดังนั้น จึงขอแนะนำ 4 หน้าหลักสำคัญ ๆ ดังนี้

1. หน้า หรือ ขั้นตอนที่ลูกค้า และ ผู้ใช้งานเข้าใช้มาก ๆ บ่อย ๆ

ดังนั้น เรื่องสถิติการใช้งานของระบบ เป็นสิ่งที่ขาดไม่ได้เลย หลาย ๆ ระบบมีข้อมูลเหล่านี้ แต่ไม่สามารถนำมาวิเคราะห์ และ ใช้งานได้ !! ส่วนใหญ่จะเป็น browse-to-purchase โดยการทดสอบควรที่จะทำการจำลองผู้ใช้งานจำนวนมากมาย และทำการทดสอบหลายหลาย flow การทำงาน (ในเรื่องเดียวกันนะ) ก่อนทำการทดสอบควรรู้ตัวเลขพื้นฐานของระบบเช่น จำนวนผู้ใช้งานพร้อม ๆ กันในหนึ่งหน่วยเวลา รวมทั้งเป้าหมายที่ตั้งไว้ อย่าทำโดยไม่มีการวางแผนโดยเด็ดขาด !! แต่ถ้าไม่รู้ข้อมูล ให้ทำการทดสอบแบบขั้นบันไดไปเรื่อย ๆ เพื่อดูว่าระบบมีขีดจำกัดที่ตรงไหน เพื่อทำให้เรารู้ว่า เมื่อไรเราควรที่ต้องมีแผนรองรับ หรือ ปรับปรุงต่อไป ไม่ใช่มาทำการวางแผน และ แก้ไขเมื่อระบบล่ม !! ซึ่งมันไม่ใช่สิ่งที่ดีอย่างแน่นอน Flow การทดสอบควรเป็นดังนี้

เปิดหน้าแรกของระบบ (Home page)
ทำการค้นหาสินค้า
เลือกสินค้าที่ต้องการซื้อ
เพิ่มสินค้าเข้าตะกร้า (Shopping cart)

ต้องทำให้มั่นใจว่า ไม่มีขั้นตอนไหนที่ทำงานช้า หรือ สะดุด

2. ทดสอบส่วนของ Shopping cart และขั้นตอนการ Checkout

เป็นส่วนที่สำคัญมาก ๆ ของระบบ e-commerce เพราะว่า มันคือส่วนชี้เป้นชี้ตายของระบบเลยว่า ลูกค้าจะซื้อสินค้าหรือไม่ ? ลูกค้าจะจ่ายเงินได้หรือไม่ ? ลองคิดดูสิว่า ถ้าขั้นตอนการทำงานใน shopping cart มีปัญหา หรือการ checkout มีปัญหา แน่นอนว่า ลูกค้าจะไปซื้อสินค้าที่อื่นอย่างแน่นอน เพราะว่า เกิดความไม่เชื่อมั่นต่อระบบแล้ว การจะกลับมาใช้อีกครั้งเป็นเรื่องที่ไม่ง่ายเลย

3. อย่าลืมทดสอบ Mobile app ด้วยล่ะ

ถ้าดูจากข้อมูลการใช้งานในปัจจุบัน พบว่ามีการใช้งานผ่าน Mobile เยอะมาก ๆ บางระบบมีการใช้งานผ่าน mobile เป็นหลักไปแล้วด้วย ดังนั้น ระบบ e-commerce ควรทดสอบผ่าน mobile ด้วย ไม่ว่าจะเป็น web บน mobile browser หรือ native mobile app ก็ตาม เพื่อทำให้มั่นใจว่า ระบบที่พัฒนานั้น มันเหมาะสมต่อการใช้งานผ่าน mobile เพื่อเพิ่มจำนวนผู้ใช้งาน และ ยอดการซื้อขายอีกด้วย

4. ทดสอบหน้าโปรโมชันใหม่ ๆ รวมทั้งถ้า Landing page ต่าง ๆ ด้วย

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

แนะนำขั้นตอนการทำ Performance testing นิดหน่อย

พิจารณาว่า scenario และ flow ใด มันสำคัญมาก ๆ สำหรับระบบ
หาจำนวน concurrent user ในช่วง peak time มาซะ
ทำการสร้าง testing environment เพื่อรองรับข้อ 1 และ 2
ทำการเขียน script การทดสอบ รวมทั้งเตรียมข้อมูลสำหรับทำการทดสอบ ใช้ข้อมูลจริงนะครับ
เริ่มทำการทดสอบด้วยจำนวน concurrent user น้อย ๆ ก่อน แล้วค่อย ๆ เพิ่มแบบ step-by-step เพื่อหาค่า base line
ทำการ monitoring ระบบ ไม่ว่าจะเป็น server, network, logging, application, database เพื่อทำการระบุว่าส่วนไหนเกิดปัญหา จากนั้นจึงทำรายงานการทดสอบ
เมื่อเกิดปัญหาขึ้นมา ให้ทำการแก้ไขทั้ง application, software และ hardware ต่างๆ
เมื่อแก้ไขปัญหาเรียบร้อยให้ทำการเริ่มทดสอบใหม่อีกครั้ง จากนั้นจึงทำการวิเคราะห์ และ เปรียบเทียบ เพื่อสรุปผลต่อไป

แสดงขั้นตอนการทดสอบดังรูป Ecommerce-Performance-Testing

สุดท้ายแล้ว

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

ปัญหามันเพียงแค่ว่า คุณคิดและทำ Performance testing ตอนไหนเท่านั้นเอง ?

วันนี้ทำ Performance testing แล้วหรือยัง ?

testing

วันนี้ได้พูดคุย และ อธิบายเกี่ยวกับ Test Double ไปนิดหน่อย จึงนำมาอธิบายเพิ่มเติม พร้อมยกตัวอย่าง เพื่อทำให้เห็นภาพว่า Test Double แต่ละตัวนั้น เป็นอย่างไร ใช้งานอย่างไร และ แตกต่างกันอย่างไร โดยจำอธิบายเฉพาะ Mock, Stub และ Dummy เท่านั้น เนื่องจากเป็นสิ่งที่ใช้งานบ่อยสุด ๆ แล้ว มาเริ่มกันเลย

เนื้อหาต่าง ๆ ใน blog นี้อ้างอิงข้อมูลจากบทความเหล่านี้

Mock Aren’t Stub เขียนโดยคุณ Martin Fowler
The Little Mocker เขียนโดยคุณ Robert C. Martin

เนื่องจาก class ส่วนใหญ่ มักจะต้องทำงานร่วมกับ class อื่น ๆ เสมอ ดังนั้น เมื่อเราเขียน unit test เพื่อทดสอบการทำงาน เราจำเป็นต้องหลีกเลี่ยงการเรียกใช้งาน class จริง ๆ ของสิ่งที่ต้องทำงานร่วมกัน เพื่อให้เราสามารถทดสอบการทำงานได้ตามที่ต้องการ ซึ่งเทคนิคที่ใช้งานกันคือ Test Double ซึ่งประกอบไปด้วย 5 ชนิด คือ

Mock
Stub
Spy
Dummy
Fake

แต่ขออธิบายพร้อมยกตัวอย่างเฉพาะ Mock, Stub และ Dummy เท่านั้น เนื่องจากใช้งานบ่อยนั่นเอง

1. Mock

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

Mock เป็นการตรวจสอบพฤติกรรมการทำงาน ( Behavior verification ) ของ class ที่เราทำงานด้วยว่า มีการทำงานตามที่เราต้องการ หรือ คาดหวังไว้หรือไม่

ตัวอย่างเช่น ใน Service ของเราต้องเรียกใช้ DAO เพื่อทำการบันทึกข้อมูล สิ่งที่เราต้องการ คือ DAO ทำการบันทึกหรือไม่ ? นั่นหมายถึง method save() ของ DAO ถูกเรียกหรือไม่นั่นเอง คำถามคือ แล้วจะจะทดสอบได้อย่างไรล่ะ ? มาดูตัวอย่าง code กัน เริ่มที่ class UserService กันก่อน ซึ่งเราต้องการที่จะทดสอบ [gist id="ec087ea9702345027fbf" file="UserService.java"] คำอธิบาย จะเห็นได้ว่า class UserService นั้นมี class ที่ทำงานด้วย 2 class คือ UserDAO และ User แต่ class ที่เราสนใจพฤติกรรมการทำงานก็คือ UserDAO ซึ่งเราต้องการรู้ว่า พฤติกรรมการทำงานมันถูกต้องหรือไม่ ? เมื่อ method createUser() จาก class UserService ถูกเรียกใช้งานแล้ว method save() ของ class UserDAO ต้องถูกเรียกใช้งานด้วย เราสามารถเขียนการทดสอบได้ดังนี้ [gist id="ec087ea9702345027fbf" file="UserServiceTest.java"] คำอธิบาย ในการทดสอบจะเห็นได้ว่า ในส่วนของ Test Fixtures หรือ ข้อมูลสำหรับการทดสอบนั้น เราจะทำการ mock class UserDAO ( ตัวอย่างนี้ใช้ mock library ชื่อว่า Mockito ) จากนั้นในการทดสอบ จะทำการตรวจสอบพฤติกรรมการทำงานของ class UserDAO ว่า มีการเรียกใช้ method save() หรือไม่ ปล. ถ้าไม่ต้องการใช้ mock library สามารถเขียนเองได้นะครับ วิธีที่ง่ายที่สุดคือ การ extends จาก class UserDAO นั่นเอง

2. Stub

บางคนจะเรียกว่า Stub out หรือเป็นการกำหนดสถานะของสิ่งนั้น ๆ ตามต้องการ ว่าต้องการให้ object ที่ทำงานด้วยนั้นมีสถานะอย่างไร ? จะมีสถานะถูก หรือ ผิด ตามที่ต้องการทดสอบ ดังนั้นจึงเรียกว่า State verification นั่นแสดงว่า เราต้องการตรวจสอบสถานะของ object ว่าถูกต้องตามที่เราคาดหวังหรือไม่ นั่นเอง ตัวอย่างเช่น ใน class UserService นั้น จำเป็นต้องทำการตรวจสอบข้อมูลของผู้ใช้งาน ผ่าน class UserValidationService ถ้าผ่านจะทำการกำหนดสถานะของผู้ใช้งานให้เป็น TRUE แต่ถ้าไม่คือ FALSE มาดูตัวอย่าง code กันดีกว่า [gist id="ec087ea9702345027fbf" file="UserService2.java"] ถ้าเราต้องการทดสอบ โดยให้บันทึกข้อมูลสถานะของผู้ใช้งานเป็น TRUE ล่ะ เราจะต้องทำอย่างไร ? สิ่งที่ทำได้ตอนนี้คือ Stub การทำงานของ class UserValidationService มันไปเลย ดังนั้นถ้าเรียกใช้งานผ่าน method isValid() แล้ว จะต้อง return ค่า TRUE ออกมาเสมอ เขียน code ของการทดสอบได้ดังนี้ [gist id="ec087ea9702345027fbf" file="UserServiceTest2.java"] คำอธิบาย จะเห็นได้ว่าได้ทำการสร้าง Stub ด้วยการ extends มาจาก class จริง ๆ โดย stub นี้จะส่งค่า TRUE กลับมาเสมอเมื่อเรียกใช้งาน method isValid() ทำให้เราสามารถควบคุมสิ่งต่าง ๆ ได้ นั่นส่งผลให้เราสามารถทดสอบการทำงานได้ซ้ำแล้วซ้ำเล่า นี่คือการตรวจสอบสถานะของการทำงานด้วย Stub

ถ้าถามว่าระหว่าง Mock กับ Stub ใช้อะไรเยอะกว่า ผมตอบได้เลยว่า ใช้ Stub เยอะกว่ามาก

3. Dummy

ชื่อมันตรงตามตัวเลย คือ ให้เราสร้าง class หน้าโง่ ๆ ขึ้นมา มันอาจจะไม่มีการ implement อะไรเลย มีเพียงเพื่อให้ code ของเรา compile ผ่านเท่านั้นเอง ส่ง dummy เข้าไป เพื่อให้มันครบตามที่ต้องการเท่านั้นเอง โดย dummy เหล่านี้ไม่สามารถนำไปใช้งานจริง ๆ ได้นะ !! ตัวอย่างเช่น จากการทดสอบในตัวอย่างของ Stub นั้น จะพบว่ามี class หนึ่งที่ไมีถูกใช้งานอะไรเลย นั่นก็คือ class UserDAO ดังนั้น ถ้าเราต้องการสร้าง Dummy ของ class UserDAO ขึ้นมาล่ะ จะต้องทำอย่างไรดี ? โดยถ้าใครมาเรียกใช้ method ต่าง ๆ ของ class Dummy จะต้องโยน exception ออกมาเสมอ เพราะว่า มันคือ dummy ไงล่ะ เอาไปใช้งานจริง ๆ ไม่ได้หรอกนะ มาดู code กันดีกว่า [gist id="ec087ea9702345027fbf" file="UserServiceTest3.java"] ปล. พวก inner class ต่าง ๆ เหล่านี้ ถ้าต้องการใช้ซ้ำ ๆ จากการทดสอบอื่น ๆ แล้ว แนะนำให้แยกออกไปสร้าง class ใหม่เลยนะ

มาถึงตรงนี้แล้ว เป็นยังไงกันบ้าง ?

น่าจะพอทำให้เห็นภาพของ Mock, Stub และ Dummy ได้ชัดเจนมากยิ่งขึ้น ส่วนของ Spy กับ Fake ขออธิบายสั้น ๆ ก็แล้วกัน ไม่เช่นนั้นจะงงกันมากไปกว่าเดิม

4. Spy

ถูกใช้เมื่อเราต้องการทำให้มั่นใจว่า พฤติกรรมการทำงานของสิ่งที่เราสนใจ มันทำงานได้ถูกต้องจริง ๆ นะ ( Exclusive behavior verification ) เช่น ต้องเรียกมากกว่า 1 ครั้ง เป็นต้น แต่ข้อเสียของ Spy ที่เห็นได้ชัด คือ code ของการทดสอบจะผูกติดกับ code จริง ๆ มากจนเกินไป บางครั้งมันคือการ lock spec ของ code เลย ดังนั้น เมื่อมีการแก้ไข code จะกระทบต่อส่วนการทดสอบอย่างมาก

5. Fake

เป็นการ implement ที่เหมือนจริงมาก ๆ บางครั้งเกือบแยกไม่ออกกับของจริงเลยด้วยซ้ำ ทำให้เป็นข้อเสียหนึ่งของ Fake แต่มันเหมาะสมกับการจัดการกับบางสิ่งบางอย่าง ที่ไม่สามารถทดสอบบน production หรือ server จริง ๆ ได้ ตัวอย่างของ Fake ที่ชัดเจนมาก ๆ คือ Memory database

โดยสรุปแล้ว

Test Double ใช้สำหรับการทำงานร่วมกันของ class ต่าง ๆ ในส่วนของการทดสอบ หรือ unit test นั่นเอง โดย Test Double ที่ใช้มาก ๆ คือ Mock, Stub และ Dummy ดังนั้น developer ทั้งหลายจะต้องศึกษา เรียนรู้ และ ทำความเข้าใจ ว่าแต่ละตัวมันคืออะไร ว่าแต่ละตัวใช้งานอย่างไร ว่าแต่ละตัวแตกต่างกันอย่างไร สุดท้ายจริง ๆ ถ้าต้องการให้การทดสอบมันทำได้ง่าย ๆ แต่ละส่วนการทำงาน หรือ แต่ละ class ต้องไม่ผูกมัดกันแน่น (Loose coupling) นะ ต้องแยกเป็นอิสระต่อกัน (Isolation)

เชื่อเถอะว่า ถ้า code มันทดสอบได้ยาก แสดงว่า code ที่เขียนขึ้นมามันก็ยาก แถมผูกมัดกันแบบแน่น ๆ ( ลองหา new ใน code ดูสิ !! ) ซึ่งเป็นที่มาของ spaghetti code นั่นเอง

netflix-culture-valley

จากบทความเรื่อง The Stack Behind Netflix Scaling ทำการสรุปโครงสร้าง เครื่องมือ และ วัฒนธรรมองค์กรของระบบ Netflix ซึ่งทำการรวบรวมจากบทความ และ งานสัมมนาต่าง ๆ คิดว่า น่าสนใจเลยนำมาแปล และ สรุปไว้นิดหน่อย เริ่มกันเลย

เริ่มที่เครื่องมือต่าง ๆ ที่ใช้ในการพัฒนาระบบ

ภาษาโปรแกรมที่ใช้ประกอบไปด้วย Java, JavaScript และ Python
JavaScript ที่ใช้มี 2 ส่วนคือ Node.js สำหรับฝั่ง Backend และ React สำหรับฝั่งผู้ใช้งาน
Database ที่ใช้งานประกอบไปด้วย MySQL, Oracle และ Cassandra ซึ่งเคยอ่านเจอบทความหนึ่งจากหัวหน้าทีมพัฒนาของ Netflix บอกว่าระบบหยุดขยายการใช้งาน Oracle ด้วยการใช้งาน MySQL แทน
Database ที่ใช้นั้นจะใช้ผ่าน Amazon RDS (Relational Database Service) และ Amazon DynamoDB
ระบบส่ง email ใช้ Amazon SES (Simple Email Service)
จัดการ source code ผ่าน Github
ระบบ Continuous Integration ใช้ Jenkins

สิ่งที่น่าสนใจอย่างมากของ Netflix คือ วัฒนธรรมองค์กร (Culture)

เนื่องจากเป็นองค์กรที่มีชื่อเสียงเรื่อง culture อย่างมาก ตัวอย่างเช่น เรื่องของ Hardwork ไม่ได้เกี่ยวข้องกับจำนวนชั่วโมงการทำงานที่บริษัท แต่ใส่ใจเรื่องของงานที่มันแจ่ม ๆ มากกว่า เรื่องของ Context, not Control เน้นว่าให้หลีกเลี่ยงการจัดการแบบ Commad and Control เช่น การตัดสินใจจากระดับบนเพื่อสั่งงานลงมา การที่จะดำเนินงานต่าง ๆ ต้องได้รับการอนุญาตจากฝ่าย management ก่อน มีกลุ่ม committee ในการทำงาน มีการประชุมวางแผนงาน และ ขั้นตอนการทำงานที่มากเกินไป หรือ เยอะกว่าการลงมือทำ ซึ่งเรื่องต่าง ๆ เหล่านี้ให้ทำการหลีกเลี่ยงซะ เรื่องของ Great Workplace สถานที่ทำงานดี ๆ ไม่ได้หมายความว่า ต้องมีกาแฟดี ๆ ให้กิน ต้องมีอาหารกลางวันให้กินฟรี ๆ ต้องมีการเลี้ยงฉลอง ต้องมี office ที่สวยงาม แต่มันคือ เพื่อนร่วมงาน และ งานที่ทำต่างหาก ใน slide ยังอธิบายอีกว่า หลาย ๆ บริษัทมักจะติด คำ ประโยค และ quote ที่ดี ๆ ไว้ เช่นเรื่อง Integrity, Communication, Respect และ Excellence แต่สิ่งที่เกิดขึ้นจริง ๆ กลับตรงกันข้ามเสียอย่างนั้น !! สามารถอ่านเพิ่มเติมได้ที่ Slide :: Culture อีกเรื่องที่มีการพูดถึงอย่างมาก คือ

Do not tolerate brilliant jerks. The cost to teamwork is too high - CEO Netflix

ระบบของ Netflix ส่วนใหญ่ใช้บริการของ Amazon

โดยที่ infrastructure หลักจะอยู่บน Amazon EC2 ส่วนข้อมูลชนิด digital ต่าง ๆ จะเก็บอยู่ที่ Amazon S3 และระบบ Backend ยังนำ software ที่เป็น opensource มาใช้งานอีก ไม่ว่าจะเป็น MySQL, Gluster, Apache Tomcat, Hive, Chukka, Cassandra และ Hadoop มันจะเยอะไปไหน ... แต่ยังไม่หมดนะ !! แสดงดังรูป netflix-architecture

ระบบของ Netflix สามารถใช้งานได้หลากหลาย device

ดังนั้นสิ่งที่ทางระบบต้องทำก็คือ แปลงข้อมูลของ VDO ให้อยู่ในรูปแบบต่าง ๆ มากถึง 120 รูปแบบ รวมทั้งการให้บริการแบบ Streaming จะเป็นแบบ Adaptive bitrate streaming หมายความว่า คุณภาพของ VDO และ เสียง จะแปรผันตามความเร็ว internet ของผู้ใช้งาน รวมทั้งผู้ใช้งานยังสามารถเลือกคุณภาพของ VDO ได้เองอีกด้วย

สิ่งที่น่าสนใจอีกอย่าง คือ Netflix recommendation system

คือระบบที่แนะนำสิ่งที่เกี่ยวข้อง สิ่งที่น่าสนใจ สิ่งที่ผู้ใช้อาจจะคาดไม่ถึง เป็นระบบที่นำเอา Machine learning เข้ามาประยุกต์ใช้งาน ซึ่งเป็นระบบที่มีชื่อเสียงอย่างมาก ไม่แพ้ระบบของ Amazon เลย สามารถอ่านเพิ่มเติมได้จาก Learning a Personalized Homepage

สุดท้าย Netflix ยังได้สร้าง opensource project ออกมาให้ใช้อีกด้วย

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

Big Data
Data persistence
Build and Delivery tool
Performance
Security

สามารถดูเพิ่มเติมได้ที่ Github :: Netflix

เป็นอย่างไรบ้าง สำหรับโครงสร้าง และ วัฒนธรรมองค์กร แบบคร่าว ๆ ของ Netflix ? มันน่าสนใจไหม ?

android-icon

จากบทความเรื่อง Android Performance Improvement for SlideShare ทำการอธิบาย วิธีการปรับปรุงประสิทธิภาพการทำงานของ SlideShare App บน Android มีเป้าหมายเพื่อ

ให้ app มีประสิทธิภาพที่ดีขึ้น
ให้ผู้ใช้งาน app สามารถใช้งานได้ราบรื่นขึ้น
ลดจำนวนการ crash ของ app ลง

มาดูว่าทีมพัฒนา SlideShare app เขาทำกันอย่างไรบ้าง ?

มี 3 เรื่องที่ทีมพัฒนาเน้นสำหรับการปรับปรุง app

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

Image loading
JSON parsing
Data model storage

มาดูรายละเอียดของแต่ละเรื่องกัน

1. เรื่องการ load ภาพ (Image loading)

ทีมพัฒนาใช้งาน opensource library ในการ load ภาพ ไม่ว่าจะเป็น Picasso และ Glide โดย library ต่าง ๆ เหล่านี้ล้วนมีปัญหาเรื่อง memory ทั้งนั้น เนื่องจากข้อมูลรูปภาพจะถูกจัดเก็บใน memory ถึงแม้ว่าอาจจะไม่ทำให้ app หยุดทำงาน แต่ก็ทำให้การใช้งาน app ไม่ราบรื่น และกระตุกในตอนที่ต้องเลื่อนหน้าไปมา ปัญหามันเกิดจากรูปภาพมีขนาดใหญ่นั่นเอง ส่งผลให้ตัว Garbage Collector มันหยุดทำงาน ดังนั้น ทีมพัฒนาจึงต้องทำการ optimize การ load รูปภาพโดยด่วน เพื่อให้ใช้ memory น้อยลง จะได้ลดปัญหาต่าง ๆ ลงไป สิ่งที่ทีมพัฒนาได้สร้างขึ้นมา คือ library ของตัวเอง เพื่อจัดการการ load รูปภาพโดยเฉพาะ ซึ่งมีความสามารถในเรื่อง bitmap pooling และ การ recycle bitmap โดยการทำงานจะต้องขึ้นอยู่กับเวอร์ชันของ Android อีกด้วย (ยากมากมาย) !! ประกอบไปด้วย ก่อน Android Lollipop Bitmap จะถูก decode ด้วย inPurgeable flag ทำการจัดเก็บ bitmap ที่จะ load และ cahing ไว้ใน ashmem ซึ่งแน่นอนว่า ไม่ได้อยู่ใน Java HEAP ดังนั้นทำให้มั่นใจได้ว่าตัว Garbage Collector จะไม่มีทางหยุดทำงานอย่างแน่นอน แสดงการทำงานดังรูป

ตั้งแต่ Lollipop เป็นต้นไป จะทำการเก็บ bitmap ไว้ให้อยู่แล้ว และไม่สามารถใช้ inPurgeable flag ได้แล้วเนื่องจากมัน deprecated ไปแล้ว ส่วนการ reuse bitmap จะใช้งานผ่าน inBitmap รวมทั้งตัว Garbage Collector มันทำงานแบบ background process ใน ART ซึ่งหมายความว่า ข้อมูล bitmap จะไม่อยู่ใน JAVA HEAP ซึ่งหมายความว่าปัญหาต่าง ๆ จะหมดไป แสดงการทำงานดังรูป

สามารถดูเพิ่มเติมได้ที่ Android Developer :: Managing Bitmap Memory

2. การ parser ข้อมูลในรูปแบบ JSON (JSON parsing)

รูปแบบข้อมูลในการติดต่อสื่อสารระหว่าง app กับ server side คือ JSON ดังนั้น

ใน Android app ต้องแปลงข้อมูลจาก JSON มายัง data model เพื่อใช้งาน
ใน Android app ต้องแปลงช้อมูลจาก data model ไปยัง JSON ก่อนที่จัดส่งไปยัง server side

ซึ่งการแปลงข้อมูลไปมาเช่นนี้ คือการใช้ resource ของ device นั่นเอง (Resource driven) คำถาม คือ แล้วจะใช้ library จัดการข้อมูล JSON ตัวไหนดีล่ะ ? คำตอบ JSON parser ที่มีมาให้ใน Android SDK ทำงานได้ช้า แถมใช้ memory เยอะอีก แถมไม่มี stream parsing อีก ( ก่อน Honeycomb ) ดังนั้นตัดตัวนี้ไปได้เลย ทางทีมพัฒนาได้ลองใช้ library หลาย ๆ ตัว ไม่ว่าจะเป็น Jackson, JSON, LoganSquare

สุดท้ายพบว่า LoganSquare ตรงกับความต้องการ และมีประสิทธิภาพในการทำงานดีที่สุด

3. การจัดเก็บข้อมูล data model ( Data model storage )

โดยปกติข้อมูลที่ใช้บน Android app จะต้องมีการเก็บ caching data ไว้ใช้เสมอ เพื่อประสิทธิภาพการทำงานของ app ที่ดี การทำงานประกอบไปด้วย

การจัดเก็บข้อมูล
การอ่านข้อมูล

ดังนั้น เราต้องการที่จัดเก็บข้อมูล หรือ database บน Android ที่มีความเร็วในการอ่าน และ เขียน สูง ๆ โดยทีมพัฒนาเริ่มใช้งาน SQLite ก่อน แต่เมื่อมีการอ่าน และ เขียนในปริมาณที่สูง ๆ รวมทั้งจำนวนข้อมูลที่มาก และ ซับซ้อนขึ้นเรื่อย ๆ พบว่า มันได้กลายเป็นปัญหาคอขวดของ app ไป ดังนั้น ทีมพัฒนาจึงได้นำ key-value data มาใช้ นั่นก็คือ SnappyDB เริ่มจากการนำมาใช้แทนที่ SharedPreference ก่อน เพราะว่า SharedPreference จะมีปัญหาเมื่อจำนวน key มันมีปริมาณมาก ๆ ตอนนี้ยังไม่ได้นำมาใช้แทนที่ SQLite นะ แต่ในอนาคตทีมพัฒนากำลังทำอยู่ และ อยู่ในแผนอีกด้วย

จากการแก้ไขปัญหา 3 เรื่องนี้ ทีมพัฒนาก็ได้ทำ benchmark ซึ่งได้ผลดังนี้

จำนวน memory ที่ถูกใช้งานลดลงไป 47% โดยจำนวน memory สูงสุดใช้ไปเพียง 40% เท่านั้น
ปัญหาเรื่องตัว Garbage Collector หยุดทำงาน ลดลงไป 92%
เมื่อนำ LoganSquare มาใช้สำหรับการ parsing JSON พบว่าทำงานเร็วขึ้น 15%

แต่ก็ยังมีปัญหาอื่น ๆ ให้แก้ไข และ ปรับปรุงต่อไป โดยสิ่งที่ต้องการ และ เป็นเป้าหมายหลักของทีมพัฒนา คือ Android app crash-free for 99.9 %

นี่คือวิธีการปรับปรุงประสิทธิภาพ Android app ของ Slideshare นะ น่าจะมีประโยชน์สำหรับ Android developer กันบ้าง ลองนำไปศึกษา และ ใช้งานกันดูครับ

are-you-too-busy-to-improve2

มาดู 6 รูป ที่สะท้อนถึงการพัฒนาตัวเราเอง ทีม และ องค์กร แต่ส่วนใหญ่มักจะอ้างว่า เราไม่มีเวลา เราไม่ว่าง เรามีงานเยอะมาก ๆ คนน้อย งานเยอะ คำถาม คือ แล้วคุณทำการพัฒนาตัวเองอย่างไร ? ข้อมูลต่าง ๆ นำมาจาก blog เรื่อง Are you too busy to improve?

รูปที่ 1 :: Are you too busy to improve ?

เป็นรูปที่คิดว่า ทุก ๆ คน น่าจะเคยเจอมาบ้าง เป็นคำถามที่น่าจะทิ่มแทงใจ ใครหลาย ๆ คน ลองถามตัวเองสิ ? are-you-too-busy-to-improve2

รูปที่ 2 :: Are you too busy to innovate ?

ถ้าคุณต้องการเปลี่ยนแปลงไปยังสิ่งใหม่ ๆ ถ้าคุณต้องการปรับปรุง คุณจะไม่บอกว่า ไม่มีเวลา หรอกนะ แต่คุณจะต้องสร้างเวลานั้นขึ้นมา เพื่อทำการปรับปรุง และเปลี่ยนแปลงอยู่อย่างต่อเนื่อง (Continuous Improvement) are-you-too-busy-to-innovate1

รูปที่ 3 :: Planning for lower utilization is good for both improvement and flow

ในการวางแผนงาน ควรที่จะแบ่งเวลาไว้สำหรับการพัฒนา และ ปรับปรุงด้วยเสมอ ไม่มีใครที่จะทำงานหนัก ๆ แล้วได้ผลออกมาดีหรอกนะ แบ่งเวลาไว้พัฒนาตัวเองบ้างนะ เพื่อเพิ่มคุณภาพ และ ความสามารถของคุณ planning-for-lower-utilization

รูปที่ 4 :: Small batches is good for both improvements and flow

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

รูปที่ 5 :: See yourself as a gardener

ทำตัวคุณให้เหมือนกับคนดูแลสวน ลองคิดดูสิว่า ถ้าคุณไม่ดูแลสวนเป็นเวลานาน ๆ หญ้าจะสูงขนาดไหน ต้นไม้จะขึ้นรกสวนขนาดไหน สวนจะอัตรายสักเพียงใด ซึ่งเป็นสิ่งที่ไม่ดีเลย ใช่ไหม ? ดังนั้น จะต้องทำการดูแลสวนเป็นประจำทุกวัน นั่นก็เปรียบเหมือนตัวเราเอง ซึ่งต้องทำสิ่งต่าง ๆ ให้ดี ซึ่งต้องพัฒนาปรับปรุงสิ่งที่ทำให้ดีขึ้นอยู่อย่างเสมอ see-yourself-as-a-gardener

รูปที่ 6 :: We are what we repeatedly do. Excellence, then, is not an act, but a HABIT

นี่คือ หัวใจของ Continuous Improvement เราจะทำการพัฒนา และ ปรับปรุงตัวเราเองไปทุกวัน อยู่อย่างสม่ำเสมอ จนมันกลายเป็นส่วนหนึ่งของเรา จนมันกลายเป็นนิสัยของเราไปแล้ว ไม่ได้มีใครมาสั่งการ หรือ บังคับให้ทำ ตัวอย่างเช่น การสร้าง software ที่มีคุณภาพที่ดีขึ้นมา excellence-is-a-habit

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

PR-cover

กลับมาอีกครั้งสำหรับงาน BarCamp Bangkhen 2015 ซึ่งเป็นงานที่ทุก ๆ คนสามารถกำหนดได้เองว่า อยากจะพูดเรื่องอะไร อยากจะฟังเรื่องอะไร จากทั้งความรู้ และ ประสบการณ์ที่ดีและไม่ดี เอามาบอกเล่าบอกกล่าวให้เพื่อน ๆ และ คนอื่น ๆ รู้กัน รออะไรกันอยู่ล่ะ ลงทะเบียนกันเลย คำถามที่มักถามกันบ่อย ๆ เกี่ยวกับงาน BarCamp Bangkhen 2015

1. จัดที่ไหน และ เมื่อไร ?

จัดขึ้นในวันอาทิตย์ที่ 22 พฤศจิกายน พ.ศ. 2558 ณ อาคารนานาชาติ 17 (IUP) คณะวิศวกรรมศาสตร์ มหาวิทยาลัยเกษตรศาสตร์ หรือดูแผนที่จาก Google Map ได้เลย

2. BarCamp มันคืออะไร ? เป็น Bar เที่ยวกลางคืนหรือเปล่านะ ?

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

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

3. ทำไมต้องมางาน BarCamp Bangkhen ด้วยล่ะ ?

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

เทคโนโลยี
ทริปท่องเที่ยว
สอนธุรกิจ
รีวิวเกมส์
เอาตัวรอดในดินแดนซอมบี้
และอื่นๆอีกมากมาย

4. ช่องทางการติดต่อ และ ดูรายละเอียดต่าง ๆ เพิ่มเติมล่ะ มีไหม ?

มีสิทางนี้เลย

Website: www.barcampbangkhen.org
Facebook: http://facebook.com/barcampbangkhen
Twitter: @barcampbangkhen

แล้วเจอกันในงานครับ สนุกแน่นอน งานนี้จะเกิดขึ้น และ สนุกสนานได้ เมื่อมีทุก ๆ คนครับ ปล. Blog สรุปจากงานเมื่อปีที่แล้ว :: สรุปสิ่งที่แบ่งปันและได้รับจากงาน Barcamp บางเขน 2014 awesome

Manual-testing

manual-vs-automated-testing-which-of-them-is-in-demand

การสร้างชุดของ Automated test หรือ การทดสอบแบบอัตโนมัติ มันทำได้ยากมาก ๆ โดยเฉพาะพวกระบบ Legacy หรือ ระบบที่อยู่มาอย่างยาวนาน หรือ ระบบที่ไม่ได้เขียน Automated test มาตั้งแต่เริ่มต้น รวมทั้งยังพบว่า ทีมพัฒนาส่วนใหญ่จะไม่ลงทุนเพื่อเขียนอีกต่างหาก เนื่องจากคิดว่า เราคงทำไม่ได้หรอก เนื่องจากคิดว่า มันสิ่งเปลืองเวลา เนื่องจากคิดว่า ระบบของเรามันแตกต่าง เนื่องจากคิดว่า ระบบที่เราสร้างมันไม่สามารถเขียน Automated test ได้หรอกนะ ซึ่งเป็นแนวคิดที่ไม่ถูกต้อง และ นำไปสู่หายนะในที่สุด ทำไมนะ ? บทความนี้ นำข้อมูลมาจาก Blog เรื่อง MANUAL TEST IS UNSUSTAINABLE

ลองย้อนกลับไปดูช่วงเริ่มต้นพัฒนาระบบดูสิ

จะพบว่าการทดสอบแบบ Manual มันทำได้ง่ายมาก ๆ มันใช้เวลาในการทดสอบน้อยมาก แต่เมื่อมันค่อย ๆ เกิดการเปลี่ยนแปลง เมื่อระบบใหญ่ขึ้น การทดสอบแบบ Manual จะใช้เวลานานขึ้น และ ยากขึ้น และดูเหมือนว่า การทดสอบแบบ Manual มันกลับกลายเป็นปัญหา เพราะว่า ไม่สามารถทดสอบได้ครบทุก ๆ feature นั่นหมายความว่า เราไม่สามารถหาปัญหา หรือ ความผิดพลาด ทั้งหมดได้ นั่นหมายถึง คุณภาพของระบบที่พัฒนา มันย่อมไม่ดีใช่ไหม ? นั่นหมายถึง คุณภาพของระบบที่พัฒนา มันไม่ยั่งยืนใช่ไหม ? ปล. บางที่ก็แก้ไขที่ปลายเหตุ ด้วยการเพิ่มคนทดสอบไปสิ !! บางที่ก็กลับไปกดดัน ให้ทดสอบดี ๆ และคาดหวังผลลัพธ์ที่สุดยอด !! สิ่งที่มักพบเจออยู่เป็นประจำ คือ Feature ใหม่ทำงานได้ แต่ feature เก่ากลับทำงานไม่ได้ Bug เก่าที่เคยแก้ไขไปแล้ว กลับมาอีกครั้งหนึ่ง วนแบบนี้ไปเรื่อย ๆ ไม่จบไม่สิ้น แต่ไม่เคยจำกัน ทำไมนะ !!

ปัญหามันมาจาก ความสามารถในการพัฒนา และ ทดสอบ มันมีเท่าเดิม

แสดงดังรูป

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

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

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

ลองถามตัวคุณเองสิว่า เรายังจะมาพูด หรือ อ้างว่า เราไม่มีเวลา มาสร้าง Automated test หรอกนะ กันอยู่อีกหรือไง ?

Boy+Scout+1

จาก blog เรื่อง The Programmer's Oath โดยคุณ Robert C. Martin อธิบายถึงคำสัญญาที่ programmer ที่ดีทุกคนพึงมี และ ปฏิบัติ จึงนำมาแปลตามที่เข้าใจ มาดูกันว่ามีอะไรบ้าง ?

ด้วยเกียรติของ Programmer ข้าพเจ้าขอสัญญาว่า

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

แล้วคุณล่ะ จะให้คำสัญญาหรือไม่ ?

ปล. นึกถึงตอนเรียนลูกเสือสามัญเลยนะ

big_data2

ข้อมูลที่น่าสนใจเกี่ยวกับแนวโน้มที่สำคัญ ๆ ของ Big Data ทั้งปี 2015 จาก Tableau Report :: Top 7 Trends in Big Data for 2015 ซึ่งทำให้เห็นว่าทั้งปี 2015 นั้น Big Data มันทำให้เกิดการเปลี่ยนแปลงอะไรบ้าง ประกอบไปด้วย 7 เรื่องดังนี้

1. Big Data gets cloudy

แน่นอนว่าในปี 2015 นั้นเรื่องของระบบ Cloud ได้รับความนิยมสูงมาก ๆ และมีอัตราการใช้งานที่สูงขึ้นอีกมากด้วย ซึ่ง Big Data ก็เช่นกัน ดังจะเห็นได้จาก บริษัทในให้บริการ Big Data บนระบบ Cloud เติบโตอย่างต่อเนื่อง เช่น Amazon Redshift และ Google Big Query

2. ETL gets personal

ประมาณ 80% ของการวิเคราะห์ข้อมูล จะอยู่ที่กระบวนการเตรียมข้อมูล (Data preparation) ดังนั้น เครื่องมือต่าง ๆ ที่เกี่ยวกับการเตรียมข้อมูล ไม่ว่าจะเป็นการ cleansing data ไม่ว่าจะเป็นการแปลงชนิดข้อมูล ไม่ว่าจะเป็นการแปลงรูปแบบข้อมูล จึงได้รับความนิยม และ ต้องการสูงมาก ๆ

3. SQL or NoSQL ?

เป็นคำถาม และ ประเด็นในการถกเถียงกันอย่างมากในปัจจุบัน แต่หลัก ๆ แล้ว NoSQL นั้นถูกสร้างมาเพื่อ Big Data มีเป้าหมายหลักเพื่อ

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

ดังจะเห็นได้ว่ามี product ในตระกูล NoSQL ออกมามากมาย และ ได้รับความนิยมสูงด้วย ไม่ว่าจะเป็น MongoDB, Cassandra และ Couchbase เป็นต้น

4. Hadoop :: Part of the new normal in data storage

ในโลกของ Big Data นั้น Hadoop ได้เข้ามาเป็นตัวหลักสำหรับการจัดเก็บข้อมูลไปแล้ว ซึ่งใช้งานร่วมกับ database ชนิดอื่น ๆ ได้ด้วย ดังจะเห็นได้จาก commercial tool จากหลาย ๆ บริษัทนั้น สามารถทำงานร่วมกับ Hadoop ได้แล้ว ไม่ว่าจะเป็น SAP, HP, IBM ดังนั้น Hadoop มันกลายเป็นคู่ขวัญกับ Big Data ไปแล้ว หรือบางคนอาจจะเรียก Hadoop แทน Big Data ก็เป็นได้

5. You will start trying to fish in the data lake

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

6. The big data ecosystem will start to change form

เมื่อสิ่งต่าง ๆ เปลี่ยนไป ไม่ว่าจะเป็น เรื่องของวิธีการแก้ไขปัญหา เรื่องของเทคโนโลยี เรื่องของเครื่องมือ เรื่องของข้อมูลที่เกิดขึ้นอย่างรวดเร็ว และ มากมาย เรื่องของการประมวลผลข้อมูล ทำให้เกิดสิ่งต่าง ๆ รอบข้างขึ้นมามาย รวมถึง Big Data ด้วยเช่นกัน โดยเฉพาะเรื่องของ Massively Parallel Processing (MPP) จะเปลี่ยนไปมากมาย

7. IOT (Internet of Things) will continue to grow, driving new data solutions

คงปฏิเสธไม่ได้ว่า IoT นั้นกำลังได้รับความนิยม พร้อมทั้งก่อให้เกิดข้อมูลจำนวนมากมาย และ รวดเร็วอย่างมาก ทำให้เกิดแนวทางการรับมือ และ แก้ไขใหม่ ๆ ขึ้นมา ทั้งการจัดเก็บ ประมวลผล และ สรุปผลออกมา ดังจะเห็นได้ว่าทาง Cisco, IBM และ Amazon ก็ได้ออก solution และ เครื่องมือมารองรับด้วยเช่นกัน แน่นอนว่า ปีต่อ ๆ ไปจะมีเครื่องมือต่าง ๆ ออกมาอีกมากมาย

จากแนวโน้มทั้ง 7 ข้อที่เกี่ยวข้องกับ Big Data

น่าจะพอทำให้เห็นว่า เราควรจะเตรียมตัว เตรียมความพร้อมอย่างไรบ้าง เพื่อที่จะจัดการกับข้อมูล เพื่อให้สามารถสร้างรายได้จาก Big Data เพื่อให้สามารถเห็นโอกาสใหม่ ๆ จาก Big Data

วันนี้คุณพร้อมกับ Big Data แล้วหรือยัง ?

craftsman

จาก blog เรื่อง คำมั่นสัญญาของ Programmer ที่ดีทุกคน พึงปฏิบัติ มีคำถามว่า แล้ว Craftsmanship มันคืออะไร เป็นอย่างไร และ ต้องทำอย่างไรบ้าง ดังนั้น จึงนำมาสรุปไว้กันหน่อย

Software Craftsmanship คืออะไร ?

Craftsmanship is doing what you love and doing it right.

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

แต่จำไว้ว่า Craftsmanship มันไม่ใช่เป้าหมายของเรา แต่มันคือ วินัยที่ต้องกระทำไปตลอด

แล้วจะก้าวไปสู่ Craftsmanship ได้อย่างไร ?

สิ่งแรกสำคัญมาก ๆ คือ คำว่าคุณภาพของสิ่งที่ทำ (Quality) คุณภาพนั้นไม่สามารถต่อรองได้ คุณต้องทำให้ดีที่สุดเท่าที่จะทำได้ ( Your best, not the best ) สิ่งที่สอง คือ ต้องมีความเชื่อว่า จะต้องทำให้ดีขึ้นกว่าเดิมเสมอ ดังนั้น เมื่อเราเห็นสิ่งใด หรือ ไปทำอะไรก็ตาม เราจะหาทางเพื่อปรับปรุงสิ่งนั้นให้ดีขึ้นกว่าเดิม หยุดติ หยุดพูด แล้วลงมือทำให้มันดีขึ้นซะ ผลที่ได้ คือ สิ่งที่คุณทำอยู่มันจะดีขึ้นอย่างแน่นอน สิ่งที่สาม คือ ประสบการณ์ ประสบการณ์ และ ประสบการณ์ ประสบการณ์จากการลงมือทำ ประสบการณ์จากความผิดพลาด ประสบการณ์มันทำให้เราเห็นว่า สิ่งใดควรทำ สิ่งใดไม่ควรทำ สิ่งใดที่คือจุดอ่อน สิ่งที่ควรปรับปรุง แก้ไข ดังนั้น ถ้าอยากมีประสบการณ์ ต้องลงมือทำ คิดอย่างเดียว มันไม่ได้ช่วยอะไรนะ ดังนั้น Craftsmanship ประกอบไปด้วย

คุณภาพ (Quality)
ความเชื่อ ความหลงไหล (Passion)
ประสบการณ์ (Experience)

กลับมาเรื่องของ Software Craftsmanship กันต่อ

โดยที่มี Manifesto of Software Craftsmanship ด้วยนะ ว่าด้วยเรื่องของ Professional Software Development ควรที่จะ ฝึกฝนในการสร้างงานที่เต็มเปี่ยม 3 อย่างข้างต้น รวมทั้งยังสอนผู้อื่นอีกด้วย เพื่อให้ผลลัพธ์ที่ได้ คือ สิ่งที่มีคุณค่า ประกอบไปด้วย

Not only working software but also well-crafted software

ไม่ใช่เพียงส่งมอบ software ที่ทำงานได้เท่านั้น แต่ต้องเป็น software ที่มีคุณภาพสูง

Not only responding to change but also steadily adding values

ไม่ใช่เพียงพร้อมรับต่อการเปลี่ยนแปลงเท่านั้น แต่สิ่งที่เพิ่มเข้าไป ต้องเป็นสิ่งที่เพิ่มคุณค่าอีกด้วย

Not only individuals and interactions but also a community of professionals

ไม่ใช่เพียงการพูดคุย หรือ ทำงานเพียงส่วนตัว หรือ ทีมเท่านั้น แต่ยังต้องสร้างเป็น community ของ professional ขึ้นมา หลาย ๆ ที่จะเรียกว่า Community of Practice (CoP)

Not only customer collaboration but also productive partnerships

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

เพิ่มเติมจาก VDO เรื่อง Craftsmanship and Ethics

โดยคุณ Robert C. Martin ได้พูดถึงสิ่งต่าง ๆ ที่นักพัฒนา software ที่ดี และ Professional programmer ควรปฏิบัติ เพื่อปรับปรุงตัวเราเอง อธิบายไว้ว่า สิ่งที่นักพัฒนา software สร้างออกไปคือ code ดังนั้น ถ้าต้องการปรับปรุงอย่างแรกเลยก็คือ ปรับปรุง code ซึ่งเราควรปรับปรุงเล็ก ๆ และ บ่อย ๆ แล้วเราจะพบว่า code ของเรามันดีขึ้นอยู่เสมอ แต่โชคไม่ดีสำหรับโลกของการพัฒนา software ที่เรามักจะทำการแก้ไข และ ปรับปรุง code ให้ดีขึ้น เมื่อเราเจอว่ามันแย่ (ส่วนใหญ่ใช้เวลานานมากกว่าจะเจอ) ซึ่งมันคือปัญหาที่ใหญ่มาก ๆ สำหรับการพัฒนา software ลองถามตัวเราเองสิว่า มีกี่ครั้งที่ code แย่ ๆ มันทำให้เราทำงานได้ช้า ? เชื่อเถอะว่า เยอะ !! คำถาม แล้วทำไมเราเขียน code แย่ ๆ เหล่านั้นขึ้นมากันล่ะ ? ตอบได้เลยว่า เราไม่มีเวลาที่จะเขียน code ให้เร็วนะสิ !! ปัญหาที่แท้จริงของเรา คือ เราพยายามไปหา code แย่ ๆ หลังจากที่เขียนไปแล้วนาน ๆ เช่น วันพรุ่งนี้ สัปดาห์หน้า เดือนหน้า หรือ ปีหน้า สาเหตุที่ต้องแก้ไข เพราะว่า code เหล่านั้นมันทำให้เราทำงานได้ช้าลง !! แต่การแก้ไขที่แท้จริง คือ ต้องแก้ไขเดี๋ยวนี้ ณ ตอนนี้ ไม่ต้องรอแก้ไข หรือ ทำทำให้มันเสร็จไปก่อน นี่คือสิ่งที่นักพัฒนา software ที่ดีต้องทำ อย่าลืมว่า Later == Never ซึ่งใน VDO ได้แนะนำแนวคิด และ แนวปฏิบัติ ให้มากมาย โดยส่วนใหญ่จะเป็นแนวปฏิบัติที่อยู่เบื้องหลังของ Agile practice และ Extreme Programming (XP) ไม่ว่าจะเป็น

Short Iteration development
Pair programming
Test-Driven Development (TDD)
Clean code
หลีกเลี่ยง Big Design Up Front (BDUF)
Increase improvement
Don’t write bad code
100% code coverage แต่ห้ามเอามาเป็น KPI นะ !!
Avoid debugging
Use good tools
No Grand Redesigns หรือ อย่า Rewrite นั่นเอง
Continuous Integration
Align Authority with Responsibility
Manual Test Scripts are Immoral !!
QA Should Find Nothing

ปิดด้วยประโยคง่าย ๆ แต่สำคัญ คือ

The only way to go fast is to go well. (Go fast Go well) แปลง่าย ๆ ว่า มีทางเดียวเท่านั้นที่คุณจะไปได้เร็ว คือ ทางที่ดี

สุดท้าย Love your craft everyday นะครับ

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

คุณล่ะคิดว่า Software Craftsmanship เป็นอย่างไร ? มาเรียนรู้ และ ฝึกฝนกันครับ

Screen Shot 2558-11-21 at 11.18.45 PM

จาก Engineering blog ของ Pinterest เรื่อง Deploy software at Pinterest ทำการอธิบายเรื่องการ deploy ระบบงานว่าเป็นอย่างไร รวมไปถึงขั้นตอนการพัฒนา และ แก้ไข Bug อีกทั้งเครื่องมือต่าง ๆ เพื่อให้แต่ละทีมทำงานร่วมกันได้อย่างมีประสิทธิภาพ มาดูในรายละเอียดกันหน่อย

เริ่มด้วยเครื่องมือต่าง ๆ ที่ใช้งาน

Github Enterprise สำหรับจัดการเวอร์ชัน ของ code, จัดการ code review , การ merge code และใช้งาน API ต่างๆ
Jenkins สำหรับจัดการระบบ Continuous Integration เพื่อทำการ build และ ทดสอบ unit test ของแต่ละการเปลี่ยนแปลง
Zookeeper สำหรับจัดการสถานะ และ บอกแต่ละ node ของ server ว่าทำงานอยู่บน code เวอร์ชันอะไร
Amazon S3 สำหรับจัดเก็บผลการ build รวมทั้งให้สำหรับ share data ของระบบอีกด้วย ซึ่งสามารถรองรับการขยายตัวได้ง่าย

Build pipeline ของระบบเป็นอย่างไร ?

เนื่องจากระบบของ Pinterest นั้นมันดีมาก ๆ สามารถที่จะทำการ deploy code จาก branch master ไปยัง production server ได้ตลอดเวลา ดังนั้นมาดูกันว่ามีขั้นตอนการทำงาน หรือ build pipeline อย่างไร แสดงดังรูป ซึ่งไม่ได้เยอะเลยนะ !!

โดย Software Engineering แต่ละคนจะทำงานตามขั้นตอนนี้เสมอ

เมื่อต้องพัฒนา feature ต้องทำการสร้าง branch ขึ้นมา ด้วยคำสั่ง git branch
เมื่อพัฒนาเสร็จแล้ว ให้ทำการ commit และ push ขึ้น Github Enterprise
ทำการสร้าง และ ส่ง Pull Request การเปลี่ยนแปลง
จากนั้น Jenkins ทำการ run automated test เพื่อตรวจสอบว่า Pull Request นั้น ๆ มันทำงานได้ถูกต้อง
ทางผู้ดูแล code หลักจะทำการ approve และ Jenkins ทำการ merge code ไปยัง branch master
ระบบจะมี trigger เมื่อทำการ merge code ไปยัง branch master เพื่อทำการ run automated ในข้อ 4 อีกรอบ
เมื่อทำการทดสอบผ่าน ทำการสร้าง branch jenkins-stable ขึ้นมา จากนั้นทำการสร้าง TAR file ของระบบ และ upload ไปยัง Amazon S3
ระบบที่ทำการ deploy แบบอัตโนมัติ ก็จะทำการ copy TAR file จาก Amazon S3 ไป deploy ทันที
ส่วนระบบที่ทำการ deploy แบบ manual อยู่ก็เข้าไป copy มาจาก Amazon S3 เอง

ส่วนการ deploy ของ Pinterest จะเรียกว่า Atomic Deploy System

ซึ่งแก้ไขปัญหาของการ deploy ไม่ต้องทำการ restart server ใด ๆ เลย การ deploy แบบนี้ทำให้ service ที่ต่างไม่ต้องหยุด หรือ ปิดการใช้งานระบบอีกต่อไป นั่นคือให้ทำการทั้ง version เก่า และ ใหม่ ไปเลย ใช้วิธีการสลับที่เรียกว่า Flip flop แสดงดังรูป

คำอธิบาย ถ้าเราต้องการ deploy ระบบงาน version B มีขั้นตอนการทำงานดังนี้

Zookeeper ทำการส่งข้อมูลไปยัง Varnish (Load Balance) ว่า version A จะไม่ใช้งานแล้วนะ
Varnish รอทำการเปลี่ยน
ทำการ Rollout ระบบ นั่นคือ uninstall version A และ install version B
เมื่อทำการ install version B เรียบร้อยแล้ว จะทำการแจ้งไปยัง Varnish ว่า version B พร้อมแล้วนะ
Varnish ก็จะทำงานตามการแจ้ง คือเปลี่ยนไปใช้งานที่ version B แทน
นั่นคือ ในตอนนี้ version ปัจจุบันของระบบคือ version B แล้ว

สามารถอ่านเพิ่มเติมได้ที่ Stealthy shipping with atomic deploys

สิ่งที่น่าสนใจมาก ๆ คือ Design Principle

Don’t touch the deployed code directly

นั่นคือ script ของการ deploy ห้ามแตะต้อง หรือ แก้ไขโดยตรง มันคืออะไรกันนะ ? ในช่วงเริ่มต้นของ pinterest นั้น ทำการจับเก็บ script การ deploy ไว้ที่ repository เดียวกับ code แต่เมื่อระบบใหญ่ขึ้น รวมทั้งมีการพัฒนาเครื่องการ deploy ขึ้นมา ทำให้ต้องย้าย script การ deploy ไปยัง repository ของระบบการ deploy ซะ รวมทั้งเปลี่ยนจากการใช้งาน git command ไปใช้ Github API แทน ซึ่งทำให้การ deploy รวดเร็วขึ้น และลดจำนวน dependency ต่าง ๆ ออกไป โดยสิ่งที่ต้องการ คือ ต้องการให้ขั้นตอน deploy มันเหมือนกันทั้งหมด ไม่ว่าจะพัฒนาด้วยภาษาโปรแกรมอะไรก็ตาม ทำให้ทุก ๆ คนมีขั้นตอนการ deploy เดียวกัน อีกทั้งพยายามจะให้ระบบทำงานแบบอัตโนมัติได้มากที่สุดเท่าที่จะทำได้ และสิ่งที่ต้องคิดเพิ่มคือ ในแต่ละขั้นตอนมันทำให้การทำงานง่ายขึ้นไหม ? ถ้าทำไปแล้ว มันทำให้ชีวิตยากขึ้น ก็ไม่น่าทำนะ !! เช่น ทำให้การ deploy ง่ายขึ้นหรือไม่ ?

Crash early, Crash often !!

Biggest challenges ของทีมมีอะไรบ้าง ?

Provisioning system
Configuration management
Python Packaging ซึ่งพบว่า PIP ไม่ตอบโจทย์ในการทำงาน และ มีปัญหาอย่างมาก ดังนั้นต้องใช้การจัดการรูปแบบอื่น ๆ
การสร้าง service ใหม่ ๆ ให้ง่ายสำหรับการ configuration และ deploy

Screen Shot 2558-11-22 at 3.28.35 PM

ปีนี้ไม่ได้ไปร่วมงาน Agile Tour Bangkok 2015 เลยได้แต่ตามอ่านจาก feed และ blog ต่าง ๆ แทน ซึ่งมีหนึ่ง blog ที่น่าสนใจเขียนไว้ที่ InfoQ.com คือ Real-life Agile Scaling - Henrik Kniberg's Opening Keynote at Agile Tour Bangkok จึงได้นำมาแปล และ สรุปตามที่เข้าใจ เป็นดังนี้

เริ่มต้นด้วยปัญหาในการขยาย Agile ออกไปมากกว่า 1 ทีม

ซึ่งมันเป็นเรื่องที่ยาก และ บ่อยครั้งผลที่ออกมากลับแย่ลงกว่าเดิมอีก ดังนั้นมาดูกันว่า Scaling Agile มันคืออะไร และมีสิ่งใดบ้างที่องค์การต่าง ๆ ต้องรับมือ ปรับเปลี่ยน เนื่องจากพบว่าคนที่ลงมือทำ กลับไม่รู้ และ ไม่เข้าใจว่า ผลกระทบจากการปรับเปลี่ยนมันเป็นอย่างไรบ้าง ? ดังนั้นมาเริ่มกันเลย ก่อนอื่นผมชอบรูปนี้มาก ๆ จาก Slide :: Scaling Agile at Lego Screen Shot 2558-11-22 at 2.10.49 PM

มาดูความเสี่ยง และ ค่าใช้จ่าย จากการ Scaling Agile กันว่ามีอะไรบ้าง ?

แสดงดังรูป 1 Risks of Scaling

โดยในการ Scaling Agile ต้องรู้และเข้าใจสิ่งต่าง ๆ เหล่านี้ มิเช่นนั้นจะนำไปสู่หายนะได้

How to slice the elephant ?
Team Structure
- How to tackle dependencies across teams
Feedback loop
- How to keep teams synchronised and aligned

มาดูรายละเอียดในแต่ละเรื่องกัน

How to slice the elephant ?

นั่นคือการแบ่งงานใหญ่ ๆ ออกเป็นงานย่อย ๆ แล้วเรียงลำดับของงานที่ทำตามลำดับความสำคัญนั่นเอง คล้าย ๆ กับ MVP (Minimum Viable Product) แต่ได้แนะนำขั้นตอนการเลือก และ แบ่งงานดังนี้

Earliest testable
Earliest usable
Earliest lovable

แสดงดังรูป 2 Earliest Testable Product

Team Structure

Feature team ดีกว่า Component team อย่างแน่นอน แต่มันมีความเสี่ยงอย่างมากต่อองค์กรที่เป็นแบบ Silo อย่างแข็งแกร่ง ดังนั้นจึงแนะนำให้ทีมเป็นแบบ hybrid ไปก่อน นั่นคือ ผสมผสานระหว่าง feature และ component team เพราะว่าในองค์กรใหญ่ มักจะมีความซับซ้อนเยอะ มีพวก blackbox technology เยอะ ดังนั้น จึงต้องการคนจาก component team มาด้วย แสดงดังรูป 3 Team Structures

How to tackle dependencies across teams ?

แน่นอนว่าในการทำงานต้องทำงานร่วมกันมากกว่า 1 ทีม บ่อยครั้งพบว่าจะเกิด dependency ระหว่างทีมเยอะมากมาย ตัวอย่างเช่น เราจะสร้าง feature A ไม่ได้ ถ้าอีกทีมไม่สร้าง B ขึ้นมาก่อน !! ดังนั้น จะแก้ไขปัญหาของ dependency ระหว่างทีมได้อย่าง ? โดยวิธีการที่แนะนำก็คือ Platform team แสดงดังรูป 4 Dependencies

รวมทั้งยังได้แนะนำการสร้างทีม ควรประกอบไปด้วย

ทีมมีจำนวนสมาชิกระหว่าง 3 - 9 คน
สมาชิกทุกคนในทีมทำงานแบบ full time ทำงานด้วยกัน ซึ่งต้องเป็นทีมที่มั่นคง ไม่แยกออกจากกัน
ทีมมีเป้าหมายเดียวกัน ร่วมกัน และ ชัดเจน
ทีมต้องรู้ว่าใครคือลูกค้า ไม่ว่าจะทั้งจากภายใน หรือ ภายนอก
บางทีมต้องการคนมาช่วยจัดเรียงลำดับความสำคัญงานของลูกค้า เช่น Product Owner
ทีมต้องเป็นแบบ Cross-functional นั่นคือทีมต้องมีความสามารถทั้งหมดที่จำเป็นต่อการส่งมอบสิ่งที่มีคุณค่าให้ลูกค้า
ทีมต้องมีความยืดหยุ่น ไม่มีใครเป็นคอขวดของทีม

แสดงดังรูป 5 teams of teams

Feedback loop

ในระดับทีมนั้น เรื่องของ feedback น่าจะพอเป็นที่เข้าใจกันดีใน Agile ไม่ว่าจะเป็น

Continuous Integration
Daily standup meeting
Iteration planning
Retrospective
Showcase

ยิ่งใน Scaling Agile ยิ่งต้องการ feedback loop ที่รวดเร็วเช่นกัน แต่ละทีมต้องทำการ sync ข้อมูลกันเสมอ แต่ละทีมต้องมีช่วงของ iteration เหมือนกัน แต่ละทีมต้องทำการ integate product กันอยู่อย่างสม่ำเสมอ แต่ละทีมต้องทำการ sync การวางแผนงานต่าง ๆ แต่ละทีมต้องมีการทำ release checkpoint ร่วมกัน แสดงดังรูป 6 Feedback Loops

สิ่งที่ขาดไม่ได้เลยคือ Continuous Integration

เนื่องจากการทำงานร่วมกันหลาย ๆ ทีม เรื่องคุณภาพของงาน ของ product มันต้องอยู่ในระดับที่สูง มันจะทำให้เห็นว่ามี dependency อะไรบ้าง มันจะทำให้รู้ปัญหาได้อย่างรวดเร็ว ส่วน Continuous Delivery นั้นมันก็มีประโยชน์ เอาไว้สำหรับ product ที่ต้องการ feedback เร็วจากลูกค้า แต่ไม่ได้จำเป็นเท่า Continuous Integration แสดงดังรูป 7 CI CD

ต่อมาคือเรื่องบทบาทของ Leadership

เป็นอีกหนึ่งส่วนที่ช่วยให้การ Scaling Agile ประสบความสำเร็จ ซึ่งจะช่วยสร้างสิ่งแวดล้อมที่เอื้อต่อการทำงานเป็นทีม ไม่ใช่เข้ามาสั่ง สั่ง สั่ง อย่างเดียว !! อ่านเพิ่มเติมเรื่อง What is an Agile Leader ได้ซึ่งอธิบายได้ละเอียดมาก ๆ แสดงดังรูป 8 Aligned

Agile มันไม่ใช่เป้าหมายของการเดินทาง

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

สุดท้ายทำการสรุปเป็น Key Take Aways ดังนี้

Small as possible
Agile is a means, not a goal
No right to Wrong way
No one-size-fit-all
Build feedback loop at all level

แสดงดังรูป 10 Summary

ไม่ได้ไปร่วมงาน แต่ได้อ่านได้แปล ก็ ok ล่ะ !!

elasticsearch-logo

หลังจากที่รู้จักกับ Elasticsearch ตั้งแต่ verison 0.9 มาจนถึง 2.0 นั้น มีความสามารถต่าง ๆ เปลี่ยนแปลงไปมากมาย หนึ่งในนั้นคือ Mapping หรือ การกำหนดโครงสร้างของข้อมูล มาดูว่าควรทำการกำหนด mapping อย่างไร เพื่อให้ทำงานได้ดียิ่งขึ้น สามารถใช้ได้ทั้ง version 1.7 และ 2.0

1. กำหนดชนิดของข้อมูลในแต่ละ field ให้ถูกต้อง และ เหมาะสม

โดยปกติ Elasticsearch นั้น เราไม่จำเป็นต้องกำหนด mapping ของข้อมูล เนื่องจากจะสร้าง mapping ให้อัตโนมัติจากข้อมูลนั่นเอง (Dynamic mapping) แต่ถ้าผลการทำงานอาจจะไม่ถูกต้อง และ เหมาะสมกับความต้องการ ดังนั้นแนะนำให้ทำการสร้าง mapping ขึ้นมาก่อน หรืออาจจะใช้ index template ก็ได้ ตัวอย่างเช่น

ข้อมูลชนิด geo_point สำหรับเก็บข้อมูลตำแหน่ง latitude และ longitude
ข้อมูลชนิด date สำหรับข้อมูล timestame

2. ในแต่ละ field ควรกำหนดให้ Elasticsearch ทำการ analyse และ จัดเก็บเท่าที่จำเป็น

โดยปกติ Elasticsearch นั้น จะทำการ analyse และ จัดเก็บข้อมูลของทุก ๆ field ซึ่งไม่ค่อยมีผลมากนักสำหรับตอนเริ่มต้นของระบบ

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

ดังนั้น เพื่อลดการใช้ resource ต่าง ๆ โดยไม่จำเป็น ต้องทำการพิจารณาว่า field ใดควร analyse และ จัดเก็บบ้าง ? หรือ field ไหนไม่ถูกใช้งานเลย ? ซึ่งสามารถกำหนดได้ใน mapping นั่นเอง ตัวอย่างเช่น ข้อมูลของหน้า web page ซึ่งเป็น HTML ซึ่งใช้งานเพียงแสดงผลอย่างเดียว ไม่เคยทำการค้นหาเลย ดังนั้น ควรกำหนดให้จัดเก็บอย่างเดียว แต่ไม่ทำการ analyze

3. ใช้งาน Multi-fields หรือ Raw field เมื่อต้องการทั้ง Analyse และ Aggregation

ตัวอย่างเช่น ข้อมูลของ Tag ซึ่งสามารถจัดเก็บข้อมูลที่มีพวก white space ได้ เช่น ช่องว่าง และ - เป็นต้น และข้อมูล Tag ต้องนำมาใช้งาน เพื่อนับว่าแต่ละ Tag มีข้อมูลที่เกี่ยวข้องจำนวนเท่าไร ? แน่นอนว่า ต้องทำการนับผ่าน Aggregation นั่นเอง ซึ่งเป็นปัญหา classic ที่ทุก ๆ คนจะต้องเจอ การแก้ไขที่เหมาะสมที่สุด คือ การใช้ multi-field โดย field หลัก กำหนดให้ทำการ analyze และ จัดเก็บ ส่วน raw field จะกำหนดไม่ให้ analyze เพื่อนำมานับจำนวนข้อมูลที่เกี่ยวข้องได้อย่างถูกต้อง

4. ให้ระวังการกำหนดจำนวน Replica และ Shard ของแต่ละ index

เนื่องจากเราไม่สามารถแก้ไขค่าเหล่านี้ได้ หลังจากการ indexed ข้อมูลไปแล้วนะ ดังนั้น ควรทำการประมาณการว่า ข้อมูลมีอัตราการเติบโตเท่าไร เพื่อจะได้เตรียมแผนการรับมือไว้ได้ โดยค่าของ Replica นั้น เราจะเพิ่มก็ต่อเมื่อ

ต้องการเครื่องมาช่วยรองรับผู้ใช้งานที่มากขึ้น
ต้องการเพิ่มเรื่องของ Availability
ต้องการ scale up

แนะนำให้เริ่มค่า replica ที่ 1 ส่วนจำนวนของ Shard ขึ้นอยู่กับขนาดของข้อมูล ซึ่งแต่ละ Shard ไม่ควรเกิน 30 GB

5. ถ้าไม่อยากให้ Elasticsearch cluster ตาย แนะนำให้กำหนดจำนวน field ซะ

จำนวน field มีเท่าที่จำเป็นเท่านั้น อย่าเผื่อ !! อ่านเพิ่มเติมได้ที่ Mapping Explosion

6. สำหรับ Elasticsearch 1.x ให้ทำการกำหนดค่าของ doc_values=true

เพื่อไม่ให้ Elasticsearch ทำการ analyse ข้อมูลชนิด String เป็นวิธีการลดจำนวน memory ที่ใช้งานลงไปอย่างมาก ส่วนใน Elasticsearch 2.0 ไม่ต้องทำอะไร เพราะว่าเป็นค่า default อยู่แล้ว

7. แนะนำให้ทำการ reindex มากกว่าลบและสร้าง mapping ใหม่นะครับ

เนื่องจากการลบและสร้าง mapping ใหม่มันใช้ resource ที่สูงมาก ๆ แต่ง่ายและสะดวก แต่ในการทำงานจริง ๆ จะไม่ทำการลบข้อมูลจริง ๆ นะ เพียงทำการกำหนด delete flag = true ไว้เท่านั้นเอง ดังนั้น คุณจะยังไม่ได้พื้นที่ของ harddisk กลัมบโดยทันทีนะ ซึ่งจะได้กลับมาเมื่อทำการ merge segment เสร็จเรียบร้อย ส่วนใน Elasticsearch 2.0 นั้นไม่สามารถลบ mapping ได้แล้วนะ ต้องลบ และ สร้าง index ใหม่เท่านั้น

ทั้ง 7 ข้อ เป็นคำแนะนำสำหรับการจัดการกับ mapping

เนื่องจากปกติ mapping จะถูกสร้างอย่างอัตโนมัติเมื่อทำการ indexed ข้อมูล แต่เพื่อให้ Elasticsearch ทำงานได้อย่างมีประสิทธิภาพกว่าเดิม ควรที่จะต้องทำการปรับแต่ง mapping กันหน่อยนะครับ น่าจะพอมีประโยชน์บ้าง สำหรับคนที่ศึกษา และ นำ Elasticsearch ไปใช้งาน