Khi đi học hoặc mới đi làm, chúng ta được dạy về việc 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 đề.

Khi tham gia dự án đầu tiên, hẳn ai cũng mong rằng mình sẽ được tiếp xúc với những dòng code mạch lạc, chất lượng như vậy.

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ẹ.

Thật đấy, 96.69% code của các dự án lớn đều như vậy cả. Có thể dự án hiện tại bạn đang làm cũng vậy đấy!

Vì sao thế? Cùng đọc bài viết này để biết nhé!

Dev tính không bằng trời tính

Là một developer có tâm, hẳn ai trong chúng ta cũng rất có trách nhiệm với những dòng code mình viết ra. Vì thế, khi bắt đầu một dự án, ai cũng sẽ cố gắng thiết kế architecture cho phù hợp, viết những dòng code đầu tiên một cách vô cùng cẩn thận, tỉ mỉ.

Trớ trêu thay, dev tính không bằng trời tính! Nếu không có qui 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 (dân nước ngoài gọi điều này là software rot hoặc code rot).

Từ những lý do khách quan

Có những lý do … bất khả kháng mà coder chúng ta không kịp trở tay:

• Requirement liên tục thay đổi: Requirement trong ngành mình thường í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. Có nhiều requirement đòi hỏi ta phải thay đổi hơn 50% hoặc code lại từ đầu!

Giả sử, ban đầu khách hàng muốn làm web bán áo thun ở Hồ Chí Minh. Sau khi code được 6 tháng, khách hàng lại muốn nó trở thành web bán trà sữa trên troàn quốc, hỗ trợ ship và tracking đơn hàng. Việc đổi code từ bán áo sang bán trà + đơn hàng sẽ đòi hỏi rất nhiều thay đổi.

• 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.

Khi deadline đã dí sát mông, developer chúng mình chỉ code cho chạy xong là mừng, làm gì kịp nghĩ tới chuyện review code hay test xem có bị lỗi đoạn nào không.

• Bug và requirement dồn dập: Sau khi, sản phẩm đã release, bạn nghĩ rằng có thể thư thả fix bug, refactor code để cài thiện chất lượng?

Nhầm rồi, khách hàng đòi phải có thêm chức năng chat với khách hàng + livestream sản phẩm “gấp”. Vòng xoáy deadline dí => Code rởm => Deadline dí … lại tiếp tục

• Developer có vấn đề về tinh thần hoặc sức khỏe (Bị deadline dí nên thức khuya, dễ mệt mỏi buồn ngủ và ốm vặt; bị sếp cằn nhằn hay trả lương chậm; bị gấu giận, vợ bỏ). Những điều nhỏ nhặt này đều ảnh hưởng đến năng suất và chất lượng code.

https://giphy.com/gifs/deadline-sNjTRqN38JDXy

Đến những lý do chủ quan

Tất nhiên, không phải lúc nào code rởm cũng là vì những lý do bên ngoài như dự án, team leader hay khách hàng.

Là một developer, là người trực tiếp viết ra những dòng code đó, chính chúng ta cũng có vài phần trách nhiệm. Nhiều khi, code thối là bởi nhiều lý do xuất phát từ chính bản thân chúng ta:

• 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.

Không có document hay coding convention, khi developer mới gia nhập, họ không biết bắt đầu như thế nào, mỗi người viết code một kiểu khiến code rối như canh hẹ.

Ngoài ra, có nhiều dự án mà developer tiền nhiệm đã nghỉ việc, lên chức hoặc … xuống lỗ. Developer mới sẽ không hiểu rõ dự án, phải tự mò mẫm nên code rối nay lại càng rối.

 

• 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 v…v gì cả.
• 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.

Kết

Hồi mới đi làm, khi vào một dự án lâu đời, nhìn những đống code dài ngoằn nghèo vài ngàn line trong 1 file code, không tách class hay đặt tên rõ ràng; mình cũng từng lôi tổ tổng 8 đời mấy lão developer tiền nhiệm ra mà chửi.

Đi làm được lâu, mình mới hiểu rằng developer cũng là con người, cũng có lúc mệt mỏi hay mắc sai lầm, cũng có khi do những yếu tố khách quan nên không thể viết những dòng code tốt nhất.

Do vậy, khi thấy code tởm lợm bẩn bựa, mình lại tự nhủ lòng: Chắc cha này viết code khi bị deadline dí, sếp trả lương chậm, con khóc vợ giận bồ nhí dỗi; nên code mới tởm thế này! Từ đó mình hiểu và thông cảm cho họ hơn.

Nói túm lại, qua bài này, chúng ta đã hiểu lý do phần lớn code của các dự án lớn sẽ… tởm dần đều theo thời gian.

Ở bài viết sau, mình sẽ chia sẻ về chuyện “Nên làm gì trong trường hợp này”, cũng như những kinh nghiệm để giữ vững chất lượng của code qua thời gian nhé!