Có "khoản nợ kỹ thuật" cụ thể không có giá trị phát sinh không?

Question

Có (ít nhất) hai cách mà các khoản nợ kỹ thuật được đưa vào dự án. Đầu tiên là bởi quyết định có ý thức. Một số vấn đề không đáng để giải quyết trước, vì vậy chúng được cho phép tích lũy như nợ kỹ thuật. Thứ hai là do sự thiếu hiểu biết. Những người làm việc trong dự án không biết hoặc không nhận ra rằng họ đang phát sinh nợ kỹ thuật. Câu hỏi này đề cập đến câu hỏi thứ hai. Có các khoản nợ kỹ thuật mà bạn cho vào dự án của bạn sẽ không đáng kể để tránh ("Nếu tôi chỉ biết ...") nhưng một khi chúng được nhúng vào dự án, chúng trở nên đắt hơn đáng kể?

Answer 1

Không bắt đầu dự án web bằng cách sử dụng khung công tác javascript và công cụ triển khai thực hiện thủ công đã có sẵn. Duy trì javascript viết tay đã trở thành đủ của một nỗi đau mà tôi đã kết thúc tách nó ra tất cả và làm lại nó với với khuôn khổ.

Answer 2

Một ví dụ về việc này đang chạy cơ sở dữ liệu ở chế độ không hỗ trợ Unicode. Nó hoạt động ngay cho đến thời điểm bạn buộc phải hỗ trợ các chuỗi Unicode trong cơ sở dữ liệu của bạn. Đường dẫn di chuyển là không tầm thường, tùy thuộc vào cơ sở dữ liệu của bạn. Ví dụ, SQL Server có độ dài hàng tối đa cố định theo byte, vì vậy khi bạn chuyển đổi các cột thành chuỗi Unicode (NCHAR, NVARCHAR, v.v.) có thể không đủ chỗ trong bảng để giữ dữ liệu mà bạn đã có. Bây giờ, mã di chuyển của bạn phải đưa ra quyết định về việc cắt bớt hoặc bạn phải thay đổi hoàn toàn bố cục bảng. Dù bằng cách nào, nó làm việc nhiều hơn là chỉ bắt đầu với tất cả các chuỗi Unicode.

Answer 3

Không có thiết kế cố kết phía trước có xu hướng dẫn đến nó. Bạn có thể vượt qua nó đến một mức độ nếu bạn dành thời gian để tái cấu trúc thường xuyên, nhưng hầu hết mọi người tiếp tục bashing đi ở một thiết kế tổng thể mà không phù hợp với yêu cầu thay đổi của họ. Đây có thể là câu trả lời chung chung hơn về những gì bạn đang tìm kiếm, nhưng có xu hướng là một trong những nguyên nhân phổ biến hơn của nợ kỹ thuật.

Answer 4

Tại công ty trước đây, họ đã sử dụng và buộc COM đối với những nội dung không cần thiết.

Một công ty khác có codebase C++ không cho phép STL. (WTF ?!)

Một dự án khác mà tôi đã sử dụng MFC chỉ dành cho các bộ sưu tập - Không có giao diện người dùng nào được tham gia. Điều đó thật tệ.

Phân nhánh tất nhiên cho những quyết định đó không tuyệt vời. Trong hai trường hợp, chúng tôi có sự phụ thuộc vào các công nghệ MS đáng thương mà không có lý do gì và những người khác buộc phải sử dụng các công cụ và bộ sưu tập đồ sộ.

Tôi phân loại chúng là "nợ" vì chúng tôi phải đưa ra quyết định và cân bằng sau này trong các dự án do các quyết định ngu ngốc lên phía trước. Hầu hết thời gian chúng tôi phải làm việc xung quanh những thiếu sót.

Answer 5

Trong khi không phải ai cũng có thể đồng ý, tôi nghĩ rằng người đóng góp lớn nhất cho nợ kỹ thuật bắt đầu từ giao diện của bất kỳ loại ứng dụng nào và làm việc trong ngăn xếp. Tôi đã tìm hiểu rằng có ít cơ hội sai lệch hơn so với mục tiêu dự án bằng cách thực hiện kết hợp TDD và DDD, bởi vì bạn vẫn có thể phát triển và thử nghiệm chức năng lõi với giao diện trở thành đóng băng.

Được cấp, nó không phải là một khoản nợ kỹ thuật, nhưng tôi thấy rằng phát triển từ trên xuống là một cánh cửa mở đang mời các quyết định không được suy nghĩ tốt - tất cả vì mục đích làm điều gì đó "trông thật tuyệt". Ngoài ra, tôi hiểu rằng không phải ai cũng đồng ý hoặc cảm thấy như vậy về nó, vì vậy số dặm của bạn có thể thay đổi theo cách này. Động lực và kỹ năng của đội cũng là một phần của phương trình này.

Answer 6

Bỏ qua hoàn toàn các sự cố bảo mật.

Tạo kịch bản lệnh chéo trang là một ví dụ như vậy. Nó được coi là vô hại cho đến khi bạn nhận được alert('hello there!') bật lên trong giao diện quản trị (nếu bạn may mắn - tập lệnh cũng có thể sao chép âm thầm tất cả quản trị viên dữ liệu có quyền truy cập hoặc phân phát phần mềm độc hại cho khách hàng của bạn).

Và sau đó bạn cần 500 mẫu cố định hôm qua. Sửa lỗi vội vàng sẽ khiến dữ liệu bị thoát kép và sẽ không cắm tất cả các lỗ hổng.

Answer 7

tôi thực sự đấu tranh với thế này, cố gắng để cân bằng YAGNI so với "Tôi đã bị đốt cháy trên này một lần quá thường xuyên"

danh sách của tôi về những điều tôi xem xét trên mọi ứng dụng:

1. Localization:
   2. Là múi giờ bao giờ sẽ trở nên quan trọng? Nếu có, tồn tại ngày/giờ trong UTC.
   3. Thư/văn bản có được bản địa hóa không? Nếu có, hãy gửi thư từ bên ngoài.
2. Độc lập nền tảng? Chọn triển khai dễ dàng được chuyển.

Các khu vực khác nơi nợ kỹ thuật có thể được phát sinh bao gồm:

• đen Lỗ Thu thập dữ liệu: Tất cả mọi thứ đi vào, không có gì bao giờ đi ra ngoài. (Không có kế hoạch dài hạn để lưu trữ/xóa dữ liệu cũ)
• Không giữ MVC hoặc tầng tách biệt một cách rõ ràng trong suốt thời gian ứng dụng - ví dụ, cho phép quá nhiều logic để leo vào Chế độ xem, thêm giao diện cho thiết bị di động hoặc dịch vụ web tốn kém hơn nhiều.

tôi chắc chắn rằng sẽ có những người khác ...

Answer 8

lưu trữ ngày tháng trong một cơ sở dữ liệu trong múi giờ địa phương. Tại một số thời điểm, ứng dụng của bạn sẽ được di chuyển sang múi giờ khác và bạn sẽ gặp sự cố. Nếu bạn kết thúc với những ngày hỗn hợp, bạn sẽ không bao giờ có thể gỡ rối chúng. Chỉ cần lưu trữ chúng trong UTC.

Answer 9

Khả năng mở rộng - trong các ứng dụng kinh doanh theo hướng dữ liệu cụ thể. Tôi đã nhìn thấy nhiều hơn một lần mà tất cả dường như chạy tốt, nhưng khi môi trường UAT cuối cùng được đứng lên với kích thước bảng cơ sở dữ liệu tiếp cận sản xuất, sau đó mọi thứ bắt đầu rơi xuống bên phải và trái. Thật dễ dàng cho một chương trình hàng loạt hoặc màn hình trực tuyến chạy khi db về cơ bản là giữ tất cả các hàng trong bộ nhớ.

Answer 10

Kiểm tra đơn vị - Tôi nghĩ rằng không viết các bài kiểm tra khi bạn phát sinh một khoản nợ khổng lồ khó bù đắp. Mặc dù tôi là một fan hâm mộ của TDD, tôi không thực sự quan tâm nếu bạn viết thử nghiệm của bạn trước hoặc sau khi bạn thực hiện mã ... chỉ miễn là bạn giữ cho các bài kiểm tra của bạn được đồng bộ hóa với mã của bạn.

Answer 11

Các cliche là sớm tối ưu hóa là gốc rễ của mọi tội lỗi, và điều này chắc chắn là đúng đối với vi -optimization. Tuy nhiên, hoàn toàn bỏ qua hiệu suất ở một mức thiết kế trong một khu vực mà nó rõ ràng sẽ là vấn đề có thể là một ý tưởng tồi.