Là lỗi một phần của nợ kỹ thuật?

Scrum Master của chúng tôi liên tục coi các lỗi là nợ kỹ thuật. Anh ấy có đúng không, những con bọ được coi là nợ kỹ thuật trong thế giới của Agile?

Tôi nghĩ rằng câu trả lời ở đây khá đơn giản - đặc điểm chính của nợ kỹ thuật là thứ gì đó chúng ta phải gánh chịu bởi sự lựa chọn.

Chúng tôi chọn đưa ra các quyết định về kiến ​​trúc, thiết kế hoặc triển khai mà chúng tôi mong đợi sẽ gây ra các vấn đề cho chúng tôi sau này để đạt được các mục tiêu cụ thể sớm hơn.

Một lỗi không phải là thứ chúng tôi chọn có trong mã của mình - vì vậy thực tế nó không phải là nợ kỹ thuật.

Tất nhiên người ta có thể đưa ra tất cả các loại tranh luận thú vị (và có thể hợp lệ) về các lựa chọn được phát hiện qua bài viết nhưng về cơ bản (và đặc biệt là trong bối cảnh của câu hỏi) không, lỗi không phải là nợ kỹ thuật - nghe có vẻ giống như lạm dụng trò chơi bingo buzzword đối với tôi.

Như một phần tái bút - Tôi không đồng ý với khẳng định rằng một khoản nợ kỹ thuật nhất định sẽ dẫn đến các lỗi trong chính nó vì điều đó dẫn đến nhiều giả định về bản chất của các lựa chọn được đưa ra. Ví dụ, bạn có thể có mã được viết tốt, có cấu trúc tốt, kiểm tra mã được bảo hiểm mà vẫn thực hiện - nói - thỏa hiệp kiến ​​trúc để giao hàng sớm. Tương tự như vậy, bạn có thể chọn không tự động hóa các quy trình triển khai của mình, điều này sẽ không dẫn đến lỗi nhưng có thể sẽ dẫn đến rất nhiều căng thẳng và đau đớn. Tất nhiên, nếu khoản nợ là bạn đã viết mã không RẮN (hoặc bất cứ điều gì) thì có ... nhưng điều đó không có nghĩa là luôn luôn như vậy.

Đúng.

Nợ kỹ thuật (còn được gọi là nợ thiết kế hoặc nợ mã) là một phép ẩn dụ thần kinh đề cập đến hậu quả cuối cùng của việc phát triển phần mềm và kiến ​​trúc phần mềm kém phát triển trong một cơ sở mã.

Nguồn: Wikipedia

Đọc nợ kỹ thuật như một điều gì đó bạn có thể tránh được bằng cách có một quy trình công việc tốt hơn (ví dụ: thực hiện kiến ​​trúc đúng cách trước khi chuyển sang mã hóa, làm TDD, v.v.), thực hành mã hóa tốt hơn, v.v.

Hầu hết các lỗi có thể tránh được bằng cách xem xét bổ sung hoặc sử dụng các phương pháp chính thức hơn. Bằng cách không làm mọi thứ bạn có thể để không gặp lỗi ngay từ đầu, bạn hạ thấp chi phí trước mắt / ngắn hạn của dự án, nhưng làm tăng nợ kỹ thuật.

Sau khi đọc câu trả lời của BЈовић , tôi thấy rằng nó có thể không dễ dàng như tôi nghĩ.

• Ví dụ: lỗi có phải là một phần của nợ kỹ thuật không? Bài viết tuyên bố rằng chỉ những lỗi bạn biết nhưng quyết định không sửa là một phần của nợ kỹ thuật.

• Một ví dụ khác, Suy nghĩ về Nợ kỹ thuật của Christopher đủ điều kiện các lỗi là kết quả của nợ kỹ thuật, không phải là một phần của nó. Điều này đang được nói, nhiều kết quả được liệt kê, như "chi phí để thực hiện tính năng mới", bị ảnh hưởng bởi số lượng lỗi.

• Cuối cùng, khi tạo mô hình nợ kỹ thuật ABCDE-T , tôi đã bao gồm các lỗi là một trong sáu yếu tố, nhưng chúng được xem xét khác nhau. Trọng tâm không phải là bản thân các lỗi, mà là các cách chúng được thu thập, ưu tiên và giải quyết. Bản thân lỗi xuất hiện là kết quả của nợ kỹ thuật (như trong ví dụ trước), nhưng không bao giờ xuất hiện như một yếu tố của nợ kỹ thuật.

Điều này đang được nói, tôi vẫn có xu hướng trả lời rằng các lỗi buganyany là một phần của nợ kỹ thuật.

Đối số đầu tiên:

Đọc trích dẫn của Jeff Atwood, hầu hết các lỗi sẽ đủ điều kiện là:

nỗ lực thêm mà chúng ta phải làm trong sự phát triển trong tương lai vì sự lựa chọn thiết kế nhanh và bẩn

Trong các ứng dụng kinh doanh, gần như mọi lỗi đều xuất phát từ sự lựa chọn thiết kế nhanh và bẩn hoặc thực tiễn xấu (đó là thiếu kiểm thử, việc sử dụng các công nghệ mà các nhà phát triển không biết đủ, thiếu giao tiếp, thiếu hiểu biết về tên miền, v.v.) Điều này có nghĩa là "bằng cách tái cấu trúc thiết kế nhanh và bẩn thành thiết kế tốt hơn" và bằng cách điều chỉnh các thực tiễn tốt hơn, các doanh nghiệp có thể giải quyết hầu hết các lỗi của họ.

Đối số thứ hai:

Nếu chúng ta thực hiện song song giữa khoản nợ thông thường của một công ty, điều quan trọng cần tính đến khi công ty được bán cho công ty khác và khoản nợ kỹ thuật, điều quan trọng không kém là phải tính đến khi dự án được bán cho công ty khác hoặc được đưa ra đến một nhóm khác, chúng ta có thể dễ dàng thấy rằng các lỗi là một phần của nợ kỹ thuật, vì nhóm mới sẽ:

• Phải xử lý các lỗi đó trước khi tạo các tính năng mới (điểm 5 của Joel Test: Bạn có sửa lỗi trước khi viết mã mới không?)

• Hoặc giữ các lỗi, bảo quản / tăng theo cách này các khoản nợ kỹ thuật.

Jeff Atwood trong bài viết Trả nợ kỹ thuật của bạn đưa ra câu trả lời khá hay về nợ kỹ thuật là gì:

các khoản nợ kỹ thuật phát sinh các khoản thanh toán lãi, dưới dạng nỗ lực thêm mà chúng ta phải làm trong sự phát triển trong tương lai vì sự lựa chọn thiết kế nhanh chóng và bẩn thỉu. Chúng tôi có thể chọn tiếp tục trả lãi, hoặc chúng tôi có thể trả hết tiền gốc bằng cách tái cấu trúc thiết kế nhanh và bẩn thành thiết kế tốt hơn. Mặc dù chi phí để trả hết tiền gốc, chúng tôi có được bằng cách giảm các khoản thanh toán lãi trong tương lai.

Nói đúng ra, lỗi không phải là một phần của nợ kỹ thuật, nếu chúng không làm chậm quá trình phát triển phần mềm hơn nữa (thay đổi mọi thứ, thêm các tính năng mới, v.v.). Chúng là lỗi phần mềm.

Tuy nhiên, khi quá tốn kém để sửa một lỗi, hoặc nó buộc bạn phải làm việc xung quanh nó (và đưa ra các khoản nợ kỹ thuật thậm chí nhiều hơn), thì nó trở thành một phần của nợ kỹ thuật.

Một lỗi không phải là nợ kỹ thuật. Nợ kỹ thuật đang lướt qua chất lượng, không phải là không có nó. Phần mềm không nên được cung cấp với các lỗi trong đó ngay từ đầu. Bạn biết đấy, toàn bộ phần mềm làm việc trên tài liệu toàn diện.

Người phạm tội lớn nhất của nợ kỹ thuật là "sửa lỗi tạm thời", bạn biết những gì bạn đưa vào để vượt qua bài kiểm tra và nhận câu chuyện được chấp nhận Những điều mà bạn đã tự hứa với mình, bạn sẽ tái cấu trúc sau đó, nhưng sau đó không bao giờ thực hiện. Khi các bản sửa lỗi tạm thời, các bản vá và các thứ khác tích lũy, mã trở nên lộn xộn không cần thiết, khó cập nhật và kiểm tra và nói chung là một cơn ác mộng, nhưng nó vẫn hoạt động.

Để hỗ trợ cho ý kiến ​​này, tôi đã đi thẳng đến nguồn, Ward Castyham. Về điều này, Ward đã thực hiện một cuộc phỏng vấn tốt một thời gian trước với Capers Jones, nó đáng để xem.

Tranh luận về nợ kỹ thuật, với Ward Castyham & Capers Jones

Một bài viết khác đáng đọc là của Martin Fowler

Martin Fowler về nợ kỹ thuật

Trong bài viết của Martin, vui lòng tìm liên kết đến đề cập ban đầu về nợ kỹ thuật của Ward Castyham, từ OOPSLA92:

Hệ thống quản lý danh mục đầu tư WyCash

Một trích dẫn từ bài viết trên:

Mặc dù mã chưa trưởng thành có thể hoạt động tốt và được khách hàng hoàn toàn chấp nhận , nhưng số lượng vượt quá sẽ khiến chương trình không thể quản lý được, dẫn đến sự chuyên môn hóa cao của các lập trình viên và cuối cùng là một sản phẩm không linh hoạt. Vận chuyển mã lần đầu tiên giống như đi vào nợ nần.

Cuối cùng, Nợ kỹ thuật có thể đã bao gồm các lỗi đối với một số người và tôi đoán điều đó tốt. Tôi chỉ không nghĩ rằng đó là ý định ban đầu.

Nói đúng ra, câu trả lời cho câu hỏi của bạn là Không.

Nợ kỹ thuật có thể (và có thể sẽ) dẫn đến lỗi, nhưng kết luận rằng bất kỳ lỗi nào là kết quả của nợ kỹ thuật đang đặt ra một cách giải thích giữa hai sự thật: có lỗi và có nợ kỹ thuật (giả sử có thể kết luận là thực tế).

Nếu Scrum Master của bạn tuyên bố 'như một lý thuyết' rằng các lỗi là kết quả của nợ kỹ thuật, thì anh ta sẽ cắt giảm. Nếu anh ta nói điều này về các lỗi cụ thể cứ xuất hiện lại thì anh ta có thể đúng - chúng ta không thể thấy chất lượng mã từ đây ;-)

Anh ta cũng có thể có một khiếu nại liên tục về việc mọi người không nghe anh ta về các khoản nợ kỹ thuật, và do đó gắn nhãn mọi lỗi là nợ kỹ thuật, nhưng bây giờ tôi đang suy đoán.

Theo tôi, thực sự không có vấn đề gì nếu bạn nói rằng lỗi là một phần của nợ kỹ thuật ... hay không.

Một thực tế rõ ràng là các lỗi hiện tại đại diện cho công việc bổ sung có thể cần phải được thực hiện trong tương lai, để khắc phục chúng hoặc để khắc phục chúng.

Nợ kỹ thuật (như nhãn thường được sử dụng) cũng thể hiện công việc làm thêm có thể cần phải được thực hiện trong tương lai ... bằng cách này hay cách khác.

Vì vậy, cho dù bạn nói lỗi đã biết (hoặc chưa biết) là nợ kỹ thuật ... hay không ... thực sự chỉ là vấn đề định nghĩa. Và vì không có thẩm quyền định nghĩa ¹ của "nợ kỹ thuật", toàn bộ cuộc thảo luận là loại vô nghĩa.

Như Lewis Carroll đã viết:

'Khi tôi sử dụng một từ,' Humpty Dumpty nói, với giọng điệu khinh bỉ, 'nó có nghĩa là những gì tôi chọn nó có nghĩa - không hơn không kém.' .

Đó thực sự là cách ngôn ngữ tự nhiên hoạt động. Từ có nghĩa là những gì mọi người nghĩ rằng họ có nghĩa. Định nghĩa từ điển và vv chỉ đơn thuần là tài liệu về cách các từ được sử dụng, và chúng không nhất thiết là tài liệu chính xác. Nếu Scrum Master của bạn muốn coi các lỗi đã biết là nợ kỹ thuật, ai sẽ nói rằng anh ta "sai"?

^{1 - Trích dẫn những người như Ward Cummingham và Caper Jones cũng không giúp được gì. Tốt nhất nó cho chúng ta biết ý nghĩa của chúng (hoặc có nghĩa) khi họ sử dụng (sử dụng) cụm từ. Họ không "sở hữu" cụm từ. Mặc dù họ chắc chắn là chính quyền về các vấn đề này, đây vẫn chỉ là ý kiến ​​của họ.}