Làm thế nào để sửa bản sao / dán mẫu?

Khi tôi làm việc, mọi người (chuyên gia tư vấn) cảm thấy bị ép phải phát hành các tính năng nhanh nhất có thể. Vì vậy, thay vì dành quá nhiều thời gian để suy nghĩ về cách làm mọi thứ đúng cách hoặc vì họ không muốn phá vỡ bất cứ điều gì, mã được sao chép từ các mô-đun khác nhau và được sửa đổi.

Không dễ để ngăn chặn điều này, vì cơ sở mã được mở cho toàn bộ công ty. Rất nhiều người làm việc về điều này.

Bây giờ sự lộn xộn đã có, cách tốt nhất để loại bỏ những dư thừa đó mà không phá vỡ quá nhiều là gì?

Một phần của câu trả lời là Tái cấu trúc .

Đầu tiên, bắt đầu viết bài kiểm tra đơn vị để đảm bảo rằng bạn không vô tình phá vỡ bất cứ điều gì với những thay đổi của bạn. Sau đó bắt đầu cải tiến thiết kế, loại bỏ trùng lặp, vv trong các bước nhỏ, chạy thử nghiệm đơn vị của bạn sau mỗi bước, khắc phục mọi sự cố nếu bất kỳ thử nghiệm nào thất bại hoặc hoàn nguyên ngay lập tức nếu bạn gặp phải vấn đề lớn hơn bạn có thể giải quyết dễ dàng.

Phần khác là giáo dục .

Mọi người phải được dạy không để lại mã xấu phía sau. Đây chắc chắn là một cuộc chiến lâu dài, vì thói quen và quá trình suy nghĩ rất khó (đôi khi thậm chí là không thể) thay đổi . Tuy nhiên, không có nó, bạn sẽ tiếp tục nhận được một nguồn cung cấp mã xấu vô tận để được tái cấu trúc.

Bạn có thể chọn thực hiện đánh giá mã nhóm để thảo luận mở về thói quen mã hóa tốt và xấu, và truyền bá công đức trước đây. Nói "bạn phải (không) viết mã như thế này là không đủ", bạn cần thuyết phục mọi người bằng logic và sự thật phũ phàng. Giống như "nếu bạn có đoạn phương thức này được nhân đôi qua codebase n lần, bạn nghĩ cơ hội nào nếu một lỗi được tìm thấy trong phương thức đó, nó sẽ được sửa trong mỗi bản sao của mã phương thức?"

Công ty của bạn cũng có thể cần sửa đổi các tiêu chí khuyến khích và chấp nhận cho các chuyên gia tư vấn - nếu họ có thể thoát khỏi việc viết mã cẩu thả, họ chắc chắn sẽ tiếp tục chọn con đường dễ dàng hơn. Nếu công ty tiếp tục định giá "giao hàng nhanh" trong khả năng duy trì dài hạn, sẽ không có gì thay đổi :-( Vì vậy, bạn cũng có thể cần thảo luận vấn đề này với quản lý. Một cách để làm cho họ hiểu là: tái cấu trúc có nghĩa là giữ mã sạch, dễ dàng hiểu và duy trì. Bỏ qua tái cấu trúc cũng giống như nợ trong thẻ tín dụng của bạn. Bạn có thể thoát khỏi nó trong một thời gian, nhưng nếu bạn không chủ động quản lý thói quen mua hàng và các khoản nợ của mình, chắc chắn nó sẽ sụp đổ trên vai bạn một ngày nào đó. Trong vòng đời của một dự án phần mềm, phá sản là khi dự án trở nên không thể hiểu được: việc viết lại từ đầu trở nên dễ dàng hơn là thêm một tính năng mới vào cơ sở mã hiện có. Hoặc người dùng đã quá chán ngán với mức độ hỗ trợ và tính năng kém hơn mà họ chỉ đơn giản chuyển sang cạnh tranh.

Là một phần của giáo dục như @Peter đã nói, bạn có thể giới thiệu một trình phát hiện sao chép và dán như PMD và sử dụng nó như một phần của bản dựng của bạn theo chu kỳ để giúp thực thi phần này trong các tiêu chuẩn mã hóa của bạn.

Hãy chắc chắn rằng tiêu chuẩn mã hóa dự án của bạn bao gồm mẫu này để bạn có đường cơ sở để bắt đầu các cuộc thảo luận.

mọi người (chuyên gia tư vấn) cảm thấy bị ép phải phát hành các tính năng nhanh nhất có thể

Bạn không có vấn đề kỹ thuật, bạn có vấn đề xã hội. Thật vậy, bạn có một vấn đề quản lý.

Không dễ để ngăn chặn điều này, vì cơ sở mã được mở cho toàn bộ công ty. Rất nhiều người làm việc về điều này.

"Cơ sở mã được mở cho toàn bộ công ty" là một vấn đề không phải là vấn đề. Không quan trọng.

Vấn đề là có một hệ thống khen thưởng quản lý được áp dụng để sao chép và dán. Nguyên nhân sâu xa là mọi người được khen thưởng (nghĩa là được trả tiền hoặc được khen ngợi hoặc được thăng chức hoặc gia hạn) để sao chép và dán.

Bạn không thể phá vỡ điều này mà không thay đổi căn bản văn hóa từ "nhấn để phát hành các tính năng nhanh nhất có thể" thành "được thưởng khi thực hiện các thay đổi cơ sở mã được kiểm tra tốt, phù hợp".

Bạn phải

1. Bắt đầu từ đầu, với các nhà quản lý củng cố phần thưởng. Bạn phải tiết lộ thực tiễn hiện tại và ghi lại các chi phí và rủi ro. Bạn phải đề xuất một giải pháp thay thế giúp giảm chi phí và rủi ro.

2. Bạn phải không ngừng ghi chép và tiết lộ chi phí và rủi ro cho phần còn lại của nhiệm kỳ tại tổ chức đó. Không ngừng nghỉ. Dựa trên thực tế. Chi phí và rủi ro. Mỗi tuần chi phí nhiều hơn và rủi ro nhiều hơn từ sao chép và dán.

3. Bạn sẽ phải giúp các nhà quản lý tin tưởng vào cách tiếp cận mới sẽ khiến họ trông ổn và bạn sẽ bị bỏ qua.

Điều rất quan trọng để giảm sao chép và dán. Nhưng thật khó để thay đổi văn hóa của một tổ chức. Bạn phải cung cấp rất nhiều sự thật và bạn phải giải quyết vụ việc nhiều lần cho những người quản lý không đồng ý với bạn.

Tôi có một cơ sở mã bây giờ đã bắt đầu thối từ đó. Tôi đã có hơn 10 hàm tĩnh cho mỗi mô-đun về cơ bản giống với các hàm tĩnh tương tự trong các mô-đun khác. Mỗi người hành xử chỉ đủ khác nhau để đảm bảo một hóa thân mới với mục đích làm mọi việc càng nhanh càng tốt.

Hôm nay, tôi đã phải thêm một tính năng khác và tôi không thể sử dụng nó nữa. Tôi đã tạo một thư viện mới, kết hợp các hàm 100 + thành 10 hàm reentrant thay đổi một chút hành vi của họ dựa trên cờ bit và sau đó viết một loạt các thử nghiệm để đảm bảo mọi thay đổi đối với thư viện đó không phá vỡ bất kỳ điều gì khác.

Tổng thời gian sử dụng: 4 giờ. Tôi đã sẵn sàng tham gia cuộc đua marathon kéo dài 20 giờ nếu cần thiết và rất ngạc nhiên khi tôi nhanh chóng mang đến một mớ hỗn độn đang phát triển. Như một phần thưởng, sau đó dễ dàng hơn để khắc phục một loạt các vấn đề phụ thuộc tiêu đề. Ngoài ra, do nhiều công cụ độc quyền của chúng tôi hiện nằm trong các đối tượng tĩnh để liên kết, chúng tôi có thể cung cấp cho khách hàng của mình những người có quyền truy cập vào mã nguồn nhiều hơn trước đây.

Lời khuyên của tôi: cắn viên đạn và tái yếu tố gây rối bây giờ trước khi làm như vậy thực sự trở nên tồi tệ . Có thể bạn sẽ không mất nhiều thời gian như bạn nghĩ, nhưng hãy tạo một chi nhánh mới cho chính bạn chỉ trong trường hợp.

Ngoài ra, bạn vẫn có thể sao chép / dán để đưa các tính năng ra khỏi cửa trong khi khắc phục sự cố cơ bản. Khi bạn đã hoàn tất, chỉ cần lấy ra những thứ đã dán và sử dụng thư viện mới thay thế.

Tôi đồng ý với các câu trả lời cho đến nay. Bạn nên:

• tạo bài kiểm tra đơn vị
• cấu trúc lại
• giáo dục
• nỗ lực vào các tiêu chuẩn mã hóa và phát hiện vi phạm

Nhưng mặt khác, bạn cần xem xét nguyên nhân khiến mọi người sao chép dán và khắc phục điều đó.

• mọi người có thể không thể sử dụng lại mã theo cách tốt vì nó được kết hợp với nhiều
• mọi người có thể không biết rằng có một thư viện mà họ có thể sử dụng
• Mã thư viện có thể không đủ chung chung và việc nướng phiên bản của riêng bạn dễ dàng hơn so với sử dụng thư viện hiện có
• Có thể không có một chiến lược phiên bản tốt (không phải kiểm soát nguồn) và việc thay đổi một thư viện chung có thể chỉ khiến nhiều ứng dụng khác được thử nghiệm.

Vì vậy, tôi nghĩ rằng để ngăn chặn mô hình sao chép / dán bạn cần làm cho việc tái sử dụng dễ dàng hơn.

• làm cho thư viện có thể khám phá và tài liệu tốt
• làm cho các thư viện độc lập với mọi thứ
• nghĩ về một chiến lược phiên bản tốt
• đảm bảo khả năng tương thích ngược
• nghĩ về khả năng mở rộng dễ dàng của các thư viện

đọc Hướng dẫn thiết kế khung

Hi vọng điêu nay co ich.

Có một thái độ mạnh mẽ "sao chép dán có hại". Tôi nghĩ nó tốt, nhưng đi hơi xa. Sao chép dán như một bài tập trong việc khám phá những điểm tương đồng và khác biệt giữa hai phương pháp hoặc lớp học - như một bước trong quá trình tam giác hóa - tôi nghĩ là lành mạnh. Nhưng việc dừng lại quá trình tam giác hoàn chỉnh - loại bỏ sự trùng lặp được giới thiệu bằng bản sao dán - thực sự có hại.

Nếu bạn có thể tìm cách sử dụng thái độ đa sắc thái đó, để nói với các nhà phát triển không phải là "điều đó tồi tệ!", Mà là "chưa đầy đủ, bạn có thể làm việc với tôi để hoàn thành việc tái cấu trúc không?", Thì bạn có thể thấy mình có nhiều cuộc trò chuyện mang tính xây dựng hơn.

Tôi quan tâm đến vấn đề tương tự ở đây, và tôi nghĩ rằng: Đừng cố gắng tránh nó trả trước, chỉ cần tái cấu trúc khi nó trở nên quá tệ.

Mô-đun tôi hiện đang làm việc trên startet như một bản sao của mô-đun khác, bây giờ tôi đang thay đổi mọi thứ cần phải khác đi. Một khi điều này được thực hiện và mô-đun mới kết thúc, tôi sẽ so sánh nó với mô-đun ban đầu và tìm ra phần nào ít nhiều không thay đổi và nên được chuyển đến một thư viện, lớp cha trừu tượng, v.v.

Bất cứ ai phụ trách đều có lỗi. Một người không thể được yêu cầu xem xét mọi dòng mã, nhưng họ đặt ra các tiêu chuẩn và khung thời gian.

Các nhà thầu (hoặc bất kỳ ai là người ngắn hạn trong một dự án) có thể được đưa vào vị trí mà họ chỉ được bồi thường khi làm cho nó hoạt động lần đầu tiên. Có một số động lực để hoàn thành nó càng sớm càng tốt. Mã sao chép có thể không bao giờ cần phải sửa đổi và nếu nó không phải là mã.

Bạn có thể thử và buộc họ sửa nó vào thời gian riêng của họ. Sau đó, họ sẽ bắt đầu thực hiện nó ngay từ đầu, nhưng sau đó mất rất nhiều thời gian để hoàn thành công việc. Tôi nghĩ AmmoQ có ý tưởng đúng đắn về việc tái cấu trúc những thứ đang gây ra vấn đề.

Cách duy nhất để loại bỏ mã sao chép / dán mã là (IMHO) đánh giá mã, yêu cầu một người (hoặc tốt nhất là nhiều hơn) kiểm tra mã và khi họ tìm thấy mã dường như từ một hành động sao chép / dán hãy để người lập trình tái cấu trúc.

Theo đề xuất, đây chủ yếu là một vấn đề trong tổ chức. Cố gắng bắt đầu bằng cách giáo dục mọi người (đừng quên lớp quản lý trực tiếp phía trên vị trí của bạn). Nó giúp rất nhiều để bắt đầu có được một hoặc hai người trên tàu của bạn và để virus lây lan. Khi đa số nghĩ rằng đây là một ý tưởng tốt, hãy mô tả nó và cố gắng giới thiệu các đánh giá để đảm bảo nó vẫn như vậy. Đây là một quá trình rất chậm và tẻ nhạt nhưng nó không thể thay đổi nhanh chóng. Lúc đầu, nó sẽ tốn thêm thời gian để quản lý quan trọng biết và hỗ trợ mục tiêu dài hạn.

@Anders K. Nhận xét là một phương tiện tốt để giữ cho thực hành tại chỗ. Khi buộc mọi người viết mã, họ không tin vào điều đó tạo ra nhiều ma sát. Họ sẽ rơi trở lại trong hợi cũ ngay khi có thể. Tôi tin chắc rằng bạn nên bắt đầu với giáo dục để đạt được đà.