Bài viết này không phải một chia sẻ kỹ thuật thông thường, mà là một góc nhìn tôi tích lũy được qua nhiều năm dẫn dắt technical team: đôi khi, cách giải quyết vấn đề tốt nhất không nằm ở việc mở rộng biên giới suy nghĩ, mà ở việc thu hẹp nó lại một cách có chủ đích.

Khi "Think Outside The Box" Trở Thành Cái Bẫy

Có một câu nói gần như đã trở thành phản xạ trong giới công nghệ: hãy nghĩ ngoài chiếc hộp. Gặp vấn đề khó, người ta khuyên nhau đừng bị giới hạn bởi những gì đang có, hãy tưởng tượng như thể không có ràng buộc nào cả.

Nghe thì rất truyền cảm hứng. Nhưng trong thực tế vận hành một đội kỹ thuật, tôi nhận ra câu nói này thường bị hiểu sai theo một hướng nguy hiểm: nó biến thành cái cớ để bỏ qua những gì đang tồn tại, để đề xuất một công cụ mới, một framework mới, hoặc tệ hơn là một cuộc viết lại toàn bộ hệ thống, chỉ vì "chúng ta cần tư duy đột phá".

Tự do tuyệt đối, khi không có bất kỳ ràng buộc nào để bám vào, thường không sinh ra sáng tạo. Nó sinh ra sự tê liệt, hoặc tệ hơn, sinh ra những giải pháp phức tạp không cần thiết. Một đội ngũ đứng trước một tờ giấy trắng tuyệt đối thường mất nhiều thời gian hơn để tìm ra hướng đi, so với một đội ngũ được giao một vài ràng buộc rõ ràng ngay từ đầu.

Đây chính là lúc một hướng tư duy ngược lại đáng được nhắc đến.

Chiếc Hộp Không Phải Nhà Tù

Trong lĩnh vực nghiên cứu về sáng tạo có ứng dụng (applied creativity), có một trường phái đi ngược lại hoàn toàn với lời khuyên quen thuộc ở trên. Thay vì phá bỏ ranh giới, trường phái này đề xuất: hãy vẽ ra một ranh giới rõ ràng, càng cụ thể càng tốt, rồi buộc bản thân tìm giải pháp chỉ bằng những thành phần đã có sẵn bên trong ranh giới đó.

Nguyên tắc cốt lõi ở đây được gọi là "thế giới khép kín" (closed world). Ý tưởng rất đơn giản: phần lớn những đổi mới thực sự hữu ích không đến từ việc mang một thứ hoàn toàn xa lạ vào bài toán, mà đến từ việc sắp xếp lại, kết hợp lại, hoặc giao thêm một vai trò mới cho những thứ vốn đã tồn tại ngay trong tầm tay.

Hãy thử liên tưởng đến thơ. Một bài thơ tự do, không vần điệu, không cấu trúc, cho phép người viết muốn viết gì cũng được. Nhưng một bài thơ theo thể loại có luật chặt chẽ (số câu cố định, vần điệu bắt buộc) lại thường buộc người viết phải đào sâu hơn vào ngôn từ, phải tìm ra cách diễn đạt tinh tế hơn để vừa giữ được ý, vừa tuân theo luật. Ràng buộc, trong trường hợp này, không giết chết sáng tạo. Nó ép sáng tạo phải làm việc chăm chỉ hơn.

Trong kỹ thuật phần mềm, điều tương tự cũng xảy ra. Một hệ thống legacy với vô số ràng buộc về hạ tầng, ngân sách, hoặc thời hạn, thường buộc đội ngũ phải hiểu sâu hơn về những gì đang có, thay vì vội vàng thay thế nó bằng thứ gì đó mới.

Vài Kỹ Thuật Nhỏ Nhưng Có Võ

Trường phái tư duy này không chỉ dừng ở triết lý suông, nó đi kèm một vài thao tác cụ thể mà bất kỳ ai cũng có thể áp dụng khi đứng trước một bài toán kỹ thuật.

Thao tác đầu tiên là phép trừ: thử loại bỏ một thành phần tưởng chừng thiết yếu ra khỏi hệ thống, rồi xem điều gì xảy ra. Rất nhiều lần, việc bớt đi một tầng trung gian, một bước xử lý, hoặc một tính năng ít người dùng, lại làm lộ ra một kiến trúc gọn gàng hơn hẳn so với bản gốc.

Thao tác thứ hai là hợp nhất nhiệm vụ: giao thêm một vai trò mới cho một thành phần đã tồn tại, thay vì thêm một thành phần mới chỉ để làm đúng một việc. Một bảng dữ liệu vốn chỉ để lưu trạng thái giao dịch có thể được giao thêm nhiệm vụ làm nguồn phát sự kiện, thay vì phải dựng thêm một hệ thống hàng đợi riêng biệt.

Thao tác thứ ba là chia nhỏ rồi sắp xếp lại: tách một chức năng lớn thành các phần nhỏ hơn, sau đó bố trí lại các phần đó theo một trật tự khác với trật tự ban đầu, để lộ ra cách vận hành hiệu quả hơn.

Điểm chung của cả ba thao tác này: chúng đều bắt đầu từ những gì đã có, không phải từ một trang giấy trắng.

Một Ví Dụ Từ Bài Toán Nhất Quán Dữ Liệu

Để cụ thể hóa, tôi muốn kể một tình huống quen thuộc với nhiều đội kỹ thuật: bài toán đảm bảo tính nhất quán khi một service vừa phải ghi dữ liệu vào cơ sở dữ liệu, vừa phải phát ra một sự kiện cho các service khác biết.

Phản xạ "nghĩ ngoài chiếc hộp" thường dẫn đến kết luận quen thuộc: chúng ta cần một message broker chuyên dụng, cần dựng thêm hạ tầng, cần học thêm một hệ sinh thái mới. Đây không phải là một lựa chọn sai, nhưng nó thường được đưa ra quá sớm, trước khi đội ngũ thực sự xem xét kỹ những gì đang có trong tay.

Ngược lại, cách tiếp cận "trong chiếc hộp" sẽ đặt câu hỏi khác: cơ sở dữ liệu quan hệ mà chúng ta đang dùng, vốn đã hỗ trợ transaction đáng tin cậy, có thể đảm nhận thêm vai trò gì không? Câu trả lời, như nhiều người áp dụng mẫu hình Transactional Outbox đã nhận ra, là có. Một bảng outbox nằm ngay trong cùng transaction với dữ liệu nghiệp vụ, được một tiến trình đọc và phát đi sau đó, giải quyết được phần lớn bài toán nhất quán, mà không cần thêm bất kỳ hạ tầng mới nào.

Bạn có thể xem qua bài viết về Transactional Outbox được viết tại đây nhé.

Hoặc bấm vào link này https://builder.classmethod.vn/blog/the-transactional-outbox-pattern-never-lose-a-message-again/

Giải pháp này không hào nhoáng. Nó không mang lại cảm giác "đột phá công nghệ". Nhưng nó tận dụng triệt để một thành phần đã có sẵn, đã được vận hành ổn định, đã được đội ngũ hiểu rõ. Đó chính là tinh thần của thao tác hợp nhất nhiệm vụ đã nhắc ở trên.

Giới Hạn Của Việc Giới Hạn

Tôi không muốn bài viết này trở thành một lời cổ vũ tuyệt đối cho việc luôn luôn bó hẹp tư duy. Tư duy "trong chiếc hộp" có giới hạn riêng của nó.

Có những bài toán thực sự đòi hỏi một sự thay đổi nền tảng: khi kiến trúc hiện tại đã chạm trần về hiệu năng, khi mô hình kinh doanh đã đổi khác hoàn toàn, hoặc khi công nghệ nền tảng đã lỗi thời đến mức việc vá víu thêm chỉ kéo dài vấn đề thay vì giải quyết nó. Trong những tình huống đó, việc cố thủ với "những gì đang có" không còn là kỷ luật, mà trở thành sự trì trệ núp bóng thận trọng.

Ranh giới giữa hai điều này không phải lúc nào cũng rõ ràng, và đó là lý do vai trò của người dẫn dắt kỹ thuật (dù là tech lead hay engineering manager) trở nên quan trọng: không phải để áp đặt một trong hai lối tư duy, mà để đặt đúng câu hỏi ở đúng thời điểm.

Vậy Khi Nào Nên Dùng Cách Nào?

Qua thực tế làm việc, tôi nhận thấy một cách phân biệt tương đối hữu ích. Khi vấn đề nằm ở việc vận hành, tối ưu, hoặc mở rộng một hệ thống đã chứng minh được giá trị, tư duy "trong chiếc hộp" gần như luôn nên được thử trước. Chi phí thấp hơn, rủi ro thấp hơn, và tận dụng được kiến thức đội ngũ đã tích lũy.

Ngược lại, khi vấn đề nằm ở việc định hình một hướng đi hoàn toàn mới, ví dụ như một sản phẩm mới, một thị trường mới, hoặc một bài toán mà chính định nghĩa của nó còn chưa rõ ràng, thì việc mở rộng biên giới suy nghĩ, tạm gác các ràng buộc hiện tại sang một bên, mới thực sự cần thiết.

Nói cách khác: "trong chiếc hộp" phù hợp cho câu hỏi làm sao để tốt hơn; "ngoài chiếc hộp" phù hợp cho câu hỏi liệu chúng ta có đang hỏi đúng câu hỏi hay không.

Lời Kết

Lần tới khi đội ngũ của bạn đứng trước một bài toán khó và ai đó buột miệng "chúng ta cần nghĩ ngoài chiếc hộp", có lẽ câu hỏi đáng hỏi trước tiên là: chúng ta đã thực sự nhìn kỹ vào bên trong chiếc hộp chưa? Đã thử sắp xếp lại, kết hợp lại, hoặc giao thêm vai trò mới cho những gì đang có chưa?

Rất có thể, câu trả lời cho bài toán đang nằm ngay đó, chỉ là chưa được nhìn đúng góc mà thôi.

Lê Hữu Tiến hiện là Associate Engineering Manager tại Classmethod Đà Nẵng.