Tôi đã học được rất sớm về việc cắt và dán mã của người khác mất nhiều thời gian hơn trong thời gian dài mà tự viết nó. Theo ý kiến ​​của tôi trừ khi bạn thực sự hiểu về nó, việc cắt và dán mã có thể sẽ có những vấn đề sẽ là một cơn ác mộng cần giải quyết.

Đừng hiểu sai ý tôi, ý tôi là tìm mã người khác và học từ nó là điều cần thiết, nhưng chúng tôi không chỉ dán nó vào ứng dụng của mình. Chúng tôi viết lại các khái niệm vào ứng dụng của chúng tôi.

Nhưng tôi liên tục nghe về những người cắt và dán, và họ nói về nó giống như đó là thông lệ. Tôi cũng thấy những bình luận của những người khác cho thấy đó là thông lệ.

Vì vậy, hầu hết các lập trình viên cắt và dán mã?

Hai trường hợp chung:

Từ dự án này sang dự án khác:

Hầu hết các lập trình viên cắt và dán mã trong khả năng này. Họ có thể tìm thấy một dự án trước đó hoặc một cái gì đó trực tuyến và sao chép / dán chính xác hoặc sao chép / dán và thay đổi nó. Tôi nghĩ rằng thực tế này là tốt. Điều này đặc biệt tốt khi nó được chứng minh mã. (Ví dụ: Một số loại đối tượng tiện ích từ một dự án trong quá khứ hoạt động tốt hoặc có thể từ một blog có một vài thay đổi cần thiết). Trường hợp điều này có thể xấu, là khi bạn sao chép mã mà bạn không hiểu hoặc nơi mã kém hoặc nơi có giải pháp thay thế tốt hơn nhiều so với mã bạn đang dán.

Bên trong cùng một dự án: Sao chép và dán trong cùng một dự án thường không phải là một ý tưởng hay. Đây là một mùi hôi mà mã đang được sao chép chỉ nên ở trong một phương thức / lớp ở đâu đó và được gọi lặp đi lặp lại. Có một số trường hợp ngoại lệ cho điều này, nhưng nói chung, lập trình viên nên suy nghĩ: " Có cách nào tôi có thể tham số hóa mã này mà tôi đang sao chép không? ".

Hầu hết các lập trình viên làm điều đó, nhưng điều đó không có nghĩa là bạn nên

Một trong những câu thần chú lập trình của tôi là: "Nếu tôi sao chép và dán mã, tôi đang làm gì đó sai" . Về cơ bản, KHÔ .

Tôi nghĩ rõ ràng là tái sử dụng mã có nghĩa là sử dụng mã làm tài nguyên, không lặp lại mã. Đôi khi tôi đã sao chép và dán mã của riêng mình, trong hầu hết các trường hợp tôi kết thúc bằng mã tấm nồi hơi hoặc những thứ trông thực sự giống nhau.

Sau khi đầu tư thêm thời gian với mã đó sau đó tôi kết thúc như sau:

• Một thành phần (xem thêm: tách mối quan tâm )
• Tôi có thể dùng đến sự phản chiếu để làm cho mọi thứ đơn giản hơn, sạch hơn và dễ dàng gặt hái hơn trong tương lai.
• Một thiết kế tốt hơn , bởi vì ngay cả khi nó hoạt động, tại sao không làm lại từ đầu sau khi bạn học được bài học?.
• Một mẫu mà tôi có thể trừu tượng hóa, biến thành một thành phần thư viện và loại bỏ mã trùng lặp.

Có thể tranh cãi liệu chúng ta nên hay không nên sao chép và dán mã vì khách hàng / sếp không quan tâm (ít nhất là trực tiếp và trong thời gian ngắn) và bạn có thể kết thúc với cùng một kết quả, nhưng vấn đề thực sự xảy ra khi nó xảy ra dẫn đến lỗi, mất mô-đun, và cuối cùng, bảo trì địa ngục.

Những gì bạn nên làm: tái cấu trúc càng sớm càng tốt

Không ai viết mã hoàn hảo, ngay cả khi nó hoạt động, ngay cả khi bạn không sao chép và dán và đó là mã của riêng bạn, nếu bạn không hoàn toàn hài lòng với nó, chỉ cần ghi chú trong bình luận (ví dụ: docblock "@todo") để nhắc nhở hãy tự mình cấu trúc lại cái gì và tại sao ... ngay cả khi bạn không tự mình cấu trúc lại nó, nó có thể trở thành sự khác biệt giữa hạnh phúc và sự thất vọng hoàn toàn cho người duy trì.

Cuối cùng, bạn sẽ kết thúc với mã tốt cuối cùng, ngay cả khi bạn sao chép và dán.

thông qua XKCD

Khi tôi bị mắc kẹt và tìm kiếm công cụ để giải quyết vấn đề của mình và tình cờ thấy một số đoạn mã hữu ích thực hiện những gì tôi muốn, tôi tự nhiên sao chép nó. Đôi khi nó chỉ là ý chính của nó. Sau đó tôi thay đổi nó để đáp ứng nhu cầu của tôi. Điều này xảy ra thường xuyên hơn khi tôi đi sâu vào những thứ mà tôi không phải là chuyên gia (hiện tại, Objective-C).

Tôi luôn dành thời gian để học một cái gì đó từ mã, vì vậy đối với tôi đó là một cách tuyệt vời để học và tránh phát minh lại bánh xe.

Tôi sẽ nói về việc sao chép / dán mã của người khác ở đây. Lấy một phần công việc của tôi từ thư viện cá nhân của tôi là trò chơi công bằng. Tôi biết họ và hiểu họ theo định nghĩa.

Tôi thấy rằng tình huống thường gặp nhất khi tôi "cắt và dán" mã là khi tôi gặp một vấn đề cụ thể và tôi chạy vào một bài đăng trên blog để giải quyết nó. Hầu hết tôi thường nhập lại giải pháp vào dự án của mình (sau tất cả, có lẽ nó được viết theo phong cách của tác giả blog, nếu không có gì khác). Đó thực sự không phải là mã của tôi , nhưng tôi không cảm thấy tệ khi sử dụng nó trong kịch bản đó.

Đi ra ngoài và lấy toàn bộ phương pháp hoặc hệ thống để dán chúng vào dự án của tôi và gọi nó là xong là điều tôi không hiểu. Có một câu hỏi trên StackOverflow vào một ngày khác đã minh họa hoàn hảo vấn đề với việc làm một cái gì đó như thế.

Kết hợp một con quái vật Frankenstein với các phần mã khác nhau không thể hiệu quả đến thế. Ý tôi là, nếu bạn giỏi về điều đó, điều đó có nghĩa là bạn lặp đi lặp lại cùng một giải pháp hoặc bạn đã hiểu đủ về mã của người khác rằng cùng một mức độ sao chép / dán không còn cần thiết và bạn năng suất sẽ cải thiện thông qua việc không phải giải quyết các vấn đề giữa các mẫu mã không tương thích.

Cá nhân tôi đã không gặp nhiều lập trình viên sao chép / dán trên quy mô lớn. Tôi đã thấy nhiều người tự mã hóa vào những góc sâu nhất và tối nhất, nhưng đó là một câu chuyện khác. Dựa trên giai thoại cá nhân của tôi, tôi muốn nói rằng hầu hết các lập trình viên không sao chép / dán toàn bộ ứng dụng với nhau, nhưng thực sự rất khó để nói chắc chắn.

Xấu: Sao chép và dán cùng một khối mã nhiều lần

Nếu bạn thấy mình làm điều này, có lẽ bạn nên dành một giây để suy nghĩ về những gì có thể được trừu tượng hóa khỏi mã được sao chép và tạo một hàm / phương thức để xử lý nó. Đây là nơi tính nguyên tắc DRY (Đừng lặp lại chính mình).

Tốt: Sao chép một khối mã được biết là có tác dụng

DRY (Đừng lặp lại chính mình) cũng áp dụng ở đây, theo một nghĩa khác. IE, đừng lặp lại công việc bạn đã làm trong quá khứ. Nếu bạn đã dành thời gian để viết một phần mã, gỡ lỗi, kiểm tra nó và nó đã được chứng minh là hoạt động trong một cơ sở mã sản xuất; bạn sẽ không thể sử dụng lại nó

Hầu hết mọi người cho sao chép - dán một đoạn rap tệ bởi vì nhiều lập trình viên mới bắt đầu dành thời gian để lùng sục trên mạng và sao chép / dán một mớ hỗn độn mã của người khác mà không hiểu nó thực sự làm gì.

Viết mọi thứ từ đầu mỗi lần không tốt hơn. Tôi biết có rất nhiều lập trình viên theo trường phái thuần túy cũ rằng mọi thứ nên được viết từ đầu và tôi hy vọng tôi không bị mắc kẹt khi làm việc với họ. Nếu bạn có 5 năm kinh nghiệm lập trình, bạn nên có một thư viện mã khá đáng kể để sử dụng lại. Đó là một trong những tài sản tốt nhất mà một lập trình viên có kinh nghiệm có thể mang đến bàn vì nó có khả năng tiết kiệm rất nhiều thời gian phát triển.

Nếu ban đầu bạn không hiểu mã cũ của mình, hãy dành một chút thời gian để đọc các bình luận và tự làm quen lại. Nếu bình luận của bạn tệ ... tốt, đó là một vấn đề khác hoàn toàn.

Sau 25 năm viết mã, đã có những lúc (không có quyền truy cập vào mã tôi đã viết cho một chủ nhân trước đó) Tôi ước mình có thể cắt và dán. TUY NHIÊN điều này đã rất hiếm (và tiếp tục đọc).

Có lẽ ví dụ tốt nhất là một trình phân tích cú pháp dòng lệnh thực sự đơn giản mà tôi đã gặp nhiều năm trước cho các hệ điều hành unix. Một vòng lặp đơn giản nén qua các đối số và xử lý các tùy chọn. Nó rất đơn giản và thanh lịch, và tôi đã sử dụng nó (nhiều hơn là một mẫu hơn là cắt và dán theo nghĩa đen) nhiều lần kể từ đó. Đây là ngoại lệ chứ không phải là quy tắc.

Thông thường, việc cắt và dán ole đơn giản là hoàn toàn không phù hợp - việc cắt và dán khái niệm hay thuật toán của nó trở nên quan trọng hơn.

Tôi không quá tự hào - Tôi sẽ vui vẻ tìm kiếm xung quanh để tìm một thuật toán xác minh mã chẵn lẻ hoặc mã xác thực hoặc một cái gì đó kỳ lạ như thế. Sau đó dành một vài giờ để hiểu nó để xem liệu nó thực sự là thứ cực kỳ nhanh chóng mà tôi đã theo đuổi, hay một đống rác ngây thơ.

Tôi lo lắng mỗi khi ai đó chỉ sao chép mã mà không tạm dừng để hiểu nó. Họ hoặc là một thiên tài (hiểu nó và tất cả sự tinh tế của nó trong nháy mắt), hoặc là một kẻ ngốc. Không có nhiều chỗ cho bất cứ thứ gì ở giữa. Ồ, và cũng không có nhiều thiên tài thực sự.

Không hiểu gì, bạn thực sự không biết bạn vừa ném gì vào THỰC SỰ, không chỉ là những điều kiện hạnh phúc mà cả những điều kiện không vui hay điều kiện đầu vào. Đôi khi điều này không quan trọng vì bạn gặp may mắn. Và đôi khi điều này làm cho đau đớn lâu dài.

Có một tình huống phổ biến mà về cơ bản bạn CẦN phải làm điều đó để có hiệu quả.

Bất kỳ công nghệ nào xa lạ với bạn đều khó học trừ khi bạn có một ví dụ hoạt động để bắt đầu. Do đó, bạn sao chép và dán nó để có một cái gì đó thực sự chạy , và sau đó bắt đầu mày mò với nó.

Là một lập trình viên mới (4 tháng trong công việc đầu tiên của tôi), tôi dựa vào sự giúp đỡ khá nhiều (dù là từ SO hay những nơi khác). Tôi đưa ra quan điểm KHÔNG sao chép và dán mã người khác một cách mù quáng. Ngay cả khi mã được cung cấp là những gì tôi sẽ sử dụng, tôi sẽ nhập nó vào chương trình của mình và sau đó dành một ít thời gian để đảm bảo rằng tôi hoàn toàn hiểu những gì nó làm và lý do cho nó.

Tôi muốn đảm bảo rằng tôi không ngừng học hỏi và không chỉ đơn giản là một chuyên gia về cắt và dán

Tôi có rất nhiều cảm xúc về chủ đề này và tôi không thể thành thật nói bất kỳ ai trong số họ là hoàn toàn khách quan.

Có nhiều đối số để cắt và dán mã của người khác vào ứng dụng của bạn. Một số trong số họ có thể có ý nghĩa, một số có thể không. Chẳng hạn, nếu bạn có một phương pháp từ blog của ai đó lấy đầu vào và chạy một số thuật toán toán học phức tạp nằm ngoài khả năng toán học của bạn và tạo ra kết quả - đó là một đối số để cắt và dán - hãy xin phép tác giả sử dụng mã và ghi có cho họ khi đến hạn - đó là điều đáng trân trọng.

Có những lý lẽ cho việc không phát minh lại bánh xe - một lần nữa, điều này có ý nghĩa, theo lý thuyết. Nhưng nếu bạn không dành thời gian để làm quen với mã bạn đang cắt và dán, bạn sẽ không biết liệu có cách nào tốt hơn để giải quyết vấn đề này không, bạn không biết liệu có lỗi trong mã không . Điều gì nếu bánh xe bạn dán bị hỏng?

Có những lý lẽ về tốc độ và hiệu quả - bạn xây dựng một thư viện mã của người khác mà bạn đã xé, đánh cắp, đạo văn hoặc nói cách khác, bạn có thể không bao giờ cần biết cách lập trình ngoài Frankensteining một số ứng dụng cùng nhau ra khỏi các bộ phận khai hoang.

Có những lúc và những nơi tôi cho rằng hành vi này hoàn toàn chấp nhận được. Để hack cùng nhau các công cụ vứt bỏ nhanh chóng không được thiết kế để có tuổi thọ cao nhưng để hoàn thành nhiệm vụ, ngay bây giờ bằng cách móc hoặc bằng kẻ gian. Với mục đích tạo mẫu và nghiên cứu đồng ý, để học hỏi và thăng tiến trong bối cảnh lý thuyết tôi nghĩ đây là trò chơi hoàn toàn công bằng.

Cắt và dán mã của người khác là đạo văn - nếu bạn có phước lành của họ và bạn hiểu mã bạn đang dán và nó phù hợp với cấu trúc của các tiêu chuẩn mã hóa cho ứng dụng của bạn, thì tốt thôi, tôi sẽ thừa nhận đó là trò chơi công bằng.

Là một kỹ sư phần mềm chuyên nghiệp, tôi được trả tiền để duy trì tiêu chuẩn và quy tắc đạo đức. Tôi không được trả tiền để ăn cắp, ăn cắp hoặc vi phạm bản quyền của người khác khiến khách hàng của tôi có nguy cơ bị truy tố. Bên cạnh đó, có một rủi ro rất thực tế là khi bạn chạy mã cắt / dán đã nói nó có tác dụng phụ thảm khốc.

Không nhắm mục tiêu câu trả lời này vào bạn John, tôi biết bạn rất có khuynh hướng đạo đức khi nói đến các chủ đề như thế này, vì vậy đây thực sự chỉ là một câu nói chung theo hướng của câu hỏi.

Phụ lục : Điều đó nói rằng, tôi cảm thấy rằng việc cắt và dán mã của riêng bạn giữa các dự án là hoàn toàn có thể chấp nhận được - trừ khi nó được viết dưới dạng làm việc cho người khác thuê, trong trường hợp đó bạn không sở hữu bản quyền và bạn nên xin phép của người mà bạn đã mã hóa nó cho. Tôi đã thấy rằng trừ khi mã phù hợp với các khái niệm chức năng sở hữu, hầu hết các nhà tuyển dụng đều đồng ý với bạn sử dụng lại ý tưởng của riêng bạn cho các khách hàng khác.

Cho rằng, trong một kho lưu trữ nguồn mở, 15% tất cả các phương thức được sao chép từ dự án này sang dự án khác (pdf), câu trả lời dường như là có.

Nếu mã tốt thì thay vì sao chép và dán nó nên được tạo thành một thư viện chung. Nhưng mọi người không thể bị làm phiền với việc tái cấu trúc và họ thích có chức năng tương tự được lan truyền bằng bản sao và phương thức.

Thay vì có một luật tuyệt đối phổ biến về sao chép và dán là tốt hay xấu, bạn nên xem khi nào nên sử dụng nó.

Ưu điểm của sao chép và dán là: Giúp bạn đi nhanh Nhược điểm là: Cùng một mã được phát tán ở nhiều nơi và mọi vấn đề được tìm thấy / giải quyết cần phải được giải quyết ở mọi nơi, nếu thay vì sao chép và dán một thư viện được sử dụng làm thư viện chung thì bản cập nhật sẽ tuyên truyền khắp nơi. Đối với một khoản đầu tư ban đầu nhỏ của việc sử dụng một thư viện thay vì trải rộng cùng một mã ở khắp mọi nơi.

Lựa chọn là liệu có tiết kiệm được một chút thời gian ban đầu so với rất nhiều sau đó hay không, sau đó sao chép và dán là cách để thực hiện, nếu không thì tái cấu trúc và đưa nó vào một thư viện chung.

Trong hầu hết các trường hợp, mã bạn sẽ tìm thấy trên mạng sẽ không phù hợp với mục đích chính xác của bạn.

Những gì nhìn thấy bản thân tôi đang làm rất nhiều là sao chép mã từ một ai đó, tước nó xuống bản chất và sau đó thêm mã cho đến khi nó đáp ứng yêu cầu của tôi. Tôi sẽ luôn cấu trúc lại nó để phù hợp với quy ước đặt tên và phong cách mã hóa của tôi.

Cá nhân tôi ghét nó khi tôi đọc một hướng dẫn và họ bắt đầu bằng cách hiển thị mã cho một trường hợp phức tạp. Bắt đầu với bản chất và hiển thị các khối xây dựng để mở rộng mã. Nếu tôi từng bắt đầu một blog riêng, tôi sẽ cung cấp cho mọi người một ví dụ mã nhận xét cho thấy bản chất của những gì tôi muốn làm, cách bạn có thể thêm chức năng / trường hợp đặc biệt và ví dụ hoạt động đầy đủ của tính năng cơ bản.

Tại sao phải phát minh lại bánh xe nếu bạn hiểu mã đang làm gì, có quyền sử dụng lại mã (hoặc mã mở) và bạn không nhất thiết cần tất cả mã mà người khác đã viết. Tôi thường xuyên sao chép một triển khai thuật toán và sửa đổi nó theo nhu cầu của riêng tôi. Thông thường mặc dù khi tôi chỉ cắt và dán nó là bởi vì tôi không cần tất cả mọi thứ trong ví dụ nên việc thêm một tệp khác sẽ chỉ là một sự lãng phí (hoặc đó là một cái gì đó bên trong một chức năng). Tôi đồng ý với jzd nếu bạn đang cắt và dán mã của riêng bạn trong cùng một dự án thì có một số sai lầm và có lẽ bạn nên tìm ra một cách kinh tế để lib nó hoặc chia sẻ chức năng.

Tôi thấy rằng các thành viên nhóm " tích hợp " hoặc những người không có nhiều kinh nghiệm về mã hoặc trong lập trình có xu hướng sao chép và dán thường xuyên hơn và không hiểu những gì họ đã làm (gặp phải các vấn đề được đề cập trong câu hỏi của bạn).

Tôi cũng thấy rằng các lập trình viên thường tránh xa việc cắt và dán vào sự phiền muộn của họ vì họ yêu thích mã và thường phát minh lại bánh xe, chỉ vì họ muốn làm điều đó tốt hơn hoặc tìm hiểu thêm.