Tại sao code lại bốc mùi thối?

Khi tham gia dự án ai cũng muốn phải viết code rõ ràng, mạch lạc, chất lượng:

• Code phải được chia tách thành các class/module rõ ràng.

• Mỗi module phải làm một nhiệm vụ duy nhất, ít lệ thuộc lẫn nhau (high cohension/low coupling)

• Code được thiết kế theo architecture phù hợp (3-tier hoặc MVC) tùy vào dự án. Có sử dụng design pattern tùy vào vấn đề.

Thế nhưng, đời sẽ cho bạn một gáo nước lạnh ngay lập tức! Khi tham gia một dự án, nhiều khả năng các bạn sẽ được đọc một đống code vừa khổng lồ, vừa tởm vừa rối như canh hẹ.

Lý do khách quan

• Không có quy trình phù hợp, như một định lý, code của dự án nào cũng sẽ tởm dần đều theo thời gian (gọi là software rot hoặc code rot).

• Requirement liên tục thay đổi: Requirement trong ngành công nghệ ít khi rõ ràng cụ thể mà rất hay thay đổi. Đổi requirment đồng nghĩa với việc sửa code.

• Deadline dí sát đít: Khách hàng thường hay đổi yêu cầu, muốn sản phẩm chất lượng cao nhưng phải xong sớm. Dẫn đến việc phát triển thiếu các giai đoạn review code hay testing.

• Bug và requirement dồn dập: Sau khi, sản phẩm đã release nhưng các yêu cầu vẫn tiếp tục thay đổi dẫn đến không có giai đoạn refactor code để cài thiện chất lượng.

• Dev có vấn đề về tinh thần hoặc sức khỏe, thức đêm thiếu ngủ do bị dí deadline

Lý do chủ quan

• Chưa đủ trình độ và kinh nghiệm để phân tách module cho hợp lý.

• Chưa biết cách lựa chọn architecture hay áp dụng các design pattern phù hợp.

• Chỉ lo viết code chứ không chịu bỏ thời gian để viết document, lựa chọn coding convetion hay vẽ architecture cho hệ thống.

• Quá tự tin (hoặc lười) nên cứ nghỉ code mình viết ra là tốt nhất, không có bug. Viết xong không test mà commit thẳng luôn, không thông qua code review,...

• Do văn hóa của team, không quan trọng chất lượng code mà chỉ quan trọng số lượng module hoàn thành, tốc độ hoàn thành nhanh hay chậm. Điều này sẽ để lại nhiều technical debt – nợ kĩ thuật trong dự án. Về lâu về dài, code quá “tởm” sẽ khiến dự án rất khó mở rộng hay sửa chữa.