Định Luật Conway: Tại Sao Solo Dev Nên Xây Dựng Monolith?
Lê Lân0
Conway’s Law và Bài Học Quý Giá Từ Một Dự Án Phần Mềm Đơn Giản
Mở Đầu
Bạn đã từng nghe về định luật Conway chưa? Đây là một trong những phát hiện thú vị nhất trong lĩnh vực phát triển phần mềm và tổ chức doanh nghiệp. Conway’s Law phát biểu rằng kiến trúc của một hệ thống phần mềm sẽ phản ánh cấu trúc giao tiếp giữa các bộ phận trong tổ chức phát triển hệ thống đó. Nghĩa là, cách các nhóm trong công ty trao đổi và phối hợp sẽ ảnh hưởng trực tiếp tới cách hệ thống được xây dựng và ngược lại. Điều này không chỉ là một giả thuyết mới nổi mà đã được nghiên cứu sâu rộng và chứng minh có tính ứng dụng thực tế cao.
Trong bài viết này, tôi sẽ chia sẻ kinh nghiệm cá nhân khi áp dụng Conway’s Law vào dự án passion project của mình - ứng dụng quản lý công việc nhà “Hounty”. Qua đó, bạn sẽ hiểu rõ hơn cách lý thuyết này có thể giúp giải quyết những khó khăn trong quá trình phát triển phần mềm, đặc biệt là giai đoạn hoàn thiện cuối cùng.
Conway’s Law Là Gì?
Định nghĩa cơ bản
Conway’s Law được đặt theo tên Melvin Conway, người đầu tiên nêu ra giả thuyết này vào năm 1967:
"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."
Tạm dịch: Bất kỳ tổ chức nào thiết kế hệ thống đều tạo ra một thiết kế phản ánh cấu trúc giao tiếp của tổ chức đó.
Tác động hai chiều
Điều thú vị là Conway’s Law hoạt động theo cả hai chiều: bạn có thể điều chỉnh cấu trúc tổ chức để thay đổi thiết kế hệ thống hoặc tạo ra kiến trúc hệ thống mới để thúc đẩy sự đổi mới trong tổ chức.
Ví dụ, khi cải thiện sự phối hợp giữa hai nhóm phát triển, bạn có thể thấy những cải thiện rõ rệt trong việc phát hiện và sửa lỗi phần mềm, từ đó nâng cao chất lượng triển khai sản phẩm.
Bài Học Từ Dự Án Hounty
Thách thức 10% cuối cùng
Tôi đã dành nhiều thời gian để xây dựng Hounty - một ứng dụng quản lý công việc nhà đơn giản nhưng hiệu quả cho gia đình. Tuy nhiên, việc đi đến 10% hoàn thiện cuối cùng là một thử thách thật sự lớn.
- Tôi chứng kiến nhiều người khác cũng gặp khó khăn tương tự, bị mắc kẹt trong các vấn đề kiến trúc.
- Cá nhân tôi từng nhiều lần định viết lại toàn bộ ứng dụng từ đầu, dù chức năng chính vẫn chưa hoàn chỉnh.
Những cố gắng này làm tôi tự hỏi: Phải chăng sự hoàn hảo trong phần mềm không phải lúc nào cũng là điều đúng đắn?
Ngộ nhận về sự hoàn hảo trong phát triển phần mềm
Tôi vốn đã biết đến nguy cơ tối ưu hóa sớm và sự phức tạp không cần thiết trong giải pháp kỹ thuật. Tôi luôn theo đuổi triết lý “đơn giản là thông minh”. Thế nhưng, chính tôi lại bị mắc kẹt trong vòng luẩn quẩn hoàn hảo với một dự án khá đơn giản khi đóng vai trò duy nhất chịu trách nhiệm.
Kinh nghiệm cá nhân: Sự trì hoãn và sự cầu toàn quá mức phần nào là kết quả của sự không phù hợp giữa kiến trúc phần mềm và mô hình tổ chức (trong trường hợp này là tôi một mình).
Phải Đơn Giản Hóa Kiến Trúc
Modular Không Phải Lúc Nào Cũng Tốt
Tôi là người ủng hộ cấu trúc module, nơi mỗi phần đều có phạm vi rõ ràng và có thể độc lập quản lý. Cách làm này rất hiệu quả trong các dự án đa thành viên vì:
- Dễ dàng chia sẻ quyền sở hữu mã nguồn
- Kiến trúc phần mềm phản ánh đúng cấu trúc đội nhóm
Tuy nhiên, với dự án solo như Hounty, tôi đã tự rơi vào bẫy cố gắng giữ mọi thứ quá tách rời, dẫn đến cảm giác cô đơn và nặng nề trong phát triển.
Đừng Ám Ảnh Với “Monolith”
Tôi từng quan niệm rằng:
Monolith là xấu, phải chia nhỏ microservices càng sớm càng tốt.
Nhưng theo Conway’s Law, trong bối cảnh tôi - một cá nhân phát triển sản phẩm, việc xây dựng một kiến trúc monolith đơn giản không chỉ chấp nhận được mà còn là tối ưu. Việc gom tất cả file trong một thư mục, triển khai nhanh chóng để tiếp cận người dùng thực sự mới là tiêu chí quan trọng lúc này.
Hiểu Đúng Về Nợ Kỹ Thuật
Nhiều người nhầm lẫn nợ kỹ thuật (tech debt) là khoảng cách giữa hệ thống hiện tại và các chuẩn mực ngành công nghiệp hoặc best practices.
Tôi nhận ra rằng nợ kỹ thuật thực chất là sự không phù hợp giữa hệ thống phần mềm và tổ chức hỗ trợ nó. Doanh nghiệp cần một hệ thống vận hành hiệu quả với sự cản trở thấp nhất cho các nhà phát triển.
Ví dụ:
Tình huống | Hệ quả | Giải pháp |
|---|---|---|
Kiến trúc quá phức tạp cho đội ngũ nhỏ | Chậm tiến độ, trì hoãn phát hành | Áp dụng Strangler Fig pattern từng bước đơn giản hóa |
Thiếu BFF Layer (Backend For Frontend) | Khó sửa đổi module mà không làm hỏng ứng dụng | Xây dựng BFF để cách ly các phần backend |
Hiện tại, Hounty sử dụng Supabase với lớp BFF Deno, nơi hầu hết logic nằm trong tầng database. Ban đầu tôi khó chấp nhận điều này, nhưng nó hoàn toàn phù hợp với mục tiêu bảo mật và khả năng mở rộng cho giai đoạn hiện tại.
Thực Thi: “Không Hoàn Thành Cho Đến Khi Ra Mắt”
Tôi dự định ra mắt Hounty phiên bản beta, nhưng phát hiện ra người dùng dưới 13 tuổi không được phép thử nghiệm TestFlight hay cài ứng dụng chưa công bố trên Play Store nếu không từ bỏ quyền kiểm soát phụ huynh. Điều này thúc đẩy tôi hoàn thiện và tinh chỉnh trải nghiệm người dùng để có thể vượt qua quy trình xét duyệt ứng dụng.
“90% ready” không có nghĩa là có thể ra mắt. Hoàn thành thực sự là khi sản phẩm đến tay người dùng cuối.
Kết Luận
Định luật Conway đã giúp tôi nhận ra rằng kiến trúc phần mềm phải phù hợp với cách thức tổ chức làm việc cũng như con người chịu trách nhiệm xây dựng hệ thống đó. Trong dự án cá nhân như Hounty, việc áp dụng một kiến trúc đơn giản, thậm chí là monolith, không chỉ hợp lý mà còn là cách giúp tiến độ dự án nhanh chóng hơn.
Đừng để sự hoàn hảo cản trở hành động. Hãy ưu tiên đưa sản phẩm tới tay người dùng, từ đó nhận phản hồi để tiếp tục phát triển và cải tiến.
Nếu bạn đang gặp phải bế tắc trong dự án phần mềm của mình, Conway’s Law có thể là chìa khóa giúp bạn giải tỏa nút thắt đó.
Tham Khảo
- Conway, M.E. (1968). “How Do Committees Invent?” Datamation.
- Newman, S. (2015). “Building Microservices”. O'Reilly Media.
- Feathers, M. (2004). “Working Effectively with Legacy Code”. Prentice Hall.
- Richardson, C. (2019). “Microservices Patterns”. Manning Publications.
1
100%
Loading...