Nợ code (technical debt)
Đây là món nợ rất xấu nếu code quá nhiều tiềm ẩn rủi ro, tương tự như nợ xấu ngân hàng. Nếu nợ code quá lớn đến mức các kỹ sư khác không thể bảo trì nổi, rốt cuộc phải đập đi làm lại, thì hậu quả vô cùng khủng khiếp tương tự như sự sụp đổ của một hệ thống ngân hàng. Có thể nói nợ code là hậu quả của chiến thuật "tiền trảm hậu tấu" mà các developer sử dụng để pass qua Test Case, đáp ứng yêu cầu hiện tại của khách hàng. Nhưng khi go-live sẽ phát sinh vô số vấn đề "bóng ma" đằng sau hàng triệu dòng code tưởng như sạch sẽ (cleanup).
Nợ kĩ thuật được hình thành như thế nào? Nó tồn tại như thế nào trong một dự án công nghệ?
Xuyên suốt quá trình phát triển dự án, mọi quyết định kĩ thuật đều đi kèm "một món nợ kĩ thuật" nhất định.
Với các dự án dù là công nghệ hay bất kì lĩnh vực nào thì cũng cần phải có hạn chót (deadline) cho mọi công việc. Deadline sẽ giúp đảm bảo dự án phát triển ổn định, đúng thời hạn và còn đảm bảo sự phối hợp tốt nhất giữa những thành viên trong dự án. Tuy nhiên, đôi khi những deadline được đặt ra không hoàn toàn phù hợp với khối lượng thời gian cần bỏ ra để hoàn thành một công việc cụ thể. Do đó, những lập trình viên sẽ phải có những thỏa hiệp nhất định, với bản thân và cả với đội công nghệ. Họ sẽ phải chấp nhận dùng những "giải pháp tạm thời" để cho ra sản phẩm "chạy được và ổn định" trong thời gian ngắn nhất và sau đó sẽ dành thời gian để cải tiến, nâng cấp thành những giải pháp hiệu quả, có thể tồn tại lâu dài hơn. Đây là cách mà nợ kĩ thuật "hình thành và tích lũy".
Làm gì để trả nợ?
Có nhiều người khi được hỏi trên các diễn đàn, tạp chí… thường đưa ra câu trả lời giống nhau với cách xử lý khá “hàn lâm” như: dừng việc phát triển, ngồi lại để refactory code…
Thực tế thì cách làm đó tuy đúng nhưng hiệu quả hay không còn tùy vào thợ code. Thợ code được yêu cầu dành cả ngày chỉ để refactor code và tối ưu performance quả thực là một cực hình. Quản lý là một nghệ thuật. Hãy dùng nghệ thuật để bắt nhịp các thành viên, tạo cảm hứng làm việc, động viên tinh thần bằng cách vạch ra mục tiêu càng cụ thể càng tốt …
Biện pháp trả nợ cần phải được “lồng” vào một nhiệm vụ nào đó nhưng đầy ý nghĩa, làm sao để hút các thành viên vào những công việc ít thú vị này, khiến họ mê mệt không kém gì niềm vui được code. Thí dụ tình huống số 1: thợ A mong muốn nâng cấp UI/UX, hãy giao nhiệm vụ “kép” cho A: Vừa nghiên cứu nâng cấp UI/UX vừa tối ưu lại code front-end. Tình huống số 2: tính năng “Danh mục sản phẩm” sắp đến giao đoạn nâng cấp, bảo trì, trong đó bổ sung các tiện ích “Tìm kiếm”, “Tạo truy cập nhanh (bookmark)”…, thợ B được giao nhiệm vụ quan trọng này. Trong 1 tuần chờ đợi phân tích và lên thiết kế mockup cho các tiện ích, B được yêu cầu xử lý làm mịn lại code, tối ưu performance trước khi thiết kế chức năng tìm kiếm… Tình huống số 3: Sử dụng các “khoảng thời gian im lặng” 4 tiếng mỗi tuần để lên kế hoạch trả nợ.
Hãy nhớ rằng trong lúc trả nợ, thợ sẽ vô tình tìm ra các lỗ hổng kỹ thuật. Trong cái khó sẽ ló cái khôn.
Muốn đi nhanh, hãy đi một mình. Muốn đi xa hơn, hãy đi cùng nhau.
Tổng hợp từ Internet
TIGO Solutions
