วันนี้มีโอกาสไปร่วมงาน iOSDevTH Meetup #7 ของกลุ่ม iOS Developer Thailand
จัดที่บริษัท Ascend ตึก AIA รัชาภิเษก
มีหัวข้อที่น่าสนใจ 2 หัวข้อคือ
- Concurrency on iOS
- 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 ก็จบแล้ว
ถ้าเราลองแบ่งส่วนการทำงานตามหน้าที่
ก็น่าจะแบ่งออกเป็นส่วนต่าง ๆ ดังนี้
- ส่วนการแสดงผลคือ View class
- ส่วนการประมวลผลเรื่อง counter คือ Counter class หรือ Model
- ส่วนเชื่อมต่อทั้ง View และ Model คือ ViewController
- แต่ละส่วนเชื่อมต่อกันด้วย 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
- รูปแบบการทำงาน
ซึ่งเรื่องต่าง ๆ เหล่านี้มันคือพื้นฐานและธรรมชาติของการพัฒนาเลยนะ
