Bài viết này về nợ kỹ thuật có một số điểm tốt, bao gồm:

Làm việc trên "các vấn đề kỹ thuật" hoạt động tốt nhất khi nó được điều khiển bởi các câu chuyện. Cơ sở mã có thể cần làm việc ở mọi nơi, nhưng tiền chi trả sẽ chỉ được nhận khi mã sẽ được xử lý vì lý do đối mặt với người dùng. Nếu không có câu chuyện nào sẽ đi qua một khu vực tồi tàn, làm việc trên đó phần lớn là lãng phí.

Do đó, tôi thích cách tiếp cận các câu chuyện như bình thường (nhưng có lẽ ít hơn trong số đó) và tuân theo "quy tắc trinh sát của cậu bé" rời khỏi khu cắm trại tốt hơn bạn tìm thấy. Nói cách khác, bất cứ nơi nào câu chuyện dẫn chúng ta, hãy viết nhiều bài kiểm tra hơn, hãy tái cấu trúc mạnh mẽ hơn.

Cách tiếp cận này có ít nhất những ưu điểm sau:

• duy trì dòng chảy "hợp lý nhất" của câu chuyện;
• cung cấp trợ giúp từ tất cả các tài năng nhóm;
• quy định cho cả nhóm học cách giữ mã sạch;
• tập trung cải thiện chính xác nơi cần thiết;
• không lãng phí cải thiện mà "có thể" cần thiết;

Tôi đã thấy chất lượng mã có ảnh hưởng rất lớn đến năng suất dài hạn, vì vậy tôi tin rằng nợ kỹ thuật nên được quan tâm. Tôi nghĩ rằng bài viết trên có ý nghĩa, nhưng tôi không chắc chắn về hai điểm cuối cùng. Tôi quan tâm đến việc tìm hiểu những trải nghiệm thực tế về lợi ích từ việc xóa nợ kỹ thuật, ngay cả khi nó không liên quan đến câu chuyện của người dùng.

Những lợi ích tích cực nào bạn đã thấy từ việc làm sạch cơ sở mã của mình và loại bỏ nợ kỹ thuật? Những phương pháp bạn đã sử dụng để hoàn thành công việc?

Tôi có thể cho bạn một ví dụ từ kinh nghiệm của tôi.

Khoảng 10 hoặc 12 năm trước, tôi đã thừa hưởng một ứng dụng từ một nhóm các nhà phát triển cuối cùng đã rời khỏi công ty (quá lâu để vào đây ...). Hệ thống này là một hệ thống tạo báo cáo phần mềm trung gian lớn được trồng tại nhà. Nó chạy mỗi đêm mỗi tuần và tạo ra khoảng 2 tá báo cáo Excel cho các giám đốc điều hành cấp cao của một công ty Fortune 500. Khi tôi thừa hưởng nó, phải mất khoảng 5-6 giờ để chạy và trong bất kỳ tuần nào cũng sẽ thất bại ít nhất 2 đêm.

Tôi không phải là một người cắm trại hạnh phúc khi được đưa ra mớ hỗn độn này.

Ban đầu kế hoạch của tôi chỉ là cầm máu và khắc phục nguyên nhân chính của những thất bại. Sau khi tôi trở nên thoải mái hơn với cơ sở mã, tôi bắt đầu tìm kiếm những nơi mà tôi có thể tái cấu trúc và thêm sự ổn định và hiệu suất. Trong khoảng 2 năm hoặc lâu hơn, tôi đã thực hiện nhiều, nhiều thay đổi cho hệ thống. Chúng tôi đã nghỉ hưu hệ thống đó một vài năm trước và tại thời điểm đó, toàn bộ quá trình mất 45 phút để chạy và không tạo ra bất kỳ vấn đề nào trong nhiều năm.

Rất nhiều công việc đã đi vào việc trả các khoản nợ kỹ thuật nhưng nó vẫn tốt, rất xứng đáng. Thật tuyệt khi không nhận được bất kỳ cuộc gọi điện thoại nào vào giữa đêm mà hệ thống bị lỗi. Thật tuyệt khi đến văn phòng trong nhà sư và không thấy gì ngoài tin tốt trong nhật ký.

(Ngoài ra ... Sau một vài năm, tôi đã gặp một trong những nhà phát triển chính của hệ thống này. Anh ấy hỏi tôi nó hoạt động như thế nào và tôi nói với anh ấy rằng hệ thống tồi tệ như thế nào. Anh ấy thực sự xin lỗi và nói với tôi rằng anh ấy biết nó sẽ như thế nào một số ít để hỗ trợ sau khi anh ấy rời đi và ước rằng anh ấy đã làm tốt hơn về nó).

Theo kinh nghiệm của tôi, lợi ích của việc dọn dẹp mã là đáng chú ý nhất khi tôi phải duy trì mã nơi việc dọn dẹp chưa được thực hiện. Khi việc dọn dẹp được thực hiện, các thay đổi của tôi bao gồm đọc qua mã, phát hiện ra một hoặc hai địa điểm cần thay đổi và đi từ đó. Nếu việc dọn dẹp chưa được thực hiện, hãy thêm một bước đầu tiên để đọc mã một vài lần và cố gắng tìm hiểu xem tác giả (đôi khi là tôi) đã nghĩ gì khi anh ta viết nó.

loại bỏ nợ kỹ thuật mang lại ít hỗ trợ kỹ thuật hơn và nền tảng tốt hơn để cải tiến

luôn luôn

Một kinh nghiệm tôi có là khi tôi quản lý nhóm Hiệu suất Trang web tại công ty trước đây. Mỗi đêm, trong khoảng thời gian từ một giờ đến hai giờ, trang web mà nhóm của tôi đang theo dõi sẽ giảm xuống dưới ngưỡng hiệu suất có thể chấp nhận được do thông tin cào bot từ trang web nhanh chóng. Các biện pháp mà nhóm thực hiện để giải quyết vấn đề này bao gồm đăng nhập vào hệ thống quản trị thủ công và chặn các địa chỉ IP gây rắc rối. Không cần phải nói, điều này khiến một thành viên của đội ngủ hàng giờ gần như mỗi đêm. Tôi nhận thấy những gì đã xảy ra và đã tự mình gọi BlackBerry trong vài ngày để xem nó tệ như thế nào và cho nhóm của tôi nghỉ ngơi.

Sau vài ngày, tôi chỉ đơn giản là đến gặp chủ doanh nghiệp của nhóm và cho họ biết rằng nếu chúng tôi không triển khai hệ thống chặn tự động để các bot sẽ gặp khó khăn hơn nhiều khi ảnh hưởng đến hiệu suất của trang web, chúng tôi có thể sẽ mất một số nếu không phải tất cả các thành viên trong nhóm do mệt mỏi và kiệt sức. Họ đồng ý và chúng tôi đã thực hiện một hệ thống cho phép chúng tôi ngủ vào ban đêm. Chủ doanh nghiệp hiểu rằng chi phí của một vài ngày hoặc một tuần phát triển là tối thiểu so với chi phí thuê / đào tạo kỹ sư mới.

Về hai điểm cuối: Tôi hiểu nó đến từ đâu, như được giải thích trong bài viết gốc của mình :

Hoặc, có thể chỉ định lại một số nhà phát triển để thực hiện các vấn đề kỹ thuật này, trong khi phần còn lại của nhóm tiếp tục với các công cụ hướng đến người dùng? Điều này có thể ảnh hưởng đến vận tốc nhóm, nhưng vậy thì sao?

"Vậy thì" bằng gì: chủ sở hữu sản phẩm và những người ở phía doanh nghiệp khác trở nên không vui. Và khi Momma không vui, mọi người đều không vui.

Tuy nhiên, ranh giới giữa những gì phải làm và những gì có thể được thực hiện là khá mơ hồ. Người dùng phải đối mặt là rất rộng, và bao gồm hiệu suất và xảy ra lỗi. Nhưng trong một số trường hợp, vấn đề cơ bản của hiệu năng kém và lỗi xuất hiện cao nằm sâu hơn trong mã. Nói theo cách của anh ta: một câu chuyện có thể không đi qua một khu vực tồi tàn, nhưng khu vực tồi tàn đó có thể che giấu một số điều khó chịu tấn công câu chuyện trên con đường được làm sạch bên cạnh nó.

Những thứ không ảnh hưởng đến hiệu suất tổng thể ít thú vị hơn để làm sạch, nhưng người ta nên đánh giá rất kỹ ảnh hưởng của những điểm đó. Thường xuyên hơn không có ảnh hưởng gián tiếp có thể là khá đáng kể.

Lợi ích lớn nhất mà một tổ chức sẽ nhận được do thanh toán nợ kỹ thuật là tránh lãi kép. Có một ví dụ trong mục blog dưới đây cho thấy số tiền gốc nợ của một khoản nợ kỹ thuật đã tăng từ $ 160k đến $ 430k chỉ trong năm năm. Nó sẽ mất một lập trình viên toàn thời gian chỉ dành riêng để phục vụ số nợ đó. Điều đó sẽ giúp đặt nó trong quan điểm cho những người ra quyết định!

Từ blog.acrowire.com .