Ở bài “Tại sao code của dự án hiện tại nó … tởm quá vậy” trong kì trước, mình đã nói lý do mà code của các dự án càng để lâu sẽ càng loằng ngoằng, rối rắm.

Đây là chuyện bất khả kháng, và chúng ta ít khi có quyền lựa chọn project mình tham gia!

Thay vì than trời, trách đất, chửi mấy lão developer trước kia, bạn hãy cùng mình tìm hiểu một số cách “sống chung với lũ” – tức sống và làm việc chung với code bựa.

Ở cuối bài, mình cũng sẽ chia sẻ một số phương pháp để nâng cao chất lượng code trong dự án, giúp code đỡ “tởm dần đều” qua thời gian nhé!

Có nên đập đi làm lại?

Khi code của hệ thống trở nên quá tởm, một trong những giải pháp hay được lựa chọn là … “đập đi làm lại”.

Cách này ban đầu nghe có vẻ khá hợp lý:

• Dựa theo hệ thống cũ, chúng ta đã hiểu hệ thống nên làm gì, cần những tính năng gì.
• Từ đó, ta có thể dễ dàng design, lựa chọn technical stack cho phù hợp với nhu cầu dự án.
• Developer cũng hiểu hơn về business, rút ra được bài học từ những sai lầm trong dự án cũ để build code tốt hơn

Tuy nhiên, cách này có những nguy cơ tiềm ẩn:

• Team sẽ mất khá nhiều thời gian để xây dựng lại hệ thống từ đầu. Không thêm được chức năng nào mới hay mang đến value cho doanh nghiệp.
• Có những bug ngầm đã được fix trong hệ thống cũ mà khi code lại từ đầu ta dễ bỏ qua. Khi code dự án mới chúng sẽ… trồi lên lại.
• Trong quá trình code lại, requirement lại tiếp tục được thêm thắt và thay đổi. Nhiều khả năng, hệ thống mới hoàn thành sẽ có code … vừa rối vừa bựa không kém cái cũ!

Gương điển hình ở đây là Netscpae. Vì quyết định viết lại code của trình duyệt Netspace 4.0, Netscape đã mất tới 3 năm để ra phiên bản mới, mất khá nhiều thị trường vào tay các trình duyệt khác.

Làm sao để sống chung với lũ?

Vì các lý do trên, đa phần các công ty thường không muốn viết lại từ đầu, mà chỉ cần bảo trì và thêm chức năng vào code cũ.

Là một developer, chúng ta phải làm sao để làm việc hiệu quả với chúng?

• Tìm đọc document: Document là thứ bạn nên đọc đầu tiên khi vừa tham gia dự án.

Document đầy đủ sẽ giúp bạn hiểu rõ kiến trúc của hệ thống, coding convetion, cách setup môi trường để code và build.

• Hỏi người đi trước: Có những thứ không thể ghi đầy đủ trong requirement, mà chỉ nằm trong đầu developer.

Lúc này, cách hay nhất là túm đầu một bác senior hay đã theo dự án lâu năm để hỏi. Hoặc bạn cũng có thể xin phép ngồi pair programming với họ, bạn sẽ học được rất nhiều thứ từ hệ thống hiện, coding convention cho đến qui trình làm việc.

• Đọc và chạy code: Nếu dự án hiện tại không có document, developer thì đã xách quần chạy hết thì sao?

Chúc mừng bạn, bạn xui vkl! Lúc này, điều duy nhất bạn có thể làm là mò mẫm cách build và chạy code, sau đó đọc code và tìm hiểu xem code đươc chạy như thế nào!

• Sửa những lỗi nhỏ tới lớn: Một cách khác là bạn tìm những bug nho nhỏ của chương trình, sau đó tìm cách fix chúng.

Việc fix bug sẽ giúp bạn hiểu được chương trình gồm những phần nào, chúng hoạt động ra sao. Trong các công ty lớn, các lập trình viên mới vào cũng hay được giao task fix bug để tìm hiểu hệ thống rõ hơn.

Phương pháp phòng chống “Code Tởm”

Tất nhiên, phòng bệnh hơn chữa bệnh. Như mình đã nói, nếu không có các biện pháp phòng chống, code sẽ tởm dần đều, technical debt của dự án cũng sẽ tăng dần đều theo thời gian.

Vậy làm sao để ngăn chặn những điều đó? Những bác lập trình viên thế hệ trước đã chia sẻ vài kinh nghiệm “xương máu” cho chúng ta:

• Document đầy đủ: Viết document là một công việc dài dòng nhàm chán, không thú vị bằng viết code nên anh em chúng ta ai cũng lười làm.

Bạn không cần viết document cho từng file hay dòng code, hãy tập trung viết về architecture và các module của dự án, các flow hay gặp, cách setup và deploy là được rồi.

Hãy nghĩ tới những người sẽ phải hốt shit cho bạn về sau. Có khi người đó là chính bạn đấy!

• Unit Test và Comment: Viết unit test sẽ giúp người đọc hiểu một hàm sẽ hoạt động ra sao, kết quả là gì. Comment tốt sẽ giúp bạn hiểu được tại sao code được thiết kế và viết như vậy.

Ngoài ra, nhờ có unit test, ta sẽ tự tin hơn khi refactor code, không lo tạo thêm bug cho phần mềm.

• Code Review: Trước khi commit, code nên được một hoặc hai thành viên khác trong tìm review, tìm ra những lỗi sai và đề xuất cách cải tiến.

Tin mình đi, khi viết code và biết rằng sẽ có người review, bạn sẽ viết cẩn thận, có tâm và… chất lượng hơn nhiều!

Đừng chê trách hay than phiền, vì ngành phần mềm vốn là như vậy!

Bản chất của “phần mềm” là mềm mại, uyển chuyển, dễ thay đổi. Bạn sẽ không thể nào xây dựng architecture, viết code hoàn hảo ngay từ lúc bắt đầu project. Một architecture tốt phải dễ dàng tiến hóa, biến đổi cho phù hợp với những thay đổi đó.

Từ góc nhìn của người dùng, họ không hề quan tâm đến chất lượng code. Họ chỉ quan tâm đến chất lượng sản phẩm, thời gian xây dựng. Xét cho cùng, thứ mang lại giá trị chính là sản phẩm tạo ra từ code, chứ không phải là chất lượng code!

Một sản phẩm code hơi lởm nhưng được vài chục, vài trăm người dùng sẽ đem lại lợi nhuận cho công ty nhiều hơn một hệ thống thiết kế hoàn hảo nhưng trễ deadline tận 3 năm, không ma nào thèm sử dụng.

Kết

Tất nhiên, dưới vai trò của một developer, góc nhìn của chúng ta sẽ khác. Chúng ta phải code có tâm, có trách nhiệm với chính những dòng code mình viết ra.

Một sản phẩm code lởm sẽ gặp khó khăn khi cần mở rộng, phát triển hoặc phục vụ cho hàng ngàn hàng triệu người dùng. Do vậy, người developer có tâm cũng phải biết cách giữ cho code không bị tởm dần đều theo thời gian.

Còn bạn thì sao? Đã bao giờ bạn gia nhập một dự án có code … tởm không thể tả chưa? Bạn và đồng đội đã giải quyết như thế nào? Cùng chia sẻ trong mục comment nha.