Nội dung bài viết được dịch từ https://roadmap.sh/, ở khía cạnh của một người đang làm Frontend Developer, đang học để trở thành Software Architect, mỗi vài viết là 1 kĩ năng. Vào vấn đề, ...

Để trở thành một software architect, bạn cần có các kĩ năng sau:

• Thiết kế và Kiến trúc
• Ra quyết định
• Đơn giản hoá vấn đề
• Biết code
• Viết tài liệu
• Giao tiếp
• Ước lượng và đánh giá
• Cân bằng
• Tư vấn và hướng dẫn
• Kĩ năng marketing

Sau đây là kĩ năng số 1, Thiết kế và Kiến trúc.

Thiết kế và Kiến trúc

Biết các nguyên tắc thiết kế cơ bản (Design Principles):

Nguyên tắc là những gì mà chúng ta cần tuân thủ, nó giống như việc bạn cần dùng chén để đựng thức ăn và dùng muỗng để lấy thức ăn. Ví dụ:

• Tạo ra các thành phần rồi gộp chúng lại sẽ hay hơn là kế thừa
• Gộp những phần dễ thay đổi thành một nhóm, gộp những phần không thay đổi thành một nhóm
• Lập trình theo hướng trừu tượng, tạo ra tên của hành vi, nhưng không chi tiết hành vi đó. Chỉ chi tiết khi hành vi đó cần triển khai.
• Nguyên tắc Hollywood, "Đừng gọi chúng tôi, chúng tôi gọi cho bạn", component-sử-dụng sẽ truyền callback vào component-được-sử-dụng, component-được-sử-dụng sẽ gọi callback này khi xử lí
• SOLID, DRY, KISS, YAGNI, ...

Có rất nhiều nguyên tắc, chúng có thể trùng lặp nhau hoặc chứa đựng một phần của nhau. Phạm vi bài viết này sẽ không liệt kê và chi tiết hết được. Hãy tìm đọc nó!

Biết các mẫu thiết kế cơ bản (Design Patterns):

Khác biệt với Nguyên tắc, cái mà chúng ta cần tuân thủ. Mẫu là cái có sẵn, việc của chúng ta là lựa chọn. Mẫu là một trong những công cụ quan trọng nhất mà một kiến trúc sư cần có để phát triển các hệ thống có thể bảo trì. Với các mẫu, bạn có thể tái sử dụng thiết kế để giải quyết các vấn đề phổ biến với các giải pháp đã được chứng minh. Thông thường, các mẫu này sẽ được phản ánh trong cách sử dụng một Framework cụ thể, bạn có thể sử dụng nó trong cách viết mã của mình. Hai nguồn cơ bản để tiếp cận là:

• GoF (Gang of Four): Cuốn sách "Design Patterns: Elements of Reusable Object-Oriented Software" do John Vlissides, Ralph Johnson, Richard Helm, Erich Gamma viết là cuốn sách bắt-buộc-đọc cho tất cả những ai làm trong ngành phát triển phần mềm. Mặc dù các mẫu đã được xuất bản hơn 20 năm trước nhưng chúng vẫn là cơ sở của kiến trúc phần mềm hiện đại. Ví dụ, mẫu Model-View-Controller (MVC) đã được mô tả trong cuốn sách này, được áp dụng trong nhiều lĩnh vực hoặc là cơ sở cho các mẫu mới hơn, ví dụ như Model-View-ViewModel (MVVM).
• POSA (Pattern-Oriented Software Architecture): Kiến trúc phần mềm hướng mẫu là một tập hợp các mẫu thiết kế để phát triển hệ thống phần mềm có thể mở rộng và thích ứng với các yêu cầu thay đổi. Những mô hình này lần đầu tiên được mô tả trong cuốn sách “Patterns of Scalable, Reliable Services” của Kevin Hoffman.

Tìm hiểu sâu hơn về các mẫu và phản mẫu (Patterns và Anti-Patterns):

Nếu bạn đã biết tất cả các mẫu cơ bản, hãy mở rộng kiến thức của bạn với nhiều mẫu thiết kế phần mềm hơn hoặc tìm hiểu sâu hơn về lĩnh vực quan tâm của bạn. Một trong những cuốn sách yêu thích của tôi về tích hợp ứng dụng là "Enterprise Integration Patterns" do Gregor Hohpe viết. Cuốn sách này áp dụng trong nhiều lĩnh vực bất cứ khi nào hai ứng dụng cần trao đổi dữ liệu, dù là trao đổi tệp tin kiểu cũ từ một số hệ thống cũ hay một kiến trúc microservice hiện đại.

Biết về các nguyên tắc kiến trúc (Architectural Principles):

Nguyên tắc kiến trúc đề cập đến một bộ hướng dẫn hoặc quy tắc được sử dụng để hướng dẫn kiến trúc phần mềm. Những nguyên tắc này nhằm đảm bảo rằng kết quả có thể duy trì được, có thể mở rộng, dễ hiểu và sửa đổi. Chúng có thể là:

• Nguyên tắc Component (Component Principles): chia nhỏ những phần liên quan thành component, để module hoá, dễ sử dụng, dễ hiểu, dễ test, dễ duy trì,...
• Chính sách và chi tiết (Policy vs Detail): Chính sách là những định nghĩa ở cấp cao, tổng thể, kiến trúc do architect hoặc designer quyết định; Chi tiết là những phần cấp thấp, cụ thể, thuật toán, cấu trúc dữ liệu do developer sẽ thực hiện.
• Khớp nối và Gắn kết (Coupling vs Cohesion): Khớp nối là sự kết hợp các component lại với nhau, càng lõng lẽo càng tốt (Component PDF có thể sử dụng với Component GetViewDocument hoặc Component GetPrintDocument); Gắn kết là sự kết hợp trong nội hàm component, càng liên quan càng tốt (Trong component PDF chỉ nên xử lí PDF, không nên xử lí gọi API để lấy document).
• Ranh giới (Boundaries): Các ranh giới này có thể là vật lý, chẳng hạn như giữa các vi-dịch-vụ khác nhau trong hệ thống phân tán; có thể là phi vật lý như các lớp khác nhau trong một ứng dụng.

Biết về các kiểu kiến trúc (Architectural Styles):

Kiểu kiến trúc trong phần mềm đề cập đến thiết kế và tổ chức tổng thể của hệ thống phần mềm cũng như các nguyên tắc và mẫu được sử dụng để hướng dẫn thiết kế. Những kiểu này cung cấp một khuôn khổ chung cho việc thiết kế một hệ thống và có thể được sử dụng để đảm bảo rằng hệ thống có cấu trúc tốt, có thể bảo trì và có thể mở rộng.

• Kiểu sự kiện (Messaging): Event-driven, Publish-Subscribe
• Kiểu phân phối (Distributed): Client-Server, Peer-to-Peer
• Kiểu cấu trúc (Structural): Component-based, Monolithic, Layered

Biết về các mẫu thiết kế (Architectural Patterns):

Các mẫu kiến trúc là một tập hợp các giải pháp đã được chứng minh là hoạt động tốt cho các loại hệ thống phần mềm cụ thể. Chúng cung cấp những thuật ngữ chung và tập hợp các phương pháp hay nhất để thiết kế và xây dựng hệ thống phần mềm, đồng thời có thể giúp các nhà phát triển đưa ra quyết định thiết kế tốt hơn. Một số mẫu kiến trúc phổ biến bao gồm:

• Service-Oriented Architecture (SOA)
• Microservices
• Serverless
• Message Queues Streams
• Command Query Responsibility Segregation (CQRS)
• Domain-Driven Design (DDD)
• Model-View-Controller (MVC)
• Blackboard
• Microkernel
• Event Sourcing

Biết các biện pháp chất lượng:

Tạo ra kiến trúc, chưa hẵng là xong, cần phải định lượng xem chúng hoạt động thế nào. Đây là cơ sở để đánh giá một kiến trúc tốt. Tại sao các hướng dẫn và tiêu chuẩn mã hóa phải được định nghĩa, áp dụng và kiểm soát? Bởi vì chất lượng (liên quan đến yêu cầu chức năng) và các yêu cầu phi chức năng. Và một phần để đạt được tất cả các thuộc tính chất lượng này là áp dụng công việc kiến trúc tốt. Bạn có thể bắt đầu tìm hiểu thêm về các biện pháp chất lượng trên Wikipedia. Lý thuyết là quan trọng. Thực hành cũng quan trọng — thậm chí quan trọng hơn — nếu bạn không muốn trở thành một Ivory Tower Architect. Các thuộc tính có thể là: có thể bảo trì, đáng tin cậy, có thể thích nghi, an toàn, có thể kiểm tra, có thể mở rộng, có thể sử dụng, v.v.

Thử nghiệm và hiểu các nhóm công nghệ khác nhau:

Tôi nghĩ đây là hoạt động quan trọng nhất nếu bạn muốn trở thành một kiến trúc sư giỏi hơn. Thử nghiệm các nhóm công nghệ (mới) và học được điểm mạnh và yếu của chúng. Công nghệ khác nhau hoặc mới đi kèm với các khía cạnh và mẫu thiết kế khác nhau. Bạn có thể không học được gì từ việc chỉ lướt qua các slide trừu tượng. Hãy thử nghiệm và cảm nhận sự đau đớn (fix bug sml) hoặc sự nhẹ nhõm.

• Một kiến trúc sư không chỉ cần có kiến thức rộng ở nhiều lĩnh vực mà cần thêm kiến thức sâu ở một lĩnh vực (T-shape, tôi sẽ có một bài viết về điều này).
• Không quan trọng phải thành thạo tất cả các nhóm công nghệ nhưng phải có sự hiểu biết vững chắc về những điều quan trọng nhất trong lĩnh vực của bạn.
• Cũng nên thử công nghệ không thuộc lĩnh vực của bạn. Ví dụ, nếu bạn sâu vào SAP R/3, bạn cũng nên thử JavaScript và ngược lại. Dù vậy, cả hai bên sẽ ngạc nhiên về những tiến bộ mới nhất trong SAP S/4 Hana. Ví dụ, bạn có thể tự thử và tham gia một khóa học miễn phí tại openSAP.
• Hãy tò mò và thử nghiệm những điều mới. Cũng thử những thứ mà bạn không thích vài năm trước.

Phân tích và hiểu các mẫu được áp dụng:

Hãy xem bất kỳ framework hiện tại nào, ví dụ, Angular. Bạn có thể nghiên cứu rất nhiều mẫu trong thực hành, ví dụ, Observables. Cố gắng hiểu cách nó được áp dụng trong framework, tại sao nó được thực hiện. Và nếu bạn thực sự tận tâm, hãy xem xét sâu hơn vào mã và hiểu cách nó được thực hiện.

Hãy tò mò và tham gia Cộng đồng:

Tham gia các hội nhóm, diễn đàn trên Facebook, X, Telegram, Meetup, ...