Screen Shot 2558-12-07 at 10.52.23 PM
จากบทความเรื่อง Android Development Culture
ได้พูดถึงรูปแบบการพัฒนา Andriod app
ซึ่งน่าจะต้องปรับเปลี่ยนไปจากเดิมที่เคยเป็นมา

เนื่องจาก project ต่าง ๆ นั้นล้วนไม่มี automated test เลย
ทั้ง unit test, integration test และ functional test
รวมไปถึงไม่มีการใช้ lint tool ในการตรวจสอบ code
ชอบสร้าง code ที่มันยุ่งเหยิง ที่เราเรียกกันว่า spaghetti code
ในปัจจุบันมันมีคำเรียกใหม่ คือ reactive spaghetti
และอื่น ๆ อีกมากมาย

ดังนั้นมาดูว่า เราควรต้องปรับเปลี่ยนสิ่งใดกันบ้าง ?

ประโยคที่น่าสนใจ

Optimization without a good level of code quality is a kind of premature optimization,
premature optimization is also known as the root of all evil.

ดังนั้นเรื่อง คุณภาพของ code จึงเป็นเรื่องที่สำคัญมาก

Fail Fast, Fail Early

เราต้องเจอปัญหาของ app ก่อนที่จะส่งมอบให้ผู้ใช้งานเสมอ
หรือรู้ปัญหาก่อนผู้ใช้งาน

ลองถามตัวเราเอง และ ทีมพัฒนาสิว่า
ในปัจจุบันนั้น เรารู้ปัญหาก่อนหรือหลังผู้ใช้งาน ?

โดยแนวปฏิบัติดังต่อไปนี้ จะช่วยเรื่องนี้ทั้งหมด

1. Pull Request, Code Review และ Continuous Integration

แน่นอนว่า code ของระบบงานทั้งหมดต้องถูกจัดการด้วย Version Control System
ไม่ว่าจะเป็น Git, Mercurial HG และ Subversion

โดยขั้นตอนการพัฒนาควรเริ่มต้นจาก Pull request
ซึ่ง developer แต่ละคนเป็นคนส่งการเปลี่ยนแปลงเข้ามา
จากนั้นจะมีระบบ Continuous Integration
เพื่อทำการ build ระบบแบบอัตโนมัติ เช่นการ build, code review และ test
ถ้าผลการทำงานผ่าน จะทำการ merge code เข้ามายัง main branch
แต่ถ้าไม่ผ่าน จะไม่ทำการ merge เข้าไปยัง main branch

2. Code quality

Code ที่สร้างขึ้นมานั้น ควรที่จะเป็น SOLID
ซึ่งไม่ใช่ก็น่าจะใกล้เคียงกันบ้าง

โดยไม่จำเป็นต้องไปยึดติดกับ Design Pattern ใด ๆ
เช่น MVC, MVP, MVVM และ VIPER เป็นต้น
แต่ควรที่จะแยกการทำงานต่าง ๆ ออกจากกันให้ชัดเจน (Isolation)
หรือบางคนจะเรียกว่า Separation Of Concern
เพื่อลด bad code ในการ review นั่นเอง

3. Static code/resource analysis

เครื่องมือพวก Static code analysis นั้นช่วยเราหา code ที่น่าจะก่อให้เกิดปัญหา
ก่อนที่จะทำการ package และ ส่งมอบไปให้ผู้ใช้งาน
และเป็นเครื่องมือช่วยเหลือในการทำ Code Review อีกด้วย

โดยใน Android มีเครื่องมือให้ใช้มากมาย เช่น

  • Android Lint
  • FindBugs
  • PMD
  • SonarQube
  • FB Infer

แนะนำให้นำเครื่องมือเหล่านี้
ไปใช้ที่เครื่อง developer ทุกคน
และนำไป run ไว้ในระบบ Continuous Integration
เพื่อทำให้รู้ว่า code ของคุณได้ไปต่อหรือไม่ !!

4. Unit test

แน่นอนว่า code ทุก ๆ บรรทัด
แน่นอนว่า code ทุก ๆ class
แน่นอนว่า code ทุก ๆ method/function
ที่ developer ทุกคนเขียนขึ้นมานั้น
มันสามารถทำงานได้อย่างถูกต้องตามที่คาดหวัง

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

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

  • JUnit 4
  • Android Unit test หรือ Android Instrumentation
  • รวมทั้งยังสามารถนำ Mock framework มาใช้ได้ด้วย เช่น Mockito เป็นต้น

จะเขียนตามแนวคิด Test-Driven Development (TDD) หรือไม่ก็ตาม
มันขึ้นอยู่กับคุณ และ ทีม
แต่ Unit test นั้น คุณ และ ทีมจำเป็นต้องเขียน !!

แน่นอนว่า developer ทุก ๆ คนต้องสามารถ run unit test นี้ได้เสมอ
รวมทั้งทำการ run unit test บนระบบ Continuous Integration อีกด้วย

5. Code coverage

เมื่อคุณเริ่มเขียน Unit test แล้ว
น่าจะต้องอยากรู้ว่ามันครอบคลุม code ไปเท่าไร ?
มี code ส่วนไหนบ้างที่ยังไม่มี Unit test ครอบคลุมบ้าง ?

โดยใน Android project นั้น
เราสามารถใช้ Code Coverage Tool ชื่อว่า Jacoco
ช่วยในการตรวจสอบได้เลย
รวมทั้งสามารถเพิ่มขึ้นตอนการตรวจสอบ
ในระบบ Continuous Integration ได้อีกเช่นกัน

โดยที่จำนวน Code coverage นั้น
มีไว้สำหรับการปรับปรุงการเขียน test ของทีมนั่นเอง

6. Functional หรือ UI test

เพียง Unit test มันคงยังไม่พอ
เราต้องการการทดสอบที่มากกว่านั้น
นั่นก็คือ การทดสอบ function การทำงานต่าง ๆ
ด้วยมุมมองของผู้ใช้งานนั่นเอง

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

เชื่อว่าในปัจจุบันจะมีกลุ่มของ QA/Tester
สำหรับทำการทดสอบแบบ manual test
แต่มันกลับกลายเป็นปัญหาคอขวดของการพัฒนาไป
ดังนั้น เราต้องการการทดสอบแบบอัตโนมัติ
เพื่อลดภาระของ QA/Tester ลงไป
ไม่ใช่ว่าไม่มีคนกลุ่มนี้นะครับ

โดยใน Android ก็ได้เตรียมการทดสอบไว้ให้แล้ว เช่น

  • Android Instrumentation test
  • UI Automator
  • Espresso

ซึ่งแนะนำให้เริ่มจาก Espresso ก่อนเลย

คำถามที่น่าสนใจ คือ ใครเป็นคนเขียน test ล่ะ ?
ตอบง่าย ๆ คือ Developer ไงล่ะ
แต่ถ้าสามารถสอนให้ QA/Tester เขียนได้
จะเป็นเรื่องที่ดีอย่างมาก
เนื่องจาก QA/Tester จะมีวิธีการคิด
สำหรับการทดสอบที่แตกต่างออกไปจาก developer
และอย่าลืมควรสอบ Code coverage ด้วยล่ะ

สุดท้ายแล้วเราต้องสามารถ run ชุดการทดสอบเหล่านี้ได้บนเครื่อง developer เอง
รวมทั้งนำไป run ในระบบ Continuous Integration ด้วย

7. Integration test

ทำการทดสอบอีกแล้ว
แต่ Integration test เอาไว้ตรวจสอบว่า
แต่ละส่วนการทำงาน หรือ แต่ละ component
มันทำงานร่วมกันได้อย่างถูกต้องตามที่คาดหวัง เช่น

  • HTTP layer
  • REST API layer
  • Executor layer
  • Persistence layer

ดังนั้นสิ่งที่เราต้องการมากกว่า Unit test ก็คือ
การจำลองส่วนการทำงานต่าง ๆ
ของแต่ละ component ขึ้นมานั่นเอง
ซึ่งผมเขียนอธิบายไว้ในเรื่อง Hermetic Testing

โดยเราสามารถทำการทดสอบพวก Integration test
ด้วย Unit test และ Android Instrumentation ได้เลย
ซึ่งมันทำงานได้รวดเร็วมาก
และแน่นอนว่าสามารถนำไป run ในระบบ Continuous Integration ได้อีกด้วย

มาถึงตรงนี้ น่าจะพอทำให้เห็นภาพแล้วว่า

การพัฒนา Android app ที่ดีนั้นควรเป็นอย่างไร
ซึ่งในฐานะที่เป็น developer ก็ควรที่จะนำแนวปฏิบัติเหล่านี้ไปใช้งานบ้างนะครับ
เพื่อจะได้ไม่เป็นภาระให้แก่ลูกหลานในอนาคต

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

Tags: