วันนี้ได้อ่านบทความต่าง ๆ จาก Clean Swift
จึงทำการสรุป และ แปลไว้อ่านกันนิดหน่อย
ซึ่งน่าจะมีประโยชน์สำหรับนักพัฒนาอย่างมาก
มาเริ่มด้วยเรื่อง Clean Swift คืออะไร ?
เป้าหมายหลักของ Clean Swift Architecture คือ
แก้ไขปัญหา Massive View Controller
ผลที่ตามมาคือ เมื่อลูกค้าถามว่า
ต้องใช้เวลาเท่าไรในการแก้ไข Bug ?
ต้องใช้เวลาเท่าไรในการเพิ่ม feature ใหม่เข้าไป ?
สิ่งที่คุณจะตอบไปคืออะไรล่ะ
แน่นอนว่าต้องรีบ ๆ ตอบออกไปว่า …
แต่ในใจลึก ๆ คุณก็รู้อยู่แก่ใจว่า ..
เวลาเหล่านั้น คือ การโกหกล้วน ๆ
เนื่องจาก
มันมีอะไรที่เยอะกว่า
มันมีอะไรที่ซับซ้อนกว่า
และสิ่งที่ตอบออกไปนั้น คุณก็ไม่ได้มั่นใจเลย !!
มันเป็นเพียงแค่ตัวเลขที่ต้องบอกออกไปเท่านั้นเอง
เมื่อลงมือทำแล้ว ผลที่ออกมาคือ ไม่สามารถส่งมอบงานตามเวลาที่บอกไว้ได้
นั่นคือ
- คุณไม่ได้ทำตามสัญญาที่ให้ไว้
- คุณทำลายความน่าเชื่อถือของตัวเอง
- คุณได้สร้างความไม่พอใจขึ้นมา
- ลูกค้าโมโห ฟาดงวงฟาดงาใส่คุณ
- เสียทั้งเวลา และ เงิน !!
สิ่งเหล่านี้มันทำให้เกิดแต่เรื่องแย่ ๆ ขึ้นมา
ยิ่งถ้าเป็นนักพัฒนาด้วยแล้ว ยิ่งแย่ไปใหญ่
เพราะว่า ส่วนใหญ่มักจะประเมินเวลา และ ค่าใช้จ่าย
ต่ำกว่าความเป็นจริงอย่างมาก
ซึ่งมันเป็นสิ่งที่โกหกทั้งสิ้น
บางครั้งลูกค้าไม่รู้ว่า เรามำการพัฒนาอย่างไร ?
บางครั้งลูกค้าไม่เข้าใจว่า เราทำการพัฒนาอย่างไร ?
- ระบบมีความซับซ้อนอย่างไร ?
- ต้องหยุดเปลี่ยนความต้องการบ่อย ๆ
- ต้องสนใจที่ function ในการทำงานมากกว่า User Interface(UI)
- ถ้าทำการแก้ไข code ที่ทำไว้สัก 1-2 เดือนที่แล้ว จะใช้เวลาน้อยใช่ไหม ?
ฝั่งนักพัฒนาก็เช่นกัน เข้าใจสิ่งที่เขียนหรือสร้างเพียงใด ?
code เป็นอย่างไร ?
มีกี่ class ?
มีกี่ method ?
มี loop และ condition ที่ซับซ้อนไหม ?
code แต่ละบรรทัดทำการทดสอบไหม ?
เมื่อเกิดปัญหาแล้ว รู้สาเหตุหรือไม่ ? หรือต้องทำการ debug ?
เมื่อเกิดปัญหาแล้ว สามารถจำลอง หรือ สร้างปัญหาเหล่านั้นได้หรือไม่ ?
เมื่อทำการเปลี่ยนแปลง code แล้ว สามารถเห็นผลของการเปลี่ยนแปลงหรือไม่ ?
ทำซำ้ ๆ แบบนี้ไปจนกว่าจะแก้ไขปัญหาได้
หรือว่า เมื่อทำการแก้ไข หรือ เพิ่ม code ใหม่เข้าไปแล้ว
คุณจะรู้สึกกลัวว่า
สิ่งที่แก้ไข หรือ เพิ่มเข้าไปนั้น มันจะไปกระทบต่อส่วนอื่น ๆ !!
เพราะว่า ไม่มีชุดของ unit test
และไม่สามารถทำ regression test ได้บ่อย ๆ
ซึ่งปัญหาต่าง ๆ เหล่านี้มันคือ
วงจรชีวิตแบบแย่ ๆ ของการพัฒนา software
ที่พบเจอกันอยู่อย่างเสมอ !!
ดังนั้นวิธีการแก้ไขปัญหา เรามักจะใช้ MVC pattern (Model View Controller)
ถ้าเป็น iOS app นั่นคือ
เราทำการ refactor code ในส่วนของ View Controller
ให้อยู่ในโครงสร้างที่ดีขึ้น
นั่นคือ แยกส่วนการทำงานที่ไม่ควรอยู่ใน View Controller ออกมา
ทำการแยกส่วนของ business logic ไปไว้ที่ model
เป็นวิธีการที่เรียบง่ายมาก ๆ
แถมทำให้เราเขียนชุดการทดสอบในแต่ละส่วนได้ง่ายมาก ๆ
แต่มีนักพัฒนาน้อยคนมาก ๆ ที่จะทำ !!
มันแปลก ๆ ดีนะ
ปัญหาที่เกิดอีกก็คือ
เราจะทำการเขียน code ให้มันเสร็จ ๆ ไปก่อน
หลังจากนั้นจึงทำการ refactor code ต่อไป !!
คำถามที่เกิดขึ้นมาคือ
ทำไมต้องทำการ refactor code หลังจากเขียนเสร็จไปแล้วล่ะ ?
ทำไมไม่เขียน code ที่ผ่านการคิดเรื่อง refactor มาแล้วเลยล่ะ ?
จะได้ไม่เสียเวลา !!
ส่งที่เรากำลังทำอยู่ มันคือการแก้ไขที่ต้นเหตุของปัญหาหรือเปล่านะ ?
ต้นเหตุของปัญหาหลัก ๆ คือ Architecute ของระบบงาน !!
แต่เมื่อไปค้นหาว่ามี Architecture แบบไหนบ้าง
ก็จะเจอแนวคิดมากมาย เช่น
- MVC
- MVP
- MVVM
- Reactive
- VIPER
- Protocol Oriented MVVM
จะใช้อะไรดีล่ะ ? !!!!!
แนะนำให้ลองทุก ๆ ตัวดูนะ
แต่สิ่งที่จะแนะนำและอ้างอิงคือ แนวคิด Clean Architecture ของคุณ Uncle Bob
โดยแนวคิดนี้จะช่วยทำให้
- ทำการหาและแก้ไขปัญหาได้ง่ายและรวดเร็วขึ้น
- มั่นใจในการเปลี่ยนแปลง
- ง่ายต่อการเพิ่ม feature ใหม่ ๆ
- แต่ละ method/function จะสั้น ๆ และมีหน้าที่การทำงานเพียงอย่างเดียว
- ทำการแยกส่วนการทำงานออกจากกันอย่างชัดเจน
- แยกส่วนการทำงานออกจากส่วนการแสดงผล
- สร้างส่วนการทำงานที่ใช้ซ้ำ ๆ ออกมา เพื่อให้สามารถ reuse ได้ง่าย
- ทำการเขียน code ที่ดูแลรักษาได้ง่าย
- ทำการเขียน unit test เพื่อทดสอบ code ที่เขียนขึ้นมา
ส่วนรายละเอียดของ code ตัวอย่างดูเพิ่มเติมได้ที่ Github :: Clean Swift
ซึ่งจะนำมาสรุปต่อไป
สำหรับ Clean Swift เป็นแหล่งความรู้ที่นักพัฒนาพลาดไม่ได้เลยนะ
ลองทำการศึกษาและนำไปใช้งานดูครับ
ปล. ไม่ใช่เพียง iOS app เท่านั้นนะ
ระบบงานอื่น ๆ ก็สามารถนำแนวคิดไปใช้งานได้อีกด้วย
