Bài viết được sự cho phép bởi tác giả Vũ Thành Nam
Có lẽ đây là một chủ đề nói đơn giản cũng không hẳn mà nói phức tạp cũng không hẳn, đi sâu hơn vào lĩnh vực này mình cảm thấy mình thật nhỏ bé, vì vậy có thể bài viết này sai sót ở đâu đó do mình còn ít kinh nghiệm mong các bạn có thể bổ sung góp ý thêm nhé!
Đầu tiên thì bạn thường đặt câu hỏi tại sao lại phải làm phức tạp hóa vấn đề lên trong khi một phần mềm chỉ cần đáp ứng đúng và đủ nhu cầu hiện tại của mình.
Nếu như bạn đã đọc qua về quá trình phát triển của các kiến trúc phần mềm thì bạn sẽ nhận thấy chúng ta thiết kế không phải nhằm mục đích đáp ứng mỗi nhu cầu hiện tại, mà nó còn để giải quyết những vấn đề phát triển trong tương lai.
Dưới đây là một số lý do mà các kiến trúc sư phần mềm đã phải đau đầu cho những thiết kế đáp ứng tương lai:
Code maintainance
Mình thường so sánh việc kiến trúc phần mềm với kiến trúc xây dựng, nó có khá là nhiều điểm tương đồng. Hãy thử tưởng tượng bạn muốn thiết kế và xây dựng một ngôi nhà nhưng bạn không chắc chắn cái bạn muốn, cái duy nhất bạn có chỉ là ý tưởng nhưng không thể nào thiết kế một cách tùy ý được. Vậy bạn cần ngay lúc này là bản thiết kế vậy là bạn tìm đến một kiến trúc sư.
Ngôi nhà của bạn, bạn nghĩ nên có 2 phòng ngủ, ah không có thể là 40 phòng ngủ. Vậy làm thế nào để kiến trúc sư hay chính bạn có thể lên kế hoạch một cách chắc chắn đây, khi này kiến trúc sư đành phải đâu đầu suy nghĩ làm sao có thể thêm hoặc bớt số phòng ngủ sao cho dễ dàng nhất. Bản vẽ ban đầu sẽ thể hiện được cái bạn muốn, từ đó nó cũng đánh giá được chi phí xây dựng, nhưng mà khi có sự thay đổi trong cái bạn muốn ban đầu, bản vẽ này vẫn phải đáp ứng được nhu cầu thay đổi một cách ít nhất có thể, chi phí chỉnh sửa cũng phải ít nhất mà vẫn đáp ứng được yêu cầu mới. Đó chính là sự đau đầu của một kiến trúc sư mà không phải ai cũng làm được.
Trong kiến trúc phần mềm cũng vậy, nhiều kiến trúc sư phần mềm có nhiều năm kinh nghiệm thường hiểu được vấn đề này, khi này họ sẽ tạo ra những thành phần (phần tử) theo hướng trừu tượng hóa nhằm dễ dàng thay đổi, dễ dàng tích hợp, dễ dàng nâng cấp hay thay đổi vị trí. Một điều đáng lưu tâm nữa đó là thiết kế làm sao để những người xây dựng hay những người vận hành, bảo trì và phát triển sau này có thể hiểu được, điều này đồng nghĩa với việc có một chuẩn chung và có một quy định chung cho chuyên ngành.
Vậy nên nói không ngoa chứ lập trình viên chẳng khác nào một thợ xây, nó thiết kế và thi công theo bản vẽ và khi đạt tới số năm kinh nghiệm rồi thì họ có thể lên chức thành kiến trúc sư nếu muốn
Code Reusability
Cách tốt nhất để tăng chất lượng code lên đó chính là code ít đi, “Không code, không bug”. Điều này thật vô lý nhưng mà nó lại vô cùng thuyết phục, bạn có thể code 1 tính năng và đã được kiểm thử, việc bạn sử dụng lại đoạn code của tính năng đó sẽ giúp bạn tiết kiệm được thời gian viết mới cũng như thời gian kiểm thử lại. Vậy nên giải pháp kiến trúc làm sao để có thể tái sử dụng tối đa hết mức có thể sẽ được ưa chuộng và là một trong những mục tiêu vô cùng quan trọng. Dựa vào ý tưởng tái sử dụng này mà những thư viện (libraries), nền tảng (frameworks), mẫu chung (templates), hay công cụ sinh mã code (code generators) ra đời cũng là vì vậy.
Cùng hình dung bạn có những mảnh lego nhỏ nhỏ xinh xinh, bạn có thể dùng nó để xây tàu, xây nhà, xây cầu mà cũng chỉ là những mảnh lego đó. Đó chính là tính đa dụng mà người thiết kế cần lưu tâm khi thiết kế những thành phần trong phần mềm của mình theo hướng lego. Có thể tái sử dụng để xây dựng bất cứ thứ gì và ở bất cứ đâu.
Vậy làm sao để thiết kế tính đa dụng dễ dàng tái sử dụng được như vậy, lại một lần nữa đau đầu rồi.
Features, features and features
Tính năng, tính năng và tính năng, điều mà được ưu tiên hàng đầu cho bất cứ sản phẩm phần mềm nào. Nếu bạn là một nhà quản lý bạn thường đứng giữa sự lựa chọn những quyết định mang tính thử thách, một phần mềm đáp ứng đủ tốt cho chức năng đồng thời dễ dàng mở rộng, vận hành, bảo trì và phát triển. Tất nhiên là muốn chọn cả hai rồi, vậy chi phí thiết kế kiến trúc không cho phép và chỉ được chọn một thì sao. Chắc chắn lúc này là anh ấy sẽ phải chọn đáp ứng đủ tính năng là ưu tiên hàng đầu. Nhiều khi vẫn biết là kiến trúc đó chưa tốt nhưng về mặt thời gian và chi phí không đủ thì đành phải nợ lại (Technical Debt).
Nợ thì phải trả, điều đó luôn đúng rồi, nhưng việc ưu tiên tính năng là hoàn toàn chính xác vì khách hàng trả tiền cho bạn là để xây dựng tính năng mà. Việc bạn phải làm lúc này là thông báo cho khách hàng và đưa là những options những giải pháp khác nhau cho khách hàng lựa chọn. Ví dụ để đảm bảo tính năng thì bạn có thể xây dựng theo hướng cấu hình (configuration) để đảm bảo thêm tính dễ dàng thay đổi, xây dựng tách nhỏ module để có thể đẽ dàng tái sử dụng. Có lẽ ưu tiên tính năng nhưng bạn vẫn nên nghĩ mở rộng hơn và tối ưu nhất có thể tại thời điểm đó để sao có thể nợ ít nhất. Bạn hiểu ý mình chứ?
Bạn thấy đó, kiến trúc đâu phải dễ dàng gì, mà một khi bản vẽ của bạn sai thì một khi đã thi công rồi nó sẽ tốn rất nhiều chi phí về sau, trách nhiệm thiết kế lúc này rất nặng.
Bạn nghĩ sao về mảng này trong chuyên ngành phát triển công nghệ phần mềm? Góp ý thêm cho mình nhé!
Bài viết gốc được đăng tải tại ntechdevelopers.com
Xem thêm:
- Nguyên lý SOLID trong Node.js với TypeScript
- Top 6 nguyên lý thiết kế microservices cho lập trình viên có kinh nghiệm
- Thiết kế service có tải ghi cao không gây tranh chấp tài nguyên
Xem thêm Việc làm Developer hấp dẫn trên TopDev
