DRY는 소프트웨어 프로젝트 관리의 적입니까?

가장 기본적이고 널리 인정되는 소프트웨어 개발 원칙 중 하나는 DRY입니다 (반복하지 마십시오). 또한 대부분의 소프트웨어 프로젝트에는 어떤 종류의 관리가 필요합니다.

이제 관리하기 쉬운 작업 (예상, 일정, 제어)은 무엇입니까? 올바른 반복 작업, DRY에 따라 피해야 할 작업.

따라서 프로젝트 관리 관점에서 기존 코드를 100 번 복사하여 작업을 해결하고 필요에 따라 각 복사본에 약간의 적응을하는 것이 좋습니다. 항상, 당신은 당신이 한 일과 남은 양을 정확히 알고 있습니다. 모든 관리자가 당신을 사랑합니다.

대신 DRY 원칙을 적용하고 중복 코드를 어느 정도 제거하는 추상화를 찾으려고하면 상황이 다릅니다. 일반적으로 많은 가능성이 있습니다. 결정을 내리고 연구하고 창의력을 발휘해야합니다. 짧은 시간에 더 나은 솔루션을 제안 할 수도 있지만 실패 할 수도 있습니다. 대부분의 경우 실제로 얼마나 많은 작업이 남아 있는지 말할 수 없습니다. 당신은 프로젝트 매니저의 최악의 악몽입니다.

물론 나는 과장하지만 분명히 딜레마가 있습니다. 내 질문은 : 개발자가 DRY를 과도하게 수행하는지 여부를 결정하는 기준은 무엇입니까? 우리는 어떻게 좋은 타협을 찾을 수 있습니까? 아니면 타협점을 찾는 것만이 아니라이 딜레마를 완전히 극복 할 수있는 방법이 있습니까?

참고 :이 질문은 이전의 것과 동일한 아이디어, 소프트웨어 개발에 대한 일상적인 작업량 및 추정에 대한 영향과 같은 아이디어를 기반으로 하지만 내 주장을 더 명확하게 생각합니다.

프로젝트 관리의 주요 목표는 정확한 견적을 산출하는 것으로 가정합니다. 그렇지 않다. 프로젝트 관리의 기본 목표는 개발자와 동일합니다. 제품 소유자에게 가치를 제공합니다.

자동화보다는 느린 수동 프로세스를 많이 사용하는 제품은 이론 상으로는 추정하기가 더 쉽지만 (의심 할지라도) 고객에게 가치를 제공하지 않으므로 단순히 프로젝트 관리가 좋지 않습니다. 딜레마가 없습니다.

소프트웨어 프로젝트의 평가는 어렵다는 것이 잘 알려져 있으며이를 관리하기 위해 수많은 책이 작성되었으며 다양한 프로세스가 개발되었습니다.

PM 의 유일한 목표가 정확한 추정치를 생성하는 것이면 쉬울 것입니다. 추정값을 10 배로 채우고 개발자가 조기에 완료하면 나머지 게임을 할 수 있습니다. 게임을해도 제품의 유지 관리 성이 줄어들지 않기 때문에 복사 붙여 넣기 작업을 사용하여 시간을 절약하라는 제안보다 실제로이 방법이 더 좋습니다.

그러나 실제로 제품 소유자는 유용한 견적 과 품질이 우수한 제품을 가능한 한 빠르고 저렴하게 제공하기를 원합니다 . 이는 PM이 탐색해야 할 실제 제약 조건입니다.

어쨌든 반복적 인 수동 작업이 자동화 된 것보다 더 예측 가능하다고 가정합니다. 모든 경험은 반복적 인 작업임을 보여줍니다 더 에러가 발생하기 쉬운. 복사하여 붙여 넣은 코드에서 버그가 발견되면 어떻게해야합니까? 갑자기 버그 수정 비용에 반복 횟수가 곱 해져서 불확실성이 폭발합니다.

복사-붙여 넣기가 훌륭하고 DRY는 복사 된 템플릿이나 사본을 향후에 유지 관리하거나 발전시킬 필요가없는 프로그램을 만드는 것이 중요하지 않습니다. 이 두 소프트웨어 구성 요소의 수명주기가 완전히 다른 경우 공통 코드를 리팩토링하여 자체 개발중인 자체 라이브러리에 리팩토링하여 이들을 함께 결합하면 실제로는 노력에 예측할 수없는 영향을 줄 수 있습니다. 반면에 하나의 프로그램 또는 프로그램 시스템 내에서 코드 섹션을 복사 할 때 일반적으로이 모든 부분은 동일한 수명주기를 갖습니다. DRY 및 프로젝트 관리에 이것이 무엇을 의미하는지 아래에서 설명하겠습니다.

예를 들어, 컴퓨터 게임 산업은 최대 몇 개월 또는 1 년 동안 짧은 기간 동안 유지해야하는 많은 프로그램을 생성하고, 그 시간이 지나면 복사 붙여 넣기를 수행합니다. 유지 보수 기간이 끝난 이전 게임의 오래된 코드를 새 게임의 코드 기반으로 완벽하게 처리하면 속도가 빨라질 수 있습니다.

불행히도, 지난 몇 년 동안 처리해야했던 대부분의 프로그램의 수명주기는 그와 매우 다릅니다. 나에게 도착한 요구 사항 또는 버그 수정 요청의 98 %가 변경 요청 이었습니다.기존 프로그램의 경우 또한 기존 소프트웨어에서 무언가를 변경해야 할 때마다 "프로젝트 관리"또는 계획은 테스트 및 디버깅 노력이 매우 적을 때 가장 잘 작동합니다. 이는 한 곳에서 무언가를 변경하더라도 복사로 인해 발생하지 않습니다. 붙여 넣은 비즈니스 로직을 사용하면 코드베이스에서 다른 12 곳을 변경해야한다는 것을 쉽게 잊을 수 있습니다. 모든 장소를 찾더라도 모든 장소를 변경하고 변경 사항을 테스트하는 시간은 변경해야 할 장소가 한 곳인 것처럼 훨씬 높습니다. 따라서 변경 사항을 정확하게 예측하여 프로젝트 예산과 쉽게 충돌 할 수있는 비용보다 수십 배 높은 비용이 발생할 수 있습니다.

TLDR-원본 또는 사본의 버그 수정 및 유지 관리가 필요하지 않은 프로그램을 개발할 때마다 자유롭게 복사하십시오. 그러나 귀하, 귀하의 팀 또는 회사가 책임을 지거나 책임을지는 경우 가능할 때마다 DRY를 적용하십시오.

예

부록으로, "버그 수정 및 유지 관리"의 의미와 실제 사례를 통해 특히 하나의 제품 내부에서 계획을 예측할 수없는 방법에 대해 설명하겠습니다. 실제로 이러한 종류의 일이 실제로는 100 인스턴스가 아니라 실제로 발생하는 것을 보았지만 복제 인스턴스가 하나만 있으면 문제가 시작될 수도 있습니다.

작업 : 응용 프로그램에 대해 100 개의 서로 다른 보고서를 작성합니다. 각 보고서는 매우 유사하게 보이며, 보고서 간의 요구 사항 차이, 논리가 다르지만 전혀 차이가 없습니다.

이 작업을 수행하는 개발자는 첫 번째 작업을 생성하고 (3 일이 소요될 수 있음) QA 및 고객 검사가 완료되어 일부 버그가 수정되거나 사소한 버그 수정이 완료된 후 정상적으로 실행되는 것 같습니다. 그런 다음 전체 내용을 복사하여 붙여넣고 다음 보고서를 수정하여 다음 보고서를 작성하기 시작했으며 새 보고서마다 평균 ~ 1 일이 필요했습니다. 언뜻보기에 매우 예측 가능합니다 ...

이제 100 개의 보고서가 "준비"되면 프로그램이 실제 프로덕션으로 이동하고 QA 중에 간과 된 몇 가지 문제가 발생합니다. 성능 문제가 있거나, 보고서가 정기적으로 충돌하거나, 다른 작업이 의도 한대로 작동하지 않을 수 있습니다. 이제 DRY 원칙을 적용했을 때 코드 기반을 한 곳에서 변경하면 이러한 문제의 90 %를 해결할 수 있습니다. 그러나 복사-붙여 넣기 방식으로 인해 문제는 한 번이 아니라 100 번 해결되어야합니다. 한 보고서에서 다른 보고서로 변경 사항이 이미 적용되어 있기 때문에 개발자는 첫 번째 보고서에 대한 수정 사항을 다른 보고서에 신속하게 복사하여 붙여 넣을 수 없습니다. 그는 100 개의 보고서를 모두보고 수정하여 변경 사항을 번역해야합니다. 보고, 테스트 및 개별적으로 디버깅 할 수 있습니다. PM의 경우 이것은 정말 어려워지기 시작합니다. 그는 물론 "일반적인"버그 수정 (3 시간이라고하자)에 시간을 걸리고 이것을 100으로 곱할 수 있지만, 실제로 이것은 아마도 잘못된 추정 일 것입니다. 다른 사람보다 만들기가 더 쉬울 수 있습니다. 그리고이 추정이 정확하더라도 디버깅 비용이 필요한만큼 100 배나 높아지면 회사에 많은 비용이 들게됩니다.

다음에 고객이 모든 보고서에서 회사 엠블럼의 색상을 변경하거나 페이지 크기를 구성 할 수 있도록하거나 비슷한 방식으로 모든 보고서에 영향을 미치는 다른 새로운 요구 사항을 요구할 때도 마찬가지입니다. 따라서 이러한 상황이 발생하면 비용을 추정하고 코드가 건조되었을 때 지불해야 할 가격의 100 배를 고객에게 청구 할 수 있습니다. 그러나 이것을 몇 번 시도하면 고객은 엄청난 진화 비용을 기꺼이 지불하지 않기 때문에 프로젝트를 취소합니다. 그리고 아마도 그 시점에서 누군가가 왜 이런 일이 발생했는지 질문 하고이 카피 붙여 넣기 프로그래밍을 결정한 사람을 손가락으로 가리킬 것입니다.

내 요점은 : 당신이 다른 사람들을 위해 소프트웨어를 생산할 때, 당신은 항상 일을 작동시키고, 버그를 수정하고, 변화하는 요구 사항에 프로그램을 적응시키는 등의 책임을 항상 단기간 동안 가지고 있습니다. 그린 필드 프로젝트에서도, 부품은 초기에 계획된 개발 노력보다 훨씬 더 빠르게 추가 할 수 있습니다. 특히 복사하여 붙여 넣은 모든 코드가 하나의 제품에 포함 된 경우 책임 기간은 모든 부분에 대해 동일합니다. 더 이상 사용되지 않는 죽은 프로젝트에서 일부 오래된 코드를 복사하여 붙여 넣은 상황과는 다릅니다. 적극적인 유지 관리.

따라서 프로젝트 관리 관점에서 기존 코드를 100 번 복사하여 작업을 해결하고 필요에 따라 각 복사본에 약간의 적응을하는 것이 좋습니다. 항상, 당신은 당신이 한 일과 남은 양을 정확히 알고 있습니다. 모든 관리자가 당신을 사랑합니다.

기본 어설 션이 잘못되었습니다.

소프트웨어를 만드는 것은 다른를 다른 직업에서 당신은 매일 새로운 것을 만들고있어 것입니다. 결국, 어떤 고객은 비용을 지불하려고하지 않습니다 당신을 다른 사람이 이미 만든 무언가를 구축 할 수 있습니다. 프로젝트 관리자는 예측을 좋아하지만, 수 그들의 같은 상사 값 . 약간의 변형으로 코드를 복사하여 붙여 넣는 경우 회사에 큰 가치를 제공하지 않습니다.

결국 이 회사는 우수한 프로그래머를 고용함으로써 짧은 시간 안에 동일한 작업을 수행 할 수 있다는 것을 알게 될 것입니다. 그렇지 않은 경우 경쟁 업체가 그럴 것입니다.

잘라 내기 및 붙여 넣기 프로그래밍은 결국 소프트웨어 포기로 이어집니다. 나는 매우 큰 전화 회사에서 유선 서비스를 주문하는 시스템의 계약자였습니다. 모든 테스트가 수동으로 이루어졌고 작업 코드를 변경하고 싶지 않았기 때문에 시스템은 잘라서 붙여 넣었습니다. 가장 작은 향상으로 인해 수백 줄의 코드 사본이 새로 생성 될 수 있습니다. 원래이 응용 프로그램은 최대 12 개의 실제 줄을 처리하도록 작성되었습니다. 물론이 제한은 코드의 수백 곳에서 이루어졌습니다. 약 4 년 후 비즈니스는 팀에게 더 큰 계정을 처리하는 데 무엇이 필요한지 물었습니다. 그들은 약 1 천 8 백만 달러를 추정했습니다. 이 시점에서 프로젝트는 최소한의 유지 관리를 위해 해외 팀으로 전환되었습니다. 기존 팀이 모두 해고되었습니다.

이러한 방식으로 생각하는 조직은 더 나은 기술을 보유한 회사에 의해 쇠약 해지고 있습니다.

여기에 적용되는 잊혀진 최대 값 은 3의 규칙입니다 . 즉, 코드를 한 번 복사해도 괜찮지 만 일반 코드로 대체해야합니다.

3은 임의의 숫자처럼 보이지만 일반적인 시나리오는 응용 프로그램 및 데이터베이스에서 데이터와 논리가 복제되는 것입니다. 데이터베이스와 조회 클라이언트 측에 조회 테이블이있는 경우가 자주 인용됩니다. 패러다임의 차이로 인해이를 한 곳에 쉽게 저장할 수 없으므로 정보가 종종 두 곳에 나타납니다.

DRY 코드를 사용하는 것이 좋지만 비즈니스 로직이 예외를 지시하는 경우가있을 수 있으므로 이전에 일반적인 소스에서 두 개 이상의 코드를 작성해야합니다.

그래서 뭐 할까? 현 상태에 대한 코드 (결국 YAGNI ). 코드는 수정하기 쉽도록 작성되어야하지만, 필요하지 않을 수도있는 종과 휘파람을 작성하는 것은 단지 돈을 버는 것입니다.

귀하의 질문에는 프로젝트 관리의 세 가지 기능, 즉 추정, 일정 및 제어 만 나열됩니다. 프로젝트 관리는 프로젝트의 제약 내에서 목표를 달성하는 것입니다. 프로젝트 제약 조건 내에서 목표를 달성하는 데 사용되는 방법은 다른 많은 유형의 프로젝트와 소프트웨어 프로젝트에서 다릅니다. 예를 들어, 제조 공정을 반복 가능하고 잘 이해하기를 원합니다. 그러나 소프트웨어 개발은 ​​대부분 지식 작업입니다-일상적이지 않으며 엄격한 지침과 절차를 따르는 것이 아니라 사고가 필요합니다. 소프트웨어 프로젝트를 시작, 계획, 실행, 모니터링 및 제어하고 닫는 데 사용되는 기술은 소프트웨어 프로젝트에서 수행해야하는 작업 유형, 특히 수행 할 수없는 비 루틴 작업을 설명해야합니다. 특정 지침 및 절차.

또 다른 문제는 정보의 반복과 관련된 개념 인 DRY를 취하여 작업 관리에 적용하려는 것입니다. DRY는 단순히 정보에 대한 권위있는 표현은 하나만 있어야한다고 말합니다. 프로젝트 관리자는이 정보를 수용해야합니다. 모든 사람이 정보를 어디로 가야하는지 알고 변경 사항을 쉽게 전달할 수 있으며 변경 내용을 잘 관리하고 관리 할 수 ​​있기 때문입니다. DRY는 재사용 가능한 부분을 통해 장기 비용을 낮추고, 장기 일정을 유지하고, 프로젝트 관리 삼각 지대에 3 가지 품질을 향상시키는 데 도움이됩니다 . 효과적으로 DRY를 만들기 위해 시간과 돈을 투자해야하지만 프로젝트 관리자는 시간, 비용, 일정 및 품질을 절충해야합니다.

새 코드 작성은 작업의 일부일뿐입니다

귀하의 제안은 처음에 새로운 코드를 작성하는 부분을 더 쉽게 추정 할 수있게합니다. 그러나 실제로 (새로운 시스템이든, 기능 추가 또는 기능 변경이든) 새로운 작업을 수행하는 것만으로는 충분하지 않으며 단지 소수의 작업 일뿐입니다. 부분은 전체 작업의 20 % -40 %와 같습니다.

따라서 초기 개발을 실제로 필요한 것, 통합, 테스트, 재 작성, 다시 테스트에 적용하는 작업을 포함하여 대부분의 작업을 쉽게 추정 할 수 없습니다. 다른 방법으로, 의도적으로 DRY를 피하는 것은 그 부분을 훨씬 더 크고 단단하며 더 가변적 인 추정치로 만들었습니다. 완전히 잘못 될 것입니다.

적은 부분의 작업에 대한 추정 품질을 향상 시키지만 많은 부분의 작업에 대해서는 더 나쁜 추정을함으로써 더 나은 추정을 얻을 수 없습니다. 따라서 실제로는 절충이 아니라 생산성이 떨어지지 만 추정치가 낮아지는 손실 상황입니다.

DRY는 유용하지만 과대 평가되었습니다. 어떤 사람들은 그것을 너무 멀리 가져갈 수 있습니다. 많은 개발자들이 깨닫지 못하는 것은 두 가지 (약간) 다른 목적으로 동일한 방법을 사용하기 위해 DRY를 구현할 때마다 서로 다른 용도 사이에 매우 엄격한 결합을 도입한다는 것입니다. 이제 첫 번째 유스 케이스에 대한 코드를 변경할 때마다 두 번째 유스 케이스를 회귀하는지 여부도 확인해야합니다. 이것들이 광범위하게 독립적 인 유스 케이스라면 밀접하게 결합되어야하는지 여부는 매우 의심 스럽습니다. 아마도 그렇지 않아야합니다.

DRY를 과도하게 사용하면 일반적으로 일부 코드를 복제하는 더 작은 원자 적 방법이 훨씬 더 유지 관리가 가능할 때 사용되는 모든 다양한 사용 사례를 처리하기 위해 복잡하게 폭발하는 신 방법이 생길 수 있습니다.

그러나 질문은 프로젝트 관리 수준에서 실제로 관련이 없다는 것을 제안합니다. 프로젝트 관리자는 실제로 이러한 수준의 구현 세부 사항에 관심을 갖기를 원하지 않습니다. 그것들이 아마도 미세 관리 일 것입니다. 실제로 ... 구현 방법 은 개발자와 기술 책임자의 책임입니다. 프로젝트 관리는 무엇 을 언제 수행 해야하는지에 더 관심이 있습니다.

편집 : 의견에 따르면 , DRY를 피하면 개발 시간을 쉽게 예측할 수있는 한 때로는 불확실성을 줄일 수 있다는 데 동의합니다 . 그러나 나는 이것이 (1) 비즈니스 요구 사항이 충족 될 때까지의 기간, (2) 프로세스에서 어떤 기술적 부채가 취해지고 있는지, (3) 총 비용에 대한 위험과 관련하여 더 시급한 문제와 관련하여 중요한 문제라고 생각합니다. 건축 선택의 소유권-많은 경우에 DRY를 갈 것인지 아닌지를 결정하는 것은 프로젝트 관리자에게보다 정확한 정보를 제공하는 것이 조금 더 쉬운 지 여부보다 그 요소에 대한 위험 / 보상에 더 기반을 두어야하는 디자인 선택입니다. .

나는 당신이 DRY를 오해하고 있다고 생각합니다.

예를 들어 봅시다 :

public Class A
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }
}

public Class B
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }

    public int Add(int x, int y)
    {
        return x + y;
    }
}

vs.

public Class C : A
{
    public int Add(int x, int y)
    {
        return x + y;
    }
}

클래스 B를 C로 대체함으로써 DRY 원칙을 따르고 코드 중복을 줄였습니다. 그러나 이전에 상속을 한 적이 없다면 프로젝트에 대한 미지 또는 위험을 증가시키지 않았습니다.

DRY에 대해 이야기 할 때의 의미는 디자인 작업과 비슷하다고 생각합니다. 즉 :

public Class A
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }
}

새로운 요구! 일부 고객은 두 배로 곱할 수 있어야합니다 !!

// Use class B for new clients!!
public Class B
{
    public int Multiply(double x, double y)
    {
        return x * y;
    }
}

vs.

public Class A // Version 2
{
    public int Multiply(int x, int y)
    {
        return Multiply(x as double, y as double);
    }

    public int Multiply(double x, double y)
    {
        return x * y;
    }
}

여기에서 (작동한다고 가정) 우리는 실제 요구 사항이나 비즈니스 규칙의 수학적 모델을 만들려고 노력하면서 이전 요구 사항과 새로운 요구 사항을 모두 처리 할 수있는 솔루션을 설계했습니다. 실제로 우리가 모델링하는 시스템은 훨씬 더 복잡 할 것이며, 우리의 모델은 정확하게 맞지 않을 것이며, 최종 사례와 예기치 않은 결과를 찾아서 수정하는 데 시간이 걸릴 것입니다.

그렇다면이 경우 B 또는 A 버전 2를 사용해야합니까?

• B는 부작용이 적고 실제 요청 된 변경에 더 구체적이며 추정하기 쉽고 더 빨라질 것입니다.

• 버전 2는 전반적인 코드가 줄어들고보다 우아한 솔루션이 될 것입니다.

다시 한 번 말하지만 사양 및 요구 사항의 품질에 달려 있습니다.

우리가 에지 케이스와 이전 버전과의 호환성을 다루는 매우 명확한 사양을 가지고 있다면 버그를 생성하지 않고 모델을 리팩토링 할 수있을 정도로 시스템을 충분히 이해할 수 있습니다.

단일 시스템에 대한 긴급 요청이있는 경우 전체 시스템을 고려하지 않고 해당 고객의 동작이 변경되어야하는 유일한 요구 사항입니다. A를 리팩토링하여 모델을 '개선'하면 상당한 위험이 따릅니다. 솔루션을 설계하고 테스트하는 데 필요한 추가 알 수없는 시간으로 인해 다른 고객을 차단하거나 마감일을 초과하는 경우.

단락 별 단락

가장 기본적이고 널리 인정되는 소프트웨어 개발 원칙 중 하나는 DRY입니다 (반복하지 마십시오). 또한 대부분의 소프트웨어 프로젝트에는 어떤 종류의 관리가 필요합니다.

옳은.

이제 관리하기 쉬운 작업 (예상, 일정, 제어)은 무엇입니까? 올바른 반복 작업, DRY에 따라 피해야 할 작업.

반복적 인 작업은 자동화되고 의무적 이어야합니다 . 손으로 만들면 지루하고 오류가 발생하기 쉽습니다.

따라서 프로젝트 관리 관점에서 기존 코드를 100 번 복사하여 작업을 해결하고 필요에 따라 각 복사본에 약간의 적응을하는 것이 좋습니다. 항상, 당신은 당신이 한 일과 남은 양을 정확히 알고 있습니다. 모든 관리자가 당신을 사랑합니다.

"configuration"으로 "adaptation"이라는 단어를 변경할 수 있다고 생각합니다. 이 코드 조각에 복사해야 할 버그가 있다고 가정하십시오. 특정 조건에서 나타나는 버그. 원본 소스에서 수정되지 않은 경우 복사 할 부분이 많이 있습니다. 이것은 나쁠 수 있지만 누군가는 다음을 수행해야합니다.

• 먼저 원본 소스에서 코드를 수정하십시오.
• 다른 모든 장소에서 코드를 수정하십시오.
• 그 장소가 모두 있는지 확인하십시오. 관리자에게이 작업을 수행해야한다고 말하면 적어도 누군가를 미워할 것입니다.

대신 DRY 원칙을 적용하고 중복 코드를 어느 정도 제거하는 추상화를 찾으려고하면 상황이 다릅니다. 일반적으로 많은 가능성이 있습니다. 결정을 내리고 연구하고 창의력을 발휘해야합니다. 짧은 시간에 더 나은 솔루션을 제안 할 수도 있지만 실패 할 수도 있습니다. 대부분의 경우 실제로 얼마나 많은 작업이 남아 있는지 말할 수 없습니다. 당신은 프로젝트 매니저의 최악의 악몽입니다.

중복을 제거하면 단일 실패 지점이 발생합니다. 무언가가 실패하면 어디서 이런 일이 벌어 질지 확신 할 수 있습니다. SOLID와 Design Patterns는 바로 그 문제를 해결하는 데 도움이됩니다. 마감일이 너무 짧으면 절차 스타일 "코딩"을 유발하는 경향이 있습니다. 재사용 가능한 무언가를 만들기 위해 하나의 프로젝트에 더 많은 시간을 투자했다는 것은 기능이 재사용 될 때 다음 프로젝트에 소요되는 시간이 최소화되어야한다는 것을 의미 하지만 , 처음부터 구성 할 수 있어야합니다 .

물론 나는 과장하지만 분명히 딜레마가 있습니다. 내 질문은 : 개발자가 DRY를 과도하게 수행하는지 여부를 결정하는 기준은 무엇입니까? 우리는 어떻게 좋은 타협을 찾을 수 있습니까? 아니면 타협점을 찾는 것만이 아니라이 딜레마를 완전히 극복 할 수있는 방법이 있습니까?

많은 사람들이 여기서 딜레마가 없다고 지적했습니다. 예, 아니오

이전에 해본 적이없는 실험적인 것이 있다면 딜레마가 없습니다. 그렇지 않으면 새로운 예약 시스템과 같이 다시 수행해야 할 작업이있는 경우 이미 추상화 된 것이므로 필요한 항목에 따라 다릅니다.

나는 딜레마가 있다고 생각합니다. 기능이 요청되지 않을 경우 기능에 무언가를 구현해야합니다. 요청시 무언가를 구현하십시오. 아무도 사용하지 않을 거대한 인프라가 필요하지 않습니다.

이것은 향후 재사용을위한 설계 나 YAGNI 원칙에 관한 것이 아닙니다. 현재 작업 패키지에서 코드를 반복하는 것입니다.

절대적으로 디자인에 관한 것입니다. 어쩌면 다시 사용 그럼에도 불구하고 자체 있지만 디자인.

개발자가 DRY를 과도하게 수행하는지 여부를 결정하는 기준은 무엇입니까?

경험과 기존 환경 / 상황. 주어진 문제에 대해 더 높은 건조도를 시도 할 때 프라도 원리에 대한 강한 감각을 얻게됩니다. 그런 다음 갑자기 경영상의 고려가 이루어집니다. 시간, 목표, 고객, 장기 코드 관리 (누군가 기술 부채 ) 등이 공격 계획을 알려줍니다.

우리는 어떻게 좋은 타협을 찾을 수 있습니까?

어 ... 디자인? 리팩토링은 디자인입니다. DRYing의 범위는 루프에서 메소드, 클래스로 슈퍼 노바처럼 쉽게 확장 할 수 있습니다. 거기에 있었어요. 그러나 문제를 연구하기 전까지는 실제로 알 수 없습니다. 이것이 디자인입니다.

어떻게 디자인 문제가되지 않습니까? 직접 복제 된 코드보다 문제를 더 광범위하게 고려해야합니다. 이것은 기존 코드이든 빈 시트이든 관계없이 디자인 활동입니다. "추출 방법"이든 새 클래스와 모듈 생성이든.

발문

... 참조 된 질문과 답변은 프로젝트 관리 측면을 다루지 않습니다.

설계 시간을 무시하고 일반적인 관리. 이상적으로 코딩하기 전에 불필요한 여분의 반복성을 설계했을 것입니다. 대신 경영진은 개발 (및 버그 수정)이 실제로는 카탈로니아 인 단일 올림픽 이벤트 (코딩)라고 생각합니다. 그들은 모두 아날로그라고 생각하기 때문에 1/1000 초로 측정됩니다.

대신 DRY 원칙을 적용하고 중복 코드를 어느 정도 제거하는 추상화를 찾으려고하면 상황이 다릅니다.

나는이 경험을했다 : "GUI 양식의이 행을 작성하는 데 이틀을 보냈고 나머지 양식을 작성하는 데 2 ​​시간이 걸렸다." 나는 재사용 할 수있는 클래스를 식별하는 데 시간이 걸렸다는 것을 의미합니다-DRY는 자연스러운 부작용입니다-GUI 양식 행 및 다른 클래스. 일단 디버깅되면이 코드는 현재 매우 빠르게 코딩 된 형태에 걸쳐 개별적으로 그리고 구성 적으로 사용되었으며, 빌드 업 복잡성에도 불구하고 테스트는 매우 빠릅니다. 그리고 놀랍게도 낮은 버그 비율로 공식 테스트를 수행했습니다.

대부분의 경우 실제로 얼마나 많은 작업이 남아 있는지 말할 수 없습니다. 당신은 프로젝트 매니저의 최악의 악몽입니다.

나도 몰랐지만 앞선 디자인 노력이 효과가있을 것이라고 믿었다. 우리 모두는 이것을 말하지만 특히 경영진은 그것을 신뢰하지 않습니다. 경영진은 내가 망치고 있다고 생각했을 것입니다. "2 일이 지났지 만 아직 2 %도 코딩하지 않았습니다!"

어떤 경우에는 경영진이 "디자인에 너무 많은 시간을 소비하고 있습니다."라고 말했을 때 총을 고수했습니다. 그리고 동료들은 "너무 많은 수업입니다."라고 말합니다. 글쎄, 훨씬 덜 복잡한 하위 프로젝트는 약 1 개월이 걸리고 (나는 야구장 추측이라고 생각했지만) 5 개월이 걸렸습니다. 3 개월은 POS이므로 테스트 / 고정에있었습니다. "그러나 우리는 디자인 할 시간이 없었습니다!". 그들은 실제로 그렇게 말했습니다.

내 질문은 : 개발자가 DRY를 과도하게 수행하는지 여부를 결정하는 기준은 무엇입니까? 우리는 어떻게 좋은 타협을 찾을 수 있습니까? 아니면 타협점을 찾는 것만이 아니라이 딜레마를 완전히 극복 할 수있는 방법이 있습니까?

관리 방법을 보여줍니다. 일부 데이터를 캡처하십시오. 다른 작업, 특히 슬랩 대시 대쉬 작업을 수행하는 동료의 작업과 비교하십시오. 그 실패의 더미는 항상 경쟁에서 패배하고 테스트에 갇히고 릴리스 후에 더 많은 버그를 수정하기 위해 다시 돌아온 것 같습니다.