Hôm nay tình cờ tham gia một event có nói đến vấn đề Technical debt (nợ kỹ thuật) nên viết bài này coi như là note lại và những gì bản thân đã trải qua.

Tất cả mọi dự án đều có nợ kỹ thuật. Tất cả lập trình viên đều đã từng nợ. Chỉ khác nhau ở việc họ đã trả hết chưa, có muốn trả hay không, hoặc không còn cơ hội để trả nữa hay không mà thôi.

Nợ ở đây được hiểu là những thứ mà chúng ta có nghĩa vụ phải trả với việc chúng ta đã làm. Nếu nợ tiền thì trả bằng tiền, nợ tình cảm trả bằng tình cảm. Thì nợ kỹ thuật không chỉ trả bằng code. Mà còn bằng tiền, bằng thời gian và cả bằng sự lạc quan, vui vẻ mỗi ngày của bạn.(thực ra thì dù sao chúng ta cũng phải làm, phải trả nợ, nên cứ vui vẻ lên 👐 )

Những nguyên nhân chính dẫn đến nợ kỹ thuật là:

1. Yêu cầu chưa rõ ràng trong khi vẫn phải triển khai
2. Do áp lực, yêu cầu gấp và đẩy nhanh tiến độ từ cấp trên, nơi mà doanh nghiệp cần một cái gì đó launch sớm hơn trước khi tất cả các thay đổi cần thiết hoàn tất
3. Thiếu quy trình và kiến thức trong quá trình phát triển phần mềm
4. Thay đổi yêu cầu ở những giây phút cuối
5. Tech lead không đủ năng lực, thiếu tầm nhìn về bài toán tổng thể business và áp dụng công nghệ
6. Công nghệ đã lạc hậu, không có convention cụ thể, thiếu các quy chuẩn…
7. Thiếu sự hợp tác giữa các bên liên quan, vấn đề tam sao thất bản
8. Phát triển phần mềm không hướng người dùng, mà hướng tới sở thích của boss
9. Không kiểm thử, không document…
10. Do tính thiếu cẩn thận, tặc lưỡi cho qua, hết giờ làm mà vẫn phải fix bug, nên làm tạm cho nó chạy rồi xử lý sau(mà thường thì sau là không có hồi đáp)

…

Đó là một số nguyên nhân(trong vô vàn nguyên nhân khác nữa) mà khi vấn đề trở nên quá muộn thì “Mọi người đều muốn viết lại toàn bộ dự án từ đầu”.
Hoặc công ty sẽ rất khó tuyển được nhiều nhân tài mới bởi codebase quá đỗi kinh hoàng, các lập trình viên cũng dần rời đi khỏi công ty, và đó là khi code trở thành môi trường làm việc mệt mỏi…

Vấn đề thực sự với việc tích lũy nợ kỹ thuật là doanh nghiệp sẽ không bao giờ muốn trả hết. Vì nỗi đau của nợ kỹ thuật thường chỉ cảm thấy bởi các lập trình viên, nên trả hết là một điều rất khó khăn, doanh nghiệp sẽ khó chấp nhận việc bạn dành ra cả tháng trời chỉ để refactor lại dự án trong khi nó không có tác động trực tiếp gì đến doanh thu cũng như trải nghiệm khách hàng.

Chắc hẳn các bạn đã nghe:

“Do it now because we really need.`"

— Làm nó gấp cho tao, bởi vì tính năng này cần gấp.

“We’ll come back to this later when we have the time.”

— Chúng ta sẽ quay lại làm nó sau khi chúng ta có thời gian.

Và chúng ta thường đi đến một thỏa hiệp thông qua việc tăng nợ kỹ thuật lên. Nói như vậy không có nghĩa nợ kỹ thuật là điều xấu. Giống như nợ tài chính có thể giúp bạn đạt được các mục tiêu lớn trong cuộc sống nhanh hơn, không phải tất cả các khoản nợ kỹ thuật đều xấu và quản lý nó tốt có thể mang lại lợi ích to lớn cho công ty của bạn.

Điều này đặc biệt đúng đối với các công ty đang phát triển nhanh chóng, những người có nhu cầu quan trọng là launch sản phẩm sớm và thường xuyên để xác định sự phù hợp của sản phẩm / thị trường(market fit), đáp ứng nhu cầu của khách hàng và nắm bắt các cơ hội mới.

Nhưng cũng giống như nợ tài chính, bạn phải khôn ngoan về việc phát sinh nợ công nghệ. Về lâu dài, nợ tích lũy có thể làm chậm tốc độ release của bạn, gây ra các vấn đề về việc scale, khủng hoảng đội dev và ảnh hướng tới toàn bộ business của công ty.

Có 3 loại nợ như sau:

1. Cố tình nợ

Thông thường thì các lập trình viên sẽ tìm và chọn cách nào nhanh nhất và đúng đắn để làm một tính năng, module nào đó ra mắt khách hàng sớm nhất có thể, dẫn tới việc họ chịu gánh nợ để đạt được điểu đó.

“We sometimes deliberately incur tech debt to reduce time to market.”

Vấn đề là khi chúng ta thực hiện theo cách này, nếu ngay lúc đó chúng ta tiết kiệm được một chút thời gian để release một tính năng, thì rất có thể chúng ta sẽ mất nhiều thời gian hơn thế để sau này có thể tái cấu trúc và sửa lại. Hãy chắc chắn rằng các bên liên quan và ngay cả cấp trên của bạn nhận thức được rằng điều này sẽ làm chậm các tính năng khác ra mắt sau này.

Giải pháp: Hãy note vấn đề này lại thành các issue, ticket, hoặc viết document, để dễ dàng theo dõi và sau chúng ta có thể giải quyết nó mà không tốn nhiều thời gian xem lại vấn đề, và nó rất tốt cho việc nếu như có ai đó tiếp nhận lại công việc của bạn.

2. Vô tình nợ

Đây là vấn đề về kiến thức và kinh nghiệm. Trước khi thiết kế hay viết code chúng ta không thể lường trước được các case cũng như sự thay đổi trong business, nếu kiến thức và kinh nghiệm chưa đủ lớn thì chúng ta rất dễ dẫn tới việc hệ thống khó maintain và scale sau này. Đây thực sự là cái chúng ta thông cảm được, bởi nó nằm ngoài tầm kiểm soát của chúng ta.

Giải pháp: Không biết không có tội. Nhưng không học thì rất có tội. Vì vậy luôn luôn thực hành, tái cấu trúc và cập nhật các công nghệ mới nhất, hữu ích. Dành thời gian nhiều hơn để hiểu thiết kế(cả về business thì càng tốt) hệ thống chúng ta đang làm, cải thiện dần nó và dọn dẹp dần các spaghetti code trong codebase.

3. Nợ không cần trả

Có những cái nợ mà chúng ta không cần trả. Đó là ở những công ty khởi nghiệp trẻ, khi mà họ chấp nhận đánh đổi nợ ban đầu để đổi lấy việc release MVP sớm nhất có thể. Nhưng có đến 90% các công ty khởi nghiệp thất bại và khoản nợ sẽ không bao giờ cần phải trả nữa. (Friendster là điển hình của một điều ngược lại, họ chết không phải vì không có khách hàng, họ chết vì nợ kỹ thuật quá nhiều).

Giải pháp: Cái này thì không có giải pháp nào tốt hơn là đừng biến nó thành thói quen, hãy dành thời gian nên kế hoạch để tối ưu, làm cho những gì chúng ta viết ra trở nên tốt hơn mỗi ngày.

Bạn cần phải có chiến lược trước khi xác định nợ. Nếu mua nhà trả góp thì phải tính toán mỗi tháng trả bao nhiêu, bao lâu thì trả xong… thì kỹ thuật cũng sẽ tương tự, hãy xác định rằng nợ nên khi nào nó được trả. Nếu chúng ta ra mắt một tính năng với việc buộc phải thực hiện nợ kỹ thuật để khiến nó release nhanh hơn thì hãy cam kết rằng sau 1 tuần, sau khi đạt 10k user, … thì chúng ta sẽ trả nợ.

Nếu nợ không thể trả được ngay hoặc mất một thời gian dài để trả nó, thì chúng ta cần xin thêm thời gian hoặc báo cáo với cấp trên ưu tiên và dành thời gian để tái cấu trúc và để họ có chiến lược điều chỉnh kịp thời. Đừng để đến khi mọi thứ quá muộn và nó sẽ trở thành cơn ác mộng và nỗi ám ảnh kinh hoàng cho các lập trình viên.

Ở đâu đó có một câu như thế này, chúng ta chỉ được chọn 2 trong 3 thứ là: Tính năng, chất lượng và thời gian. Đó là vấn đề liên quan mật thiết đến nợ kỹ thuật.

“Hãy cố gắng đừng để vấn đề của bạn trở thành nỗi đau cho người đến sau. Có trách nhiệm và cẩn thận hơn với những gì mình đã làm ra. Đừng biến nợ kỹ thuật trở thành thói quen của bạn.”