Khi mã nguồn lớn tới mức không thể giữ trong đầu, hãy vẽ nó ra giấy: những khối chính, dữ liệu chảy giữa các khối, và những gì đi ra ngoài hệ thống. Bản đồ này không cần đẹp, không cần đúng chuẩn ký hiệu nào, chỉ cần giúp bạn và đồng nghiệp cùng nhìn vào một bức tranh và thấy rõ chỗ nào còn mù mờ.
Chào bạn, đây là Nhà Lập Trình. Não người chỉ giữ được vài thứ cùng một lúc. Một hệ thống có vài chục thành phần, vài trăm nghìn dòng mã thì vượt xa sức chứa đó. Những người lập trình lâu năm mà mình quen đều có một thói quen giống nhau: họ vẽ. Tập này mình kể vẽ thế nào cho có ích.
Vì sao phải vẽ khi đã có mã?
Mã là sự thật chi tiết, nhưng nó quá chi tiết để thấy hình dạng tổng thể. Giống như đứng giữa một khu phố, bạn thấy từng ngôi nhà rất rõ nhưng không biết khu phố nằm ở đâu trong thành phố. Bản đồ cho bạn đứng lên cao.
Khi vẽ, bạn buộc phải quyết định: thứ gì là khối chính, thứ gì là chi tiết. Chính việc quyết định đó giúp bạn hiểu. Nhiều lần mình bắt đầu vẽ và nhận ra mình không biết hai khối này nói chuyện với nhau bằng cách nào. Đó là chỗ cần đọc thêm.
Bản đồ còn là trí nhớ ngoài. Hôm nay bạn hiểu, tuần sau quên. Bản đồ giữ lại những gì bạn đã hiểu, để lần sau không phải đọc lại từ đầu.
Và bản đồ là ngôn ngữ chung. Chỉ vào một ô vuông và nói chỗ này hay chậm dễ hơn nhiều so với đọc tên một loạt tệp.
Bắt đầu từ ngoài vào trong
Tầng đầu tiên của bản đồ là hệ thống nhìn từ bên ngoài. Vẽ hệ thống là một ô ở giữa. Xung quanh là những ai và những gì nói chuyện với nó: người dùng trên điện thoại, người quản trị trên máy tính, cổng thanh toán, dịch vụ gửi tin nhắn, hệ thống kế toán của đối tác.
Tầng này nghe đơn giản, nhưng rất nhiều người làm trong một hệ thống nhiều tháng mà không biết hết nó nói chuyện với những ai. Rồi một ngày dịch vụ gửi tin nhắn đổi cách kết nối, và không ai biết hệ thống có dùng dịch vụ đó.
Tầng thứ hai là mở ô ở giữa ra. Bên trong có những khối lớn nào: trang web cho khách, trang quản trị, máy chủ xử lý, cơ sở dữ liệu, các tiến trình chạy nền, bộ nhớ đệm. Nối các khối bằng mũi tên cho biết ai gọi ai.
Với nhiều việc, hai tầng này đã đủ. Chỉ khi cần làm sâu vào một khối, bạn mới vẽ tầng thứ ba cho riêng khối đó.
Vẽ dòng chảy của dữ liệu
Ngoài các khối, điều quan trọng nhất cần vẽ là dữ liệu đi đâu. Một đơn hàng sinh ra ở trang web, được ghi vào cơ sở dữ liệu, được một tiến trình nền đọc để gửi thư xác nhận, được đồng bộ sang hệ thống kho, và cuối ngày được tổng hợp vào báo cáo.
Vẽ dòng chảy này giúp bạn trả lời những câu hỏi thực tế. Nếu hệ thống kho ngừng hoạt động một giờ thì đơn hàng có mất không? Nếu đổi cấu trúc bảng đơn hàng thì những ai bị ảnh hưởng? Dữ liệu cá nhân của khách đi qua những nơi nào?
Câu hỏi cuối rất quan trọng với bảo mật. Nhiều khi dữ liệu nhạy cảm chảy tới những nơi không ai ngờ, như nhật ký lỗi, tệp xuất báo cáo gửi qua thư, bản sao dữ liệu cho môi trường thử nghiệm.
Dùng màu khác nhau cho các loại dữ liệu nếu cần. Không phải để đẹp, mà để mắt bạn thấy ngay dữ liệu nhạy cảm đang chảy qua bao nhiêu khối.
Giữ bản đồ đơn giản và đúng
Cám dỗ lớn nhất khi vẽ là vẽ quá nhiều. Mỗi tệp một ô, mỗi hàm một mũi tên. Kết quả là một bức vẽ rối như mạng nhện, không ai đọc nổi, kể cả người vẽ.
Nguyên tắc của mình là một bản đồ chỉ nên có khoảng năm đến chín khối. Nhiều hơn thì gộp lại, hoặc tách thành bản đồ riêng cho một tầng sâu hơn.
Đừng lo về ký hiệu chuẩn. Có những bộ ký hiệu vẽ kiến trúc rất bài bản, học cũng tốt, nhưng một ô vuông, một mũi tên và vài chữ ghi chú đã đủ cho phần lớn nhu cầu. Người xem hiểu được là đạt.
Và giữ cho bản đồ đúng. Một bản đồ sai nguy hiểm hơn không có bản đồ, vì người ta tin nó. Ghi ngày vẽ lên bản đồ, và mỗi khi hệ thống thay đổi lớn, cập nhật hoặc vẽ lại.
Dùng bản đồ để nói chuyện với đội
Bản đồ phát huy nhiều nhất khi được vẽ cùng nhau. Mời một đồng nghiệp lâu năm ngồi xuống, đưa bút cho họ và nhờ họ vẽ hệ thống. Bạn sẽ học được trong một giờ nhiều hơn một tuần tự đọc mã. Và bạn sẽ thấy chỗ họ ngập ngừng, đó là chỗ ngay cả người cũ cũng không chắc.
Khi bàn một thay đổi lớn, đặt bản đồ lên bàn và chỉ vào những khối sẽ bị ảnh hưởng. Người làm giao diện, người làm máy chủ, người vận hành cùng nhìn một bức tranh, ít hiểu lầm hơn hẳn.
Khi có người mới vào đội, bản đồ là thứ đầu tiên nên đưa cho họ. Nó giúp họ biết mình đang đứng ở đâu trước khi lạc vào chi tiết.
Một tờ giấy khổ lớn, vài cây bút màu, và một giờ ngồi cùng nhau. Đó có lẽ là khoản đầu tư rẻ nhất mà một đội phần mềm có thể làm.
Câu hỏi thường gặp
Nên vẽ sơ đồ hệ thống bằng giấy hay phần mềm?
Giấy và bảng trắng nhanh và dễ sửa khi đang suy nghĩ hoặc thảo luận. Khi bản đồ đã ổn định và cần chia sẻ lâu dài, chép lại bằng phần mềm vẽ để dễ cập nhật và lưu cùng dự án.
Có cần học ký hiệu chuẩn để vẽ kiến trúc phần mềm không?
Không bắt buộc. Ký hiệu chuẩn hữu ích trong đội lớn hoặc tài liệu chính thức, nhưng ô vuông, mũi tên và ghi chú rõ ràng đã đủ cho phần lớn nhu cầu hằng ngày.
Bản đồ hệ thống nên chi tiết đến mức nào?
Mỗi bản đồ chỉ nên có khoảng năm đến chín khối. Cần chi tiết hơn thì vẽ thêm bản đồ riêng cho từng khối, thay vì nhồi mọi thứ vào một hình.
Bao lâu thì nên cập nhật bản đồ hệ thống?
Mỗi khi có thay đổi lớn như thêm dịch vụ mới, tách hay gộp thành phần. Ghi ngày vẽ lên bản đồ để người xem biết nó còn mới hay đã cũ.
Bản đồ hệ thống giúp gì cho bảo mật?
Nó cho thấy dữ liệu nhạy cảm đi qua những nơi nào, kể cả những nơi dễ bị quên như nhật ký lỗi hay bản sao thử nghiệm. Biết dữ liệu ở đâu là bước đầu để bảo vệ nó.
