Bài viết guest post của bạn Thành Nguyễn

Giỏi thuật toán sẽ mang lại nhiều lợi thế: Khả năng giải quyết vấn đề, code logic hơn, bố cục đẹp hơn. Đó là điều không thế chối cãi. Điểm yếu của thuật toán là nó gắn chặt với một ngữ cảnh biz rất cụ thể. Trong cái ngành công nghiệp khắc nghiệt này thì biz rule all, biz thay đổi nhanh mà thuật toán không điều chỉnh chạy theo kịp thì cũng vứt. Thuật toán càng cao siêu tối ưu thì thường phức tạp, càng phức tạp thì khó bảo trì.

Thực tế khi mình review code thấy nhiều bạn tập trung cao vào giải thuật nên code phức tạp quá mức cho phép, để rồi khi biz thay đổi thì rất mệt mỏi, kết quả phải “đập”. Maintain đoạn code khó hiểu chỉ để giải quyết một phần nhỏ của tổng thể là không vui chút nào.

thuật toán

Xét ở góc độ vĩ mô, một đoạn code không chỉ cấu thành duy nhất bởi yếu tố giải thuật mà còn nhiều khía cạnh khác như: Tính đơn giản, dễ bảo trì, khả năng mở rộng, khả năng chịu lỗi, đáp ứng yêu cầu nghiệp vụ, v.v Trong một phần mềm người ta dành 80% chi phí để DUY TRÌ (maintain) nó (Oracle, Sep. 1997, Java Code Conventions). Cho nên ở góc độ xây dựng sản phẩm mang tính lâu dài, tôi sẽ dành trọng số cao nhất cho tính đơn giản, dễ bảo trì và khả năng mở rộng trong tương lai. Thuật toán sẽ có trọng số lớn trong vài ngữ cảnh đặc thù.

Một best practice là hạn chế sử dụng nhiều map/dict. Cứ mỗi một mapping là tạo ra một mối liên kết. Khi viết code phải xem xét hiệu chỉnh đa liên kết thì tốn chi phí suy nghĩ cao. Mapping sẽ tốt khi ánh xạ từ một id đến toàn bộ data (quản lý toàn bộ nghiệp vụ), hoặc áp dụng cho một phần nhỏ của nghiệp vụ.

Một best practice khác là tránh lạm dụng concurrent data structures chỉ để kỳ vọng “không bị race condition”. Áp dụng đúng lúc đúng ngữ cảnh mới là chân ái.

Bài viết từ bạn Thành với N năm kinh nghiệm review code (biết đâu sau này nhiều kinh nghiệm hơn thì bạn Thành có góc nhìn khác với bài viết hiện tại).