Cận cảnh về Technical debt
Technical debt case studies
Câu chuyện 1: Năm 2013, khi launching Visual Studio 2013 và dịch vụ Visual Studio Online, Microsoft đã gặp sự cố 7 tiếng out of service. Triệu chứng lúc đó quan sát được là service không thể handle được hàng triệu người dùng với lý do vô cùng bất ngờ: service chỉ được scale duy nhất trên 1 đơn vị. Sâu xa về mặt kĩ thuật hơn đó là do các service khi được triển khai đã quên mất việc liên lạc với nhau qua IP port.
Câu chuyện 2: Năm 2015, Reddit gặp vụ scandal lớn khi mà các engineer muốn triển khai các bot kiểm duyệt bài tự động nhưng hệ thống với các vấn đề kĩ thuật hiện có, đã không thể chạy mượt mà được và hậu quả là đã bị sót rất nhiều bài viết.
Cả 2 câu chuyện trên đều xoay quanh một chủ đề duy nhất, một nguyên nhân duy nhất, đó là Technical debt.
Technical debt là gì?
Theo khái niệm mà Ward Cunningham đưa ra khi phát triển phiên bản wiki đầu tiên thì Technical debt là hiện tượng phải tiêu tốn nhiều công sức phát triển phần mềm sau khi đã áp dụng các kĩ thuật đơn giản để thực thi thay vì áp dụng giải pháp tốt nhất.
Tình huống dễ phát sinh technical debt mà các engineer hay gặp như sau: Trước mắt bạn có 2 giải pháp: một dễ làm & nhanh nhưng chắc chắn sẽ có vấn đề trong tương lai mà bạn phải giải quyết; và một giải pháp hoàn hảo nhưng mất thời gian và bạn chọn giải pháp đầu tiên. Đó chính là thời điểm technical debt xuất hiện. Nó cũng giống như khoản tín dụng bạn vay để chi trả cho món hàng bạn muốn mua ngay tại thời điểm đó và trong tương lai, bạn phải trả lại khoản tín dụng đó nếu không muốn một ngày nào đó sẽ phải phá sản.
Nguyên nhân chính gây Technical debt
Trong quá trình phát triển phần mềm, technical debt là điều không thể tránh khỏi, chủ yếu do các nguyên nhân chính sau:
- Không tôn trọng ưu tiên theo kế hoạch
- Phạm vi thay đổi trong iteration (requirement, domain …)
- Độ seniority của engineering team thấp
- Thiếu document
- Kiến trúc không hiệu quả
…
Hậu quả của Technical debt
Vấn đề lớn nhất của các khoản nợ đó là thời gian và technical debt cũng không phải ngoại lệ.
Nếu không có các hành động thích ứng để giải quyết technical debt, hiển nhiên nó sẽ làm chậm tốc độ phát triển phần mềm, dẫn tới giảm chất lượng sản phẩm, giảm khả năng mở rộng theo thời gian của sản phẩm, giảm động lực và tinh thần của engineer. Việc này cũng giống như các khoản nợ khi không được trả đúng hạn, ta phải chịu thêm lãi suất, cộng với các khoản nợ trước, tới một lúc nào đó sẽ vượt quá khả năng chi trả, cuộc sống trở nên khó khăn hơn và viễn cảnh tay trắng là điều không tránh khỏi.
Các tips tránh Technical debt
Các engineer không thể lường trước được những thay đổi công nghệ trong 10 năm tiếp theo, nhưng ít nhất nếu tuân thủ các lời khuyên dưới đây, bạn sẽ tự mình giảm thiểu tối đa technical debt:
- Viết automated test script: đảm bảo feedback về lỗi tới engineer là nhanh nhất để xử lý
- Refactor quyết liệt: giữ code luôn clean ngay khi có cơ hội
- Xử lý bug ở chế độ đèn đỏ: luôn coi bugs là kẻ thù số một của mình, ám ảnh để xử lý ở mức ưu tiên cao nhất
- Kiểm soát deadline: khách hàng luôn vội vàng, nếu engineer thoả hiệp, tức là bạn đã tạo cơ hội để technical debt xuất hiện, gây khó cho chính mình ở thì tương lai. Hãy làm tốt khâu ET để đảm bảo cân bằng yếu tố tính năng và kĩ thuật ở mức tốt nhất.
- Chú trọng vào việc monitoring production: Phòng hơn chống. Việc monitoring hiện quả giúp engineer sớm phát hiện vấn đề và có giải pháp phù hợp.
- Xây dựng với tư tưởng luôn cải tiến: Hãy giữ mọi thứ SOLID và đơn giản, module hoá nó để dễ mở rộng, thay đổi, tái sử dụng sau này.
- Xây dựng với tư tưởng thử nghiệm trước khi release: Luôn áp dụng A/B testing một cách liên tục để biết được model nào đáng để đầu tư code để scale.
- Áp dụng CI/CD: tích hợp liên tục, kết hợp với automation testing giúp engineer phát hiện vấn đề sớm, xử lý kịp thời và có sản phẩm chất lượng tốt.
- Pair programming: hai engineer trình độ tương đồng cùng develop sẽ giúp quá trình review gần như ngay lập tức, giúp phát hiện vấn đề từ ngay khi chưa submit.
Tổng kết
Technical debt là yếu tố luôn song hành trong các sản phẩm phần mềm, đặc biệt là đối với các startup. Vấn đề lớn nhất của các khoản nợ là nó có đáng để nợ. Trong trường hợp của startup thì cần xem xét yếu tố gì có giá trị còn lớn hơn khoản nợ (yếu tố cơ hội, yếu tố sống còn …) để xem có sẵn sàng chấp nhận technical debt. Đó là lý do vì sao đôi khi Technical debt không hẳn là xấu. Nhưng hãy nhớ một khi đã có technical debt thì sớm hay muộn, bạn-một engineer, cũng phải giải quyết và càng sớm càng tốt.
— — — — — —
Tham khảo:
