แปลเรื่อง Android Development Culture

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