Cách tốt, ngắn gọn để giải thích sự nguy hiểm của lập trình sao chép-dán đối với người không lập trình là gì? [đóng cửa]

Tôi đang tìm kiếm một sự tương tự hoặc ẩn dụ tốt có thể minh họa các vấn đề của lập trình sao chép-dán cho những người không lập trình. Thỉnh thoảng tôi thực hiện đánh giá mã / hệ thống cho các khách hàng tiềm năng và một trong những vấn đề phổ biến tôi thấy là số lượng lớn mã sao chép dán trên tất cả các cơ sở mã của họ. Đó là điều tôi thường xuyên gọi ra trong các bài đánh giá, và mỗi lần tôi phải giải thích tại sao đây là một vấn đề (điều này đặc biệt khó khăn với những khách hàng biết đủ về lập trình để hiểu rằng tái sử dụng là một điều tốt, nhưng không đủ để hiểu tại sao copy-paste không phải là một hình thức tái sử dụng tốt). Rõ ràng, tôi có thể (và làm) giải thích vấn đề về bảo trì mã, nhưng thật tuyệt khi có một sự tương tự tốt, ngắn gọn cho vấn đề này sẽ xảy ra với những người không lập trình. Tiền thưởng nếu sự tương tự minh họa tại sao tìm kiếm và thay thế không phải là một giải pháp hiệu quả cho vấn đề này. Bất kỳ đề xuất?

Chỉ cần làm rõ (dựa trên câu trả lời của Jaroslav bên dưới) - Tôi không nói về việc sử dụng đoạn mã ở đây; những gì tôi thấy (thường xuyên lo lắng) là sao chép và dán các dải mã lớn hoặc một đoạn mã mười dòng để lấy một số dữ liệu người dùng (hoàn thành với truy vấn SQL nội tuyến) được dán vào hàng tá trang PHP hoặc ASP.NET. Vì vậy, sao chép mã từ nơi khác trong cùng một dự án.

Cập nhật: Có một số câu trả lời thực sự tốt ở đây; Tôi đã giải thích trong các ý kiến ​​tại sao tôi chọn câu trả lời của Scott Whitlock, nhưng tôi cũng rất muốn giới thiệu câu trả lời của whatsisname nếu bạn đang làm việc với những khách hàng quen thuộc với sản xuất.

Nó giống như thế này ... bạn có một chiếc đồng hồ trong nhà. Tuyệt quá! Bạn biết mấy giờ rồi, nhưng bạn luôn phải đến căn phòng đó để nhìn.

Nhưng tất nhiên bạn muốn biết bây giờ là mấy giờ mà không cần đến phòng đó, vì vậy bạn mua thêm một số đồng hồ, và bạn phân phối chúng xung quanh nhà bạn. Mỗi đồng hồ là độc lập. Tất cả đều giữ thời gian riêng của họ. Điều này có nghĩa là:

• Khi thời gian thay đổi do thời gian tiết kiệm ánh sáng ban ngày, bạn phải thay đổi tất cả chúng
• Ngay cả khi tất cả đã được thiết lập, tất cả đều khác nhau một chút và hiếm khi đồng ý hoàn hảo. Theo thời gian họ trôi dạt.

Bây giờ hãy tưởng tượng vấn đề tương tự trong một cơ sở lớn với hàng chục hoặc hàng trăm đồng hồ. Đó là lý do tại sao bạn cần một cái gì đó giống như chiếc đồng hồ nối mạng này giữ cho nó đồng bộ với cơ sở thời gian trung tâm. Bằng cách đó, thời gian được xác định một lần và chỉ một lần .

Lập trình sao chép-dán giống như mua đồng hồ độc lập hơn. Nó không có quy mô.

Hãy tưởng tượng bạn đang thiết kế một chiếc máy bay. Bạn đã có một máy bay phản lực duy nhất. Nó bán tốt. Bây giờ bạn sẽ thiết kế một máy bay 4 động cơ cho những chuyến đi dài trên đại dương.

Bây giờ, bạn không tạo ra một bộ đầy đủ các thông số kỹ thuật và bản vẽ cho từng động cơ, phải không? Không, bạn sử dụng cùng một động cơ ở cả bốn nơi. Bây giờ hãy tưởng tượng nếu bạn có 4 bộ bản vẽ, và bạn phải thay đổi một cái gì đó. Bây giờ bạn phải thay đổi nó trong tất cả bốn bản vẽ động cơ. Điều gì xảy ra nếu bạn vô tình quên thay đổi thứ gì đó trong động cơ thứ 4 vì bạn đang tìm ra?

Vì vậy, nói rằng bạn đang thay đổi chiều dài của một ốc vít, hoặc một đường ống. Bây giờ bạn không thể "tìm kiếm và thay thế" trên cơ sở dữ liệu các bản vẽ kỹ thuật của mình, bạn có thể vô tình thay đổi các ốc vít gắn trong máy bơm nhiên liệu vì chúng có cùng kích thước. Hoặc đường thủy lực cung cấp năng lượng cho bánh lái đuôi sử dụng cùng một sợi, nhưng bây giờ thì khác và bạn không thể cấp nguồn cho đuôi nữa.

Bây giờ hãy tưởng tượng bạn gặp rắc rối bởi NTSB vì động cơ của bạn ngẫu nhiên ném lưỡi tuabin và phát nổ khi bay về phía nam Florida. Bây giờ bạn nhìn vào bản vẽ động cơ nào? Tất cả bọn họ, một trong số họ? Làm thế nào để bạn biết rằng cả bốn đều giống nhau? Có lẽ các chỉnh sửa đã được thực hiện, nhưng chúng chỉ được áp dụng cho động cơ một, bởi vì anh chàng đã thiết kế các động cơ đã rời đi một năm để chơi trong một ban nhạc reggae và là người duy nhất nhớ rằng bốn động cơ nằm trong các tệp riêng biệt và anh chàng đã sửa chữa tuabin nổ là người thay thế anh ta.

Sao chép và dán mã tương tự như có các bản vẽ trùng lặp của các bộ phận cấu thành, cho dù đó là vít hay động cơ. Bạn muốn trừu tượng các thành phần xuống các phần cơ bản được tái sử dụng càng nhiều càng tốt.

Đừng sao chép các động cơ, chỉ cần viết mã gắn các động cơ vào cánh.

Bạn phải giải thích nó theo cách chia sẻ cùng một tài nguyên so với sao chép cùng một tài nguyên.

Chẳng hạn, sẽ hợp lý khi mọi ngôi nhà trong một thành phố lớn đều có một nhà máy điện chuyên dụng cung cấp điện cho ngôi nhà hay sẽ có ý nghĩa hơn khi mọi ngôi nhà đều có chung một nhà máy điện? Nếu xảy ra sự cố với một bộ phận cụ thể được sử dụng tại (các) nhà máy điện và việc sửa chữa là bắt buộc, việc sửa chữa ở một nơi sẽ dễ dàng hơn và mọi người đều được lợi từ việc sửa chữa này so với việc sửa chữa tại mỗi nhà máy điện chuyên dụng và chỉ mỗi lần sửa chữa lợi ích nhà riêng.

"Hey Nhìn tất cả các phẫu thuật là hơi giống nhau phải không?, Vì vậy bạn sẽ không phiền nếu tôi sao chép ngẫu nhiên hướng dẫn phẫu thuật cho các quy trình khác nhau từ các bác sĩ phẫu thuật khác nhau cho ca phẫu thuật của bạn?"

Sao chép và dán giống như cố gắng sản xuất các bộ phận mà không có khuôn. Nó chậm và bạn sẽ được sử dụng một lần từ mỗi bộ phận, vì một khi nó được xác định là bị lỗi hoặc bị hỏng, bạn không thể sửa khuôn để tạo ra một sự thay thế phù hợp.

Trong quá trình tìm kiếm sự tương tự, trước tiên chúng ta phải xem xét sự nguy hiểm của việc lập trình sao chép và dán :

• Lỗi được giới thiệu vì bản sao không phù hợp chính xác (các biến không cần thiết và đường dẫn mã không được dọn sạch)
• Yêu cầu kiểm tra tăng lên - sự trừu tượng hóa giúp loại bỏ nhu cầu kiểm tra hồi quy khi bạn chỉ kiểm tra những gì bạn đã thay đổi và bạn chỉ thay đổi các lá chứ không phải các nhánh.
• Sao y trùng lặp mọi thứ, lỗi bao gồm. Mỗi sửa lỗi hoặc tính năng áp dụng cho cả hai phần mã hiện có chi phí gấp đôi so với thực hiện và có khả năng cao là quên hoàn toàn.
• Tìm kiếm và thay thế làm trầm trọng thêm vấn đề trên, vì bạn không thể dễ dàng tìm thấy mã trùng lặp.

Vũ khí chính trong cuộc chiến chống sao chép và dán chương trình là sự trừu tượng . Vì vậy, để tìm một sự tương tự tốt, hãy tìm các ví dụ về sự trừu tượng trong thế giới xung quanh chúng ta.

Trừu tượng dựa trên ý tưởng thiết lập các định nghĩa và sau đó tiến hành sử dụng các định nghĩa đó trong thực thi. Thế giới sẽ ra sao nếu không có định nghĩa?

• Định nghĩa là một phần quan trọng của ngôn ngữ pháp lý. Hãy tưởng tượng một hợp đồng không có định nghĩa cốt lõi nhưng được xác định đầy đủ mọi điều khoản mỗi khi nó được sử dụng.
• Định nghĩa và mẫu được sử dụng trong xây dựng. Một vấn đề phổ biến trong xây dựng là làm cho mỗi lần cắt mới dựa trên lần cuối chứ không phải dựa trên một phép đo duy nhất được thực hiện ở đầu. Điều này có thể dẫn đến độ dài khác nhau theo thời gian.
• Tổ chức công ty dựa trên tóm tắt và định nghĩa. Điều gì sẽ xảy ra nếu mỗi lần công ty của bạn phải mở rộng, họ phải xác định vai trò mới từ đầu? Điều đó sẽ không làm việc. Vậy điều gì sẽ xảy ra nếu họ quyết định chỉ chọn một vai trò công việc tương tự và sửa đổi một chút cho phù hợp. Mọi người sẽ bị khóa vào vị trí vì không thể di chuyển tài nguyên xung quanh.

Sao chép chỉ có một nơi khi mảnh được sao chép là vĩnh viễn. Mặt khác, mọi bản sao làm cho một chi nhánh hoàn toàn mới được xử lý - được kiểm tra, bảo trì và nâng cấp riêng.

Trừu tượng chiến đấu với điều này bằng cách buộc tất cả các nhánh lại với nhau thành một thân cây và cô lập các sửa đổi cho các nhánh nhỏ hơn hoặc thậm chí là lá.

Tôi nghĩ rằng bạn đang nói về mã trùng lặp, không sao chép dán (sử dụng đoạn mã và tương tự).

Đây là một tương tự từ một cuốn sách lịch sử, minh họa nó rất tốt. Trước báo chí của Gutenberg, các nhà sư đang ngồi và viết sách bằng tay và viết lại cùng một cuốn sách nhiều lần. Những cuốn sách mà các nhà sư đã viết, thường có lỗi và nhờ Gutenberg, vấn đề này đã được loại bỏ.

Một tương tự khác: máy rút tiền. Bạn có một máy rút tiền có thể phục vụ nhiều loại thẻ khác nhau và luôn phục vụ chúng tốt. Mã trùng lặp tạo ra các máy rút tiền khác nhau, vì vậy mọi người sẽ phải chuyển sang một máy khác và đôi khi máy thậm chí sẽ cung cấp cho bạn một BSOD.

Có một bài viết tuyệt vời về dán sao chép từ Jeff http: //www.codinghorror.com/blog/2009/04/a-modest-proposed-for-the-copy-and-paste-school-of-code-reuse. html

PS tôi biết đã có báo in trước Gutenberg.

Đối với những người không phải là lập trình viên, tôi cho rằng chúng ta đang nói chuyện với những người kinh doanh, vì vậy tôi sẽ nói ngắn gọn và liên quan đến thực tế của tiền bạc.

1. Mỗi dòng mã đều tiêu tốn tiền của bạn (cho dù bằng văn bản hoặc sao chép)
2. Mỗi lỗi chi phí bạn nhiều hơn mà mỗi dòng.
3. Mỗi dòng mã thêm các lỗi tiềm năng
4. Mã trùng lặp = lỗi trùng lặp
5. Các lỗi trùng lặp hầu như không bao giờ được tìm thấy trong cùng một chu kỳ thử nghiệm.

Cắt và dán = Đốt tiền.

Tôi không thể trả lời câu hỏi nhưng nói rằng bạn thực sự không cần một sự tương tự ở đây, và cố gắng tìm ra sự tương tự phù hợp cho từng thành ngữ hoặc mô hình phát triển có vẻ gian tà và thường phản tác dụng. Nó giống như cố gắng tập yoga với bàn chân phẳng ...

Có một vài lý do tại sao sao chép / dán dẫn đến các vấn đề, nó truyền các lỗi hiện có vào các khu vực mới dán, trong một số môi trường được coi là tăng cường hiệu suất, giờ đây nó thực sự chậm hơn (tôi có thể cung cấp ví dụ nếu có ai quan tâm, nhưng nó thuộc về JIT và bạn có thực sự nghĩ rằng bạn thông minh hơn một trình biên dịch hiện đại không?).

Nó cho thấy nhà phát triển là lười biếng hoặc ích kỷ hoặc cả hai. Nếu đây là trận chiến bạn đang chiến đấu trong một đội vào lúc này, tùy thuộc vào vị trí của bạn trong đội này (đội trưởng / jnr dev, snr dev, bất cứ điều gì), bạn cần phải sửa nó, có thể bằng trọng tài trong tổ chức của bạn.

EDIT: Trong phần bình luận bên dưới, đây là mã xem xét mã của bên thứ ba thay mặt cho bên thứ ba (hoặc thậm chí có thể là bên thứ tư :)) Có một số điều hữu ích tôi có thể thêm vào.

Đầu tiên, khi mã được sản xuất cho bên thứ ba, họ có bất kỳ số liệu nào không? Dòng mã (LoC) chẳng hạn.

Tôi vẫn nghĩ rằng một số điều tôi nói ở trên vẫn còn tính. Tôi có lẽ cũng nên hỏi mục tiêu của đánh giá là gì. Nếu đó là để có được một trích dẫn để duy trì nó, hoặc thay thế nó, bạn phải hỏi rất nhiều câu hỏi khác nhau.

Dù bằng cách nào, bạn đang đánh giá chất lượng mã, sao chép mọi bản dán thuộc danh mục "Nhà phát triển cho thấy sự hiểu biết đầy đủ về trừu tượng hóa và / hoặc thiết kế kiểm soát luồng chương trình":

Nhận xét: Nhà phát triển không thể hiện bất kỳ hiểu biết nào về tính trừu tượng và cách tiếp cận của họ đối với kiểm soát luồng chương trình dễ bị lỗi. Bạn có thể giới thiệu "Độ phức tạp theo chu kỳ" tại đây. Điều đó thực sự khá dễ hiểu, và trong một vòng về cách tôi nghĩ rằng tôi có thể đã tìm thấy một câu trả lời: D Yay cho tôi.

Ok Cyclomatic phức tạp là như thế này. Bạn có một bản đồ. Nó có vị trí bắt đầu của bạn và mọi điểm đến có thể. Nó không phải là rất nhiều. Hãy suy nghĩ, bãi đậu xe, quán cà phê, nhà vệ sinh. Độ phức tạp theo chu kỳ là thước đo số lượng tuyến đường khác nhau để đến vị trí bắt đầu của bạn đến bất kỳ điểm đến nào.

Sao chép và dán mã có thể sẽ làm tăng độ phức tạp theo chu kỳ bởi vì nó sẽ bao gồm logic lặp đi lặp lại có thể được trừu tượng hóa thành khối (hoặc phương thức) có tên riêng của nó.

Có vẻ hợp lý?

Lấy một từ tiếng Anh cho một cái gì đó. Bây giờ hãy tưởng tượng mỗi khi bạn muốn mô tả điều đó, bạn đã sử dụng định nghĩa từ điển hoàn chỉnh thay vì chỉ từ. Làm thế nào dễ dàng cho người khác hiểu bạn?

Tôi tạo thành một hình ảnh tinh thần của một cái gì đó không có mặt hoặc đó không phải là trường hợp (tưởng tượng) nó Chỉ ra một hành động hoặc trạng thái có điều kiện trên một cái khác; Quá khứ đơn giản của ý chí. Chỉ ra tương lai liên quan đến một thời gian trong quá khứ. Chỉ ra một hành động trong quá khứ đã xảy ra lặp đi lặp lại hoặc thông thường (sẽ) là không dễ dàng; đòi hỏi nỗ lực thể chất hoặc tinh thần lớn để hoàn thành hoặc hiểu hoặc chịu đựng (khó khăn).

Sẽ không hại khi hiển thị một thực tế trước và sau ví dụ về mã thực đã được tái cấu trúc để loại bỏ trùng lặp.

Ngoài ra còn có mối quan tâm toàn vẹn về bảo mật và mã.

Như đã trình bày ở đây , có thể nhúng dữ liệu độc hại vào các ký tự unicode được chuyển vào bảng tạm.

Tùy thuộc vào cách trình soạn thảo của bạn phản ứng với các ký tự unicode, điều này có thể dẫn đến những thay đổi bất ngờ của mã nguồn, đầu ra trình biên dịch không mong muốn hoặc một số điều tôi chưa nghĩ đến.

Có một vài tuyến đường khác nhau mà tôi có thể thấy ở đây:

1. Đạo văn - Một số người có thể nhớ điều này từ trường học, nơi trộm cắp tài sản trí tuệ là một điều không nên. Lập trình sao chép-dán có thể giống như thế này vì ai đó có thể không hiểu nguồn hoặc những gì gotchas có thể đến từ việc sử dụng một giải pháp cụ thể chỉ được sao chép và dán một cách mù quáng mà không phân tích mức độ này hoạt động tốt như thế nào và hiểu tại sao điều này có thể hoặc không thể một giải pháp hiệu quả cho vấn đề.

2. Làm theo chỉ dẫn một cách mù quáng - Hầu hết mọi người có thể đã có kinh nghiệm phải đến một nơi nào đó mà họ chưa từng đến trước đây. Một số có thể đã sử dụng MapQuest hoặc Google Maps để tìm địa điểm và sau đó làm theo các hướng dẫn đã cho. Đã có những câu chuyện về những người bị lạc hoặc chỉ không tìm thấy nơi mà họ được cho là mặc dù phần mềm đã đưa ra những hướng dẫn cụ thể về cách đến đó. Đây là một mối nguy hiểm lớn khác của việc sao chép-dán là giống như nếu ai đó chỉ cho bạn chỉ đường để đi từ A đến B mà không cho bạn thấy bất kỳ bản đồ nào của khu vực có thể khiến chuyến đi khó khăn hơn một chút. Nếu điều đó có vẻ không khó, bạn có thể tăng tiền cược bằng cách yêu cầu người đó đi từ A đến B bịt mắt để họ phải dựa vào các giác quan khác để xác định hướng họ đang đối mặt và đi đến mục tiêu.

Dữ liệu, Thông tin, Kiến thức và Trí tuệ có thể là một mô hình tốt có thể được tham chiếu để cho thấy lý do tại sao tìm kiếm và thay thế không hiệu quả như một giải pháp vì sao chép và dán rất cơ học và không cần suy nghĩ nhiều để dữ liệu được truyền có thể không có kiến ​​thức và sự khôn ngoan của việc sử dụng nó đúng cách. Người ta có thể nhìn vào năng lượng hạt nhân cho các ví dụ về cách hiểu sự khác biệt có thể khá mạnh mẽ. Đối chiếu một lò phản ứng hạt nhân với một quả bom hạt nhân về mặt an toàn và sử dụng để xem làm thế nào biết được những gì đi đâu không đủ để khai thác an toàn sức mạnh của nguyên tử.

Hãy tưởng tượng bạn có một sinh viên nhóm và một bộ quy tắc cho trường. Thay vì đăng các quy tắc ở một nơi chung, tất cả các sinh viên phải tham khảo cho bạn mỗi người một bản sao của các quy tắc. Mỗi học sinh được cho biết họ phải tuân theo bản sao của các quy tắc cho bức thư.

Bây giờ sửa đổi một trong các quy tắc nói rằng trong trường hợp thảm họa, bạn nên đến nơi trú ẩn thảm họa mới. Bạn phải đi đến từng sinh viên và sửa đổi bộ quy tắc của họ. Nếu một trong những học sinh bị trượt và một cơn lốc xoáy, học sinh sẽ đến nơi cũ và chết một cách khủng khiếp.

Ai đó gửi cho bạn một email với một mẫu tài liệu đính kèm. Hãy tiếp tục sử dụng nó cho đến khi mẫu thay đổi. Đừng lo lắng, họ sẽ không quên gửi cho bạn một bản sao được làm mới.

Mô hình chi phí CoCoMo.

http://en.wikipedia.org/wiki/COCOMO

Nỗ lực áp dụng (E) = a * (KLOC) ** b, trong đó b> 1.0

Số mũ đó có nghĩa là nỗ lực xây dựng / duy trì / hỗ trợ / viết lại tăng nhanh hơn số lượng dòng mã.

Có một khía cạnh quan trọng khác đối với thực tiễn tồi tệ này mà chưa ai xem xét: bằng cách sao chép một cách mù quáng (toàn bộ hoặc một phần) mã từ người khác ( không có sự cho phép của họ ), bạn có thể vi phạm luật bản quyền .

Mã hóa sao chép mà tôi thấy là một trong đó nhà phát triển không hiểu hoặc không muốn biết lý do họ đang làm và sao chép các phần khác nhau đã làm "ít nhiều" những gì họ cần, cuối cùng họ nói đùa một cách ngẫu nhiên để làm cho chúng phù hợp với nhau.

Có ba vấn đề chính với điều đó:

1. Nó không bao giờ dẫn đến mã không có lỗi. Không bao giờ.
2. Nếu họ không hiểu mã trong khi viết mã, họ không bao giờ có thể tìm ra mã trong khi gỡ lỗi. Chỉ người khác mới có thể dọn dẹp mớ hỗn độn mà họ đã tạo ra, với chi phí bổ sung.
3. Nếu họ tránh nghĩ về mã họ đang viết, họ sẽ tránh học. Nếu họ tránh học, họ sẽ không bao giờ là một lập trình viên giỏi. Nếu họ không bao giờ trở thành một lập trình viên giỏi, tại sao họ lại thuộc nhóm của bạn?

Giả sử bạn có 5 người bạn gái (bạn ranh mãnh với bạn) và bạn muốn gửi cho tất cả họ một tin nhắn valentine. Bạn gõ chữ cái đầu tiên, thêm tên của cô ấy và đề cập đến một cái gì đó đáng nhớ mà các bạn đã chia sẻ. Sau đó, bạn sao chép và dán bức thư bốn lần, mỗi lần thiếu một ví dụ về tên bạn gái # 1 với bản sao và dán vì bạn đã mắc lỗi đánh máy. Bây giờ, 4 trong số năm người bạn gái của bạn đang trên đường đến nhà bạn gái # 1.