สรุปสิ่งที่ได้รับจากงาน iOSDevTH Meetup #7

วันนี้มีโอกาสไปร่วมงาน iOSDevTH Meetup #7 ของกลุ่ม iOS Developer Thailand จัดที่บริษัท Ascend ตึก AIA รัชาภิเษก มีหัวข้อที่น่าสนใจ 2 หัวข้อคือ

1. Concurrency on iOS
2. iOS development at scale

โดยในหัวข้อแรกผมมาช้าจึงไม่ได้จดอะไรมากนัก

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

มาในหัวข้อที่สองนั้นเรื่อง iOS development at Scale

เนื้อหานั้นเรียบง่ายมาก ๆ แต่ผมคิดว่ามันคือธรรมชาติของการพัฒนาเลยนะ เนื่องจากการพัฒนาที่ดีคือ ต้องเรียบง่ายและมีเหตุผล

โดยเริ่มที่ Feature development มันคือการเลือก feature ที่จะพัฒนานั่นเอง

เริ่มจากคำที่ทุกคนรู้จักกันดีนั่นก็คือ คำว่า MVP (Minimal Viable Product) อธิบายสั้น ๆ ได้ใจความว่า คือ feature ที่ระบบขาดไปไม่ได้เลย แน่นอนว่า น้อยไปก็ไม่ได้ เนื่องจากไม่มี feature อะไรใช้เลย มากไปก็ไม่ดี เนื่องจากใช้เวลาการพัฒนามากเกินไป ต่อมาว่าด้วยเรื่องขนาดของทีมพัฒนา ซึ่งมากคนมากความ ดังนั้นควรมีจำนวนไม่มาก ถามว่ามีเท่าไร ? ก็เท่าที่จะพัฒนา feature นั้น ๆ ได้ เนื่องจากเมื่อมากคนก็มากความ แถมต้องมีคนอื่นมาช่วยจัดการอีก วุ่นวายไปหมด รวมทั้งการพูดคุยที่จะต้องมากขึ้นแบบทวีคูณ และงานที่ถูกมอบหมายให้นั้นต้องไม่น้อยไปหรือมากไป พอให้กดดันกันบ้าง ที่สำคัญความสามารถและวินัยของคนต้องดีด้วยนะ !!

เรื่องต่อมาคือ Engineering practices สำหรับการพัฒนา

เป็นเรื่องที่ฟังดูแล้วง่าย ๆ แต่น่าสนใจ (ทำได้ยากมาก ๆ)

1. แต่ละส่วนของการทำงานต้องมีขนาดเล็ก (Small)

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

1. ส่วนการแสดงผลคือ View class
2. ส่วนการประมวลผลเรื่อง counter คือ Counter class หรือ Model
3. ส่วนเชื่อมต่อทั้ง View และ Model คือ ViewController
4. แต่ละส่วนเชื่อมต่อกันด้วย delegate

ทำให้แต่ละ class มีขนาดเล็ก ง่ายต่อการดูแลรักษา รวมทั้งการทดสอบอีกด้วย ไม่ว่าเป็น architecture แบบไหนก็ยืดถือแนวทางนี้เช่นกัน ทั้ง MVC, MVP, MVVM, VIPER, Redux

2. สั้น ๆ คือ Performance มันคือ feature ของระบบงาน

ดังนั้นจะไม่ทำหรือไม่สนใจไม่ได้เลย วันนี้คุณทำ profiling แล้วหรือยัง

3. Make it work, Make it right, Make it fast

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

4. เป็นสิ่งที่โดนใจก็คือ จะนำอะไรมาใช้ กรุณาเข้าใจมันให้ดี ๆ ก่อนเสมอ !!

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

5. อย่า hack code มากนัก !!

ลองถามตัวเราเองสิว่า hack code หรือ library ที่นำมาใช้เยอะหรือไม่ มิเช่นนั้นมันจะกลับมาทำร้ายเราเอง เช่น ไม่สามารถ upgrade version ได้

6. แบ่งปันความรู้ (Knowledge sharing)

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

7. Automate งานที่ทำให้ได้เยอะที่สุดเท่าที่จะเป็นไปได้

เช่น script การทำงานต่าง ๆ ทั้ง การ build การ compile การทดสอบ การ deploy การ release การ review code โดยการทำการแบบอัตโนมัติจะช่วยลดงานต่าง ๆ ลงไป ส่งผลให้มีเวลาไปทำอย่างอื่นที่สำคัญกว่า เช่นการพัฒนาและปรับปรุงระบบงานให้ดีขึ้น

8. ควรต้องมี Engineer Book

เมื่อทีมมีขนาดใหญ่ขึ้น บริษัทมีขนาดใหญ่ขึ้น ปัญหาที่ตามมาคือ การสอน การ training เป็นเรื่องที่ยากขึ้น ดังนั้นถ้ามีหนังสือเพื่ออธิบายและบอกสิ่งต่าง ๆ เช่น

• การติดตั้ง software ที่จำเป็น
• การ configuration ต่าง ๆ
• Coding style guide
• รูปแบบการทำงาน

ซึ่งเรื่องต่าง ๆ เหล่านี้มันคือพื้นฐานและธรรมชาติของการพัฒนาเลยนะ