복사 / 붙여 넣기 패턴을 수정하는 방법?

내가 일하는 곳에서 사람들 (컨설턴트)은 가능한 빨리 기능을 릴리스하라는 압박감을 느낍니다. 따라서 올바른 방식으로 작업을 수행하는 방법에 대해 생각하는 데 너무 많은 시간을 소비하거나 무언가를 중단하고 싶지 않기 때문에 코드가 다른 모듈에서 복사되어 수정됩니다.

코드 기반이 회사 전체에 공개되어 있으므로이를 방지하기가 쉽지 않습니다. 많은 사람들이이 일을합니다.

이제 엉망이 이미 존재하므로, 중복을 제거하지 않고 중복을 제거하는 가장 좋은 방법은 무엇입니까?

답의 한 부분은 리팩토링 입니다.

먼저 실수로 변경 사항을 위반하지 않도록 단위 테스트 작성을 시작하십시오. 그런 다음 작은 단계에서 디자인 개선, 중복 제거 등을 시작하고, 각 단계 후에 단위 테스트를 실행하고, 테스트에 실패하면 문제를 해결하거나, 쉽게 해결할 수있는 것보다 더 큰 문제가 발생하면 즉시 되돌립니다.

다른 부분은 교육 입니다.

사람들은 잘못된 코드를 남기지 않도록 배워야합니다. 습관과 사고 과정이 변화하기 어려우며 (때로는 불가능하기 때문에) 이것은 확실히 장기적인 싸움 이다. 그러나 그것 없이는 리팩토링을 위해 계속해서 나쁜 코드 비명 소리가 계속 나옵니다.

좋은 코딩 습관과 나쁜 코딩 습관에 대한 토론을 시작하고 전자의 장점을 전파하기 위해 그룹 코드 검토를 수행 할 수 있습니다. "이와 같은 코드를 작성해서는 안됩니다"라고 말하는 것만으로는 충분하지 않으며 사람들에게 논리와 어려운 사실을 설득해야합니다. 마찬가지로 "당신이있는 경우에 방법이 조각은 코드베이스를 통해 중복 N 번, 당신은 기회가 버그가 그 방법이 발견되면,이 방법은 코드의 각 사본에서 수정 될 것입니다 무엇을 생각하십니까?"

귀사 는 컨설턴트에 대한 인센티브 및 수용 기준 을 수정 해야 할 수도 있습니다. 만약 실수로 코드를 작성하지 않아도된다면 더 쉬운 길을 계속 선택하게 될 것입니다. 회사가 장기적인 유지 보수성에 대해 "빠른 배송"을 계속 평가한다면 아무것도 변하지 않을 것입니다 :-( 따라서이를 관리 담당자 와 논의해야 할 수도 있습니다. 이해하고 유지. 생략 리팩토링은 신용 카드에 하는것 부채처럼. 잠시 동안 그것을 벗어날 수는 있지만 구매 습관과 부채를 적극적으로 관리하지 않으면 언젠가는 어깨에 부딪 칠 것입니다. 소프트웨어 프로젝트의 수명 동안 파산은 프로젝트를 유지 보수 할 수 없게되었을 때입니다. 기존 코드베이스에 새 기능을 추가하는 것보다 처음부터 다시 작성하는 것이 더 쉬워집니다. 또는 사용자는 열등한 수준의 지원 및 기능에 익숙해 져서 단순히 경쟁 업체로 전환 할 수 있습니다.

@Peter와 같은 교육의 일환으로 PMD 와 같은 복사 및 붙여 넣기 탐지기를 도입하고 이를 코딩주기의 일부로 적용하여 빌드 사이클의 일부로 사용할 수 있습니다.

프로젝트 코딩 표준이이 패턴을 포함하는지 확인하여 토론을 시작할 기준이되도록하십시오.

사람들 (컨설턴트)은 최대한 빨리 기능을 릴리스하도록 압박감을 느낍니다.

기술적 인 문제가없고 사회적 문제가 있습니다. 실제로 관리 문제가 있습니다.

코드 기반이 회사 전체에 공개되어 있으므로이를 방지하기가 쉽지 않습니다. 많은 사람들이이 일을합니다.

"코드베이스는 회사 전체에 공개되어 있습니다"는 문제가 아닙니다. 중요하지 않습니다.

중요한 것은 복사하여 붙여 넣기를위한 관리 보상 시스템이 있다는 것입니다. 근본 원인은 사람들이 복사하여 붙여 넣기에 대해 보상 (즉, 지불 또는 칭찬 또는 홍보 또는 연장)하기 때문입니다.

문화를 "가급적 빨리 릴리스하기 위해 눌렀다"에서 "적절하게 테스트 된 코드 기반 변경을 수행 한 것에 대한 보상"으로 문화를 근본적으로 변경하지 않으면이 문제를 해결할 수 없습니다.

당신은해야

1. 보상을 강화하는 관리자와 함께 맨 위에서 시작하십시오. 현재 관행을 폭로하고 비용과 위험을 문서화해야합니다. 비용과 위험을 줄이는 대안을 제안해야합니다.

2. 해당 조직의 나머지 재임 기간 동안 비용과 위험을 끊임없이 문서화하고 노출해야합니다. 잔인한. 사실 기반. 비용과 위험. 매주 더 많은 비용과 복사 및 붙여 넣기로 인한 위험이 증가합니다.

3. 관리자가 새로운 접근 방식을 선호하게 만들면 도움이되어야하므로이를 무시하게됩니다.

복사하여 붙여 넣기를 줄이는 것이 매우 중요합니다. 그러나 조직의 문화를 바꾸기는 어렵습니다. 당신은 많은 사실을 제공해야하며, 당신에게 동의하지 않는 관리자에게 계속해서 사건을 제기해야합니다.

이제 코드베이스가 부패하기 시작했습니다. 기본적으로 다른 모듈의 동일한 정적 함수와 동일한 모듈 당 10 개 이상의 정적 함수가있었습니다. 각각은 행동 단지 가능한 한 빨리 일을 위해서의 새로운 화신을 보장하기 위해 다른만큼.

오늘은 또 다른 기능을 추가해야했으며 더 이상 사용할 수 없었습니다. 새로운 라이브러리를 만들고 100 + 함수를 10 개의 재진입 함수로 결합하여 비트 플래그를 기반으로 동작을 약간 변경 한 다음 해당 라이브러리의 변경 사항이 다른 것을 깨지 않도록 일련의 테스트를 작성했습니다.

총 소요 시간 : 4 시간 나는 필요하다면 20 시간의 마라톤을 뛸 준비가되어 있었고, 내가 얼마나 빠르게 엉망을 통제 하느냐에 놀랐다. 보너스로, 많은 헤더 의존성 문제를 해결하는 것이 더 쉬웠다. 또한, 우리의 독점적 인 많은 것들이 이제 링크를위한 정적 객체에 있기 때문에, 우리는 고객이 이전보다 더 많은 소스 코드에 액세스 할 수있게합니다.

내 충고 : 총알을 물고 그렇게하기 전에 엉망인 리팩터링을하면 실제로 나 빠진다 . 당신이 생각하는 한 오래 걸리지 않을 것입니다. 만약을 대비하여 새로운 지점을 만드십시오.

또한 근본적인 문제 를 해결하는 동시에 복사 / 붙여 넣기 기능을 사용할 수 있습니다 . 완료되면 붙여 넣은 내용을 지우고 대신 새 라이브러리를 사용하십시오.

나는 지금까지 주어진 답변에 동의합니다. 당신은해야합니다 :

• 단위 테스트 작성
• 리팩터링
• 기르다
• 코딩 표준에 노력하고 위반을 감지

그러나 다른 한편으로 사람들이 붙여 넣기를 복사하여 수정하는 원인을 찾아야합니다.

• 사람들은 코드가 많이 결합되어 있기 때문에 좋은 방법으로 코드를 재사용하지 못할 수도 있습니다.
• 사람들은 사용할 수있는 라이브러리가 있다는 것을 모를 수 있습니다
• 라이브러리 코드가 충분히 일반적이지 않을 수 있으며 기존 라이브러리를 사용하는 것보다 자신의 버전을 굽는 것이 훨씬 쉽습니다.
• 좋은 버전 관리 (소스 제어가 아님) 전략이없고 일반 라이브러리를 변경하면 다른 많은 응용 프로그램도 테스트 될 수 있습니다.

따라서 재사용을 쉽게하기 위해 필요한 복사 / 붙여 넣기 패턴을 중지한다고 생각합니다.

• 라이브러리를 검색 가능하고 잘 문서화
• 라이브러리를 모든 것과 독립적으로 만들다
• 좋은 버전 관리 전략을 생각하십시오
• 이전 버전과의 호환성 보장
• 도서관의 쉬운 확장성에 대해 생각

프레임 워크 디자인 가이드 라인 읽기

도움이 되었기를 바랍니다.

"유해한 것으로 간주되는 복사 복사"태도가 있습니다. 나는 그것이 좋다고 생각하지만 너무 멀리 간다. 삼각 측량 과정의 한 단계 로 두 방법 또는 클래스 간의 유사점과 차이점을 발견하는 연습으로 붙여 넣기를 복사하십시오 . 나는 건강하다고 생각합니다. 그러나 복사 붙여 넣기로 인한 중복을 제거하는 완전한 삼각 측량의 부족을 막는 것은 실제로 해 롭습니다.

더 미묘한 태도를 사용하고 개발자에게 "나쁘지 않다!"라고 말하는 것이 아니라 "불완전합니다. 리팩토링을 완료하기 위해 나와 함께 일할 수 있습니까?"

나는 여기서 똑같은 문제에 대해 걱정하고 있으며, 그것을 취하는 것은 : 그것을 피하려고하지 말고 너무 나빠질 때 리팩터링하십시오.

현재 다른 모듈의 사본으로 startet에서 작업하고있는 모듈은 이제 달라야하는 모든 것을 변경하고 있습니다. 이 작업이 완료되고 새 모듈이 완료되면 원래 모듈과 비교하여 변경되지 않은 부분을 찾아서 라이브러리, 추상 상위 클래스 등으로 이동 해야하는 부분을 찾습니다.

담당자는 잘못입니다. 한 사람이 모든 코드 줄을 검토 할 수는 없지만 표준과 기간을 설정합니다.

계약자 (또는 프로젝트에 단기 인 사람)는 처음 일할 때만 보상을받는 위치에 놓일 수 있습니다. 가능한 빨리 끝내도록 인센티브가 있습니다. 복사 된 코드는 수정하지 않아도되며 그렇지 않은 경우에는 수정하지 않아도됩니다.

당신은 그들 자신의 시간에 그것을 고치려고 노력할 수 있습니다. 그런 다음 처음부터 시작하지만 일을 끝내기 위해 시간이 거의 없습니다. AmmoQ는 문제를 일으키는 것들을 리팩토링하는 올바른 아이디어를 가지고 있다고 생각합니다.

복사 / 붙여 넣기 코드를 제거하는 유일한 방법은 (IMHO) 코드 검토, 코드를 확인하는 사람 (또는 바람직하게는 그 이상)이 있고, 복사 / 붙여 넣기 조치에서 온 것으로 보이는 코드를 찾을 때 프로그래머가 리팩토링하도록하는 것입니다.

제안한 바와 같이 이것은 주로 조직의 문제입니다. 사람들을 교육하는 것으로 시작해보십시오 (직접 관리 직위를 잊지 마십시오). 기차에 한두 사람을 데려와 바이러스가 퍼지게하는 데 큰 도움이됩니다. 대다수가 이것이 좋은 아이디어라고 생각할 때, 설명을 구하고 이런 식으로 유지되도록 리뷰를 소개하십시오. 이것은 매우 느리고 지루한 과정이지만 빠르게 변경할 수는 없습니다. 처음에는 추가 시간이 걸리므로 경영진이 장기 목표를 알고 지원하는 것이 중요합니다.

@Anders K. 리뷰는 연습을 유지하기위한 좋은 수단입니다. 사람들이 코드를 작성하도록 강요 할 때 많은 코드를 믿지 않습니다. 그들은 가능한 빨리 오래된 habbit에 다시 떨어질 것입니다. 나는 당신이 운동량을 얻기 위해 교육으로 시작해야한다고 굳게 믿고 있습니다.