코드의 "복사 및 붙여 넣기"가 위험한 이유는 무엇입니까? [닫은]

때로는 상사가 우리에게 불평 할 것입니다.

기능을 구현하는 데 오랜 시간이 필요한 이유는 무엇입니까?

실제로이 기능은 이전에 다른 응용 프로그램에서 구현되었으므로 코드를 복사하여 붙여 넣기 만하면됩니다. 비용이 낮아야합니다.

복사 및 붙여 넣기 코드는 제 관점에서 그렇게 간단한 것이 아니기 때문에 실제로 어려운 질문입니다.

비 기술적 인 상사에게 이것을 설명 할만한 충분한 이유가 있습니까?

복사-붙여 넣기 코드에서 버그를 발견 한 경우, 모든 위치에서 버그를 수정하고 모든 것을 기억할 수 있기를 바랍니다 (변경된 요구 사항에도 해당됨).

한 곳에서 논리를 유지하면 필요할 때 변경하는 것이 더 쉽습니다 (따라서 응용 프로그램을 업데이트해야한다고 결정한 경우 한 곳에서만 수행).

상사에게 DRY 원칙 에 대해 읽게하십시오 (반복하지 마십시오).

당신이 설명하는 것은 코드를 공유하고 한 곳에만 보관하는 라이브러리 에 대한 완벽한 사용과 같습니다 .

나중에 코드를 리팩터링 하려는 경우에만 코드를 복사하여 붙여 넣을 수 있습니다. 나중에 추출 된 공통 코드를 사용하여 최대한 많은 로직을 재사용 할 수 있도록해야합니다. 그리고 머지 않아 몇 분이지나 몇 일이 아니라 몇 주가 지났습니다.

복사 및 붙여 넣기를 사용하여 코드를 복사 하는 대신 라이브러리를 작성하여 코드를 공유 하는 것이 훨씬 좋습니다 .

여전히 재 작성보다 속도 이점이 있지만 (DRY 조회) 코드를 유지할 수있는 곳은 한 곳뿐입니다.

분명한 이유는 미래에 대한 '부채'를 취하기 때문입니다. 코드 수정, 버그 수정뿐만 아니라 변경해야 할 모든 변경 사항은 두 곳을 업데이트해야하기 때문에 비용이 두 배나 비쌉니다. 결국에는 그중 하나를 잊어 버리기 때문에 더욱 위험합니다. 다시 말해, 지금 작업 속도를 높이면 향후 작업 속도가 더 느려질 수 있습니다. 이는 비즈니스에 적합하지만 일반적으로는 그렇지 않습니다.

그러나 더 중요한 이유는 "이것과 동일하다"라는 가정이 미묘하게 잘못되지 않는 것보다 더 자주 있기 때문입니다. 코드가 무언의 가정에 의존 할 때마다, 다른 가정으로 코드를 복사하면 이러한 가정이 새로운 위치에 있지 않으면 오류가 발생합니다. 따라서 붙여 넣은 코드는 종종 다음 변경 이후가 아니라 처음부터 잘못되었습니다.

디자인 방식으로 복사하여 붙여 넣은 코드는 확실히 재앙이며 앞으로 많은 문제가 발생할 수 있습니다. 그것은 당신에게 많은 일을 소요하지만 왜 당신이 요구하는지 지금 , 대답은 : 그것은 결코 바로 복사하지 않고 붙여 있기 때문에.

유연성과 클라이언트 사용을 염두에두고 상당히 독립적 인 라이브러리로 재사용하기 위해 원래 코드를 작성했다면 훌륭하지만 복사 붙여 넣기는 아니지만 코드 라이브러리를 사용합니다. 실제 코드 복사 붙여 넣기는 일반적으로 다음과 같습니다.

• "물론, 이미 정확히 그렇게하는 코드가 있습니다!"
• "잠깐,이 5 가지 버전의 코드 중 어느 것이 내 소스로 사용하고 싶은가?"
• "흠,이 모든 'util_func_023'기능은 무엇을합니까? 문서화하지 않았습니까? 지금 어떤 기능이 필요합니까?"
• "오, 예,이 코드는 코드베이스 Y를 사용 합니다. 하나를 선택 해야 합니다. 하나를 선택하십시오 : 모든 코드베이스 Y를 새 프로젝트에 복사하거나 코드베이스 Y에서 원하는 기능을 익히고 하루를 보내십시오. 코드베이스 Y에서 원하는 기능 하나] "
• "저는 모든 것을 복사했습니다!"
• "왜 작동하지 않습니까?"
• 이것은 실제로 시작하려는 코드를 작성하는 대신 원하는 코드와 유사한 기존 코드를 디버깅하는 데 시간 / 일 / 주를 소비하는 지점입니다.

요약하자면, 직접 사용할 수없는 기존 코드는 기껏해야 유사한 코드 작성을위한 훌륭한 참조 자료가 될 수 있습니다. 확실히 전체를 들어 올릴 수 없으며 완전히 다른 시스템에서 작동 할 것으로 예상됩니다. 일반적으로 작성되고 완성 된 코드는 원본 자체가 아니라 사본 인 경우에도 가능한 한 많이 엉망으로 만들어야한다는 안전한 가정입니다.

당신이 복사 붙여 넣기에 프로젝트를 기반으로하고 싶은 경우에, 당신은 코드에있어 시작하기 쉬운 재사용을 가능하게하는 방식으로 하지 않고 원래의 코드를 복사하고 그것으로 장난. 그럴만 한 가치가 있으며, 그것이 상사가 기대하는 것이라면, 둘 다 그것이 처음부터 디자인하고 작업하는 방식인지 확인해야합니다.

복사 및 붙여 넣기는 재난이 발생하기를 기다리는 재난입니다. 상사는 최종 사용자에게 배송 된 코드가 파손 된 가격과 관련하여 배송 가격을 조기에 평가해야합니다.

이미 기능을 구현하고있는 경우 필요 복사하여 재사용 붙여, 당신이 뭔가 잘못을했을처럼 들린다. 이러한 기능을 라이브러리에 넣을 수 없으므로 복사 / 붙여 넣기없이 재사용 할 수 있습니까?

DRY 원칙 (반복하지 마십시오) : Wikipedia에서 DRY .

"모든 지식은 시스템 내에서 하나의 명백하고 권위있는 표현을 가져야합니다."

다른 링크 .

그것은 당신의 비 기술적 인 상사가 가지고있는 최악의 오해처럼 들립니다. 당신의 직업이 주로 타이핑하고 있다는 것입니다. 그들은 타이핑을 제거함으로써 많은 시간을 절약 할 수 있다고 생각합니다.

이 사람에게 줄 수있는 최고의 교육은 입력하지 않은 모든 작업을 지적하는 것입니다. 대부분의 작업이 타이핑과 동시에 보이지 않게 머리에 나타납니다.

물론 타이핑을 제거하면 시간이 절약됩니다. 그러나 훨씬 더 크고 타이핑이 아닌 작업의 일부는 더 커지고 시간을 절약하고 더 많이 먹습니다.

상사가 DRY 원리, 버그 및 기타 기술에 대해 듣고 싶습니까?

상사 나 회사가 프로젝트를 완료하는 데 필요한 시간을 과소 평가했을 때 일반적으로 들리는 이러한 의견. 그리고 잘못된 추정에 근거하여 계약서 등이 서명되었습니다. 대부분의 경우 프로그래머는 추정에 관여하지 않았습니다.

왜 이런 일이 발생합니까? 때로는 프로젝트 스폰서의 예산이 너무 적습니다. 소프트웨어를 사용하여 자동화하는 비즈니스 프로세스가 팀의 노력에 가치가 없을 수도 있습니다. 이러한 경우 관리자는 일반적으로 나쁜 소식으로 인해 매우 폐쇄되는 경향이 있습니다. 프로젝트가 시작될 때 희망적인 생각이 있습니다. 그런 다음 관리자는 프로그래머를 비난합니다. 귀하의 경우에는 복사하여 붙여 넣기를 통해 간접적으로. 극단적 인 경우이를 사망 행진 이라고 합니다 .

코드 복사 및 붙여 넣기는 일반적으로 우연의 프로그래밍 으로 이어집니다.

나는 " 다른 응용 프로그램이 다른 응용 프로그램이 이미 테스트 한 경우"여기 열쇠 및 사용, 그것은해야 변경할 수 없습니다 , 따라서 당신은 그것과 코드 공유 할 수 없습니다 공통 라이브러리를 사용 할 수 있습니다.

동일한 응용 프로그램 내에서 "복사 및 붙여 넣기"는 좋지 않지만 다른 팀에서 개발 한 코드 기반 또는 다른 릴리스 주기로 "복사 및 붙여 넣기"가 가장 좋습니다.

나는 비슷한 회사에서 일했다. 연수생으로서 나는 그때 더 잘 몰랐으므로 새로운 프로젝트를 시작할 때 상사는 다른 곳에서 코드를 붙여 넣기를 제안했습니다. 글쎄, 당신이 생각할 수 있듯이, 전체 소프트웨어는 엉망이었습니다. 버그를 고치려고 할 때 두 가지 새로운 버그가 나타났습니다.

다른 응용 프로그램에 필요한 기능이 이미 있더라도 해당 기능의 코드는 주요 재 작성 없이는 현재 응용 프로그램에 맞지 않을 수 있습니다. 포드 모터를 도요타에 장착하려고하는 것과 같습니다. 일반적으로, 복사 한 코드의 25 % 이상을 수정해야하는 경우 처음부터 다시 작성하는 것이 더 좋습니다.

문제의 코드를 매력적인 라이브러리 사운드로 추출하지만 다른 시스템의 구축 방법에 따라 사운드보다 어려울 수 있습니다. 예를 들어 해당 기능에 대한 코드는 많은 다른 코드를 부정한 방식으로 인터페이스하기 때문에 추출하기 어려울 수 있습니다 (예 : 많은 전역 변수에 액세스하는 등)

상사에게 각 변수 이름의 일부에는 이전 프로젝트의 이름이 포함되어 있으며 이제는 모두 수동으로 변경해야한다고 말합니다. 상사가 왜 복사 / 붙여 넣기가 나쁜지 알지 못하거나 알고 싶은 경우 :)

예, 가장 큰 문제는 단순히 복사하여 붙여 넣기가 아니라 복사하고 붙여 넣은 다음 약간 수정한다는 것입니다.

그런 다음 붙여 넣은 변형 중 하나에 문제가 있으면 나중에 변경됩니다. 그런 다음 나중에 다른 변형이 변경됩니다.

그런 다음 모든 변종이 변경되어 원본 복사본에 버그가 발생했음을 알 수 있습니다. 붙여 넣은 모든 영역이 동일하지 않기 때문에 이제는 잘 고정되어 있습니다.

그리고 당신은 그것을 알지 못합니다.이 종류의 엉터리 코딩은 대개 거의 전적으로 주석이 없습니다.

저에게 차이점은 동일한 코드를 여러 코드 사본으로 가지고있을 때 가지고있는 것은 많은 코드입니다. 각 특정 작업을 수행하는 코드가 하나만 있으면 시스템이 있습니다.

단일 포인트 수정으로 시스템의 동작을 매우 쉽게 변경할 수 있습니다. 많은 코드의 동작을 변경하려면 많은 코드가 필요합니다.

나는 코드가 아니라 시스템을 좋아한다.

즉각적인 기능의 개발 속도 (특히 응용 프로그램이 작은 경우)와 응용 프로그램이 증가함에 따라 장기적인 유지 관리 비용 사이에는 상충 관계가 있습니다.

복사 및 붙여 넣기는 즉각적인 기능을 위해 더 빠르지 만 버그를 수정하고 시스템 전체를 변경하고 응용 프로그램의 여러 구성 요소간에 워크 플로를 유지 관리하는 측면에서 응용 프로그램의 크기가 커짐에 따라 막대한 비용이 발생합니다.

그것이 사업주들이 들어야 할 주장입니다. 차량을 유지 관리하는 데 드는 비용과 비슷하지만 소프트웨어를 사용하면 소프트웨어 아키텍처의 깨진 부분이 일반적으로 비즈니스 측면에 숨겨져 있으며 개발자 만 볼 수 있습니다.

팀이 이전에 비슷한 기능을 구현했다면 반복하는 것이 두 번째 로 훨씬 쉬울 것 입니다.

그러나 각 응용 프로그램이 다르다고 설명해야합니다. 한 집에 문을 설치했다고해서 평평한 시간 에 다른 집에 다른 문을 설치할 수 있다는 의미는 아닙니다 . 경험 때문에 문이 더 빨라지지만 (# 문이 설치되어 있음) 장비를 얻는 데 여전히 시간이 걸립니다 , 도어를 장착하고 수직인지 확인한 후 프레임에 끼 웁니다.

우리 회사에서는 항상 클래스와 메서드를 사용하여 기술 문서를 작성합니다. u가 좋은 키로 자신의 svn 검색 응용 프로그램을 사용하여 이전에 사용 된 메소드 클래스를 찾을 수 있다면 최선의 방법이라고 생각합니다. :)