Người dịch: Dương Đình Tuấn
Architecture trong hướng đối tượng cho ứng dụng có thể được mô tả đơn giản là cách sắp xếp các lớp trong hệ thống và cách thức chúng giao tiếp với nhau. Chúng ta tìm thấy cái nhìn tổng quan về vai trò và nhiệm vụ của các lớp này trong khi tạo ra chúng.
Tuyển lập trình viên android lương up to 30M
Dưới đây là một số điều có thể giúp chúng ta hiểu về kiến trúc này:
1 . Architecture là ngôn ngữ và là nền tảng bất khả tri
Architecture dựa trên các nguyên tắc lập trình. Những nguyên tắc hướng dẫn này có thể là nguyên tắc SOLID hoặc các mẫu thiết kế / architecture ổn định và architecture có thể được áp dụng trên các ngôn ngữ và nền tảng. Nên đầu tư thời gian vào architecture. Nó không chỉ giúp chúng ta thiết kế architecture tốt hơn mà còn cải thiện kỹ năng coding.
2. Sự mơ hồ về MVP / MVVM:
Nhiệm vụ của MVP (Model-View-Presenter) / MVVM (Model-View-ViewModel) là tách UI khỏi code. Chúng ta sử dụng Presenter / ViewModel để loại bỏ hết code logic ra khỏi View (Activity/Fragment). Việc phân tách này liên quan đến VP / VVM nhằm tách ra Model (M), M có nhiệm vụ cung cấp dữ liệu tới Presenter / ViewModel.
Những gì tôi thường thấy là Presenter và ViewModel được implement một cách chuẩn với các interface và observer nhưng ngoài ra nó còn khá rối. Tôi nghĩ rằng điều này có thể đổ lỗi cho việc sử dụng VP / VVM cho toàn bộ architecture của một ứng dụng và không thể định hình được Model (M). MVP / MVVM đóng một vai trò quan trọng như một mẫu kiến trúc nhưng kiến trúc của một ứng dụng vượt xa sự phân tách UI.
-
Architecture rất quan trọng nhưng không cần thiết:
Việc học Architecture đến ở giai đoạn sau trong quá trình phát triển của một dev Android. Một trong những lý do là các ứng dụng của chúng ta có thể hoạt động tốt hơn ngay cả khi không có architecture nào, vậy tại sao phải mất thêm thời gian? Làm thế nào chúng ta sẽ thuyết phục sếp / khách hàng của mình rằng cần thêm thời gian để chúng ta dành cho việc này và có thể không có bất kỳ lợi ích nào ngay lập tức?
Chỉ sau một vài phiên bản, chúng tôi nhận ra sự lộn xộn nhưng sau đó đã quá muộn. Khi chúng ta tiếp tục gặp rắc rối hết lần này đến lần khác, chúng ta mới bắt đầu hiểu được sự cần thiết của architecture.
-
Architecture cải thiện khả năng thay đổi:
Architecture sẽ rất quan trọng nếu chỉ có một phiên bản được phát hành cho ứng dụng. Trong thực tế, đây là cách tiếp cận mà nhiều người trong chúng ta thực hiện, đó là điều thiển cận khi phát triển ứng dụng.
Nếu tôi phải chỉ ra lợi ích lớn nhất của việc có một Architecture phù hợp thì đó sẽ là sự dễ dàng sửa đổi và hiệu quả của nó mang lại.
Sự thật là chúng ta không thể thấy trước mọi thứ mà ứng dụng có thể phát triển trong tương lai nhưng một Architecture tốt có đủ sự linh hoạt để điều chỉnh theo những thay đổi chưa biết này đấy.
-
Architecture không đòi hỏi kiến thức đặc biệt:
Đối với một dev giỏi, thiết kế Architecture xuất hiện một cách tự nhiên. Điều này hơi liên quan ở luận điểm #1 nhưng nó rất quan trọng vì vậy tôi nghĩ nên sửa nó một chút và trình bày lại 😃
Dagger / RxJava hoặc bất kỳ công cụ nào khác yêu cầu chúng ta tìm hiểu những công cụ của nó. Trong trường hợp architecture, nó chỉ là các nguyên tắc và hướng lập trình. Chúng ta càng trở nên giỏi về code thì càng dễ hình dung được kiến trúc của một ứng dụng.
-
Architecture đòi hỏi kỷ luật và sự kiên nhẫn
Architecture giống như một cái cây. Chúng ta không thể nhận được quả vào ngày chúng ta trồng nó. Phải mất thời gian và công sức để thiết kế một architecture và nó là một quá trình vẫn đang tiếp diễn. Mỗi thay đổi trong ứng dụng sẽ yêu cầu một quyết định cẩn thận trước khi thực hiện.
Thiệt hại lớn đến architecture của ứng dụng là khi chúng ta bắt đầu dùng phím tắt. Những cam kết trên (để làm sạch code sau này) cuối cùng bị phá vỡ hết lần này đến lần khác.
Chúng ta cần phải hiểu những gì chúng ta đang nhận được nếu không nó sẽ là một khởi đầu tuyệt vời và cuối cùng để mất sau này. Architecture phải liên kết với vòng đời của một ứng dụng.
Google Architecture components:
Năm 2017 Google đã giới thiệu Architecture Components. Architecture component chỉ để chuyển từ Activity / Fragment sang ViewModel. Các “Architecture” components có sẵn để tạo điều kiện cho chúng ta thiết kế kiến trúc của ứng dụng. Các thành phần này giúp dễ dàng thực hiện kiến trúc này mà nếu không có thì sẽ là một công việc khó khăn.
Ví dụ như LiveData giúp dễ dàng quan sát các thay đổi trong dữ liệu vốn là thứ liên quan tới vòng đời của Activity/Fragment. Người ta có thể thấy ViewModel như một cách để lưu lại thay đổi nhưng ý nghĩa thực sự của nó là giúp chúng ta tách UI khỏi logic.
-
Chúng ta không cần phải trở thành một kiến trúc sư phần mềm Software Architect:
Mọi kiến trúc sư phần mềm là một dev nhưng không phải mọi dev đều là một kiến trúc sư. Trong một tổ chức lớn sẽ có chỉ định rõ ràng các kiến trúc sư phần mềm. Đối với họ, điều cần thiết là phải có kiến thức sâu rộng về các mẫu kiến trúc khác nhau và cách chúng vận hành.
Trong vai trò một dev, điều này giúp có một cái nhìn về architecture để chúng ta có thể hiểu được các khái niệm trừu tượng được triển khai. Điều này trở nên quan trọng hơn nếu chúng ta đang làm việc tự do hoặc trong một công ty startup với nguồn lực hạn chế. Trong trường hợp như vậy, sẽ có đủ kiến thức cơ bản về architecture.
Có nhiều mẫu và nguyên tắc đơn giản mà chúng ta có thể áp dụng để tạo ra một architecture tốt cho ứng dụng của mình mà không đi quá sâu vào thế giới architecture.
-
Lợi ích của architecture:
Như đã đề cập trước đó, một trong những lợi thế là tính dễ thay đổi. Thêm các tính năng và sửa mới trở nên dễ dàng và nhanh chóng nếu các thành phần được phân tách hợp lý và giao tiếp một cách có tổ chức. Sự tách biệt này dẫn đến nhiều lợi thế khác như khả năng kiểm tra, trong đó chúng ta có thể dễ dàng kiểm tra các thành phần độc lập.
-
Bắt đầu từ đâu?
Architecture có ở khắp mọi nơi, hệ thống nhúng, ứng dụng web, phần mềm doanh nghiệp, ứng dụng điện thoại di động, v.v … Mỗi loại yêu cầu một kiểu kiến trúc khác nhau. Nếu chúng ta không muốn trở thành kiến trúc sư phần mềm, chúng ta phải cần chọn lọc thứ chúng ta muốn triển khai.
Để hiểu nhu cầu về architecture và việc triển khai nó thì cách tốt nhất là nên nghiên cứu Clean Architecture của Robert C. Martin (còn gọi là Uncle Bob) và một chút chuyên sâu là Domain-Driven Design: Tackling Complexity in the Heart of Software của Eric Evans.
Google cung cấp hướng dẫn về architecture của ứng dụng với sự liên kết theo một hướng nhưng đó là mức vừa đủ. Khi bạn đã nắm bắt được thứ bạn có thể triển khai một mẫu architecture phân lớp thông qua hướng dẫn của Clean Architecture. Cách tiếp cận này dễ dàng và sẽ phù hợp với hầu hết các ứng dụng. Tôi đã tạo ra một ứng dụng mẫu theo các nguyên tắc này. Đây là repo Github của ứng dụng mẫu này.
Nếu bạn chưa quen với lập trình, tôi khuyên bạn nên bắt đầu với các nguyên tắc SOLID vì chúng sẽ giúp bạn sẵn sàng cho architecture 😉
TopDev via Medium
Tham khảo thêm các công việc ngành it khác tại Topdev
