cc :: somkiat

unit-testing

มีโอกาสอธิบายเรื่อง Developer testing ให้กับทีมพัฒนาฟังประมาณ 1-2 ชั่วโมง ซึ่งหนึ่งในนั้นคือเรื่อง Unit testing ซึ่งเป็นสิ่งที่ดีและสำคัญ แต่มักไม่ค่อยมีใครทำ !! เนื่องจากเป็นสิ่งที่ช่วยทำให้ทุกคนรวมทั้งตัวเราเองมั่นใจว่า

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

เพื่อลดการทำงานซ้ำ ๆ เพื่อลดการ debug ให้น้อยลง เพื่มเพิ่มความเข้าใจว่า กำลังจะทำ หรือ แก้ไขปัญหาอะไร นั่นคือ การกำหนดเป้าหมายแบบสั้น ๆ และทำการเดินแบบนี้ไปเรื่อย ๆ อาจจะช้าหน่อยแต่มั่นคง และจะเร็วขึึ้นอย่างต่อเนื่อง ซึ่งทางพี่หนุ่มแห่งสยามชำนาญกิจทำการบันทึก VDO ความยาวประมาณ 15 นาทีไว้ จึงได้นำมาแบ่งปันกันเล็กน้อย หวังว่าน่าจะเป็นอีกหนึ่งแนวคิดที่นักพัฒนา software ควรสนใจและใส่ใจ ตลอดจนฝึกฝนจนเป็นความสามารถทั่วไปที่พึงมี (Skill) และเป็นวินัยที่ขาดไม่ได้เลย (Discipline)

เราไม่สามารถบังคับให้ใครทำได้ แต่เราสามารถบอก แนะนำ และ พาทำได้

https://www.youtube.com/watch?v=5G_k1sd9kRA

reducing_apk_file_size

ในการพัฒนา Android app นั้นมีหลายสิ่งที่ต้องให้ความสำคัญ หนึ่งในนั้นคือ ขนาดของไฟล์ APK และ จำนวน method ใน dex bytecode

ซึ่งนักพัฒนาควรจะ ทำให้ขนาดของไฟล์ APK ให้เล็กและจำนวน method น้อย ๆ

แต่ก่อนอื่นต้องรู้ข้อมูลเรื่องเหล่านี้อยู่ตลอดเวลาเมื่อเกิดการเปลี่ยนแปลงขึ้น เพื่อนำข้อมูลเหล่านี้มาวิเคราะห์ และ ปรับปรุงต่อไป ดังนั้นมาดูกันว่ามีวิธีการอย่างไรบ้าง ?

เมื่อไปค้นหาพบว่ามี library ให้ใช้ด้วย

ตัวอย่างเช่น Dexcount gradle plugin ซึ่งทำการคำนวณเรื่องต่าง ๆ ให้เลย เช่น

จำนวน method
จำนวน field

การใช้งานนั้นก็ง่ายมาก ๆ เพียงแค่ทำการแก้ไขไฟล์ app/build.gradle ดังนี้ [gist id="c52e882d093e9d5840fa8b8106c0feed" file="build.gradle"] จากนั้นทำการ run ด้วยคำสั่ง [code] $./gradlew clean assembleDebug [/code] แสดงผลการทำงานดังนี้ [code] Total methods in app-debug.apk: 18163 (27.71% used) Total fields in app-debug.apk: 8516 (12.99% used) Methods remaining in app-debug.apk: 47372 Fields remaining in app-debug.apk: 57019 [/code] และยังสร้างผลการทำงานออกมาในรูปแบบไฟล์อีกด้วย เช่น

debug.csv สรุปจำนวน method และ field
debug.txt สรุปรายละเอียดแยกเป็น package
รวมทั้ง Chart ที่สวยงาม

แสดงดังรูป apk01

ส่วน Chart แสดงดังนี้ apk02

ส่วนขนาดของไฟล์ APK นั้นก็มี library ให้ใช้งานอีก เช่น APK size plugin

แต่อาจจะจะยากไป เพราะว่าใช้คำสั่ง stat บน OS ต่าง ๆ ได้ (ผมใช้ Mac นะ) [code] $stat -f%z app-debug.apk [/code] จากนั้นก็เขียนใส่ไว้ในไฟล์ เท่านี้ก็น่าจะเพียงพอแล้วสำหรับขนาดของไฟล์ APK

เมื่อการเตรียมการต่าง ๆ เรียบร้อยแล้ว นำมาทำงานบน Jenkins ดีกว่า

เนื่องจากเราต้องการรู้ว่าทุก ๆ ครั้งที่มีการสร้างไฟล์ APK นั้น ขนาดของไฟล์มีขนาดเท่าไร ? จำนวน method และ field มีเท่าไร ? ที่สำคัญเราจะเห็นประวัติหรือแนวโน้มต่าง ๆ อีกด้วย ให้ทำการติดตั้ง plugin ชื่อว่า Jenkins Plot Plugin apk03

จากนั้นใน job สำหรับ build ไฟล์ APK ให้ทำดังนี้ apk04

ทำการเพิ่ม Plot เข้าไปในส่วนของ Post Build Action ดังนี้ apk05

ส่วนของจำนวน method ก็เพิ่มเข้าไปเหมือนกันนะครับ ผลของ Plot ต่าง ๆ เป็นดังนี้ apk06

เพียงเท่านี้ก็สามารถดูแนวโน้มของไฟล์ APK แบบง่าย ๆ ได้แล้ว ส่วนการวิเคราะห์และปรับปรุงไฟล์ APK เพิ่มเติม แนะนำให้ใช้ APK Analyzer ใน Android Studio 2.2 ได้เลยนะครับ

Reference Websites https://medium.com/@mreichelt/android-apk-size-dexcount-charts-on-jenkins-ae518e961818#.7qkef26z0 http://cyrilmottier.com/2014/08/26/putting-your-apks-on-diet/

XFT-team-Idé-till-release_004

จากบทความเรื่อง The importance of size and proximity แปลมาจากบทความที่เป็นภาษาสวีเดนอีกที อธิบายเกี่ยวกับทีมทั้งจำนวนคนในทีม และ ความใกล้ชิดของคนในทีม ซึ่งมันจะสะท้อนถึงการทำงานร่วมกันของทีม ดังนั้นจึงนำมาแปลและสรุปสิ่งที่น่าสนใจไว้นิดหน่อย

ถ้าทีมมีขนาดใหญ่

ถ้าแต่ละคนในทีมอยู่ห่างกันมาก ถ้าแต่ละคนในทีมอยู่ต่างที่ ต่างประเทศกัน ถ้าแต่ละคนในทีมทำงานแบบ part time ถ้าทีมต้องการผู้เชี่ยวชาญมากมายมาช่วยเหลือ มันจะส่งผลให้ขั้นตอนการทำงานซับซ้อนเป็นอย่างมาก ซึ่งเป็นต้นเหตุของปัญหามากมายตามมา !!

แต่เมื่อนำเอาแนวคิด Agile มาปรับใช้งาน

ไม่ว่าจะเป็น Scrum, Kanban, Lean UX เน้นไปที่การทำงานร่วมกันของคน ที่มีความสามารถที่หลากหลายและแตกต่างกัน (T-shaped skills) ซึ่งเป็นความสามารถที่จำเป็นต่อการสร้าง product นั้น ๆ เมื่อมารวมกันแล้วสามารถทำงานร่วมกัน เพื่อที่จะเปลี่ยนจากสิ่งที่คิดมาเป็น product ซึ่งพร้อมที่จะ release หรือปล่อยออกไปให้ผู้ใช้งานใช้ได้เลย โดยเรียกทีมลักษณะนี้ว่า Cross functional team แสดงดังรูป

โดย Cross functional team จะมีขั้นตอนการทำงานที่เรียบง่ายมาก ๆ ดังนี้

มีสมาชิกประมาณ 3-5 คน ซึ่งต้องมีความรู้และประสบการณ์ในงานนั้น ๆ
สมาชิกต้องทำงานแบบ Full time เสมอ และต้องทำงานที่ product นี้แบบ 100% ไปเลย ห้ามมีงานอื่นมาแทรกหรือขัดจังหวะโดยเด็ดขาด
สถานที่การทำงานของทีมควรเป็นห้องขนาดใหญ่และสะดวก เพื่อเปิดให้ทีมได้แบ่งปันและเรียนรู้ให้ได้มากที่สุด โดยควรมี whiteboard เพื่อใช้วาดเขียนสิ่งต่าง ๆ ซึ่งจำเป็นต่อการพูดคุยอย่างมาก (Communication) และ โต๊ะเก้าอี้ที่สามารถเคลื่อนย้ายได้ง่ายเพื่อให้ทีมสามารถโยกย้ายปรับเปลี่ยนพื้นที่การทำงานตามที่ต้องการ (Self-reorganize)
ให้ทีมพูดคุยโดยตรงกับผู้ใช้งานจริง ๆ อยู่บ่อย ๆ เพื่อให้ทีมได้รับ feedback โดยตรงและรวดเร็ว ดังนั้นจำเป็นต้องส่งมอบงานบ่อย ๆ (Deliver in small increament)
ทีมควรกำหนดเป้าหมายให้ตรงกัน ดังนั้นควรหยุดมาพูดคุยกัน รับฟังความคิดเห็น เพื่อแก้ไขและปรับปรุงให้การทำงานของทีมดีขึ้นอยู่อย่างบ่อย ๆ

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

แต่บ่อยครั้งมักพบว่า มันไม่ได้เป็นแบบนี้เลย !!

ซึ่งทำให้เกิดขั้นตอนการทำงานที่ซับซ้อน หรือ มี overhead สูง นั่นคือที่มาของปัญหาอีกมากมาย เช่น

สมาชิกแต่ละคนทำงานแยกกันคนละที่
สมาชิกแต่ละคนมีงานแทรกและถูกขัดจังหวะจากงานอื่น ๆ
มากคนมากความ !!

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

คำถามที่น่าสนใจคือ ทีมสามารถมีจำนวนเยอะ ๆ ได้ไหม ? ตอบได้เลยว่า ได้ แต่ควรเตรียมรับมือกับมันด้วยเสมอ เพื่อลด หรือ ไม่ให้เกิดปัญหาตามมา คำถามต้องมาคือ จะลดจำนวนสมาชิกในทีมอย่างไร ? ก่อนอื่นทีมต้องมั่นใจก่อนว่า สมาชิกที่เหลือนั้นมีความสามารถเพียงพอ ที่จะสร้าง product ได้หรือไม่ ? ถ้ามั่นใจคุณก็สามารถลดจำนวนสมาชิกลงได้ สามารถอ่านเพิ่มเติมได้ที่ The importance of size and proximity

น่าจะพอทำให้เห็นรายละเอียดและเหตุผลของ Cross functional team นะครับ ว่าจะรับมือกันอย่างไรบ้าง ?

android-coding-style

เนื่องจากตามไปดูว่าทีมพัฒนาของ Android project รวมทั้ง contributor ต่าง ๆ เขามี Coding Style หรือรูปแบบการเขียน code อย่างไรกันบ้าง ? ซึ่งไปเจอเอกสารเรื่อง Coding Style for Contributor จึงนำมาสรุปเรื่องที่น่าสนใจไว้นิดหน่อย

โดยเอกสารนี้ไม่ใช่ guideline หรือ คำแนะนำในการเขียน code นะ แต่เป็นสิ่งที่นักพัฒนา และ contributor ของ Android project ต้องทำตามเสมอ มิเช่นนั้น code เหล่านั้นจะไม่ผ่านการ approve นั่นเอง

ส่วนใหญ่เป็นไปตามกฎของภาษา Java และเพิ่มเติมกฎต่าง ๆ เข้าไปดังนี้

1. ห้าม Ignore exception โดยเด็ดขาด

ตัวอย่างที่ห้ามทำเป็นดังนี้ [gist id="b09680406522e9514176899e908aed3c" file="1.java"] สิ่งที่ควรทำคือ การจัดการ exception ต่าง ๆ ให้ตรงกับกรณีนั้น ๆ เสมอตัวอย่างเช่น โยน exception ออกไปให้ผู้เรียกใช้งานเสมอ [gist id="b09680406522e9514176899e908aed3c" file="2.java"] ทำการสร้าง exception ใหม่ในแต่ละกรณี ก่อนโยนออกไปให้ผู้เรียกใช้งาน [gist id="b09680406522e9514176899e908aed3c" file="3.java"] ทำการกำหนดค่าที่เหมาะสม เมื่อเกิดข้อผิดพลาดขึ้นมา [gist id="b09680406522e9514176899e908aed3c" file="4.java"] ทำการโยน RuntimeException ออกไปเลย ซึ่งอันตรายอย่างมาก ต้องใช้อย่างระมัดระวัง !! [gist id="b09680406522e9514176899e908aed3c" file="5.java"] สุดท้ายถ้ามั่นใจมาก ๆ ก็ให้ใส่ comment ไว้ เพื่ออธิบายเหตุผล [gist id="b09680406522e9514176899e908aed3c" file="6.java"]

2. อย่าดักข้อผิดพลาดด้วย Generic exception โดยเด็ดขาด

[gist id="b09680406522e9514176899e908aed3c" file="7.java"] สิ่งที่ควรทำคือ

ดักจับข้อผิดพลาดใน catch แยกกันไปในแต่ละกรณี
ทำการ refactor code เพื่อแยกการทำงานออกจากกัน

3. ต้องทำการ import library แบบเต็ม ๆ (Fully Qualify Imports)

[code] import foo.Bar; [/code]

4. ในแต่ละ method ควรมีขนาดเล็ก ๆ

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

5. ประกาศตัวแปรเท่าที่ใช้งานเท่านั้น

ตัวอย่างเช่น [gist id="b09680406522e9514176899e908aed3c" file="8.java"] คำถามที่น่าสนใจคือ ทำไมต้องประกาศตัวแปรด้วยล่ะ ? ถ้าแยกออกมาเป็น method และ return ค่าที่ต้องการออกมาเลย น่าจะเหมาะสมกว่าหรือไม่ ? [gist id="b09680406522e9514176899e908aed3c" file="9.java"]

6. ใช้งาน Space แทน Tab เสมอ !!

เป็นสิ่งที่นักพัฒนามักไม่พูดคุยและตกลงร่วมกัน

7. เรื่องของการตั้งชื่อ มันสำคัญมาก ๆ

ชื่อของ field ที่ไม่ใช่ public และ ไม่ใช่ static ต้องขึ้นต้นด้วย m
ชื่อของ field ที่เป็น static ต้องขึ้นต้นด้วย s
ส่วน field อื่น ๆ ขึ้นต้นด้วยตัวอักษรพิมพ์เล็กเสมอ
ค่าคงที่ต้องเป็นตัวอักษรพิมพ์ใหญ่ และแต่ละคำคั่นด้วย underscore ( _ )

[gist id="b09680406522e9514176899e908aed3c" file="10.java"]

8. ชื่อของ test case ควรบอกว่าทดสอบ method อะไร และ กรณีใดเสมอ

[gist id="b09680406522e9514176899e908aed3c" file="11.java"]

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

mastering-programmer

จากบทความเรื่อง Mastering Programming เขียนโดยคุณ Kent Beck ได้อธิบายว่าเส้นทางสำหรับ Effective programmer ว่าควรเป็นอย่างไร จึงได้นำมาแปลและสรุปตามความเข้าใจของตัวเอง ในเรื่องของ Time และ Learning ซึ่งน่าจะมีประโยชน์ต่อ programmer บ้างนะครับ

เรื่องของการจัดการเวลา (Time) ประกอบไปด้วย

1. Slicing ทำการแบ่งปัญหาใหญ่ ๆ ออกเป็นปัญหาย่อย ๆ จากนั้นทำการเรียงลำดับความสำคัญตามความเหมาะสมต่อสถานการณ์นั้น ๆ ซึ่งทำให้เราเห็นว่าอะไรที่มีความสำคัญตามที่ต้องการ 2. One thing at a time ควรทำงานทีละอย่าง กินทีละคำ เพื่อทำให้เรา focus และมีสมาธิต่อสิ่งที่ทำ ซึ่งมันส่งผลดีต่องานนั้น ๆ เป็นอย่างมาก และช่วยทำให้เรารู้ feedback จากสิ่งที่ทำได้อย่างรวดเร็วขึ้น นั่นคือ เราพยายามลด overhead หรือ สิ่งที่ไม่จำเป็นออกไปให้มากที่สุด 3. Make it run, Make it right, Make it fast มันเหมือน ๆ กับ Make it work, Make it right and Make it fast นั่นเอง แต่ประเด็นหลักคือ เราต้องทำการ slice ปัญหาออกมา นั่นคือมี 3 ส่วน ลงมือทำแต่ละอย่างไปตามลำดับ ผลที่ตามมาคือ ง่ายต่อการเปลี่ยนแปลงนั่นเอง เคยไหมที่คิดแต่ละทำให้ระบบงานมันทำงานเร็ว ๆ แต่ยังไม่เคยทำให้ระบบงานมันทำงานได้เลย และสิ่งที่ทำอยู่นั้นมันถูกต้องหรือไม่ สุดท้ายก็ไม่สามารถแก้ไข หรือ เปลี่ยนแปลงอะไรได้เลย !! ได้เพียงปะผุไปวัน ๆ ... 4. Easy changes เมื่อเราพบว่าส่วนใดมันยากต่อการเปลี่ยนแปลงแล้ว สิ่งที่ต้องทำเป็นอย่างแรกคือ ทำให้ง่ายเข้าไว้ !! (Simple not easy) ซึ่งบางครั้งมันอาจจะยากก็ได้ (ยากง่ายของแต่ละคนไม่เท่ากัน) จากนั้นทำให้มันง่ายต่อการเปลี่ยนแปลง นั่นคือการ slice และ แยก (isolate) ออกมา 5. Concentration ถ้าคุณต้องการเปลี่ยนแปลงหลายสิ่งอย่างแล้ว ให้คุณทำการเรียงลำดับของสิ่งต่าง ๆ จากนั้นเริ่มทำการเปลี่ยนแปลงไปทีละอย่าง 6. Isolation ถ้าคุณต้องการแก้ไขเพียงบางส่วนเท่านั้น ให้พยายามแยกส่วนงานนั้นออกมาเพื่อแก้ไขให้ได้ 7. Baseline measurement ก่อนที่จะเริ่มทำอะไรควรมีตัวเลขตั้งต้นไว้สำหรับการวัดผลเสมอ เพื่อทำให้เรารู้ว่า หลังจากทำการแก้ไขแล้ว มันส่งผลออกมาอย่างไรบ้าง อย่าใช้แต่สัญชาตญาณและความรู้สึก !!

เรื่องของการเรียนรู้ (Learning) ประกอบไปด้วย

1. Call your shot ก่อนที่จะทำการ run code ของคุณ ลองคิด และ ทำนายก่อนสิว่า ผลการทำงานจะเป็นอย่างไร !! มันเหมือนบอกว่า เราควรเขียน test หรือ หยุดการมโนลงไปหรือเปล่านะ และให้เรารู้ตัวเองว่ากำลังทำอะไร ไม่ใช่ run code ไปเรื่อย ๆ ผิดตรงไหนก็แก้ที่นั่น ซึ่งไม่น่าจะเป็นเรื่องที่ดี 2. Concrete hypotheses เมื่อระบบงานที่สร้างทำงานไม่ถูกต้องตามที่คาดหวัง ก่อนอื่นต้องทำความเข้าใจก่อนว่า เราคิดอะไรผิดไปบ้าง ? ก่อนที่จะลงมือแก้ไขและเปลี่ยนแปลง นั่นคือการตั้งข้อสันนิษฐานนั่นเอง แต่ถ้ามันมีเยอะ ก็ให้พิจารณาก่อนว่ามันแตกต่างกันอย่างไรบ้าง ? เพราะว่า มันอาจจะเป็นเรื่องเดียวกันก็ได้ แต่สิ่งที่ต้องทำเสมอคือ คิด เข้าใจ ก่อนลงมือทำ 3. Remove extraneous detail พยายามขจัดสิ่งที่ไม่เกี่ยวข้องออกไป เช่นการเขียนรายงาน bug ต่าง ๆ ควรเขียนขั้นตอนการ reproduce bug ให้สั้นและกระชับที่สุด เมื่อทำการแก้ไข bug ให้แบ่งเป็นปัญหาย่อย ๆ ออกมา โดยเริ่มด้วย test case ที่สั้น และ ง่าย แน่นอนว่า ต้องเกี่ยวข้องกับ bug นั้น ๆ เมื่อต้องเริ่มใช้งาน API ใหม่ ๆ ให้เริ่มจากตัวอย่างง่าย ๆ ก่อนเลย เนื่องจากถ้าคุณเริ่มด้วยท่ายากแล้ว เมื่อเกิดผิดพลาดขึ้นมามันย่อมใช้เวลาและแรงเยอะ นั่นคือค่าใช้จ่ายที่สูงขึ้นมาก (มันแพงมาก ๆ) 4. Multiple scales การ scale นั้นมันเกิดได้หลายแบบผสมกัน ดังนั้นอย่าไปยึดติดมากนัก เนื่องจากปัญหามันอาจจะเกิดจากการออกแบบ ไม่ใช่จากการทดสอบ เนื่องจากปัญหามันอาจจะเกิดจากคน ไม่ใช่จากเทคโนโลยี

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

Strip-Le-code-des-autres-650-finalenglish-1

ของฝากก่อนนอน เห็นการ์ตูนเรื่อง Good Code จาก CommitStrip

ไม่แน่ใจว่า developer เข้าใจว่า Good code หรือ code ที่ดีมันเป็นแบบไหน ? และมีลักษณะแบบใดบ้าง ?

หรือว่าเป็นดังรูป !!

Strip-Le-code-des-autres-650-finalenglish-1

testing-00

ช่วงวันหยุด Developer มาหาหนังสืออ่านเพื่อเพิ่มเติมความรู้กันดีกว่า ผมขอแนะนำหนังสือเกี่ยวกับการทดสอบระบบ Web application ชื่อว่า The Way of the Web Tester

ปล. หนังสือเล่มนี้ยังเขียนไม่เสร็จนะครับ อยู่ในขั้น Beta อยู่ แต่มันน่าอ่านมาก ๆ เหมาะตั้งแต่ผู้เริ่มต้นจนถึงประสบการณ์สูง ๆ

โดยในหนังสือเล่มนี้จะอธิบายถึงสิ่งจำเป็นต่อการทดสอบระบบ Web Application

เพื่อให้พร้อมสำหรับการทดสอบแบบอัตโนมัติ เช่น

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

แบ่งเนื้อหาออกเป็น 2 ส่วน คือ

ความรู้พื้นฐานสำหรับการสร้าง Automated testing สำหรับระบบ web
ลงมือเขียน code และการสร้าง Automated test ที่ดี

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

ส่วนที่ 1

โดยเริ่มจากการอธิบายเรื่อง Pyramid Testing เพื่อทำให้เข้าใจว่า สิ่งที่เรากำลังจะสร้างขึ้นมานั้นคืออะไรกันแน่ ? เนื่องจาก developer ส่วนใหญ่เข้าใจไม่ตรงกัน !! แถมชนิดของการทดสอบมันก็เยอะอีกด้วย ดังนั้นจำเป็นต้องเข้าใจส่วนที่ 1 ก่อนนะครับ testing-01

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

ดังนั้นควรเข้าใจแนวคิดของ Pyramid testing ก่อน ซึ่งคิดโดยคุณ Mike Cohn ในหนังสือ Succeeding with Agile: Software development with Scrum แยกแต่ละเรื่องออกเป็นบท ๆ ไป ดังนี้ testing-02

ประกอบไปด้วย ชั้นบนสุดคือ User Interface หรือ UI Testing หรือบางครั้งเรียกว่า End-to-End testing เป็นการทดสอบเหมือนผู้ใช้งานจริง ๆ ชั้นรองลงมาคือ Integration testing คล้าย ๆ กับ UI Testing เพียงแต่ไม่ทดสอบผ่าน UI แต่ทดสอบในระดับ service แทน เหมือนการเขียนเส้นเชื่อมต่อระหว่างจุดเข้าด้วยกัน ชั้นล่างสุดคือ Unit testing เป็นส่วนที่เล็ก เร็ว แรงที่สุด เป็นการทดสอบในระดับ code ของนักพัฒนานั่นเอง โดยแนะนำให้อ่านจากบนลงล่างนะครับ และที่สำคัญสามารถจับคู่กับ Web Architecture ได้ดังนี้ testing-03

ส่วนการทำงานจริง ๆ มีข้อแนะนำดังนี้

ให้เริ่มจาก unit testing ให้มากที่สุด
ใช้ UI testing เท่าที่จำเป็น เนื่องจากมันใช้เวลาทดสอบสูง และ เปลี่ยนแปลงบ่อย

ส่วนที่ 2

จะลงในรายละเอียดของการสร้างชุดการทดสอบเลย ถ้าไม่ใช่ Developer อาจจะธาตุไฟเข้าแทรกได้ง่าย ๆ เลย โดยมีตัวอย่างเขียนด้วยภาษา Ruby ซึ่งเข้าใจได้ง่าย เช่น

รูปแบบการเขียน code
เรื่องการตั้งชื่อ
เรื่องการ Spacing และ Tab
การจัดการกับ code ที่ซ้ำซ้อน
การจัดการโครงสร้างของชุดการทดสอบ
การใช้งาน Test double หรือ Mocking
การแยกส่วนการทำงานต่าง ๆ ออกจากกัน
แนวคิดของ Test-Driven Development (TDD)

โดยสรุปแล้ว Web developer ไม่น่าพลาดหนังสือเล่มนี้ครับ

เนื่องจากพื้นฐานเป็นสิ่งที่สำคัญอย่างมากสำหรับการพัฒนาที่ยั่งยืน ถ้าฐานไม่แข็งแกร่งก็ยากที่จะขึ้นสูงได้

espresso-00

ใน Android Studio 2.2 Preview 3 นั้น ได้ปล่อย Espresso Test Recorder ใน Beta version ให้ลองใช้งานแล้ว ซึ่งเป็นความสามารถที่ขี้โม้ไว้ในงาน Google I/O 2016 นั่นแสดงว่า เราสามารถบันทึกการทดสอบ Android App ง่าย ๆ ด้วยการใช้งาน App แบบปกติ โดยผลที่ได้คือ ชุด code ของการทดสอบแบบอัตโนมัติ ซึ่งเราสามารถทำการแก้ไขได้อีกด้วย แต่ก็มีข้อจำกัดพอสมควร !! ดังนั้นมาทดสอบใช้งานกันดีกว่า เริ่มด้วย code ตัวอย่างแนะนำให้ใช้ Android Testing Codelab [code] git clone https://github.com/googlecodelabs/android-testing.git -b step-7 [/code] จากนั้นทำการเปิด project ด้วย Android Studio 2.2 Preview 3 ซึ่งเราสามารถใช้งานผ่านเมนู Run -> Record Espresso Test แสดงดังรูป espresso-01

จะขึ้นหน้าจอ Record Your Test ขึ้นมาดังรูป espresso-02

จะรอช้าอยู่ทำไมบันทึกสิครับ ให้ทำการเล่น App นั่นเอง จะขึ้นผลการบันทึกดังรูป espresso-03

เมื่อเล่นครบ Flow การทำงานของ App แล้ว ให้กดที่ปุ่ม Add Assertion เพื่อตรวจสอบว่า App ทำงานได้อย่างถูกต้องตามที่คาดหวังหรือไม่ ? จะแสดงการทำงานดังรูป espresso-04

จากนั้นทำการเลือก Element ที่ต้องการจะตรวจสอบ ดังรูป espresso-05

เมื่อเราพอใจแล้วให้ทำการบันทึก และ จบการทำงาน จะให้เรากำหนดชื่อ class ของ Espresso Test ดังรูป espresso-06

สุดท้ายแล้วจะได้ code ดังรูป ถ้าใครไม่เคยเขียน Espresso Test มาก่อนน่าจะมึนงงพอสมควร !! [gist id="c6e60fcb85c9be3086b25a5bd2f17825" file="NotesActivityTest.java"] จากนั้นให้ทำการทดสอบด้วยคำสั่ง [code] $./gradlew cAT [/code] ทุกอย่างผ่านเรียบร้อย !!! มันง่ายมาก ๆ นะ

ดังนั้นมาสรุปผลจากการทดลองใช้แบบคร่าว ๆ กันดีกว่า

เริ่มด้วยความช้า และ การกิน Memory ซึ่งถือเป็นเรื่องปกติของ UI Testing ดังนั้นใช้เท่าที่จำเป็นเท่านั้น ในแต่ละ Test class จะมีเพียง method หรือ test case เดียวเท่านั้น ซึ่งถือว่าเป็นเรื่องที่ดีเลยนะ ทำให้จัดการ test ได้ง่ายขึ้น สามารถใช้เฉพาะ code ที่เขียนอยู่ใน App ของเราเท่านั้นนะครับ เนื่องจาก Espresso Test มันสร้างมาจาก Instrumented Test ยังไม่สามารถใช้งานกับ WebView ได้ จากการใช้งานมันไม่สามารถจัดการ input ใน WebView และใส่ assertion ได้ ใช้ Assertion แบบพื้นฐานเท่านั้น ส่วนที่ซับซ้อนต้องมาเขียน code เอาเองนะ ส่วน feature อื่น ๆ เช่นพวก Idling resources ก็ต้องเขียนเองนะ

แต่สิ่งที่เห็นได้ชัดคือ

ช่วยให้เราเขียนชุดการทดสอบผ่าน UI Test ง่ายและสะดวกขึ้นเป็นอย่างมาก

จะได้ไม่มีข้ออ้างสำหรับการไม่เขียน test อีกแล้วนะ

และหวังว่าจะปรับปรุงความสามารถนี้ให้ดียิ่ง ๆ ขึ้นไป สำหรับใครที่เขียนเอง จะรู้สึกว่า ทำไมต้องมาใช้ความสามารถนี้ก็เป็นได้ เพราะว่า เขียนเองเร็วกว่าเยอะ !! แต่ถ้ามองในความสะดวกเริ่มจะสูสีกับ UI Test ของ XCode แล้วนะ ปล. ไม่ต้องคิดมากนะครับ เอกสารของ Espresso Test Recorder !! น่าจะทำการแก้ไขเร็ว ๆ นี้นะ espresso-07

Reference Website http://peirr.com/writing-android-tests-with-espresso-test-recorder/

fragile-00

จาก blog เรื่อง Espresso Test Record สำหรับการทดสอบ UI Test บน Android App ทำให้นึกถึงเรื่อง ทำไมเครื่องมือแบบ Record and Playback มันถึงทำให้การทดสอบแบบอัตโนมัติมีปัญหาเสมอ บางคนถึงกับบอกว่า มันไม่ได้ช่วยอะไรเลย แถมยังกลับมาทำร้ายกันอีก !!

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

จากประสบการณ์ที่ผ่านมาของการใช้เครื่องมือทดสอบแบบ Record and Playback

พบว่าถ้าระบบงานไม่มีการเปลี่ยนแปลงเลยมันจะดีมาก ๆ แต่ถ้าระบบมีการเปลี่ยนแปลงบ่อย ๆ เช่น element ต่าง ๆ ของหน้าจอมีการเปลี่ยนแปลง เพิ่มลบ สิ่งที่เกิดขึ้นคือ เราจะต้องทำการบันทึกใหม่ บ่อยครั้งเกิดชุดการทดสอบในหน้าเดิม ๆ เยอะมาก ๆ นั่นคือ เกิด duplication test ขึ้นมามากมาย บ่อยครั้งพบว่า UI Test นั้นมันพังบ่อยมาก ๆ (Fragile test/Broken test) ทั้งจากการเปลี่ยนแปลงต่าง ๆ ทั้งจากความไม่เสถียรของระบบ ทั้งจากความไม่เสถียรของเครื่องมือทดสอบ รวมทั้งชอบทำการทดสอบเมื่อระบบงานเสร็จทั้งหมด งานมันจึงเยอะ ระบบมันจึงแยะ ปัญหาก็เพียบสิครับพี่น้อง แถมคนทดสอบกับคนพัฒนาและคนให้ requirement ไม่คุยกันอีก !!

เมื่อลองไปค้นหาข้อมูลเพิ่มเติม

ก็เจอ Paper เรื่อง Why do Record/Replay Tests of Web Applications Break? ได้ข้อสรุปที่น่าสนใจว่า เมื่อ locator ต่าง ๆ บนหน้า UI เปลี่ยนแปลงชุดการทดสอบพังไปมากกว่า 70% ยังไม่พอนะ locator ต่าง ๆ บนหน้า UI ยังซ้ำกัน หรือ Duplication กันอีกด้วย ดังนั้นสิ่งที่ควรแก้ไขโดยด่วนสำหรับ Web Application คือ

อย่าใช้ XPath ในการเข้าถึง locator หรือ element ต่าง ๆ
ให้ใช้ id หรือ attribute เข้ามาช่วย
อย่าตั้งชื่อที่ซ้ำซ้อน

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

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

สุดท้ายแล้ว

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

ผมเชื่อว่าเราต้องทำการสร้างระบบที่ทดสอบได้ง่าย (Testability in your mind) ซึ่งมันเป็นสิ่งที่ดีกว่าการเลือกหรือสร้างเครื่องมือมาช่วยทดสอบ ไม่เช่นนั้นเราจะจมไปกับเครื่องมือนั้น ๆ โดยไม่สนใจ และ ใส่ใจเลยว่า ระบบที่สร้างขึ้นมามันทดสอบได้ง่ายหรือไม่

ถ้ายังงง และ มีข้อสงสัยให้กลับไปอ่านหนังสือเรื่อง The Way of Web Test Reference Websites http://www.software-testing.com.au/blog/2016/06/01/why-record-playback-almost-never-works-and-why-almost-nobody-is-using-it-anyway/ https://watirmelon.com/2016/06/01/test-automation-why-record-and-replay-fails/ https://blog.acolyer.org/2016/05/30/why-do-recordreplay-tests-of-web-applications-break/

git-push-force

วันนี้เจอประสบการณ์ไม่ค่อยดีสำหรับการใช้งาน git ด้วยคำสั่ง [code] $git push --force [/code] ผลที่ตามมาก็ไฟไหม้สิครับ ทั้ง code หาย ทั้ง commit history ต่าง ๆ หายไปหมด งานของเราอาจจะดี แต่ของคนอื่นหายหมด ภาพรวมคือ งานเข้าสิครับ !!

เป็นภัยต่อชีวิต เป็นพิษต่อทีมมาก ๆ

คำถามที่น่าสนใจคือ ทำไมเราต้องใช้ git push force ด้วยล่ะ ?

ตอบง่าย ๆ คือ มัน(มัก)ง่ายไงล่ะ ซึ่งมันเกิดจากเราทำอะไรผิดพลาดก็ไม่รู้ และส่งผลให้เราไม่สามารถ push code ขึ้นไปยัง repository ได้ ซึ่งเราสามารถใช้งานผ่านคำสั่งต่าง ๆ ของ git เพื่อแก้ไขได้เช่น

git commit --amend
git rebase
git reset

แต่บางครั้งเมื่อใช้สิ่งต่าง ๆ เหล่านี้ ก็ไม่สามารถ push code ขึ้นไปได้ นั่นคือปัญหาเรื่องของ commit history นั่นเอง ดังนั้นเราจึง git push force มันไปเลย !! ง่าย ๆ สบาย ๆ แต่พังกระจาย ถ้าไม่มีการสื่อสารที่ดีพอ หรือบางครั้งขี้เกียจ merge code ที่มันขัดแย้งกันเยอะ ดังนั้นจึงให้ตัวเราเองเป็นที่ตั้ง จากนั้น git push force มันไปเลย !!

ดังนั้นก่อนอื่นต้องทำความเข้าใจว่าผลที่ตามมาจากการกระทำมีอะไรบ้าง ?

มันจะเขียนทับการเปลี่ยนแปลงทั้งหมดเลยนะ ดังนั้นคุยกับทีมก่อนว่า ไม่มีใครที่จะเปลี่ยนแปลงอีกแล้วนะ ทำการ update สิ่งต่าง ๆ ให้เรียบร้อย แก้ไขสิ่งต่าง ๆ ให้เรียบร้อย จากนั้นจึงทำการ git push force จึงจะปลอดภัยมากขึ้น

แต่ถ้าต้องการใช้จริง ๆ แนะนำให้ใช้ git push - -force-with-lease ดีกว่านะครับ ซึ่งมันจะปลอดภัยต่อชีวิตอย่างมาก

สุดท้ายแล้วแนะนำให้ใช้ git push force เป็นทางเลือกสุดท้ายเท่านั้น

เช่นการลบ commit history ที่มีข้อมูลที่เป็นความลับ หรือเป็นสิ่งที่ไม่ต้องการให้มีจริง ๆ ซึ่งมันบ่งบอกว่า repository ของคุณมันแย่มาก ๆ หรือกระบวนการทำงานต้องปรับปรุงได้แล้วนะ Reference Websites https://robots.thoughtbot.com/git-push-force-with-lease https://developer.atlassian.com/blog/2015/04/force-with-lease/

security-00

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

สถิติของการใช้งาน Mobile
การเติบโตของ Mobile App ทั้ง Android และ iOS
สถิติของการใช้งาน Mobile App
สถิติของ Mobile App ที่โดนโจมตี
รูปแบบการโจมตี Mobile และ Mobile App

Mobile นั้นมีคุณสมบัติที่เหมาะสมต่อการโจมตีอย่างมาก

เนื่องจากมีคุณสมบัติดังนี้

พกพาได้ง่าย
หายได้ง่าย
ลืมได้ง่าย
ขโมยได้ง่าย
ขายได้ง่าย
ที่สำคัญ Online กับแบบ 24x7

ทำให้มีรูปแบบการโจมตีที่หลากหลาย ทั้งจากการโจมตีที่คนใช้งาน ทั้งจากการโจมตีที่ Mobile ซึ่งมีหลาย platform เช่น Android, iOS และ Window Phone ทั้งจากการโจมตีผ่าน App ซึ่งผู้พัฒนาไม่ใส่ใจ หรือ ไม่รู้ เช่นการจัดเก็บข้อมูลที่สำคัญโดยไม่เข้ารหัสอะไรเลย ทั้งจากการโจมตีผ่านระบบ Network ที่ไม่ปลอดภัย และอื่น ๆ อีกมากมาย

สิ่งที่แนะนำไปก็คือ Guideline และ Checklist สำหรับการโจมตีจาก OWASP Mobile Security Project

ซึ่งทำการทำแบบสำรวจและสรุปรูปแบบการโจมตี Mobile ไว้ 10 แบบ รวมทั้งสรุปวิธีการทดสอบในรูปแบบต่าง ๆ ไว้ให้ด้วย เป็นข้อมูลสำคัญที่ทางทีมพัฒนา Mobile App ต้องไม่พลาด แต่ส่วนใหญ่จะพลาด !! ประกอบไปด้วย security-01

ในปี 2015 นั้นทาง Veracode ทดสอบ Mobile App ว่าผ่าน OWASP Mobile Security หรือไม่ ?

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

Code Quality
Cryptographic issue
Information leakage

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

ทีมพัฒนามีความรู้เรื่องของ Secure coding หรือไม่ ?
ทีมพัฒนามีความรู้เรื่อง Security พื้นฐานหรือไม่ ?
ทีมพัฒนามีความรู้เรื่องของการเข้ารหัสข้อมูลหรือไม่ ?
ทีมพัฒนามีความรู้เรื่องการจัดเก็บข้อมูล และ ส่งข้อมูลให้ปลอดภัยหรือไม่ ?

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

จากปัญหาเรื่อง Code Quality หรือ คุณภาพของ Code

จึงทำการ Demo วิธีการ Reverse Engineering ของ Android App กันนิดหน่อย จากนั้นนำ code มาวิเคราะห์ต่อด้วยโปรแกรม Static Code Analysis เพื่อช่วยวิเคราะห์ว่า code ที่เขียนมานั้นเป็นอย่างไรกันบ้าง ? ซึ่งวิธีการก็ไม่ได้ยากอะไรเลย ใคร ๆ ก็ทำได้ มีขั้นตอนดังนี้

ทำการ Download ไฟล์ APK ออกมาจากมือถือ
ทำการ upload ไฟล์ APK ไปที่ http://www.javadecompilers.com/apk
จากนั้นก็จะเห็นข้อมูลทั้งหมดของ App ทั้ง code, configuration และ resource ต่าง ๆ
จากนั้นนำ source code มาวิเคราะห์ด้วย SonarQube

ได้ผลการทำงานดังนี้ ข้อมูลต่าง ๆ ในไฟล์ APK ดังนั้น APK มันก็แค่ Zip ธรรมดานี่เองนะครับ security-03

นำ code มาวิเคราะห์ก็เจอของดี ๆ ใน code เพียบ เช่น username และ password รวมทั้งวิธีการเขารหัสและส่งข้อมูลเป็นต้น !! และสรุปปัญหาต่าง ๆ ให้อีกด้วย security-04

สุดท้ายแล้วนี่คือข่าวร้ายของนักพัฒนานะครับ

ว่าคุณควรใส่ใจ code ที่เขียนให้มาก เพราะว่า code ของคุณมันอยู่ใกล้กับผู้ใช้งานมาก ๆ เรียกได้ว่าอยู่ในมือเลยดีกว่า ลองคิดดูสิว่า ถ้ามันอยู่ในมือคนไม่ดีแล้วจะเกิดอะไรขึ้นบ้าง !! ส่วนคนใช้งานก็ต้องระวังตัวเองไว้ให้มากเช่นกันครับ แต่ไม่ใช่ระแวงไปเสียทุกอย่างนะครับ และนี่คือส่วนหนึ่งของการโจมตีเท่านั้นนะครับ ยังมีอีกเยอะเลย !! โดย Slide การพูดอยู่ที่ SlideShare [slideshare id=63082160&doc=sck-mobile-application-security-160615074248&w=640&h=480]

devops

กระบวนการส่งมอบ Software (Delivery) ไปยัง Production server นั้น มันเป็นสิ่งที่มีความท้าทายและความเสี่ยงอย่างมาก ทั้งฝ่าย business ต้องคิดและวางแผนของ product ทั้งฝ่าย architect ต้องวางโครงสร้างและ technical solution ทั้งฝ่าย development ต้องสร้าง product ที่มีคุณภาพออกมา แน่นอนว่าต้องผ่านการทดสอบในรูปแบบต่าง ๆ มาอย่างหนักหน่วง ถึงแม้จะมีการเตรียมการและลงมือทำดีอย่างไรก็ตาม กระบวนการส่งมอบ Software ยังคงยากและอันตรายอย่างมาก

ปัญหาที่พบเห็นได้บ่อย ๆ คือ

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

ลดเวลา
ลดจำนวนคน

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

เริ่มที่กระบวนการส่งมอบ software

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

แนวคิดหลัก ๆ ของ DevOps ประกอบไปด้วย

การพัฒนาและทดสอบต้องอยู่บน environment ที่คล้ายหรือเหมือน production server
ทำการ deploy บ่อย ๆ
ทำการตรวจสอบเรื่องของคุณภาพอยู่ตลอดเวลา

จากแนวคิดของ DevOps นั้นมีแนวปฏิบัติที่ตอบได้นั่นก็คือ Continuous Delivery ในหนังสือ Continuous Delivery กล่าวไว้ว่า

The essence of my philosophy to software delivery is to build software so that it is always in a state where it could be put into production. We call this Continuous Delivery because we are continuously running a deployment pipeline that tests if this software is in a state to be delivered. By Jez Humble and Dave Farley

โดย Continuous Delivery คือวินัยในการพัฒนา software

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

จากรูปนั้นจะพบเจอคำต่าง ๆ มากมาย เช่น

Continuous Integration
Configuration Management
Deployment Automation
Continuous Deployment

โดยสิ่งต่าง ๆ เหล่านี้ต้องทำงานแบบอัตโนมัติ เพื่อลดความผิดพลาดต่าง ๆ ที่เกิดจากคน เพื่อลดการทำงานเดิมซ้ำ ๆ เพื่อจัดการ dependency ต่าง ๆ ได้ทั้งจากภายในและภายนอก เพื่อทำให้สามารถ deploy ระบบงานได้บ่อย ๆ เพื่อทำให้สามารถทดสอบระบบงานได้บ่อย ๆ เพื่อทำให้รู้ว่าขั้นตอนการทำงานมีปัญหาอะไรบ้าง เพื่อทำให้สามารถแก้ไขปัญหาได้อย่างรวดเร็ว เพื่อแสดงให้เห็นว่ากำลังทำอะไรและแต่ละขั้นตอนทำงานเป็นอย่างไร เพื่อทำให้มั่นใจว่า สามารถ deploy ในแต่ละ environment ได้ เพื่อทำให้การส่งมอบ software มันง่าย ๆ และทำได้ตามที่ต้องการ โดยทำงานเป็นรอบสั้น ๆ อาจจะเรียกว่า Iteration หรือ Sprint

และนี่คือแนวคิดและแนวปฏิบัติที่น่าสนใจ แน่นอนว่าต้องการคนที่มีความรู้ความสามารถ (People and Skill) และเครื่องมือที่เหมาะสมมาจัดการด้วยเสมอ (Toolsets)

Reference Websites DevOps in practice http://martinfowler.com/bliki/DevOpsCulture.html http://martinfowler.com/delivery.html

OSAutoBlogChartFinal

ช่วงวันหยุดมาดูกันหน่อยว่า เครื่องมือการทดสอบ Mobile App มีอะไรที่น่าสนใจบ้าง ซึ่งเน้นเครื่องมือที่เป็น Open source เพื่อแนะนำให้ Developer และ Tester/QA นำไปใช้งานได้ง่ายขึ้น มาดูกันว่ามีอะไรบ้าง ?

โดยทาง PerfectoMobile มีเงื่อนไขในการเลือกเครื่องมือดังนี้

ง่ายต่อการพัฒนาและทำทดสอบ เพื่อให้สามารถทำงานเป้นรอบสั้น ๆ ได้ดี
แต่ละทีมสามารถทำงานร่วมกันได้ เช่น Developer และ Tester/QA ใช้เครื่องมือเดียวกันได้
ความเหมาะสมในแต่ละ Platform เช่น Java สำหรับ Android, Swift/ObjectiveC สำหรับ iOS
สามารถทดสอบได้ดีทั้ง Emulator และ Device จริง ๆ
สามารถ integrate เข้ากับ IDE ที่ใช้พัฒนาได้
สามารถ Record ได้
Community
ความนิยมที่ Github

และอาจจะมีเงื่อนไขอื่น ๆ ขึ้นมาอีกได้ ขึ้นอยู่กับความต้องการของระบบนั้น ๆ

คำถามต่อมาคือ Use case ของระบบมีอะไรบ้าง ?

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

ทดสอบผ่าน User Interface
ทดสอบร่วมกับส่วนการทำงานต่าง ๆ ของ Mobile เช่น กล้อง, GPS และระบบ Network
เวอร์ชันของ OS และ API ต่าง ๆ
ต้องทดสอบบน Platform ต่าง ๆ ทั้ง Android และ iOS รวมทั้ง Web อีกด้วย

เครื่องมือที่น่าสนใจและได้รับความนิยมในปัจจุบัน

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

Selenium ใช้สำหรับทดสอบระบบ web application ซึ่งได้รับความนิยมสูงมาก
Appium ใช้สำหรับทดสอบ Mobile app ทั้ง Native และ Hybrid app
Calabash ใช้สำหรับทดสอบ Mobile app ซึ่งมีรูปแบบการเขียน BDD (BehaviourDriven Development) พัฒนาด้วยภาษา Ruby
Espresso ใช้สำหรับทดสอบ Android App ในปัจจุบันใน Android Studio สามารถทำการ Record Script การทดสอบได้แล้ว
XCUITest ใช้สำหรับทดสอย iOS app ซึ่งมากับ XCode IDE

เมื่อนำเงื่อนไขและคำถามจากด้านบนมาพิจารณาแล้ว แสดงผลดังรูป

ดังนั้นลองกลับมาตั้งคำถามและตอบตัวเราเองสิว่า

ระบบที่เรากำลังพัฒนาเป็นอย่างไร ? มี use case การทำงานและใช้งานอย่างไร ? ต้องการทดสอบอย่างไรบ้าง ? จากนั้นก็ลองเลือกเครื่องมือและนำไปใช้ดูครับ

sketch-microservice

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

แนวคิดจาก Object-Oriented Programming
แนวคิดจาก Conway’s Law
แนวคิดจาก Unix design philosophy

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

1. แนวคิดที่สำคัญมาก ๆ ของ Object-Oriented Programming คือ messaging

เป็นสิ่งที่ใช้ในการติดต่อสื่อสารระหว่างระบบ ถ้าเป็น Class ก็คือการรับส่งข้อมูลระหว่าง method นั่นเอง โดยข้อความที่ใช้สื่อสารกันนั้น ไม่สามารถแก้ไขได้ หรือ ทำการแก้ไขก็จะไม่กระทบต่อระบบ แต่ละระบบจะซ่อนสถานะของการทำงานเอาไว้ นั่นหมายความว่า แต่ละระบบจะทำงานแยกจากกันชัดเจนไม่ผูกหรือขึ้นอยู่แก่กัน หรือในแต่ละ process จะแยกทำงานกันอย่างอิสระนั่นเอง ทำให้ Microservice นั้นทำงานแยกจากกันเป็นอิสระ แม้ว่าจะอยู่ในเครื่อง server เดียวกันก็ตาม แต่ละ service ก็แยกการทำงานออกจากกันชัดเจน แต่ถ้าต้องการติดต่อกันก็ให้ผ่าน HTTP resource API นั่นทำให้ service ไม่ผูกติดกันมากจนเกินไป อีกทั้งทำให้การ deploy ระบบงานง่ายขึ้นอีกด้วย

2. Conway’s Law

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

มีความสามารถที่หลากหลาย
ทำงานแบบ Cross-functional team
Autonomous

3. Unix design philosophy

แนวคิดหนึ่งที่เป็นหัวใจเลยก็คือ

Make each program do one thing well

เป็นที่มาของคำว่า Micro ใน Microservice นั่นเอง แต่ในการพัฒนาระบบงานนั้น เป็นสิ่งที่ยากมาก ๆ ที่จะแบ่งการทำงานย่อย ๆ ให้ถูกต้องตั้งแต่เริ่ม ดังนั้นลองสร้างระบบงานขึ้นมาก่อน จากนั้นให้ทำการแบ่งระบบงานเป็นส่วนย่อย ๆ ออกมา และมันจะทำให้เราเห็นว่าแต่ละ service ควรแยกกันอย่างไรบ้าง ซึ่งควรจะทำงานเพียงเรื่องเดียว หรือ อย่างเดียวเท่านั้น Reference Website http://martinfowler.com/articles/microservices.html http://blogs.ugidotnet.org/luKa/archive/2015/05/10/the-3-inspiring-principles-of-microservices.aspx

hard

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

1. ชื่อของ test method/test case กับสิ่งที่อยู่ใน test body ไม่สัมพันธ์กัน

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

2. ชอบสร้าง object ใหม่ ภายใน method !!

ถ้าเป็นภาษา Java ก็คือ new XXX() นั่นเอง ถ้าเราพบเจอ code เหล่านี้จำนวนมาก แสดงว่า code ของเรานั้นผูกมัดกันอย่างมาก (Tight coupling) ผลที่ตามมาก็คือ ทดสอบได้ยากมาก ๆ ตัวอย่างเช่น ถ้าเป็นส่วนของการติดต่อ Database ถ้าเป็นส่วนของการติดต่อผ่าน Web Service คำถามคือ คุณจะทดสอบมันอย่างไร ถ้ายังสร้าง object เหล่านี้ขึ้นมาทุกครั้ง รวมทั้งต้องเรียกใช้งานไปยัง Database และ Web Service จริง ๆ เสมอ ลองคิดดูสิว่า ถ้า Database และ Web Service มันล่มไป คำถามคือ คุณสามารถทำการทดสอบระบบได้หรือไม่ ? หรือสามารถพัฒนาระบบงานต่อไปได้หรือไม่ ?

ถ้าตอบว่า ไม่ได้ แสดงว่า คุณยังไม่สามารถจัดการกับ dependency ต่าง ๆ เหล่านี้ได้ นั่นคือ สะท้อนถึง code และวิธีการคิดของเรานั่นเอง

สามารถอ่านเพิ่มเติมในเรื่องการจัดการ Dependency ได้ ซึ่งจะทำให้ code ไม่ผูกมัดกันมากเกินไป (Loose coupling) นั่นคือ ทำให้สามารถทดสอบได้ง่ายขึ้น

3. ใช้ static field/property เยอะมาก ๆ

เนื่องจากเรากำลัง share state ของการทำงานให้กับ method และ class อื่น ๆ นั่นหมายความว่า ถ้าเรามี test case จำนวนมากที่ต้องทำการแก้ไขค่าจาก static field นี้ ผลที่ตามมาก็คือ ค่าหรือสถานะของ static field อาจจะผิดพลาดก็ได้ เรียกตัวแปรเหล่านี้ว่า Global variable หรือ Global state ซึ่งมันน่ากลัวเป็นอย่างมาก !! ดังนั้นแนะนำให้ ลด ละ เลิก นะครับ

4. ระวัง final class เมื่อใช้งาน Mockito !!

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

5. ใน Constructor มีการทำงานเยอะมาก ๆ

เป็นสิ่งที่ควรระวังอย่างมาก เพื่อไม่ทำให้กระบวนการสร้าง object มันยากและซับซ้อน มิเช่นนั้น คุณจะไม่มีทางทดสอบได้เลยหรือทำได้ก็ยากมาก ๆ ดังนั้น ลด ละ เลิก นะครับ Reference Website http://misko.hevery.com/2008/07/30/top-10-things-which-make-your-code-hard-to-test/ https://dzone.com/articles/5-easy-ways-to-write-hard-to-testcode

do-notthing

เพิ่งอ่านและสรุปเรื่อง Serverlesss ไป ซึ่งเป็นแนวคิดและวิธีการใหม่ ๆ ที่น่าสนใจอย่างมาก พอกลับมามองที่ Developer ก็ต้องตอบรับแนวคิดนี้เช่นกัน ด้วยการเขียน code น้อย ๆ ตามแนวคิด Codeless programmer สิ !!

software-testing-00

จากรายงานเรื่อง World Quality Report 2015-16 นั้น ทำให้เราเห็นแนวโน้มรวมทั้งคำแนะนำต่าง ๆ ของ Software Testing ในปี 2016 ดังนั้นจึงทำการสรุปไว้นิดหน่อย ในปี 2015 ที่ผ่านมานั้นพบว่า มีการนำแนวคิด Agile และ DevOps เข้ามาประยุกต์ใช้ในองค์กรต่าง ๆ สูงมาก มีเป้าหมายเพื่อเพิ่มคุณภาพและ Time-to-market ของ product ต่าง ๆ รวมทั้งยังสามารถรับมือต่อการเปลี่ยนแปลง และทำการ release ระบบงานได้สะดวก รวดเร็วขึ้น

นั่นแสดงว่าในส่วนของการทดสอบ จำเป็นต้องมี Test Automation หรือ การทดสอบแบบอัตโนมัติ

จากรายงาน World Quality Report 2015-16 สรุปแนวโน้มของ Software Testing ไว้ดังนี้

1. มีการลงทุนสูงขึ้นอย่างต่อเนื่อง !!

2. แนวคิดและแนวปฏิบัติเรื่อง Agile + DevOps เข้ามามีบทบาทสูงขึ้นมาก

นั่นหมายถึง delivery time หรือเวลาในการส่งมอบ product จะสั้นหรือเร็วมากขึ้น และ product ยังต้องมีคุณภาพในระดับสูง ดังนั้นจำเป็นต้องนำการทดสอบในระดับต่าง ๆ มาไว้ในกระบวนการเสมอ ทั้ง Developer testing และ Customer testing

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

3. Security testing เป็นเรื่องที่ขาดไปไม่ได้เลย

ในปัจจุบันข้อมูลต่าง ๆ เกิดขึ้นเยอะ และ เร็วมาก ๆ รวมทั้งคนเราบริโภค หรือ เสพข้อมูลกันเยอะและง่ายมาก ๆ ดังนั้นเรื่อง Security Testing หรือ การทดสอบความปลอดภัยจึงมีความสำคัญอย่างมาก เพื่อทำการควบคุมและตรวจสอบข้อมูล รวมทั้งดูว่าข้อมูลเหล่านั้นทำให้เกิดความเสี่ยง หรืออาจจะส่งผลร้ายต่อระบบหรือไม่ ? หรืออาจจะถูกโจมตีจากภายนอกได้หรือไม่ ? ตัวอย่างเช่น การ review code ด้วยเครื่องมือวิเคราะห์ source code รวมทั้งการทำ penetrating testing อีกด้วย

4. Mobile Testing มันจำเป็นมาก ๆ และ ต้องเน้นเป็นพิเศษ

Mobile ได้กลายมาเป็นส่วนหลักของตลาดไปแล้ว ดูได้จากจำนวนผู้ใช้งาน ดูได้จากจำนวน App ที่มีให้ download ดูได้จาก roadmap ต่าง ๆ ของแต่ละองค์กร หลาย ๆ องค์กรมีนโยบาย Mobile First ไปแล้ว ดูได้จากความต้องการ Mobile developer ทั้ง Android และ iOS

แต่การทดสอบระบบบน Mobile กลับยังไม่ดีเท่าที่ควร หรือบางที่ยังทำการทดสอบแบบ manual เป็นหลัก !! ซึ่งขัดแย้งต่อ Time-to-maket อย่างมาก รวมทั้ง Mobile app จะต้องทำการ release บ่อยกว่า web application เยอะมาก ดังนั้นมันจึงเป็นความท้าทายอย่างมาก ว่าเราจะทดสอบ Mobile Testing กันอย่างไร ? เพื่อตอบสนองความต้องการทั้งเรื่องของคุณภาพและ Time-to-market !! รวมไปถึงเรื่อง Security Testing สำหรับ mobile ด้วย การทดสอบ Mobile App มีเยอะมาก ๆ ทั้ง Unit testing ทั้ง Integration testing ทั้ง UI testing ทั้ง Regression testing ทั้ง Security testing ทั้ง Performance testing

5. Test Automation หรือ การทดสอบแบบอัตโนมัติ

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

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

ดังนั้นการทดสอบแบบอัตโนมัติจึงมีความสำคัญอย่างมาก และกลายเป็นสิ่งที่แต่ละองค์กร ต้องพยายามสร้างคนและขั้นตอนการทำงานที่มีประสิทธิภาพขึ้นมา

แต่เรากลับพบว่า มีผู้เชี่ยวชาญเรื่องนี้น้อยมาก ๆ ทั้ง Developer, Tester !! มันจึงเป็นความท้าทายในปี 2016 อย่างมาก

โดยสรุปแล้วเราควรเน้นในเรื่องต่าง ๆ ดังนี้

Security testing เป็นสิ่งที่จำเป็นต้องมีและต้องทำงานแบบอัตโนมัติ
เน้นในเรื่องคุณภาพที่ส่งผลต่อลูกค้าเป็นหลัก เนื่องจากไม่ค่อยให้ความสำคัญกันมากนัก
ปรับเปลี่ยนขั้นตอนการทำงานใหม่ นั่นคือนำแนวคิด Agile และ DevOps มาประยุกต์ใช้กันมากขึ้น
ปรับปรุงการทดสอบ เพื่อให้มีคุณภาพและ Time-to-market
การทดสอบต้องเป็นแบบ Continuous Testing นั่นคือต้องทดสอบกันอยู่ตลอดเวลา
ต้องทำการปรับปรุงความสามารถของคน ทั้งการทดสอบ การพัฒนา และ release เพื่อทำให้เกิด Test Automation ขึ้นมา

discipline

มาดูตัวอย่างของภาพที่ Developer หลาย ๆ คนอาจจะเห็นและพบจนชิน เมื่อ Developer เปิด source code บน IDE หรือ Editor ต่าง ๆ แล้วทำการ compile และ run อาจจะพบเจอกับ Warning หรือ คำเตือนต่าง ๆ จาก compiler จำนวนมาก !! คำถามที่น่าสนใจคือ จะทำอย่างไรต่อไปดีล่ะ ?

จะทำการแก้ไข ?
จะปล่อยไว้อย่างนั้น ?
จะไม่สร้างมันขึ้นมาอีก ?

Developer จะทำอย่างไรต่อไป ?

จากสิ่งที่พบเจอมานั้น ส่วนมากมักจะปล่อยมันไป แถมสร้างขึ้นมาอีก !!

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

เรื่องต่าง ๆ เหล่านี้มันคือส่วนเล็ก ๆ ของ Code Metric

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

คำแนะนำคือ ตั้งเป้าหมายไว้เลยว่า Warning ต้องไม่มีหรือเป็นศูนย์ !!

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

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

จากการตั้งเป้าหมายเหล่านี้ก็ทำให้เกิดปัญหาเช่นกัน

จะแก้ไขไปทำไม มันไม่ได้มีคุณค่าต่อทาง business เลย
เสียเวลา เลิก ๆ ไปทำอย่างอื่นเถอะนะ
Developer ไปปิดการ warning ของ compiler กันเลย !!

เรื่องต่าง ๆ เหล่านี้มันคือ วินัยของ Developer

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

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

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

สุดท้ายขอเน้นย้ำว่า วินัยของ Developer มันสำคัญมาก ๆ

เขียน code ให้ทำงานได้ กับ ทำให้ดี มันแตกต่างกันเยอะมาก ๆ นะ

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

Reference Websites http://www.daedtech.com/with-code-metrics-trends-are-king https://blog.ndepend.com/a-test-coverage-primer-for-managers/

io-00

วันนี้ไปร่วมงาน Google I/O 2016 Extended Bangkok เป็นงานที่สรุปเนื้อหาต่าง ๆ จากงาน Google I/O 2016 มาให้อย่างเต็มอิ่ม อาจจะบอกได้เลยว่าข้อมูลมันเยอะมาก ๆ (Information Overflow) โดยเนื้อหาประกอบไปด้วย

Google Assistant
Google Home
Mobile Development
Web Development

แต่ในงานครั้งนี้ผมเลือกที่จะฟังเฉพาะ Mobile Development เท่านั้น มาดูว่ามีอะไรที่น่าสนใจบ้าง ?

1. มาดูความสามารถต่าง ๆ ของ Android N

โดยมี session นี้จะทำการแนะนำความสามารถใหม่ ๆ ทั้งสำหรับ Android development และ Android N ขอบอกเลยว่ามันเยอะมาก ๆ เช่น

Constraint Layout ซึ่งต่อไปน่าจะเป็น layout หลักของการพัฒนา App เหมือนกับ Auto Layout ใน iOS เลยนะ
Multi-window หรือ Split screen สิ่งที่ต้องสนใจมาก ๆ คือการจัดการ Life cycle ของ Activity ให้ดี มิเช่นนั้นต้องแก้ไขกันวุ่นวาย !!
Picture-in-Picture mode ใน TV ซึ่งสามารถ Drag & Drop รูปข้าม Activity หรือหนาจอได้
Notification รูปแบบใหม่ทั้ง template, custom view และ direct reply ที่ iOS ทำได้นานล่ะ !!
ในส่วน Setting ของ Android phone เช่น
- Display size คือสามารถขยาย size ของทั้งหน้า ไม่ใช่เฉพาะ font ทำให้ App สวยขึ้น
- Quick setting
- Multi Locale
Doze ใน Android N หรือโหมดหลับลึกของ Android เพื่อช่วยทำให้มือถือประหยัด Batt เมื่อไม่ใช้งาน เป็นเรื่องที่นักพัฒนาต้องเรียนรู้และเข้าใจ
Project Svelte แปลว่าผอมเพรียว เพื่อปรับปรุงให้ Android สามารถทำงานบน hardware หรือ อุปกรณ์ที่เก่า ๆ หรือ spec ต่ำ ๆ ได้ ทั้งลดการใช้งาน RAM และ Batt นั่นเอง โดยงานหลาย ๆ อย่างจะถูกตัดทิ้งเช่น CONNECTIVITY_ACTION, ACTION_NEW_PICTURE และ ACTION_NEW_VDO ซึ่งให้ไปใช้งานผ่าน JobScheduler ที่เป็น background process แทน
Data saver mode ใน Android N ช่วยลดจำนวน data ที่ใช้งานของ App
Direct boot ปรับปรุงการทำงานของ app เมื่อเครื่องทำการ reboot ขึ้นมาใหม่
Scoped Directory Access เป็นการกำหนด permission ในการเข้าถึง external storage บนเครื่องจาก App ซึ่งสามารถกำหนดเฉพาะ directory ที่ต้องการเท่านั้น เนื่องจากในรูปแบบเดิมสามารถเข้าถึงได้ทั้งหมดเลย ซึ่งน่ากลัวมาก ๆ เป็นการปรับปรุงที่ดีมาก ๆ
ว่าด้วยเรื่องของ Vulkan ซึ่งเป็น 3D render ใหม่ซึ่งเหมือน ๆ กับ Open GL นั่นเอง

จากนั้นมาเรื่องที่เกี่ยวกับ Development กันบ้าง ซึ่งก็มิใช่น้อยหน้าไปกว่ากันเลย

ADB shell ที่ทำงานรวดเร็วขึ้น นั่นแสดงว่าติดตั้ง App ได้เร็วขึ้น
NDK ตัวใหม่
สนับสนุน VR หรือพูดง่าย ๆ คือ 3D mode นั่นเอง
ตัวที่สำคัญมาก ๆ สำหรับนักพัฒนาคือ Support Library แน่นอนว่าพลาดไม่ได้เลย เช่น
- Vector Drawable (VD) ช่วยทำให้ขนาดของ App เล็กลง ซึ่งมีความสำคัญอย่างมาก
- การเลือกใช้การบีบอัดของรูปภาพมันสำคัญมาก ๆ ทั้ง VD -> WebP -> PNG -> JPG
- Night mode
- ใช้งาน RecyclerView เป็นหลักเลยนะ
- Design Support Library คือสิ่งที่นักพัฒนาอย่าพลาดนะ
- Bottom sheet
- Chrome Custom Tab

ยังไม่หมดนะ มี Instant App มาอีก ทำให้ผู้ใช้งานสามารถใช้งาน App ได้โดยไม่ต้องติดตั้ง ถือว่าเป็น killer feature ของ Android เลยก็ว่าได้ แต่มันก็ส่งผลกระทบต่อนักพัฒนาไม่น้อยนะ เนื่องจากต้องทำการ build app แยกออกมานิดหน่อย และตอนนี้ยังเป็น beta อยู่ซึ่งสามารถขอทดสอบใช้งานได้นะ พักหายใจหายคอกันหน่อยนึง ....

2. มาดูความสามารถใหม่ ๆ ของ Android Studio 2.2

ขอบอกอีกแล้วว่า มันเยอะมาก ๆ โดยแบ่งออกเป็น 4 กลุ่มใหญ่ ๆ คือ

Design
Develop
Build
Test

มาดูกันว่าในแต่ละกลุ่มมีอะไรที่น่าสนใจกันบ้าง กลุ่มที่ 1 :: Design ประกอบไปด้วย Layout Editor, Constraint Layout และ Layout Inspector ซึ่งทำให้การออกแบบ UI ของ APP ง่าย สะดวกและรวดเร็วขึ้นมา รวมทั้งปรับปรุงเรื่องของ Responsive และ Performance อีกด้วย เนื่องจาก Constraint Layout ช่วยลดความซับซ้อนของ View ลงไปอย่างมากนั่นเอง ชีวิตของนักพัฒนาน่าจะดีขึ้นกว่าเดิมมาก ๆ ที่ต้องมานั่งแก้ไขไฟล์ XML กันเลย กลุ่มที่ 2 :: Develop ประกอบไปด้วย

เริ่มด้วยตัวทีเด็ดคือ Firebase plugin ช่วยทำให้การพัฒนา App มันง่ายและสะดวกขึ้นอย่างมาก
Sample code browser ช่วยทำให้นักพัฒนาสามารถดูตัวอย่าง code สำหรับการใช้งาน API ต่าง ๆ จาก Google Sample

กลุ่มที่ 3 :: Build ประกอบไปด้วย

Instant Run ซึ่งตอนนี้ทำการปรับปรุงดีขึ้นอย่างต่อเนื่อง ทำให้การ build project รวดเร็วขึ้น (ใครปิดไว้ ก็เปิดซะนะ !!)
Merge Manifest Viewer
Project Structure Dialogue ยังไม่ออกมาให้ใช้นะ !!
ปรับปรุง Jack compiler ช่วยทำให้ใช้การ build รวดเร็วขึ้น แต่จากการใช้งานจริง ๆ ยังไม่ดีเท่าไรนัก !!

กลุ่มที่ 4 :: Test ประกอบไปด้วย

การปรับปรุง Android Emulator ให้ดีขึ้นเป็นอย่างมากรวมทั้งความสามารถครบครัน ทำให้ไม่ต้องไปใช้ Emulator อื่น ๆ แล้ว แถมยังบอกว่าเร็วกว่า device จริงอีกนะ !!
Espresso Test Recorder ช่วยทำให้การทำสอบ UI ง่ายขึ้น ซึ่งมีใน Android Studio 2.2 Preview 3 ขึ้นมานะครับ
APK Analyzer ช่วยทำให้เราวิเคราะห์ไฟล์ APK ว่าเป็นอย่างไร เช่นขนาดของไฟล์ จำนวน method และขนาดของ resource ต่าง ๆ ทำให้เราสามารถรู้ปัญหาและหาทางแก้ไขได้ง่ายขึ้น
Firebase Test Lab ช่วยทำให้เราสามารถทดสอบ App ได้เลย แต่ต้องเสียเงินนะ !!

ปล. มีข้อมูลเกี่ยวกับ Web Development นิดหน่อยคือ Progressive Web App (PWA)

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

Push notification
Service Worker
Tool ประกอบไปด้วย Angular Mobile Toolkit, Polymer App Toolkit และ SW-Toolbox, SW-Prefetch
ทำงานร่วมกับ 3-parties ต่าง ๆ ได้ เช่น ionic framework

ยังมีการสรุปใน Part 2 ไว้อีกเรื่อง Espresso UI Test และ Firebase

es-01

เนื่องจากเนื้อหาในงาน Google I/O 2016 Extended Bangkok มันเยอะมาก ๆ ดังนั้นจึงแยกเนื้อหาออกเป็น 2 ส่วน ซึ่งใน blog นี้จะสรุปเรื่องต่าง ๆ ดังนี้

UI Testing สำหรับ Android App ด้วย Espresso
ทำความรู้จักกับ Firebase ว่าน่าสนใจอย่างไรบ้าง

มาเริ่มกันเลย

1. UI Testing สำหรับ Android App ด้วย Espresso

เป็น session หนึ่งที่ตั้งใจมาฟังอย่างมาก เพราะว่า เป็นสิ่งที่สนใจและใช้งานประจำสำหรับการทดสอบ Android App โดยชอบคำพูดนี้มาก ๆ คือ

Espresso นั้นถูกสร้างขึ้นมา เพื่อส่งเสริมให้นักพัฒนาเขียนชุดการทดสอบสำหรับ App นั่นเอง

โดยทางทีมพัฒนา Android นั้นได้แยกการทดสอบออกมาเป็นอีก library ชื่อว่า Android Testing Support Library (ATSL) เพื่อช่วยทำให้ App มีคุณภาพที่ดีขึ้น ประกอบไปด้วย

UI Automator สำหรับการทดสอบการทำงานระหว่าง App และ System ของ device
Espresso สำหรับการทดสอบใน App นั้น ๆ
AndroidJUnitRunner เป็น Test Runner สำหรับ Android App ซึ่งทำการ custom มาจาก JUnit

มาดูรายละเอียดของ Espresso กันว่าเป็นอย่างไรบ้าง ? โดยจะทำงานผ่าน Instrumentation ซึ่งจะทำการ hook เข้าไปยัง Lifecycle ของ Activity ทำให้เราสามารถทดสอบได้นั่นเอง Espresso มีส่วนการทำงานหลัก 3 ส่วนคือ

View matcher สำหรับค้นหา element ต่าง ๆ ใน view
View action สำหรับกระทำกับ element ต่าง ๆ ใน view เช่น การกดปุ่ม เป็นต้น
View assertion สำหรับการตรวจสอบผลการทำงาน เช่น ข้อความที่แสดงใน TextView เป็นต้น

และยังอธิบายอีกด้วยว่า Library แต่ละตัวของ Espresso นั้นใช้ทำอะไรบ้าง [code] //เป็น library หลักของ Espresso androidTestCompile "com.android.support.test.espresso:espresso-core //สำหรับทดสอบพวก DatePicker, RecyclerView, Drawer action ต่าง ๆ androidTestCompile "com.android.support.test.espresso:espresso-contrib //Intent Rule, validation และ stub ซึ่งช่วยให้จัดการ intent ได้อย่างง่ายและสะดวกสำหรับการทดสอบ และทำงานร่วมกับ Mockito androidTestCompile "com.android.support.test.espresso:espresso-intents //สำหรับการทำงานร่วมกับพวก backgroung job androidTestCompile "com.android.support.test.espresso:espresso-idling-resource //สำหรับทดสอบ WebView androidTestCompile 'com.android.support.test.espresso:espresso-web [/code] จากนั้นทำการแนะนำวิธีการ Custom Error ของ Espresso เพื่อช่วยทำให้ error ของ Espresso อ่านและเข้าใจได้ง่าย โดยให้ทำการ implement จาก interface EspressoException รวมทั้งแนะนำ Espresso Test Recorder อีกเล็กน้อย ส่วนcode ตัวอย่างดูเพิ่มเติมได้จาก Android Coding Testlab

2. ทำความรู้จักกับ Firebase ว่าน่าสนใจบ้าง ? บอกเลยว่าเยอะมาก !!

ถือได้ว่าเป็นพระเอกของงาน Google I/O 2016 เลยก็ว่าได้ เป็นอีกหนึ่งการเปลี่ยนแปลงที่ส่งผลกระทบอย่างแรงต่อ Developer เนื่องจากมีทุกสิ่งที่ Web และ Mobile application ต้องการ ทั้ง Infrastructure ทั้ง Service ต่าง ๆ ทั้งการรองรับการขยายตัวของระบบ ทั้งการทำงานแบบ cross platform ทั้งการใช้งานที่ง่าย ทั้งเอกสารที่แจ่ม ๆ และ ละเอียด สำหรับ Android Studio ก็มี Firebase plugin ให้ใช้งานแบบง่าย ๆ อีกด้วย ดังนั้นห้ามพลาดด้วยประการทั้งปวง es-02

โดยมี feature แบ่งเป็นกลุ่มดังนี้

Develop
Grow
Earn
Analytic

ซึ่งมันเยอะมาก ๆ แสดงดังรูป (ลองไปใช้งานกันดูนะ) es-03

ถ้า Developer คนไหนยังไม่ลองใช้งาน แนะนำให้ลองไปใช้งานเถอะนะ มันช่วยเหลือให้ชีวิตง่ายขึ้นเยอะเลย ส่วน Slide ของงานนี้เขาเอาไปเก็บไว้ที่ Github:: Google I/O extended Bangkok