Cộng đồng phát triển phần mềm đang tích cực thảo luận về cách Locality of Behaviour ( LoB ) thách thức các nguyên tắc lập trình đã được thiết lập từ lâu. Cuộc tranh luận này tập trung vào việc liệu việc làm cho hành vi của code trở nên rõ ràng ngay lập tức có đáng để hy sinh các phương pháp truyền thống như DRY (Don't Repeat Yourself) và Separation of Concerns hay không.
Các Nguyên Tắc Thiết Kế Xung Đột
- DRY (Don't Repeat Yourself): Khuyến khích tái sử dụng code nhưng có thể làm phân tán hành vi qua nhiều file
- Separation of Concerns: Tách biệt HTML, CSS và JavaScript nhưng làm giảm tính địa phương
- Locality of Behaviour: Làm cho hành vi trở nên rõ ràng nhưng có thể tăng sự lặp lại
- Cần phải đánh đổi dựa trên nhu cầu của team và yêu cầu dự án
So Sánh Framework Khơi Mào Các Cuộc Thảo Luận Kỹ Thuật
Các lập trình viên đang so sánh các cách tiếp cận khác nhau để triển khai chức năng tương tự, đặc biệt là giữa HTMX và React . Trong khi HTMX cho phép các lập trình viên thấy hành vi trực tiếp trong các thuộc tính HTML , React yêu cầu phải xem code JavaScript riêng biệt để hiểu một nút bấm làm gì. Tuy nhiên, cộng đồng chỉ ra rằng những so sánh này không phải lúc nào cũng công bằng - các framework thường thực hiện những việc khác nhau ở bên dưới.
Một lập trình viên đã chia sẻ kinh nghiệm xây dựng hệ thống huấn luyện machine learning của họ, nơi kiến trúc microservice truyền thống mất 18 phút cho những thay đổi đơn giản. Cách tiếp cận thay thế của họ sử dụng Flask và HTMX đã giảm thời gian xử lý xuống còn vài giây, chứng minh cách tính cục bộ có thể tác động đến năng suất thực tế.
So sánh Tốc độ Phát triển
- Thiết lập microservice + React truyền thống: 18 phút cho những thay đổi nhỏ
- Phương pháp Flask + HTMX : Vài giây để triển khai
- Các yếu tố: thời gian biên dịch, hot reloading, độ phức tạp triển khai
- Tính địa phương có thể tác động đáng kể đến tốc độ phát triển trong các dự án thực tế
Cuộc Tranh Luận Giữa Magic Và Sự Đơn Giản
Một điểm thảo luận chính xoay quanh việc điều gì tạo nên magic trong code. Một số lập trình viên cho rằng JavaScript rõ ràng của React cảm thấy ít magical hơn so với các thuộc tính tùy chỉnh của HTMX . Những người khác phản bác rằng cả hai phương pháp đều yêu cầu học các khái niệm đặc thù của framework, khiến cho lập luận về magic trở nên chủ quan.
Cộng đồng cũng tranh luận về các mối quan ngại về khả năng mở rộng. Trong khi HTMX hoạt động tốt cho các tương tác đơn giản, các lập trình viên lưu ý rằng nó có thể trở nên lộn xộn đối với các ứng dụng phức tạp, thường vẫn yêu cầu các framework phía client bổ sung.
So sánh HTMX và jQuery
- HTMX:
<button hx-get="/clicked">Click Me</button>- hành vi hiển thị rõ ràng trong HTML - jQuery: Yêu cầu file JavaScript riêng biệt với
$("d1").on("click", function(){...})- hành vi tách biệt khỏi markup - Cách tiếp cận của HTMX thỏa mãn nguyên tắc Locality of Behaviour
- Cách tiếp cận của jQuery tạo ra "tác động ma quái từ xa"
CSS Và Styling Làm Phức Tạp Vấn Đề
Styling đặt ra những thách thức đặc biệt cho những người ủng hộ tính cục bộ. Tailwind CSS đại diện cho một cách tiếp cận để giữ các style gần với markup, mặc dù một số lập trình viên lo ngại điều này dẫn đến các chi tiết triển khai làm lộn xộn giao diện. Những người khác đề xuất các giải pháp trung gian như các khối style đặc thù cho từng trang có thể được tái cấu trúc thành các stylesheet toàn cục sau này.
Cuộc thảo luận tiết lộ rằng CSS vốn tạo ra một khoảng cách nào đó giữa hành vi và markup, vì các stylesheet bên ngoài có thể thay đổi đáng kể cách các phần tử xuất hiện và hoạt động.
Tác Động Thực Tế Đến Các Nhóm Phát Triển
Ngoài các cuộc tranh luận lý thuyết, các lập trình viên đang chia sẻ kinh nghiệm thực tế. Các nhóm làm việc với AI agents và tự động tạo code thấy rằng tính cục bộ giúp các công cụ hiểu và sửa đổi code dễ dàng hơn. Các mẫu phân tách truyền thống có thể phân tán chức năng liên quan qua nhiều file, khiến việc thay đổi tự động trở nên khó khăn hơn.
Đây chính là context engineering nói một cách ngắn gọn. DRY và SoC thực sự làm rối tung khả năng thu thập context một cách hiệu quả của agent.
Cộng đồng thừa nhận rằng các lập trình viên có kinh nghiệm có thể viết code dễ bảo trì bất kể phương pháp nào, nhưng tính cục bộ có thể giúp các thành viên trong nhóm ít kinh nghiệm hiểu codebase nhanh hơn.
Kết Luận
Cuộc tranh luận làm nổi bật rằng các nguyên tắc thiết kế phần mềm không phải là quy tắc tuyệt đối mà là những công cụ có sự đánh đổi. Trong khi locality of behaviour có thể cải thiện khả năng hiểu code và tốc độ bảo trì, nó có thể xung đột với các thực hành đã được thiết lập có lợi ích riêng của chúng. Điều quan trọng dường như là đưa ra quyết định có ý thức về những sự đánh đổi này thay vì tuân theo mù quáng bất kỳ nguyên tắc đơn lẻ nào.
Khi các công cụ phát triển và cấu trúc nhóm phát triển, đặc biệt là với sự hỗ trợ AI trở nên phổ biến hơn, sự cân bằng giữa các nguyên tắc này có thể tiếp tục chuyển hướng về các phương pháp ưu tiên khả năng hiểu code ngay lập tức.
Tham khảo: Locality of Behaviour (LoB)