Series Phản Phác Quy Chân – Luận về Technical Debt – Nợ kiếp này, duyên kiếp trước

Technical Debt (Nợ kĩ thuật) là một món nợ mà hầu như lập trình viên nào cũng phải gánh trong quá trình làm việc. Hẳn bạn sẽ thắc mắc: Hầu hết lập trình viên chúng mình đều là những con người siêng năng chăm chỉ, không cờ bạc gái gú, hết giờ làm là đi nhậu, mát xa … nhầm, về nhà với vợ con. Chúng ta không vay mượn ai bao giờ thì làm sao có nợ???

Muốn biết câu trả lời, hãy đọc bài viết để tìm hiểu thêm về Technical Debt nhé! Đây là một khái niệm khá quan trọng và bổ ích đấy.

2708226548_b80e14f366_b

Technical Debt là gì?

Khái niệm này được đưa ra bởi Ward Cunningham (Cha đẻ của wiki đầu tiên). Trong cuộc sống, đôi khi bạn sẽ phải mượn tiền để xài, sau đó cày cuốc trả. Số tiền này được gọi là nợ. Trong lập trình cùng thế, đôi khi ta chọn cách giải quyết “mì ăn liền”, giải quyết được vấn đề ngay, nhưng sẽ gây khó khăn cho quá trình phát triển và bảo trì về sau. Mỗi lần như vậy, ta tạo thêm 1 khoản “nợ kĩ thuật” cho dự án. 

Technical bebt ban đầu rất ít, nhưng theo quá trình code thì càng ngày nó càng nhiều lên, trở thành nợ nầng chồng chất. Một số ví dụ:

  • Để tái sử dụng code đã viết, ta copy và paste code sửa đôi chút (thay vì phải tách thành module riêng). Cách này nhanh, nhưng khi có bug thì sửa… chết mẹ vì code được copy ở đủ chỗ.
  • Khi có requirement mới, thay với áp dụng sửa lại code cho dễ mở rộng, ta viết thêm hàm if. Cách này nhanh, nhưng mở rộng nhiều thì code sẽ một đống if.
  • Có bug khủng liên quan tới kiến trúc hệ thống, thay vì fix bug và refactor thì ta try/catch nuốt lỗi và fix tạm ở phần ngọn, gọi là hotfix.

6a0120a85dcdae970b0128777074ad970c-pi

Technical Debt là điều tất yếu trong quá trình code. Mỗi quyết định ta đưa ra trong lúc code đều làm tăng số nợ này lên. Điều quan trọng là mượn xong thì phải trả, nếu để lâu, techinical debt tích lỹ sẽ gây ra nhiều hậu quả nguy hiểm khôn lường.

Tác hại “khủng khiếp” của nợ

Nếu không trả nợ, cả vốn lẫn lãi sẽ dần chồng chất trong quá trình phát triển. Quá nhiều technical debt làm chậm tốc độ của team, đồng thời ảnh hưởng đến tinh thần làm việc của các thành viên trong nhóm.

Trong nhiều dự án, vì ban đầu bị trễ deadline nên team phải code ẩu, sinh ra technical debt. Nợ làm cho tốc độ phát triển chậm dần lại, dẫn tới trễ dealine -> code ẩu -> thêm nợ, thành 1 vòng lẩn quẩn. Một tính năng  có thể chỉ mất 1 ngày để hoàn thành, nhưng nếu technical debt quá nhiều sẽ mất tới 1 tuần.

Tới một mức nào đó, khi không trả được lãi nữa, ta sẽ bị “phá sản”. Lúc này, code hiện tại đã nát tới mức cực kì khó mở rộng hay bảo trì, phải đập đi viết lại. Đây cũng là nguyên nhân gây trễ deadline/thất bại cho nhiều dự án.

den
Vòng tròn lẩn quẩn: trễ deadline -> nợ -> code chậm -> trễ deadline

Nợ ơi em từ đâu tới?

Nếu như nợ công của Việt Nam là do các bác “ở trển” ăn xài thoải mái thì nợ technical debt lại do chính bản thân các developer gây ra.

Có rất nhiều lý do gây ra technical debt:

  • Do khách hàng thay đổi requirement liên tục, kiến trúc dự án không kịp thay đổi cho phù hợp
  • Do bị dealine dí/manager gây áp lực nên developer code ẩu để hoàn thành task.
  • Do bản thân developer làm biếng, code không có comment, không viết document.
  • Do team không có technical lead giỏi, hoặc các thành viên không đủ nền tảng kĩ thuật tốt.

Đôi khi technical debt là do cố ý: Chấp nhận làm nhanh vì phải có sản phẩm giao khách hàng, giành dự án, vấn đề technical tính sau. Hoặc trong các công ty start-up, người ta xây dựng sản phẩm (MVP) nhanh chóng nhất có thể để khảo sát nhu cầu người dùng. Lúc này, chức năng và tốc độ phát triển mới là quan trọng nhất, code ẩu hay kiến trúc tệ không quan trọng.

viable-product

Làm sao trả nợ ???

Như mình đã nói, code nào cũng sẽ có bug, dự án nào cũng sẽ có technical debt. Cách đối phó với technical debt là tạm ngưng việc phát triển, tập trung vào trả nợ. Ta có thể trả nợ bằng cách phân tích và tái cấu trúc hệ thống, hoặc viết thêm document, viết thêm test case, refactor code để code rõ ràng, dễ cải tiến.

Đôi lúc ta cũng có thể bỏ qua technical debt, ví dụ như khi làm prototype để demo cho khách hàng. Vì prototype xong rồi vứt luôn nên ta có thể xù nợ. Tuy nhiên nên cẩn thận, có rất nhiều trường hợp khách hàng đòi mở rộng/nâng cấp prototype thành sản phẩm để tiết kiệm thời gian. Lúc này ta phải trả nợ chết cmn luôn.

paperprotoyping
Prototype bằng giấy cho đỡ tốn công code

Hãy nhớ một điều: Mỗi lần bạn code ẩu, code đểu, bạn đang thêm nợ cho dự án. Nợ đời có vay có trả, bạn không trả thì thằng khác trong team sẽ trả. Technical debt phải trả bằng thời gian, công sức và mồ hôi nước mắt của lập trình viên đấy nhé.

P/S: Nếu sắp nghỉ việc, chuyển công ty thì các bạn cứ code ẩu thoải mái, không sao đâu! Một lập trình viên xấu số nào khác sẽ trả nợ giùm bạn =))).

Dành cho các bạn muốn tìm hiểu thêm:

 

13 thoughts on “Series Phản Phác Quy Chân – Luận về Technical Debt – Nợ kiếp này, duyên kiếp trước”

  1. Mình làm tự do up app lên play store thôi. Nhưng mà yêu cầu của user nhiều quá, có lần toàn phải từ chối khéo vì không làm được mà Android thì phân mảnh đôi khi phải chơi cái hotfix là try catch ôi sợ thấy bà ra sau khi đọc bài này 😥

    Liked by 1 person

  2. Cảm ơn tác giả, bài viết rất bổ ích.
    Mình góp ý ngoài lề chút: cái hình ảnh minh họa cho bài viết ở trang chủ có thể link vào bài viết luôn được không tác giả, chứ click vào đó nó cứ link tới cái anh thì không có tác dụng gì, lại dễ nhầm lẫn @@

    Like

  3. Chức năng mới thì copy ra sửa thôi, sửa vô cái cũ gây bug càng nguy hiểm. Chấp nhận sửa nhiều nơi nhưng dễ ăn nói với khách hơn, chức năng nào thì để thế hệ đang phát triển chịu trách nhiệm. Cùng 1 bug nhưng bên chức năng cũ thì thì là nợ, nhưng bên mới thì là nợ mới của con cháu ai copy paste thì nợ của người đó nên dễ đòi hơn.

    Like

  4. “P/S: Nếu sắp nghỉ việc, chuyển công ty thì các bạn cứ code ẩu thoải mái, không sao đâu! Một lập trình viên xấu số nào khác sẽ trả nợ giùm bạn =))).”
    Và khi bạn vào một dự án khác thì cũng có thằng vứt shit cho mình lụm như bạn đã vứt shit cho người khác. Cuộc sống có vay thì có trả.

    Like

Leave a comment