Quantcast
Channel: cc :: somkiat
Viewing all articles
Browse latest Browse all 1997

[แปล] ประสบการณ์ในการพัฒนา iOS app ว่าด้วยเรื่องความเรียบง่าย

$
0
0

บ่ายนี้นั่งอ่านบทความเรื่อง 5 key learnings after 8 years of iOS development ได้ทำการสรุปประสบการณ์ในการเรียนรู้เกี่ยวกับการพัฒนา iOS ให้
  • Efficient
  • Maintainable
  • Fun
ซึ่งเป็นอีกมุมมองหนึ่งที่น่าสนใจ จึงทำการแปลและสรุปไว้นิดหน่อย มาเริ่มกันเลย

1. Stay Native

แน่นอนว่าการพัฒนา iOS ด้วยภาษา native ทั้ง Objective-C, Swift ด้วยเครื่องมือพัฒนาเช่น XCode เลย เป็นแนวทางที่เหมาะสมที่สุดแล้ว เนื่องจากการนำ Cross-platform tool/framework มาใช้นั้น มันคือการเพิ่มความซับซ้อนขึ้นมา รวมทั้งก่อให้เกิด bug หรือข้อผิดพลาดต่าง ๆ ตามมา
ที่สำคัญ Native นั้นคือหนทางในการลดความเสี่ยงต่าง ๆ ออกไป
ปล. จากประสบการส่วนตัวของผม พบว่า Native มันเริ่มไม่นิ่งเท่าไรแล้ว ตั้งแต่ Objective-C มายัง Swift จาก Swift 1 มายัง Swift 2 จาก Swift 2 มายัง Swift 3 อีกอย่างคือ XCode ที่ตัวใหม่ ๆ bug เยอะเหลือเกิน
ที่สำคัญ Cross platform tool/framework ในปัจจุบันก็ดีขึ้นอย่างมาก ดังนั้นการเลือกเครื่องมือให้เหมาะสมกับ app จึงเป็นเรื่องที่สำคัญมาก ๆ

2. Avoid external libraries

เป็นเรื่องที่สำคัญมาก ๆ ในบทความแนะนำว่า อย่าใช้ external library คือแนวทางที่ดีที่สุด อะไรที่เขียนเองได้ก็เขียน คำถามคือ เราต้องการอะไรบ้าง ? แต่ถ้าเลี่ยงไม่ได้ เช่น การใช้งาน GoogleMap ก็อนุโลมได้นะ ปล. ผมนึกถึงแนวคิดเกี่ยวกับ Don’t Reinvent the wheel ขึ้นมาเลย เช่นเรื่องของการจัดการ network เป็นต้น คำถามที่ตามมาคือ ถ้าใช้ external library พวกนี้แล้ว คุณพร้อมรับกับความเสี่ยงต่าง ๆ หรือไม่ ? เช่นพร้อมรับกับการเปลี่ยนแปลงต่าง ๆ เช่นภาษาที่ใช้พัฒนาและ API ที่เปลี่ยนไป

3. Don’t use package manager

จากข้อ 2 นั่นเอง ถ้าไม่ใช้ external library แล้ว ก็ไม่มีความจำเป็นต้องใช้ package manager tool ใด ๆ เลย บ่อยครั้งนักพัฒนามีปัญหากับ package manager tool เสียอย่างนั้น
ประเด็นหลักคือ การลดความเสี่ยง ถ้าสามารถ copy library เข้ามายัง project ได้ ทำไปแล้ว !! มันก็มีความเสี่ยงนะ ลองพิจารณากันดู

4. Layout in code instead of Storyboard

Storyboard นั้นทำให้เราเริ่มต้นพัฒนา app ได้ง่ายและรวดเร็ว แต่ถ้าต้องการให้การแสดงผลเป็นแบบ dynamic มาก ๆ หรือใส่พวก animation แปลก ๆ เข้าไปตามที่ต้องการ พบว่าการเขียน code จัดการจะสะดวกกว่ามาก บาง app พบว่า Storyboard มีขนาดใหญ่มาก ๆ มีความซับซ้อน เชื่อมโยงไปมามากมาย ดังนั้นจึงแนะนำให้สร้าง layout ใน code ไปเลย เพราะว่ามันง่ายและยึดหยุ่นกว่า ปล. จากประสบการณ์ที่ผ่านมา พบว่าระบบงานที่สร้าง layout ใน code อย่างเดียว และมีขนาดที่ใหญ่ด้วย จะพบปัญหาในแง่ของการ maintain สูงมาก ๆ แต่ถ้ามีเอกสารหรือการเขียน code ที่ดี ก็น่าจะดี แต่ส่วนใหญ่จะเขียนแย่กว่าดี !! อีกอย่างหนึ่งคือ เมื่อ XCode เปลี่ยน version Storyboard ถึงกับพังเกลี้ยงกันเลยทีเดียว !! ดังนั้นผมคิดว่าควรใช้ทั้ง Storyboard, Xib และ code ร่วมกัน

5. Use Core Data

สำหรับนักพัฒนามือใหม่ไม่ค่อยมีใครชอบ Core Data มากนัก เนื่องจากต้องเขียน code เยอะแยะตามข้อกำหนดที่วางไว้ แต่ถ้าเข้าใจและเรียนรู้อย่างถูกต้อง แล้วจะสามารถใช้งานได้อย่างมีความสุข ปล. ผมก็เป็นมือใหม่เหมือนกัน การใช้งาน Core Data ก็น่าเบื่อจริง ๆ นะ แต่ก็ไม่ยากอย่างที่คิด แต่ปัจจุบันใช้ Realm ง่ายกว่าเยอะเลย !!

สุดท้ายแล้วเป้าหมายหลักของบทความนี้คือ

การ maintain หรือดูแลรักษาระบบให้ง่ายที่สุด เพื่อต่อสู้กับ version ที่เปลี่ยนไป iOS ดังนั้นทำให้เรียบง่ายที่สุดครับ อย่าซับซ้อนมาก ขอให้สนุกกับการ coding ครับ

Viewing all articles
Browse latest Browse all 1997

Trending Articles