Trong thế giới lập trình luôn thay đổi từng ngày, mấy cuộc tranh luận thường hay lạc vào mấy chủ đề mà đáng lẽ ra đã "xong phim" từ lâu. Gần đây, có một thread trên Twitter đã tóm gọn cái cảm giác này, khi một dev bày tỏ sự bực bội vì cứ phải bàn đi bàn lại mấy thứ mà đáng ra nên coi là "chuyện cũ bỏ qua". Trong thread đó, có 5 điểm chính được nêu ra, kiểu như "bí kíp" để devs tập trung làm việc hiệu quả hơn, thay vì cứ cãi nhau về mấy thứ đã giải quyết xong.

Điểm đầu tiên là cảnh báo về việc dùng mấy công cụ Object-Relational Mapping (ORM). Nghe thì tiện, kiểu như "cầu nối" giữa code và database, nhưng thực tế thì không phải lúc nào cũng ngon nghẻ. ORM dễ gây ra mấy vấn đề về hiệu năng, vì cái gọi là "impendance mismatch" giữa thiết kế hướng đối tượng và database quan hệ. Kết quả? Query chậm, SQL thì mất kiểm soát. Thay vì vậy, devs nên thử mấy giải pháp khác như SQL builders, query DSLs, hay data mappers – mấy cái này cho phép tương tác với database trực tiếp và hiệu quả hơn. Trong thread còn có meme châm biếm về microservices, kiểu như "đơn giản là chân ái"

Điểm thứ hai là ủng hộ việc bắt đầu với kiến trúc monolithic, rồi hẵng nghĩ đến microservices khi thực sự cần. Monolithic dễ quản lý, dễ deploy, nhất là với mấy dự án nhỏ. Nhưng khi app lớn lên, chuyển sang microservices cũng giống như "con dao hai lưỡi". Đúng là microservices giúp scale và linh hoạt hơn, nhưng nó cũng kéo theo cả đống phức tạp, dễ làm team "ngộp thở". Câu chuyện này nghe quen không? Netflix cũng từng từ monolithic chuyển sang microservices để đáp ứng nhu cầu scale của họ đấy.

Tiếp theo là về monorepo. Dùng monorepo có thể giúp team làm việc dễ hơn, chia sẻ code tiện hơn, nhất là với mấy dự án lớn. Nhưng không phải không có nhược điểm đâu nha, như dễ bị conflict source code hay khó scale hệ thống source control. Tuy nhiên, nếu môi trường làm việc ưu tiên deploy nhanh và code nhất quán, thì monorepo vẫn là một lựa chọn đáng cân nhắc.

Điểm thứ tư là phê phán việc dùng mocks trong testing. Tác giả gợi ý devs nên thử test mà không cần mocks, thay vào đó dùng Nullables. Cách này có thể làm test nhanh hơn, đáng tin hơn, và dễ bảo trì hơn, tránh được mấy rắc rối từ mock-based testing. Nhưng mà, để làm được thì code production cũng phải "chịu chơi", kiểu như cần có "công tắc tắt" để phục vụ test. Cách tiếp cận này hợp với xu hướng testing hiện đại, ưu tiên hiệu quả và cân bằng giữa tự động hóa và bảo trì.

Cuối cùng, thread kết thúc bằng một lời khen nhẹ cho mấy bài phỏng vấn kiểu LeetCode, vì nó khá là "dễ thở". Điểm này như một lời nhắc nhở rằng, dù mấy cuộc tranh luận về cách làm phần mềm có thể phức tạp, thì mấy thứ cơ bản như coding và giải quyết vấn đề vẫn luôn dễ tiếp cận.

Tóm lại, thread này như một "cú hích" để chúng ta nghĩ rộng hơn về việc tập trung vào mấy cách làm hiệu quả, thay vì cứ "đào mộ" mấy vấn đề đã xong. Bằng cách chọn giải pháp đơn giản, hiểu rõ ưu nhược điểm của kiến trúc, và áp dụng mấy phương pháp testing hiện đại, devs có thể tạo ra môi trường làm việc năng suất và sáng tạo hơn. Thế giới phần mềm thì luôn thay đổi, nên hãy luôn mở lòng với mấy ý tưởng mới, nhưng cũng đừng quên giá trị của mấy cách làm đã được kiểm chứng qua thời gian nha!