Nợ công nghệ

Jan 05 2023

Nợ công nghệ là gì? Các khoản nợ kỹ thuật là những điểm triển khai kỹ thuật đã biết mà người ta có thể đã chọn một cách có ý thức để không triển khai ngay bây giờ. Các khoản nợ công nghệ là điều thường xảy ra nhưng phải được suy nghĩ thấu đáo.

Nợ công nghệ là gì?

Các khoản nợ kỹ thuật là những điểm triển khai kỹ thuật đã biết mà người ta có thể đã chọn một cách có ý thức để không triển khai ngay bây giờ. Các khoản nợ công nghệ là điều thường xảy ra nhưng phải được suy nghĩ thấu đáo. Chúng tôi sẽ trình bày một số hướng dẫn về thời điểm/cách đánh giá chúng.

Lý tưởng nhất là bất kỳ đoạn mã nào — trong lần triển khai đầu tiên phải xử lý tất cả các trường hợp đã biết. Tuy nhiên, có thể có các trình chặn đối với nó:

Đối với một số trường hợp, hy vọng là không phổ biến — chức năng của sản phẩm hoặc logic kỹ thuật có thể không rõ ràng. Đây cũng có thể là yêu cầu về quy mô hoặc lưu lượng truy cập không rõ ràng, dẫn đến nguy cơ thiếu hoặc chuẩn bị quá mức cho lưu lượng & quy mô.
Ngay cả khi việc triển khai rõ ràng đối với các trường hợp sử dụng không phổ biến, việc triển khai có thể phức tạp hoặc tốn thời gian.

Lý tưởng nhất là tất cả chúng ta đều muốn giảm thiểu các khoản nợ công nghệ, nhưng đôi khi chúng ta nên thực hiện chúng.

Sự cần thiết phải tiến lên phía trước

Mặc dù không có tất cả các chi tiết hoặc việc triển khai đầy đủ có thể gây ảnh hưởng xấu, nhưng thường thì người ta phải tiếp tục vì một số lý do sau:

Thông thường, người ta phải xây dựng hoặc triển khai một thứ gì đó để trả lời các câu hỏi khác, tận dụng một phần phản hồi từ việc sử dụng hoặc khách hàng. Phối màu có thể dẫn đến sự chậm trễ gây tốn kém và việc mạo hiểm triển khai không hoàn hảo còn hơn không.
Sự thiếu rõ ràng cụ thể có thể tương đối không đáng kể trong sơ đồ rộng hơn của chức năng được xây dựng, có thể được thêm vào hoặc sửa chữa dễ dàng và việc không triển khai chức năng có thể tốn kém hơn.

phẩm chất

Khi chúng tôi nhận một khoản nợ công nghệ, chúng tôi đã quyết định có ý thức đánh đổi việc triển khai có lẽ đúng đắn hơn với việc triển khai một phần. Một khoản nợ công nghệ tốt mặc dù:

Khi khoản nợ công nghệ được giải quyết, ít gây ra sự xáo trộn mã hơn đối với mã của triển khai hiện được chọn và
Dẫn đến lỗi một số phần không phổ biến của chức năng. Ngược lại, khi đã sửa — đó là một cải tiến gia tăng của tính năng.

Người ta chỉ phải nhận các khoản nợ công nghệ tốt đáp ứng các phẩm chất trên. Các câu hỏi sau đây giúp chúng tôi đánh giá.

Trị giá

Một số câu hỏi cần đặt ra khi đánh giá chi phí của khoản nợ công nghệ hoặc trường hợp bị bỏ lỡ:

Chức năng bị bỏ sót ở đâu - ví dụ: trong trực quan hóa/trình bày dữ liệu hoặc tạo dữ liệu? Cụ thể hơn, chức năng bị bỏ lỡ có dẫn đến dữ liệu không chính xác vĩnh viễn không?
Nhược điểm của trải nghiệm người dùng là gì? Đây có phải là một trường hợp sử dụng phổ biến mà người dùng có thể gặp khó khăn và không hài lòng hay một trường hợp không phổ biến nằm ngoài đề xuất giá trị cốt lõi của chúng tôi?
Chúng ta có chắc chắn về các chi tiết của thiết kế và triển khai chức năng bị thiếu hoặc bị bỏ qua không? Hay chúng tôi muốn có phản hồi về việc triển khai một phần để xác định nó?

Chúng tôi nhận các khoản nợ công nghệ vì những lợi ích nhất định:

Phát hành nhanh hơn, có khả năng dẫn đến tăng doanh số bán hàng hoặc sự hài lòng của khách hàng.
Khả năng nhận được dữ liệu hoặc phản hồi về việc áp dụng, có thể dẫn đến một thiết kế tốt hơn cho chức năng còn thiếu. Đối với một số chức năng không rõ ràng, điều này có thể cần thiết.
Chi phí cơ hội của nỗ lực kỹ thuật được tiết kiệm trong thời gian ngắn.

Việc tuân theo các nguyên tắc cơ bản cơ bản của thiết kế mạnh mẽ sẽ giảm thiểu việc làm lại để giải quyết nợ công nghệ.

tính mô đun

Đảm bảo các dịch vụ & đối tượng được cân nhắc kỹ lưỡng với các giao diện được xác định rõ ràng. Tính mô đun cho phép các thay đổi được bản địa hóa mà không giảm thiểu dấu chân làm lại mã.

Cố gắng nghĩ xa hơn trước mắt, vd

Nếu hiện tại chúng ta có một triển khai chức năng nhưng sau này có lẽ chúng ta có thể đặt triển khai đó như một lớp con của một giao diện. Điều này giúp giảm bớt việc thêm nhiều triển khai sau này.
Nếu một thực thể hiện có một giá trị có thể có cho trường nhưng sau này có thể có nhiều giá trị hơn, hãy biến giá trị đó thành một enum.

Lược đồ sạch

Một lược đồ cơ sở dữ liệu tốt & mô hình ORM mô hình chặt chẽ trường hợp sử dụng thực tế thường mạnh mẽ để thay đổi thêm.

Thực hành mã hóa tốt

Giữ các giá trị có thể được điều chỉnh KHÔ & không đi sâu vào mã. Chúng có thể là biến cấu hình đầu vào thời gian chạy hoặc hằng số mã. Đây phải là một quyết định có ý thức.
Một số chức năng cần khả năng lặp lại nhanh chóng hoặc tùy chỉnh cho mỗi khách hàng. Sử dụng các công cụ mã thấp / không có mã, chúng rất dễ lặp lại — ngay cả đối với một người không phải là kỹ sư. Và có ít mã hơn và do đó ít bị xáo trộn hơn.
Áp dụng các thực tiễn thiết kế và mã hóa chung được đề cập ở trên — tức là giữ mã KHÔ (dễ dàng thay đổi mã ở một nơi), giữ cho mã đơn giản (do đó dễ hiểu hơn để thay đổi), v.v.
Một số thay đổi sẽ được bổ sung — theo nghĩa đen được xây dựng dựa trên hiện trạng — ví dụ: thêm các bộ bản sao vào máy chủ cơ sở dữ liệu mongo nút đơn hiện có hoặc phân mảnh cho máy chủ cơ sở dữ liệu mongo. Nếu những điều này tốn kém để triển khai, thì nhu cầu về những cải tiến như vậy có thể được đẩy xuống xa hơn theo dòng thời gian cho đến khi cần thiết mà không cần bất kỳ nỗ lực bổ sung nào.

Không xử lý tất cả các trường hợp không phải là lý do đủ chính đáng để kiểm tra mã. Thay vào đó, dưới đây là một cách để tiến lên phía trước: