Phải làm gì khi một nhóm mới dẫn dắt một dự án có vấn đề về khả năng bảo trì?

Tôi vừa được giao phụ trách một dự án mã với các vấn đề về khả năng bảo trì. Tôi có thể làm gì để có được dự án ổn định?

Tôi thấy mình đang ở một nơi mà chúng tôi đang làm việc với một hệ thống .NET nhiều tầng rất lớn đang thiếu rất nhiều thứ quan trọng như kiểm thử đơn vị, IOC, MEF, quá nhiều lớp tĩnh, bộ dữ liệu thuần túy, v.v. chỉ mới 24 tuổi nhưng tôi đã ở đây được gần ba năm (ứng dụng này đã được phát triển được 5 năm) và chủ yếu là do những hạn chế về thời gian, chúng tôi chỉ thêm vào những thứ nhảm nhí hơn để phù hợp với những thứ nhảm nhí khác. Sau khi thực hiện một số dự án trong thời gian rảnh, tôi đã bắt đầu hiểu tầm quan trọng của tất cả các khái niệm đó. Ngoài ra do sự thay đổi nhân viên, tôi thấy mình bây giờ là trưởng nhóm trong dự án này và tôi thực sự muốn đưa ra một số cách thông minh để cải thiện ứng dụng này. Những cách mà giá trị có thể được giải thích cho quản lý. Tôi có ý tưởng về những gì tôi muốn làm nhưng tất cả chúng dường như quá sức mà không thu được nhiều tiền. Bất kỳ câu chuyện nào về cách mọi người đã hoặc sẽ giải quyết vấn đề này sẽ là một bài đọc rất thú vị. Cảm ơn.

Ngân sách thời gian để tấn công nợ kỹ thuật. Bạn chỉ cần làm điều đó. Phần nào bạn tấn công trước tiên phụ thuộc vào nơi các nhà phát triển của bạn đang dành nhiều thời gian nhất hiện tại, nhưng điều quan trọng hơn là bạn bắt đầu sau đó bạn bắt đầu với những điều lý tưởng. Nếu bạn đang sử dụng Scrum, hãy đặt các phần nợ kỹ thuật cụ thể vào công việc tồn đọng của bạn và coi chúng như các tính năng cho đến khi bạn xử lý chúng.

Làm việc hiệu quả với Legacy Code rất được khuyến khích và có thể sẽ hữu ích. Tôi chưa đọc nó, nhưng dường như có rất nhiều thông tin về việc kiểm tra đơn vị thành mã kế thừa để bạn có thể sửa đổi và cập nhật nó một cách an toàn.

Sử dụng sự tương tự thẻ tín dụng với quản lý - bạn đang "trả lãi" cho mọi việc bạn làm vì rất khó để hoàn thành bất cứ điều gì. Nếu bạn trả hết nợ kỹ thuật, bạn sẽ giải phóng những tài nguyên đó và có thể phát triển chức năng mới nhanh hơn trong tương lai. Nếu bạn không, "các khoản thanh toán lãi" (được trả trong thời gian phát triển) sẽ tiếp tục tích lũy và nhóm của bạn sẽ sản xuất chức năng mới chậm hơn.

Có thể bắt đầu ước tính lượng thời gian bạn dành cho mỗi chu kỳ đấu tranh chống lại nợ kỹ thuật để cung cấp cho họ ý tưởng về số tiền đã tích lũy. Mô tả sự thay đổi hoặc thay đổi tính năng sẽ như thế nào trong một hệ thống có thể bảo trì, nó trông như thế nào trong hệ thống thực tế và những thay đổi nào cần được thực hiện hoặc có thể là những bước đầu tiên tốt để đạt được điều đó.

Cuộn nợ kỹ thuật vào sửa lỗi và tính năng bổ sung.

Tôi đã tìm thấy một cách tiếp cận lặp đi lặp lại để cải thiện mang lại kết quả tốt nhất. Câu thần chú trong công việc của tôi là cải thiện chất lượng mã bất cứ khi nào bạn chạm vào nó. Mỗi tác phẩm cho dù đó là bản sửa lỗi hay tính năng đều bắt đầu bằng phân tích về những gì có thể sửa / tái cấu trúc / dọn sạch. Chúng tôi cố gắng làm cho bộ tái cấu trúc ngang bằng (theo tỷ lệ) cho công việc mà chúng tôi phải hoàn thành.

Tạo một danh sách theo thứ tự các vấn đề trong cơ sở mã. Hãy chắc chắn rằng tất cả mọi người biết về danh sách và thứ tự ưu tiên. Bất cứ khi nào họ nhận được một phần công việc, họ nên tìm kiếm một vấn đề từ danh sách gắn với mã bạn sẽ làm việc.

Điều này sẽ không sửa chữa mọi thứ. Có một số cấu trúc lại hoặc sửa chữa đòi hỏi một khối lượng lớn thời gian và tài nguyên. Tôi thường cố gắng gắn kết chúng với những công việc lớn khác sẽ có lợi.

Tôi chỉ có thể nói rõ ràng, nhưng hey.

Viết một bài kiểm tra đơn vị nhỏ thực hiện một đoạn mã có vấn đề, sau đó cấu trúc lại đoạn mã nói, đảm bảo rằng bài kiểm tra vẫn vượt qua. Chuyển sang một đoạn mã khác, đoạn mã bạn có thể tiếp cận dễ dàng nhất từ ​​phần đất nhỏ bé mà bạn vừa xây dựng. Lót, rửa sạch, lặp lại.

Điều này cũng sẽ giúp bạn làm quen với một chút cơ sở mã.

Sau khi bạn đã làm điều đó một thời gian, bạn sẽ thấy rằng đã đến lúc thực hiện một số tái cấu trúc mở rộng hơn. Tìm ra mã trùng lặp, vi phạm nguyên tắc DRY ... bạn biết đấy, những thứ thông thường. Đến lúc đó, bạn sẽ có một phạm vi bảo hiểm mã khá tốt, cho phép bạn xáo trộn các phương thức xung quanh, trích xuất các giao diện và tất cả các tiện ích đó.

Luôn luôn để codebase tốt hơn một chút so với trước khi bạn bắt đầu hack theo cách của mình. Tôi khá chắc chắn rằng đó là một khoản đầu tư nhỏ sẽ mang lại kết quả, ngay cả trong thời gian không dài.

Bạn có thể cố gắng giải thích các khoản nợ kỹ thuật mà dự án này có cho một ý tưởng về nơi bắt đầu. Bạn cũng có thể cố gắng mặc cả rằng do nhân viên thay đổi, phải có một chút thời gian để tăng tốc mã và điều này có nghĩa là đưa vào một số thử nghiệm để giúp đảm bảo phát triển tốt hơn trong tương lai vì các thử nghiệm có thể giúp ngăn ngừa lỗi và giúp mọi việc dễ dàng hơn người mới để làm việc trong dự án có thể.

Trong trường hợp như vậy, tôi muốn cố gắng hợp lý hóa dự án càng nhiều càng tốt. Tìm hiểu các tính năng là hoàn toàn cần thiết để có được nó để di chuyển về phía trước. Bất kỳ hệ thống nào đã tồn tại trong một thời gian dài có thể có tồn đọng rất dài. Rất nhiều trong số các mặt hàng này sẽ rất quan trọng và rất nhiều thứ sẽ chỉ là "chuông và còi".

Theo như thử nghiệm, kiểm tra đơn vị chắc chắn sẽ hữu ích, nhưng bạn có thể muốn yêu cầu một số nhân viên phi công nghệ tham gia thử nghiệm và gửi lỗi cho các thành viên trong nhóm của bạn.

Chúc may mắn.

Một lựa chọn là phủi bụi lý lịch của bạn và bắt đầu săn việc.

Một câu hỏi hay để tự hỏi mình là liệu dự án tồi tệ này có phải là dấu hiệu cho thấy toàn bộ công ty đang hoạt động như thế nào. Nếu câu trả lời là có, thì hãy hỏi xem bạn có được trả đủ tiền để ở trong một công ty tồi không.

Nhiều lần bạn có thể đẩy tái cấu trúc bởi quản lý cấp trên nếu bạn có thể nói với họ rằng đó sẽ là một bản nâng cấp hiệu năng hoặc sửa một số lỗi hiện có. Đừng tái yếu tố chỉ để thay đổi một cái gì đó thành những gì bạn sẽ làm, đặc biệt là nếu nó hoạt động. Thời gian sửa lỗi cũng có thể là một cách tốt để phù hợp với một số tái cấu trúc vì dù sao bạn cũng đã ở đó. Hãy quyết đoán và đừng nhìn nó vì bạn trẻ hơn các lập trình viên đồng nghiệp. Bắt đầu với một cái gì đó nhỏ như tham gia vào một số thử nghiệm đơn vị và làm việc từ đó, bạn có thể phát hiện ra một số lỗi có thể quản lý để cung cấp cho bạn chu kỳ cho những thứ khác.

Tôi hiện đang đọc Phát triển ứng dụng Brownfield trong .NET , về cơ bản, là về cách xử lý các vấn đề bạn hiện đang gặp phải. Cho đến nay tôi thích hầu hết những gì nó nói (không hoàn toàn là tất cả - nhưng đây là loại sách giúp bạn suy nghĩ theo cách riêng của mình thông qua các vấn đề, không phải là một dự định hoàn toàn theo quy định). Nó có thể giúp theo một số cách - nó cho thấy bạn không đơn độc; nó hy vọng sẽ cung cấp cho bạn gợi ý về cách giải quyết một số vấn đề.

Về cơ bản, tôi đồng ý với hầu hết các phương pháp tiếp cận - bạn không thể sửa toàn bộ mọi thứ chỉ sau một đêm, nhưng bạn có thể cải thiện dần dần theo từng bước rất nhỏ. Và có - Nợ kỹ thuật là phép ẩn dụ bạn cần sử dụng.

Cuối cùng nó phụ thuộc vào mức độ tốt của mọi người trong dự án. Nếu chính cùng một phi hành đoàn đã tạo ra mớ hỗn độn, thì bạn có rất ít cơ hội để làm cho nó tốt hơn với cùng một nhóm. Phân tích nhân viên của bạn, tìm ra những thành viên yếu nhất của bạn và thay thế họ (nếu bạn có khả năng làm điều đó).

"Bạn không thể làm ví lụa từ tai lợn nái".