[บทความพิเศษ] Guest และคำถามจากผู้ร่วมงาน Android Developer Meetup 1.0 ที่เหลืออยู่

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

ความเดิมตอนที่แล้วในมุม staff ผู้จัดงาน

บันทึกเรื่องราวของงาน Android Developer Meetup 1.0 ในฝั่ง Staff

เมื่อวันจันทร์ที่ 23 ธันวาคม 2019 ที่ผ่านมาได้มีการจัดงาน Android Developer Meetup 1.0 เพื่อเป็นงานส่งทิ้งท้ายปี 2019 สำหรับนักพัฒนาแอนดรอยด์ ซึ่งน่าจะเป็นงาน Meetup ครั้งแรกสุดที่จัดขึ้นด้วยกลุ่ม…

Android Developer Meetup THAke Exorcist

คำถามทั้งหมดในวันนั้นอยู่ในนี้ค่ะ

Slido

Join the conversation: ask your questions & vote in live polls.

ซึ่งถ้าอ่านบล็อกสรุปจาก 2 ท่านนี้ คำถามที่ส่งเข้ามาใน Slido ก็จะมีการถามกันไปแล้วบ้างบางข้อ

Android Developer Meetup 1.0 สิ่งที่น่าสนใจ และแกะเทปมาให้อ่าน

Fastwork : มีการแบ่งทีมตาม platform ทำ kotlin multiplatform MVVM ผสมกับ State management โดยดึงเอาคอนเซปของ Redux มาใช้ร่วมด้วย Grab : แบ่งเป็นทีมย่อย แยกเป็นโมดูล Core หลักใช้ Node Architecture…

Android Developer Meetup THParanee Apiromsanee

สรุปสิ่งที่ได้จากงาน Android Developer Meetup 1.0

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

Sterk[+sterk+]

ซึ่ง guest ในงานจะมี 3 ท่าน คือ

• Watcharin Sripongpunkul (พี่นิว), Senior Software Engineer @ Grab
• Verachad Wongsawangtham (พี่เบิร์ด), Lead Mobile Developer @ Fastwork Technologies & Ex-Agoda
• Jirachai Hongthong (พี่ปิ๊ก), Android Developer @ Krungsri Consumer

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

Review Code กันยังไง ? ต้อง review ข้าม squad หรือเปล่า ? Pass Criteria เป็นยังไง ?

พี่นิว : ถ้าในทีมก็จะ Review code ตามปกติ แต่ถ้าในกรณีที่เราแตะโค้ดของ squad อื่นเราจะต้อง inform ทีมนั้นๆให้ review ด้วย ใน Code Review ดูตั้งแต่ syntax ยัน business logic ครับ หลักๆคือถ้ามี suggestion อะไรที่ดีก็ใส่ไป แต่เนื่องจากทีมมันใหญ่บางครั้งก็อาจจะไม่ได้รู้ทั้งหมด comment อาจจะเป็นไปแนวทาง concern อะไรบ้างแล้วให้เค้าไปตรวจสอบ

พี่เบิร์ด : รีวิว Logic เป็นส่วนใหญ่ ถ้ามี change ที่เกี่ยวกับ UI หรือ เป็น Feature ใหม่จะ checkout มาเล่นด้วยระดับนึง ถ้าทุกอย่างตาม business logic ก็จะปล่อย ส่วน code style จะมองผ่านๆ เพราะจะใช้ lint check

พี่ปิ๊ก : รีวิว Code Style ตามที่ตกลงกันไว้ อ่านรู้เรื่อง ถ้ายาวหรือซับซ้อนไปก็ช่วยกันปรับให้ดีขึ้น ส่วนการรีวิวข้าม squads ก็ทำเพื่อให้เกินการแชร์ความรู้และให้ code ไปใน Style เดียวกัน

Fastwork — ส่วนตัวเคยเขียนทั้ง Hybrid & Native อยากทราบว่าเคยเจอปัญหาที่ ในการทำงานหมือนๆกัน ต้องเขียนเงื่อนไข เช็คแพลตฟอร์มในฟังก์ชั่นบ้างมั้ยคะ?

พี่เบิร์ด : มีเขียนครับ เพราะบางอย่างการแสดงผลด้วย Component ของ Platform นั้นให้ Experience กับ User ได้ดีกว่า ปกติมันจะมีวิธี check platform จาก Framework อยู่แล้ว

คิดยังไงกับ concept microservice, micro-frontend ณ วันนี้แอป grab เข้าใกล้ concept นี้รึเปล่า มีโอกาสที่เทรนด์นี้จะมาฝั่ง mobile มั้ย

พี่นิว : ฝั่ง Backend เท่าที่ทราบตอนนี้มีการทำ Microservice อยู่แล้ว ส่วนฝั่ง Mobile ยังไม่เห็นมีวี่แววนะ สิ่งที่เราทำตอนนี้คือพยายามแยกแต่ละ feature ไปเป็นแต่ละ module เพื่อนำไปใช้งานกับ module หรือ feature อื่นๆ

พี่เบิร์ด : ทีม Fastwork ยังไม่จำเป็น แต่ถ้าขยายไปเรื่อยๆ อาจจะกลับมาดูอีกครั้ง

แต่ละที่มี stack CI/CD ยังไงบ้างครับ

พี่เบิร์ด : Jenkins เป็น Master อยู่บน Cloud แล้วใช้ Mac mini เป็น node เพื่อ build ทั้ง Android/iOS ปกติ ก็จะเขียน script pipeline เพื่อจัดการทั้งหมด

พี่ปิ๊ก : หลักๆก็ใช้ Jenkins เหมือนทั่วๆไปในการ Build, Test และ Deploy ไปที่ Firebase App Distributors

ส่วนพี่นิวขอไม่ตอบคำถามนี้จ้า

UChoose — handle เรื่อง security ยังไงครับ ? มีการทำอะไรเป็นพิเศษบ้าง ?

พี่ปิ๊ก :

• ป้องกันเครื่อง root ไม่ให้ใช้งาน App
• Encrypt ข้อมูลในการรับส่งระหว่าง Server
• ทำ Source Code Obfuscate
• ทำ SSL Certificate Pinning แต่โดยพื้นฐานการทำให้ Client ปลอดภัยก็ช่วยได้ระดับหนึ่งเราจึงทำให้ API มีความปลอดภัยมากที่สุด

เขียน cross ต้องแยกทีม Android กับ iOS ไหมครับ

พี่เบิร์ด : จริงๆ ไม่ได้แยกแบบชัดเจน เพราะสุดท้ายแล้วเราควรจะเขียนด้วยทั้งคู่ แต่จะแยกให้เห็นว่าใครมีความรู้ของ Platform ไหนมากกว่า เพื่อให้เป็นคนชี้ขาดใน เรื่อง Experience และ Technical Limitation ของ Platform นั้นๆ

อยากให้เล่าเกี่ยวกับ​ A/B​ testing​ ว่าทำกันอย่างไร​ครับ​ ใครเป็นคนออกแบบ​ว่าจะเก็บ​ stat และสร้าง​ measurement matrix จากเหตุการณ์อะไรบ้าง

พี่นิว : เล่าคร่าวๆ ได้แค่ว่า Product Team จะทำงานร่วมกับ Analytic Team อย่างใกล้ชิด ซึ่งจะเป็นคนกำหนดว่าอยากจะ track อะไรใน feature นั้นๆบ้าง

และเราทำ A/B testing เพื่ออะไร:

1. ทดสอบว่า ของใหม่กับของเก่า หรือ feature ที่เหมือนกันแต่ UX/UI ต่างกัน ว่าอันไหนได้รับการตอบรับจาก user ได้ดีกว่า เช่น user ใช้มากขึ้น หรือ click มากขึ้น
2. ทุกๆ feature ใหม่ จะมี flag คอยกำหนดการเปิดปิด ใช้ในกรณีที่ทดสอบ A/B Testing ระหว่างของใหม่กับของเก่าว่าอันไหน user ใช้มากกว่ากัน
3. feature flag ยังมีประโยชน์ในกรณีที่ หาก feature นั้นมีปัญหาที่ส่งผลกระทบต่อแอป เราสามารถ สั่งปิดได้ทันที ซึ่งช่วยลดผลกระทบในวงกว้าง

พี่เบิร์ด : A/B Testing มีทำอยู่บ้างแต่ยังไม่ได้ถึงขึ้นทำเป็น framewrok ใช้กับทุกอย่าง เพราะมี maintenance cost ปกติจะเรียกคุยกันในทีม ทั้ง Engineer, BI (Business Intelligence), และ PO (Product Owner) เพื่อหา User Journey และ Matrix ที่ใช้วัด รวมถึง Target user ด้วย

พี่ปิ๊ก : ไม่ได้ทำ A/B Testing

ถ้าทั้งสามท่าน อยากออกมาทำ startup เอง อยากจะวาง position ของบริษัทตัวเองเป็นแบบไหน

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

พี่เบิร์ด : Position ของบริษัทก็คงเป็น Culture ที่เหมาะ กับการ Innovate Tool ใหม่ๆ เพราะส่วนตัวถ้าจะเปิดเองคงอยากทำ เกี่ยวกับพวก Developer Tools ซะมากกว่า

พี่ปิ๊ก : สร้าง Software ที่ให้แก้ปัญหาให้ลูกค้าองค์กรต่างๆ และเน้นนำเทคโนโลยีใหม่มาใช้

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

ส่วนงาน Android Developer Meetup ไม่ว่าจะเป็น 1.1 หรือ 2.0 จะมาวันไหนในปี 2020 อยากให้ติดตามชมตอนต่อไปจ้า สำหรับวันนี้ก็สวัสดีปีใหม่ปี 2020 ย้อนหลังแล้วกันจ้า~~~