คู่มือนี้ครอบคลุมแนวทางปฏิบัติแนะนำและสถาปัตยกรรมที่แนะนำสำหรับการสร้างแอปที่มีประสิทธิภาพและมีคุณภาพสูง
ประสบการณ์ของผู้ใช้แอปบนอุปกรณ์เคลื่อนที่
แอป Android ทั่วไปมีคอมโพเนนต์แอปหลายรายการ ซึ่งรวมถึงกิจกรรม ฟragment บริการ ผู้ให้บริการเนื้อหา และตัวรับการออกอากาศ คุณประกาศคอมโพเนนต์แอปส่วนใหญ่เหล่านี้ในไฟล์ Manifest ของแอป จากนั้นระบบปฏิบัติการ Android จะใช้ไฟล์นี้เพื่อตัดสินใจว่าจะผสานรวมแอปของคุณเข้ากับประสบการณ์โดยรวมของผู้ใช้อุปกรณ์อย่างไร เนื่องจากแอป Android ทั่วไปอาจมีคอมโพเนนต์หลายรายการและผู้ใช้มักโต้ตอบกับแอปหลายแอปในระยะเวลาสั้นๆ แอปจึงต้องปรับให้เข้ากับเวิร์กโฟลว์และงานต่างๆ ที่ผู้ใช้เป็นผู้กำหนด
โปรดทราบว่าอุปกรณ์เคลื่อนที่ยังมีทรัพยากรจํากัดด้วย ดังนั้นระบบปฏิบัติการอาจหยุดกระบวนการของแอปบางรายการเพื่อเพิ่มพื้นที่ให้กับกระบวนการใหม่ได้ทุกเมื่อ
ภายใต้เงื่อนไขของสภาพแวดล้อมนี้ คอมโพเนนต์ของแอปอาจเปิดขึ้นทีละรายการและไม่เป็นระเบียบ และระบบปฏิบัติการหรือผู้ใช้อาจทำลายคอมโพเนนต์เหล่านั้นได้ทุกเมื่อ เนื่องจากเหตุการณ์เหล่านี้อยู่นอกเหนือการควบคุมของคุณ คุณจึงไม่ควรจัดเก็บหรือเก็บข้อมูลแอปพลิเคชันหรือสถานะไว้ในหน่วยความจำของคอมโพเนนต์แอป และคอมโพเนนต์แอปไม่ควรพึ่งพากัน
หลักการทั่วไปเกี่ยวกับสถาปัตยกรรม
หากไม่ควรใช้คอมโพเนนต์แอปเพื่อจัดเก็บข้อมูลแอปพลิเคชันและสถานะ คุณควรออกแบบแอปอย่างไรแทน
เมื่อแอป Android มีขนาดเพิ่มขึ้น คุณควรกำหนดสถาปัตยกรรมที่ช่วยให้แอปปรับขนาดได้ เพิ่มความเสถียรของแอป และทำให้ทดสอบแอปได้ง่ายขึ้น
สถาปัตยกรรมแอปจะกําหนดขอบเขตระหว่างส่วนต่างๆ ของแอปและความรับผิดชอบที่แต่ละส่วนควรมี คุณควรออกแบบสถาปัตยกรรมแอปให้เป็นไปตามหลักการบางอย่างที่เฉพาะเจาะจงเพื่อให้เป็นไปตามความต้องการที่กล่าวถึงข้างต้น
การแยกข้อกังวล
หลักการที่สําคัญที่สุดที่ควรปฏิบัติตามคือการแยกข้อกังวล
ข้อผิดพลาดที่พบบ่อยคือการเขียนโค้ดทั้งหมดใน Activity หรือ Fragment คลาสที่อิงตาม UI เหล่านี้ควรมีเฉพาะตรรกะที่จัดการการโต้ตอบระหว่าง UI กับระบบปฏิบัติการเท่านั้น การทำคลาสเหล่านี้ให้เรียบง่ายที่สุดเท่าที่จะทำได้จะช่วยหลีกเลี่ยงปัญหาต่างๆ เกี่ยวกับวงจรชีวิตของคอมโพเนนต์ และปรับปรุงความสามารถในการทดสอบของคลาสเหล่านี้
โปรดทราบว่าคุณไม่ได้เป็นเจ้าของการใช้งาน Activity และ Fragment แต่เป็นเพียงคลาสกาวที่แสดงถึงสัญญาระหว่างระบบปฏิบัติการ Android กับแอปของคุณ ระบบปฏิบัติการสามารถทำลายคลาสเหล่านี้ได้ทุกเมื่อโดยอิงตามการโต้ตอบของผู้ใช้หรือสภาพของระบบ เช่น หน่วยความจำเหลือน้อย คุณควรลดการพึ่งพาโฆษณาเพื่อมอบประสบการณ์การใช้งานที่น่าพึงพอใจแก่ผู้ใช้และประสบการณ์การบำรุงรักษาแอปที่จัดการได้ง่ายขึ้น
สร้าง UI ของไดรฟ์จากโมเดลข้อมูล
หลักการสําคัญอีกประการหนึ่งคือคุณควรขับเคลื่อน UI จากโมเดลข้อมูล โดยควรเป็นโมเดลถาวร โมเดลข้อมูลแสดงถึงข้อมูลของแอป โดยอิสระจากองค์ประกอบ UI และคอมโพเนนต์อื่นๆ ในแอป ซึ่งหมายความว่าโมเดลข้อมูลไม่ได้เชื่อมโยงกับวงจรชีวิตของ UI และคอมโพเนนต์แอป แต่ระบบจะยังคงทำลายโมเดลข้อมูลเมื่อระบบปฏิบัติการตัดสินใจนำกระบวนการของแอปออกจากหน่วยความจำ
รูปแบบถาวรเหมาะสําหรับเหตุผลต่อไปนี้
ผู้ใช้จะไม่สูญเสียข้อมูลหากระบบปฏิบัติการ Android ทำลายแอปของคุณเพื่อเพิ่มพื้นที่เก็บข้อมูล
แอปจะยังคงทำงานต่อไปได้ในกรณีที่การเชื่อมต่อเครือข่ายไม่เสถียรหรือไม่พร้อมใช้งาน
หากใช้คลาสโมเดลข้อมูลเป็นพื้นฐานของสถาปัตยกรรมแอป จะทำให้แอปของคุณทดสอบได้และมีประสิทธิภาพมากขึ้น
แหล่งข้อมูลที่เชื่อถือได้เพียงแหล่งเดียว
เมื่อมีการกําหนดประเภทข้อมูลใหม่ในแอป คุณควรกําหนดแหล่งที่มาของข้อมูลจริงแหล่งเดียว (SSOT) ให้กับประเภทข้อมูลนั้น SSOT คือเจ้าของข้อมูลดังกล่าว และมีเพียง SSOT เท่านั้นที่แก้ไขหรือเปลี่ยนแปลงข้อมูลได้ โดย SSOT จะแสดงข้อมูลโดยใช้ประเภทที่แก้ไขไม่ได้ และเพื่อแก้ไขข้อมูล SSOT จะแสดงฟังก์ชันหรือรับเหตุการณ์ที่ประเภทอื่นๆ สามารถเรียกใช้ได้
รูปแบบนี้มีประโยชน์หลายประการ ดังนี้
- ซึ่งจะรวมการเปลี่ยนแปลงทั้งหมดของข้อมูลประเภทหนึ่งๆ ไว้ในที่เดียว
- ซึ่งจะปกป้องข้อมูลดังกล่าวเพื่อให้ประเภทอื่นๆ ไม่สามารถแทรกแซงได้
- ซึ่งทำให้ติดตามการเปลี่ยนแปลงข้อมูลได้ง่ายขึ้น จึงช่วยให้พบข้อบกพร่องได้ง่ายขึ้น
ในแอปพลิเคชันแบบออฟไลน์ก่อน แหล่งข้อมูลสําหรับข้อมูลแอปพลิเคชันมักจะเป็นฐานข้อมูล ในบางกรณี แหล่งที่มาของข้อมูลที่เป็นความจริงอาจเป็น ViewModel หรือแม้แต่ UI
โฟลว์ข้อมูลแบบทิศทางเดียว
เรามักใช้หลักการแหล่งข้อมูลที่ถูกต้องแห่งเดียวในคู่มือที่มีรูปแบบการไหลของข้อมูลแบบทิศทางเดียว (UDF) ใน UDF state จะไหลไปในทิศทางเดียวเท่านั้น เหตุการณ์ที่แก้ไขการไหลของข้อมูลในทิศทางตรงกันข้าม
ใน Android สถานะหรือข้อมูลมักจะไหลจากประเภทที่มีขอบเขตสูงกว่าของลําดับชั้นไปยังประเภทที่มีขอบเขตต่ำกว่า โดยทั่วไป เหตุการณ์จะทริกเกอร์จากประเภทที่มีขอบเขตต่ำกว่าจนกว่าจะถึง SSOT สําหรับประเภทข้อมูลที่เกี่ยวข้อง เช่น ข้อมูลแอปพลิเคชันมักจะไหลจากแหล่งข้อมูลไปยัง UI เหตุการณ์ของผู้ใช้ เช่น การกดปุ่ม จะส่งผ่านจาก UI ไปยัง SSOT ซึ่งมีการแก้ไขข้อมูลแอปพลิเคชันและแสดงข้อมูลในประเภทที่แก้ไขไม่ได้
รูปแบบนี้รับประกันความสอดคล้องของข้อมูลได้ดีกว่า มีโอกาสเกิดข้อผิดพลาดน้อยลง แก้ไขข้อบกพร่องได้ง่ายขึ้น และนำประโยชน์ทั้งหมดของรูปแบบ SSOT มาใช้ได้
สถาปัตยกรรมแอปที่แนะนำ
ส่วนนี้จะสาธิตวิธีจัดโครงสร้างแอปตามแนวทางปฏิบัติแนะนำ
เมื่อพิจารณาถึงหลักการทั่วไปด้านสถาปัตยกรรมที่กล่าวถึงในส่วนก่อนหน้า แอปพลิเคชันแต่ละรายการควรมีเลเยอร์อย่างน้อย 2 เลเยอร์ ดังนี้
- เลเยอร์ UI ที่แสดงข้อมูลแอปพลิเคชันบนหน้าจอ
- เลเยอร์ข้อมูลที่มีตรรกะทางธุรกิจของแอปและแสดงข้อมูลแอปพลิเคชัน
คุณสามารถเพิ่มเลเยอร์อีกเลเยอร์ที่เรียกว่าเลเยอร์โดเมนเพื่อลดความซับซ้อนและนําการโต้ตอบระหว่าง UI กับเลเยอร์ข้อมูลมาใช้ซ้ำ
สถาปัตยกรรมแอปสมัยใหม่
สถาปัตยกรรมแอปสมัยใหม่นี้สนับสนุนให้ใช้เทคนิคต่อไปนี้และอื่นๆ
- สถาปัตยกรรมแบบตอบสนองและแบบเป็นชั้น
- การรับส่งข้อมูลแบบทิศทางเดียว (UDF) ในเลเยอร์ทั้งหมดของแอป
- เลเยอร์ UI ที่มีตัวเก็บสถานะเพื่อจัดการความซับซ้อนของ UI
- Coroutine และ Flow
- แนวทางปฏิบัติแนะนำเกี่ยวกับการนําเข้าพึ่งพา
ดูข้อมูลเพิ่มเติมได้ที่ส่วนต่อไปนี้ หน้าสถาปัตยกรรมอื่นๆ ในสารบัญ และหน้าคำแนะนำที่มีสรุปแนวทางปฏิบัติแนะนำที่สําคัญที่สุด
เลเยอร์ UI
บทบาทของเลเยอร์ UI (หรือเลเยอร์การนำเสนอ) คือการแสดงข้อมูลแอปพลิเคชันบนหน้าจอ เมื่อใดก็ตามที่ข้อมูลมีการเปลี่ยนแปลง ไม่ว่าจะเป็นจากการโต้ตอบของผู้ใช้ (เช่น การกดปุ่ม) หรืออินพุตภายนอก (เช่น การตอบสนองของเครือข่าย) UI ควรอัปเดตให้สอดคล้องกับการเปลี่ยนแปลง
เลเยอร์ UI ประกอบด้วย 2 ส่วน ได้แก่
- องค์ประกอบ UI ที่แสดงผลข้อมูลบนหน้าจอ คุณสร้างองค์ประกอบเหล่านี้ได้โดยใช้ฟังก์ชัน View หรือ Jetpack Compose
- ตัวเก็บสถานะ (เช่น คลาส ViewModel) ที่เก็บข้อมูล แสดงข้อมูลต่อ UI และจัดการตรรกะ
ดูข้อมูลเพิ่มเติมเกี่ยวกับเลเยอร์นี้ได้ที่หน้าเลเยอร์ UI
ชั้นข้อมูล
ชั้นข้อมูลของแอปมีตรรกะทางธุรกิจ ตรรกะทางธุรกิจคือสิ่งที่ให้คุณค่าแก่แอปของคุณ ซึ่งประกอบด้วยกฎที่กําหนดวิธีที่แอปสร้าง จัดเก็บ และเปลี่ยนแปลงข้อมูล
เลเยอร์ข้อมูลประกอบด้วยที่เก็บแต่ละแห่งซึ่งมีแหล่งข้อมูลได้ตั้งแต่ 0 ถึงหลายแหล่ง คุณควรสร้างคลาสที่เก็บสำหรับข้อมูลแต่ละประเภทที่คุณจัดการในแอป เช่น คุณอาจสร้างคลาส MoviesRepository สำหรับข้อมูลที่เกี่ยวข้องกับภาพยนตร์ หรือคลาส PaymentsRepository สำหรับข้อมูลที่เกี่ยวข้องกับการชำระเงิน
คลาสที่เก็บมีหน้าที่รับผิดชอบงานต่อไปนี้
- การเปิดเผยข้อมูลแก่ส่วนที่เหลือของแอป
- เปลี่ยนข้อมูลไว้ในที่เดียว
- การแก้ไขความขัดแย้งระหว่างแหล่งข้อมูลหลายแห่ง
- การแยกแหล่งที่มาของข้อมูลจากส่วนอื่นๆ ของแอป
- มีตรรกะทางธุรกิจ
คลาสแหล่งข้อมูลแต่ละคลาสควรมีหน้าที่รับผิดชอบในการจัดการกับแหล่งข้อมูลเพียงแหล่งเดียว ซึ่งอาจเป็นไฟล์ แหล่งข้อมูลเครือข่าย หรือฐานข้อมูลในเครื่อง คลาสแหล่งข้อมูลเป็นสะพานเชื่อมระหว่างแอปพลิเคชันกับระบบสําหรับการดําเนินการกับข้อมูล
ดูข้อมูลเพิ่มเติมเกี่ยวกับเลเยอร์นี้ได้ที่หน้าชั้นข้อมูล
เลเยอร์โดเมน
ชั้นโดเมนเป็นเลเยอร์ที่ไม่บังคับซึ่งอยู่ตรงกลางระหว่าง UI กับชั้นข้อมูล
เลเยอร์โดเมนมีหน้าที่รับผิดชอบในการรวมตรรกะทางธุรกิจที่ซับซ้อน หรือตรรกะทางธุรกิจง่ายๆ ที่ ViewModel หลายรายการนำมาใช้ซ้ำ เลเยอร์นี้ไม่บังคับเนื่องจากแอปบางแอปอาจไม่มีข้อกำหนดเหล่านี้ คุณควรใช้แอตทริบิวต์นี้เมื่อจําเป็นเท่านั้น เช่น เพื่อจัดการกับความซับซ้อนหรือเพื่อสนับสนุนการนํากลับมาใช้ซ้ำ
โดยทั่วไปแล้วคลาสในเลเยอร์นี้จะเรียกว่า Use Case หรือ Interactor Use Case แต่ละรายการควรมีหน้าที่รับผิดชอบต่อฟังก์ชันการทำงานรายการเดียว ตัวอย่างเช่น แอปของคุณอาจมีคลาส GetTimeZoneUseCase หาก ViewModel หลายรายการใช้เขตเวลาเพื่อแสดงข้อความที่เหมาะสมบนหน้าจอ
ดูข้อมูลเพิ่มเติมเกี่ยวกับเลเยอร์นี้ได้ที่หน้าเลเยอร์โดเมน
จัดการการพึ่งพาระหว่างคอมโพเนนต์
คลาสในแอปของคุณต้องอาศัยคลาสอื่นๆ จึงจะทำงานได้อย่างถูกต้อง คุณสามารถใช้รูปแบบการออกแบบอย่างใดอย่างหนึ่งต่อไปนี้เพื่อรวบรวมข้อมูลการอ้างอิงของคลาสหนึ่งๆ
- Dependency Injection (DI): Dependency Injection ช่วยให้คลาสกำหนดการอ้างอิงได้โดยไม่ต้องสร้าง รันไทม์จะกำหนดให้คลาสอื่นเป็นผู้รับผิดชอบในการระบุข้อกำหนดเหล่านี้
- ตัวระบุบริการ: รูปแบบตัวระบุบริการเป็นรีจิสทรีที่คลาสสามารถรับข้อมูลที่เกี่ยวข้องได้แทนการสร้าง
รูปแบบเหล่านี้ช่วยให้คุณปรับขนาดโค้ดได้เนื่องจากมีรูปแบบที่ชัดเจนสำหรับการจัดการการพึ่งพาโดยไม่ทำซ้ำโค้ดหรือเพิ่มความซับซ้อน นอกจากนี้ รูปแบบเหล่านี้ยังช่วยให้คุณสลับระหว่างการติดตั้งใช้งานเวอร์ชันทดสอบและเวอร์ชันที่ใช้งานจริงได้อย่างรวดเร็ว
เราขอแนะนำให้ทำตามรูปแบบการฉีด Dependency และการใช้คลัง Hilt ในแอป Android Hilt จะสร้างออบเจ็กต์โดยอัตโนมัติด้วยการเรียกใช้ผ่านลําดับชั้นของ Dependency ให้การรับประกันเกี่ยวกับ Dependency ในเวลาคอมไพล์ และสร้างคอนเทนเนอร์ Dependency สําหรับคลาสเฟรมเวิร์ก Android
แนวทางปฏิบัติแนะนำโดยทั่วไป
การเขียนโปรแกรมเป็นสาขาที่ต้องใช้ความคิดสร้างสรรค์ และการสร้างแอป Android ก็ไม่ใช่ข้อยกเว้น การแก้ปัญหามีหลายวิธี คุณอาจสื่อสารข้อมูลระหว่างกิจกรรมหรือส่วนต่างๆ หลายรายการ ดึงข้อมูลระยะไกลและเก็บไว้ในเครื่องสำหรับโหมดออฟไลน์ หรือจัดการสถานการณ์ทั่วไปอื่นๆ อีกมากมายที่แอปที่ซับซ้อนพบ
แม้ว่าคำแนะนำต่อไปนี้จะไม่บังคับ แต่ในกรณีส่วนใหญ่ การทำตามคำแนะนำเหล่านี้จะทำให้ฐานโค้ดมีความเสถียร ทดสอบได้ และดูแลรักษาได้ในระยะยาว
อย่าจัดเก็บข้อมูลไว้ในคอมโพเนนต์แอป
หลีกเลี่ยงการกำหนดจุดแรกเข้าของแอป เช่น กิจกรรม บริการ และตัวรับสัญญาณออกอากาศ เป็นแหล่งที่มาของข้อมูล แต่ควรประสานงานกับคอมโพเนนต์อื่นๆ เพื่อดึงข้อมูลชุดย่อยที่เกี่ยวข้องกับจุดแรกเข้านั้นเท่านั้น คอมโพเนนต์ของแอปแต่ละรายการมีอายุการใช้งานค่อนข้างสั้น โดยขึ้นอยู่กับการโต้ตอบของผู้ใช้กับอุปกรณ์และสถานะโดยรวมปัจจุบันของระบบ
ลดการพึ่งพาคลาส Android
คอมโพเนนต์ของแอปควรเป็นคลาสเดียวที่ใช้ API ของเฟรมเวิร์ก Android SDK เช่น Context หรือ Toast การแยกคลาสอื่นๆ ในแอปออกจากคลาสเหล่านี้จะช่วยในการทดสอบและลดการเชื่อมโยงภายในแอป
กำหนดขอบเขตความรับผิดชอบที่ชัดเจนระหว่างโมดูลต่างๆ ในแอป
เช่น อย่ากระจายโค้ดที่โหลดข้อมูลจากเครือข่ายไปยังคลาสหรือแพ็กเกจหลายรายการในฐานโค้ด ในทํานองเดียวกัน อย่ากําหนดความรับผิดชอบหลายอย่างที่ไม่เกี่ยวข้องกัน เช่น การแคชข้อมูลและการเชื่อมโยงข้อมูล ในคลาสเดียวกัน การใช้สถาปัตยกรรมแอปที่แนะนำจะช่วยคุณในเรื่องนี้ได้
เปิดเผยข้อมูลจากแต่ละโมดูลให้น้อยที่สุด
เช่น อย่าสร้างทางลัดที่แสดงรายละเอียดการติดตั้งใช้งานภายในจากโมดูล คุณอาจประหยัดเวลาได้บ้างในระยะสั้น แต่ก็มีแนวโน้มที่จะเกิดหนี้ทางเทคนิคหลายครั้งเมื่อฐานโค้ดพัฒนาขึ้น
มุ่งเน้นที่หัวใจหลักที่ไม่เหมือนใครของแอปเพื่อให้โดดเด่นกว่าแอปอื่นๆ
อย่าสร้างสิ่งใหม่โดยการเขียนโค้ดที่ซ้ำกันซ้ำๆ แต่ให้มุ่งเน้นเวลาและพลังงานไปกับสิ่งที่ทำให้แอปของคุณโดดเด่น และปล่อยให้ไลบรารี Jetpack และไลบรารีอื่นๆ ที่แนะนําจัดการข้อมูลโค้ดซ้ำๆ
พิจารณาวิธีทำให้แต่ละส่วนของแอปสามารถทดสอบแยกกันได้
ตัวอย่างเช่น การมี API ที่กําหนดไว้อย่างชัดเจนสําหรับการดึงข้อมูลจากเครือข่ายจะช่วยให้ทดสอบโมดูลที่เก็บข้อมูลนั้นไว้ในฐานข้อมูลในเครื่องได้ง่ายขึ้น แต่หากคุณผสมผสานตรรกะจากโมดูลทั้ง 2 รายการนี้ไว้ในที่เดียว หรือกระจายโค้ดเครือข่ายไปทั่วทั้งฐานโค้ด ก็จะทำให้การทดสอบมีประสิทธิภาพมากขึ้น (หรือแทบเป็นไปไม่ได้เลย)
ประเภทมีหน้าที่รับผิดชอบต่อนโยบายการทำงานพร้อมกัน
หากประเภทหนึ่งทํางานแบบบล็อกที่ใช้เวลานาน ก็ควรรับผิดชอบในการย้ายการประมวลผลนั้นไปยังเธรดที่เหมาะสม ประเภทนั้นๆ จะทราบประเภทการคํานวณที่ทําอยู่และควรเรียกใช้เธรดใด ประเภทควรเป็นแบบปลอดภัยสำหรับหลัก ซึ่งหมายความว่าสามารถเรียกใช้จากเธรดหลักได้โดยไม่บล็อก
เก็บข้อมูลที่เกี่ยวข้องและเป็นปัจจุบันไว้มากที่สุด
วิธีนี้จะช่วยให้ผู้ใช้เพลิดเพลินกับฟังก์ชันการทำงานของแอปได้แม้ว่าอุปกรณ์จะอยู่ในโหมดออฟไลน์ โปรดทราบว่าผู้ใช้บางรายอาจไม่ได้รับการเชื่อมต่อที่รวดเร็วและต่อเนื่อง และแม้ว่าจะได้รับการเชื่อมต่อที่ดี แต่สัญญาณก็อาจไม่ดีในสถานที่ที่มีผู้คนแออัด
ประโยชน์ของสถาปัตยกรรม
การใช้สถาปัตยกรรมที่ดีในแอปจะมีประโยชน์มากมายต่อทีมโครงการและทีมวิศวกร ดังนี้
- ซึ่งจะช่วยปรับปรุงความสามารถในการบำรุงรักษา คุณภาพ และความเสถียรของแอปโดยรวม
- ซึ่งช่วยให้แอปปรับขนาดได้ ผู้คนและทีมจำนวนมากขึ้นสามารถมีส่วนร่วมในโค้ดเบสเดียวกันได้โดยที่โค้ดไม่ขัดแย้งกันมากนัก
- ซึ่งช่วยในการเริ่มต้นใช้งาน เนื่องจากสถาปัตยกรรมช่วยให้โครงการมีความสอดคล้องกัน สมาชิกใหม่ของทีมจึงสามารถเรียนรู้สิ่งต่างๆ ได้อย่างรวดเร็วและทำงานได้อย่างมีประสิทธิภาพมากขึ้นในเวลาอันสั้น
- ทดสอบได้ง่ายขึ้น สถาปัตยกรรมที่ดีจะส่งเสริมประเภทที่เรียบง่ายซึ่งโดยทั่วไปจะทดสอบได้ง่ายกว่า
- คุณสามารถตรวจสอบข้อบกพร่องอย่างเป็นระบบด้วยกระบวนการที่ชัดเจน
การลงทุนในสถาปัตยกรรมยังส่งผลโดยตรงต่อผู้ใช้ด้วย ทีมได้รับประโยชน์จากแอปพลิเคชันที่เสถียรมากขึ้นและฟีเจอร์ที่มากขึ้นเนื่องจากทีมวิศวกรทำงานได้อย่างมีประสิทธิภาพมากขึ้น อย่างไรก็ตาม สถาปัตยกรรมยังต้องอาศัยการลงทุนด้านเวลาล่วงหน้าด้วย โปรดดูกรณีศึกษาเหล่านี้ซึ่งบริษัทอื่นๆ แชร์เรื่องราวความสำเร็จเมื่อใช้สถาปัตยกรรมที่ดีในแอป เพื่อช่วยอธิบายเหตุผลในการใช้เวลานี้กับส่วนที่เหลือของบริษัท
ตัวอย่าง
ตัวอย่างต่อไปนี้จาก Google แสดงสถาปัตยกรรมแอปที่ดี โปรดดูตัวอย่างการใช้งานคำแนะนำนี้
แนะนำสำหรับคุณ
- หมายเหตุ: ข้อความลิงก์จะแสดงเมื่อ JavaScript ปิดอยู่
- ชั้นข้อมูล
- เลเยอร์ UI
- เหตุการณ์ UI