Trong bối cảnh phát triển phần mềm không ngừng phát triển, một cuộc tranh luận sôi nổi đã nổi lên xung quanh độ phức tạp và khả năng bảo trì của mã nguồn. Trong khi quan điểm truyền thống thường nhấn mạnh việc viết mã có khả năng mở rộng, các cuộc thảo luận gần đây trong cộng đồng lập trình viên đề xuất một cách tiếp cận ngược đời: ưu tiên viết mã dễ xóa hơn là dễ mở rộng.
Chi phí của sự phức tạp
Các cuộc thảo luận trong cộng đồng gần đây nhấn mạnh mối lo ngại ngày càng tăng về chi phí tiềm ẩn của các giải pháp được thiết kế quá mức. Các lập trình viên ngày càng nhận thấy rằng các trừu tượng phức tạp, mặc dù nhằm làm cho mã linh hoạt hơn, thường dẫn đến nợ kỹ thuật gần như không thể loại bỏ.
Như một lập trình viên chỉ ra, mã được sao chép-dán kém chất lượng chỉ dẫn đến một buổi chiều khó chịu để trả nợ kỹ thuật và sửa lỗi. Nhưng mã được trừu tượng hóa kém sẽ dẫn đến hàng tháng trời trả nợ kỹ thuật. Nhận xét này thách thức quan điểm thông thường về việc tái sử dụng và trừu tượng hóa mã.
Lập luận cho sự đơn giản
Một số nguyên tắc chính đã nổi lên từ cuộc thảo luận cộng đồng:
- Bắt đầu đơn giản, duy trì đơn giản
- Xây dựng ứng dụng nguyên khối ban đầu
- Triển khai trên cơ sở hạ tầng cơ bản (như một máy ảo đơn lẻ)
- Tránh tối ưu hóa sớm
- Chỉ mở rộng khi cần thiết
- Quy tắc số ba
- Lần đầu: Viết nó
- Lần hai: Sao chép nó
- Lần ba: Cân nhắc tái cấu trúc
- Lần bốn: Chắc chắn tái cấu trúc
- Thiết kế module
- Tách biệt logic nghiệp vụ khỏi triển khai
- Giữ các chi tiết kỹ thuật độc lập
- Làm cho các thành phần có thể thay thế độc lập
Ví dụ thực tế
Một ví dụ nổi bật đến từ việc so sánh giữa máy chủ hiển thị X11 và Wayland. Cộng đồng nhận thấy rằng Wayland, mặc dù cố gắng hiện đại hóa, đã trở nên phức tạp hơn X11. Các thao tác đơn giản như chụp màn hình hoặc lấy vị trí cửa sổ yêu cầu phải điều hướng qua nhiều lớp trừu tượng, trong khi cách tiếp cận đơn giản của X11 làm cho những tác vụ này dễ quản lý hơn.
Sự đánh đổi của độ phức tạp
Một quan sát thú vị từ cuộc thảo luận là phần mềm thường trở nên phức tạp tối đa theo một trong hai cách:
- Thông qua độ phức tạp vốn có của lĩnh vực
- Thông qua độ phức tạp nhân tạo do lập trình viên tạo ra
Các phương pháp tốt nhất cho mã có thể bảo trì
Dựa trên những hiểu biết từ cộng đồng, đây là những khuyến nghị chính:
- Tập trung vào nhu cầu hiện tại
- Giải quyết vấn đề thực tế, không phải giả thuyết
- Tránh xây dựng framework khi có thể sử dụng một cái có sẵn
- Giữ trừu tượng hóa ở mức tối thiểu và có mục đích
- Thiết kế để có thể xóa
- Làm cho các thành phần có thể xóa độc lập
- Tránh tích hợp sâu giữa các hệ thống
- Giữ giao diện đơn giản và rõ ràng
- Kiểm thử chiến lược
- Viết các bài kiểm tra để xác định mã có thể loại bỏ
- Tập trung vào chức năng cốt lõi
- Đảm bảo các thay đổi có thể được thực hiện an toàn
Tương lai của việc bảo trì mã
Với sự xuất hiện của AI và LLM, một số lập trình viên lạc quan về khả năng bảo trì trong tương lai. Có những suy đoán về việc sử dụng LLM để giúp dọn dẹp codebase, loại bỏ mã không sử dụng và thêm tài liệu hợp lý, mặc dù kết quả hiện tại vẫn còn hạn chế.
Sự đồng thuận của cộng đồng có vẻ rõ ràng: mặc dù việc viết mã có thể mở rộng không phải là sai, trọng tâm nên là viết mã được hiểu rõ, có phạm vi phù hợp và - khi cần thiết - dễ dàng loại bỏ. Cách tiếp cận này có thể là phương án bảo vệ tốt nhất của chúng ta chống lại sự tích tụ không thể tránh khỏi của nợ kỹ thuật trong phát triển phần mềm hiện đại.