Làm thế nào để biện minh cho thời gian tái cấu trúc mã?

Có một dự án rất lớn hơn 70k LỘC.

Dự án chắc chắn cần một số tái cấu trúc mã trong Core Framework và trong các phần khác. KHÔNG có thời gian được thiết lập khi bắt đầu dự án để tái cấu trúc. Tuy nhiên với thời gian và hơn 40 nhà phát triển cùng tham gia và rời khỏi dự án. Từ quan điểm của tôi là không thể thiếu.

Điều gì sẽ là điểm chính của bạn trong tranh luận và bảo vệ một nguyên tắc phát triển phần mềm thích hợp?

Khi làm việc trên ứng dụng kế thừa hoặc brownfield, việc thực hiện "dọn dẹp mùa xuân" với hy vọng sẽ tái cấu trúc lại toàn bộ hình dạng. Đó không phải là cách sử dụng tài nguyên hợp lý. Rốt cuộc, làm thế nào để tạm dừng phát triển trên phần mềm làm việc (chỉ có thể tái cấu trúc mã làm việc)? Bạn có thể đảm bảo thời gian dành cho Giai đoạn Tái cấu trúc lớn sẽ trả hết sau đó và không gây ra sự thoái hóa cho dự án?

Làm thế nào để bạn ăn một con voi? Một lần cắn một lúc. Bất cứ khi nào bạn cần thực hiện tính năng mới hoặc sửa lỗi bạn sẽ thấy nếu phần đó cần tái tham gia. Giống như quy tắc trinh sát của cậu bé nói: "Luôn luôn để khu cắm trại sạch hơn bạn tìm thấy". Tái cấu trúc không nên là một giai đoạn riêng biệt, nó là một phần của sự phát triển mỗi ngày.

Khi bạn có được văn hóa chất lượng này được giới thiệu cho nhóm phát triển, chất lượng sẽ được cải thiện. Sau đó, không có gì để biện minh cho quản lý.

Nói chung, việc tái cấu trúc nên được thực hiện để cho phép thay đổi khác mà bạn cần thực hiện đối với mã hoặc như một bước làm sạch tự nhiên sau khi thay đổi được thực hiện đối với mã. Trong trường hợp đó, không có gì để biện minh. Tái cấu trúc chỉ đơn giản là một phần của quá trình thực hiện công việc trên dự án. Thời gian được tính hóa đơn cho nhiệm vụ bạn đang làm khi bạn thực hiện tái cấu trúc.

Nếu nó không được thực hiện theo từng bước nhỏ, thì nó không thực sự tái cấu trúc, eh?

Tất cả các câu trả lời tốt ở đây - nhưng tôi có thể thêm một khía cạnh kinh doanh cho điều này. Cho tôi hỏi bạn TẠI SAO / Vậy-Cái gì? (nghĩ về ông chủ tóc nhọn của bạn (PHB) :)

PHB: tại sao?
Bạn: Nó sẽ giúp mọi thứ dễ dàng hơn để sửa chữa
PHB: Vậy-cái gì?
Bạn: Nó sẽ tăng thông lượng - chúng tôi sẽ nhận được các bản dựng mới nhanh hơn?
PHB: Vậy-cái gì?
Bạn: Err ... Khách hàng hạnh phúc hơn?
PHB: WTF?
Bạn: Tôi có nghĩa là tăng khuyến nghị, sự hài lòng lớn hơn, 
     lợi nhuận sớm hơn do quay vòng thấp
PHB: Ồ! Nghe hay đấy. Nhưng nó chỉ "âm thanh" tốt đẹp tôi có thể nhìn thấy nó?
Bạn: WTF?
PHB: Cho tôi xem tiền! (tức là số xin vui lòng)
Bạn: Ồ! Brb ... (đi và đặt một số số trong bảng tính đơn giản để làm cho trường hợp của bạn)

Về cơ bản, bạn phải tạo ra một trường hợp kinh doanh - chạy một số con số để làm rõ quá trình suy nghĩ của bạn và lấy các con số để phản ánh 'lợi ích' một cách khách quan. Bạn cũng sẽ biết sẽ mất bao nhiêu thời gian, chi phí gần đúng, v.v. Nó sẽ có ý nghĩa. Nếu nó có giá trị, bạn sẽ nhận được tín hiệu xanh và có thể cũng là người chủ động :)

Nếu bạn nghĩ làm thế nào tôi có thể đo lường mọi thứ hãy thử cuốn sách này

Tái cấu trúc, giống như bất kỳ hoạt động nào khác, phải có mục tiêu rõ ràng được xác định cho nó. Khi mục tiêu đó rõ ràng, bạn sẽ xem xét tình trạng dự án hiện tại và giai đoạn vòng đời. Đối với một dự án phát triển đã hoàn thành 80%, chậm tiến độ 30%, bạn nên chứng minh nỗ lực tái cấu trúc dựa trên mục tiêu đã đặt ra trước đó. Trong ví dụ này, nếu các đoạn mã được kiểm tra đơn vị và hoạt động tốt trong môi trường phát triển, thật khó để biện minh cho việc tái cấu trúc.

Việc 40 nhà phát triển còn lại có thể không ấn tượng như âm thanh. Tôi hy vọng rằng các nhà phát triển đã phân phối mã làm việc đã được xem xét và thử nghiệm. Vì vậy, trừ khi có các vấn đề đã biết trong mã này, tôi sẽ để nguyên như vậy. Ý tưởng là trong một dự án lớn như của bạn, tôi hy vọng rằng có các tiêu chuẩn và quy trình và mã không phải là một mớ hỗn độn.

Hãy nhớ rằng tái cấu trúc sẽ gây ra nhiều nếu không phải tất cả các thử nghiệm đã được thực hiện để được lặp lại. Ngoài ra, do việc tái cấu trúc kích thước này không thể được thực hiện bởi một hoặc hai thành viên cao cấp, nên việc tái cấu trúc có thể gây ra các vấn đề không tồn tại. Đây là một rủi ro không nên bỏ qua.

Phải nói rằng, không có gì bất thường khi thêm các nhiệm vụ vào một dự án khi điều không lường trước xảy ra. Vì vậy, nếu các nhà phát triển biến mất vì một số lý do, đó sẽ được coi là một sự kiện có tính chất đặc biệt và bất kỳ hành động nào để khắc phục tình trạng này phải được thực hiện. Nó sẽ được coi như một đám cháy hoặc một trận động đất, vv

Tóm lại, tôi sẽ không cấu trúc lại mã làm việc lớn trong một dự án lớn vì không có lý do kỹ thuật vững chắc, đặc biệt là tất cả chúng ta đều biết rằng hầu hết các dự án thường ở trạng thái trễ.

Hãy tưởng tượng rằng bạn đang ở phía trước một bức tường dài và to lớn. Bạn cần phải đi sang phía bên kia.

Hoặc bạn tái cấu trúc bức tường để xây dựng một cánh cửa, hoặc bạn đi xung quanh nó.

Ước tính thời gian cho cả hai giải pháp và bạn có được sự biện minh cho việc tái cấu trúc.

Đừng quên nhân thời gian trong giải pháp thứ hai với số người cần đi sang phía bên kia của bức tường.

Khi tôi đọc một trong những câu trả lời khác, hãy ăn con voi này cắn một lúc. Tôi tham gia kiểm toán một dự án quốc tế lớn, nơi các thành viên trong nhóm bị phân tán về mặt địa lý. Sau khi xây dựng hai phiên bản đầu tiên của phần mềm, nhóm đã đồng ý rằng cách tiếp cận, phong cách mã hóa và giải pháp xây dựng của chúng không nhất quán. Họ đồng ý viết các phần mới của ứng dụng theo các quy tắc và quy ước mới và khi nào (và chỉ sau đó) họ phải thay đổi một số mã cũ, trước tiên họ sẽ cấu trúc lại nó để đáp ứng quy ước mới. Mọi thứ đang hoạt động khá tốt. Quá trình tái cấu trúc đã gần hết tháng thứ 5, một số mã được cấu trúc lại, một số vẫn không được. Các tính năng mới được đưa vào thời gian, khách hàng hài lòng, nhà phát triển hạnh phúc, nhóm QA cũng hạnh phúc. Chiến thắng nghịch cảnh :)

Điểm chính của tái cấu trúc là làm cho mọi thứ dễ dàng hơn trong tương lai. Bạn không thể hiển thị lợi nhuận của tái cấu trúc trừ khi bạn so sánh nhiều dự án dài hạn được thực hiện và một số ít mà không cần tái cấu trúc liên tục. Nó thường được chấp nhận trên các nhà phát triển, rằng tái cấu trúc làm giảm chi phí bảo trì và thực hiện các thay đổi, nhưng những điều đó khó chứng minh từ quan điểm kinh doanh. Lý do chính để thực hiện tái cấu trúc là để giảm Nợ kỹ thuật .

Ngoài ra, tái cấu trúc phải là quá trình liên tục và dành thời gian cho việc tái cấu trúc nên được đưa vào chính nhiệm vụ phát triển. Có "nhiệm vụ tái cấu trúc" đặc biệt không phải là ý kiến ​​hay.