프로젝트 관리 팀은 "작동"이라는 말이 100 % 완료된 것으로 간주한다는 개념이있는 것으로 보입니다. 대부분의 프로그래머는 항상 그렇지는 않다는 것을 알고 있습니다. 일부 기능을 작동시키기 위해 대체 접근 방식을 시도한다고해서 반드시 최상의 솔루션을 찾은 것은 아니며 다른 개발자와 검토 한 후 재 작업이 필요하지 않습니다. 나는 종종 무언가를 끝내고 물러서서 비즈니스 규칙을 충족시킨 후에 더 잘할 수있는 일을 스스로에게 묻습니다. 이 "나는 더 잘할 수있는"시간이 실제로 타임 라인 내의 어느 곳에 맞아야합니까? 최선의 접근 방식은 코드를 찾은 것보다 항상 어느 정도 더 나은 코드를 유지한다는 것입니다. 이는 출시 후 리팩토링을 의미 할 수 있습니다. 하나,
답변:
폭포와 민첩성 모두에서 리팩토링 및 최적화의 필요성을 결정하는 중요한 원칙이 하나 있습니다. YAGNI (You Ai n't Gonna Need It). 두 번째 원칙은 첫 번째의 추론이다 : "조기 최적화는 모든 악의 근원", 일반적인 속담과 동등한 코딩 "우수의 적은 완벽"이다.
priciples를 가지고 적용하자. 특정 유형의 파일을 가져 와서 정보를 추출한 다음 해당 정보를 데이터베이스에 저장하는 ETL 알고리즘을 빌드해야합니다. 이번 주 목표는 (애자일 또는 SDLC 매장에 있든 상관없이) 우리가 목표를 달성하는 것입니다.
당신은 똑똑한 사람이며 큰 그림을 엿볼 수 있습니다. 이것이 프로젝트에 ETL이 필요한 유일한 파일 유형은 아니라는 것을 알고 있습니다. 따라서 다른 유형의 파일에서도 작동하도록이 ETL 알고리즘을 구현하는 것이 좋습니다. 이렇게하면 YAGNI를 위반하게됩니다. 다른 파일에 대한 알고리즘을 개발하지 않아야합니다. 그것은 주말에 필요한 하나의 파일에 대한 알고리즘을 개발하는 것입니다. 해당 목표를 달성하고 승인 테스트를 통과하려면 해당 알고리즘을 개발하고 올바르게 작동해야합니다. 다른 파일과 함께 작동하도록 추가 코드를 "필요하지 않습니다". 지금 통합하는 데 시간을 절약 할 수 있다고 생각할 수도 있고, 옳을 수도 있지만, 몹시 틀릴 수도 있습니다. 다른 파일에 대한 알고리즘은 코드를 사용할 수없는 시스템 영역에서 사용해야하거나 새 파일에 대한 요구 사항이 사용자가 모르는 방식과 다를 수 있습니다 (민첩한 경우 요구 사항이 아직 존재하지 않을 수 있습니다). 그 동안 시간을 낭비하고 불필요하게 알고리즘의 복잡성을 증가 시켰습니다.
이제 다음 주가되었으며 첫 번째 알고리즘에 대한 훌륭한 연구 결과에 대한 모호한 보상으로 두 가지 새로운 파일 형식에 대한 알고리즘을 작성하는 작업을 받았습니다. 이제 알고리즘이 더 많은 파일에서 작동하도록하려면 추가 코드가 필요합니다. 파일 별 개별 단계가 포함 된 기본 패턴을 사용하는 템플릿 메소드 패턴을 사용하여 기존 알고리즘을 확장하거나 기존 알고리즘에서 공통 인터페이스를 도출하고 인터페이스를 따르는 두 개의 새로운 알고리즘을 개발하여 플러그인 할 수 있습니다. 사용할 알고리즘을 선택할 수있는 객체
개발하는 동안 시스템이 초당 10KB의 원시 데이터를 처리 할 수 있어야한다는 것을 알고 있습니다. 로드 테스트를 수행하고 초기 드래프트 알고리즘이 8KB / s를 처리 함을 찾으십시오. 글쎄, 그것은 AAT를 통과하지 못할 것입니다. 알고리즘을 보면 O (my God) 복잡성 루프 구조가 있다는 것을 알 수 있습니다. 당신은 그것을 합리화하고 12KB / s를 얻습니다. "정말 좋다"라고 생각하지만 "코드에 루프가 불량한 경우 다른 것을 제거 할 수 있습니까?"라고 생각합니다. 버즈 "초기 최적화"규칙을 위반했습니다. 코드가 작동하고 모든 요구 사항을 통과합니다. 요구 사항이 15KB / s를 요구하도록 업데이트 될 때까지 "완료"되었습니다. 이런 일이 발생하면 코드를 다시 가져 와서 개선 할 사항을 찾으십시오.
애자일이든 기존 SDLC이든 개발 과정에서 다음과 같은 간단한 프로세스를 따르십시오. "첫 번째 패스에서는 작동 시키십시오. 두 번째 패스에서는 예쁘게 만드십시오. 세 번째 패스에서는 SOLID로 만드십시오." 이것이 의미하는 바는 코드를 처음 작성할 때 코드가 올바르게 작동하고 버그가 없도록하지만이 코드 내의 디자인 규칙에 너무 많은주의를 기울이지 말아야한다는 것입니다. 다시는이 영역을 만지지 마십시오. 다음 번에 해당 코드 줄을 방문하면 자신이 틀렸다는 것을 증명 한 것입니다. 더 이상 일회성 시스템이 아닙니다. 가독성, 코드 간결성 및 / 또는 DRY 원칙에 맞게 리팩토링하십시오 (일부 코드를 5 번 복사하기 위해 붙여 넣기하여 루프 및 / 또는 메소드 호출로 리팩토링 할 수 있음). 해당 코드 줄에서 또는 그 주변에서 세 번째로 작업 할 때
작동하고 테스트를 거친 경우 왜 수정합니까?
이것은 엔지니어 / 프로그래머로서 자신의 개인적인 기질에 위배 될 수 있지만, 그것이 작동하는 경우 계속 정제하기 위해 어떤 비즈니스 가치가 있습니까? 시간이 지남에 따라 유지 관리가 더 쉬워 집니까? 그렇다면 민첩한 방법론을 사용하여 백 로그에 새 항목을 작성하여 기존 코드를 세분화하고 리팩토링 할 수 있어야하며 백 로그에있는 다른 항목과 우선 순위를 갖습니다. 이는 민첩한 프로세스의 가치 중 일부입니다. 팀은 가장 중요한 사항과 다음에 수행 할 사항을 함께 결정합니다.
우리 팀은 또한 우리가 "기술 부채"라고 부르는 것을 추적하므로, 무언가 효과가 있지만 더 잘 할 수 있다고 알고 있다면 기술 부채로 기록합니다. 우리는 스크럼을 사용하며 때로는 스프린트에서 모든 작업을 일찍 완료합니다 (예상치에 거의 근접하면 대략 절반의 시간을 조금 일찍 끝내야 함). 그러나 완전히 새로운 것을 끌어낼 충분한 시간이 없습니다. 우리는 기술 부채를 되돌아 가서 더 많은 시간을 소비합니다. 백 로그의 사용자 스토리와 같이 공식적으로 추적되지 않으며 가능한 시간이있을 때마다 거의 작업 할 수 있습니다.
또한 "완료"작업을 호출 할 때는 사용자의 판단에 달려 있습니다. 코드의 상태가 마음에 들지 않으면 작업을 완료로 표시하지 마십시오.
리팩토링에 만족할 때까지 코드를 100 % 완료로 표시하지 마십시오. 코드를 리팩토링하는 데 드는 비용 / 혜택을 지속적으로 평가해야합니다. 충분히 공부하면 코드를 개선하는 방법이 항상 보이기 때문입니다.
TDD의 빨간색 녹색 리 팩터 방법을 사용합니다. 그래서 리팩토링은 개발에 내장되어 있습니다. 기본 모델 또는 이와 유사한 것을 변경하는 것과 같은 큰 리팩토링의 경우 먼저 시간을 소비하기 위해 경영진을 구매하게합니다.
"출시 후 리팩토링"은 무시한 회귀 테스트 및 QA 시간에 숨겨진 비용이 있으며,보고 된 버그 및 새로운 / 요청 된 기능 및 변경 사항에 대해 작업하지 않는 기회 비용도 포함합니다. 탄 스타 플
가치가 있다면, 특별한 예외가 아닌 일반적인 프로세스를 통해 우선 순위를 정하는 작업을 수행하는 것이 좋습니다. 결국 팀의 일원이며 공통 목표를 달성하고 작업 코드를 수정하여 일정에 영향을 미치는 일정을 임의로 연장합니다.
따라서 실제 답을 얻으려면 리팩토링하려는 경우 작업의 일부로 해당 시간을 예약하십시오. 스크럼 / 애자일을 수행하는 경우 정리 작업 시간 상자를 사용하십시오. 폭포 / 나선형이라면 프로세스의 리 팩터 부분을 코드 검토하고 모듈을 수락하십시오.
일부 기능을 작동시키기위한 대체 접근 방식을 시도한다고해서 반드시 최상의 솔루션을 찾았다는 의미는 아닙니다.
...이 경우 아직 100 % 완료되지 않았습니다 ...
또는 다른 개발자와 검토 한 후 재 작업이 필요하지 않습니다.
코드 검토 및 후속 재 작업이 개발 수명주기의 일부인 경우 모든 기능이 완료 될 때까지 기능이 다시 수행되지 않습니다.
나는 종종 무언가를 끝내고 물러서서 비즈니스 규칙을 충족시킨 후에 더 잘할 수있는 일을 스스로에게 묻습니다. 이 "나는 더 잘할 수있는"시간이 실제로 타임 라인 내의 어느 곳에 맞아야합니까?
때에 따라 다르지. 리팩토링을 의미하는 경우 원래 개발 작업의 일부 여야합니다. 잠재적으로 더 나은 알고리즘을 실험한다는 의미라면 별도의 작업이 될 수 있습니다.
최선의 접근 방식은 코드를 찾은 것보다 항상 어느 정도 더 나은 코드를 유지한다는 것입니다. 이는 출시 후 리팩토링을 의미 할 수 있습니다. 그러나 프로젝트 팀은 종종이 방법을 사용하는 것이 매우 불편합니다. 다시 시도해도 효과가 있고 테스트를 마친 이유는 무엇입니까?
간단히 말해 코드는 여러 수준에서 손상 될 수 있기 때문입니다.
그것은 지금 작동하는 것입니다. 깨끗하고 확장 가능하며 장기적으로 유지 관리 할 수 있는지 여부는 완전히 다릅니다.
자세한 답변은 이 스레드를 참조하십시오 .
내가보고 읽을 수있는 한, 이것은 해결되지 않은 질문입니다. 따라서 회피는 "YAGNI"와 같은 최초의 응답과 같은 답변입니다. 사실 애자일에는 리팩토링을 할 수있는 곳이 없습니다.
지금까지 가장 좋은 대답은 기술 부채에 대한 것입니다. 불행히도 이것은 많은 기업에서 소프트웨어의 슬픈 현실입니다. 민첩한 방법이든 민첩하지 않은 방법론이든 상관없이 모든 것을 즉시 처리하려는 서두르는 것이 일반적입니다. "최소한 비즈니스 요구 사항 충족"및 "YAGNI"(코드를 깨끗하게 유지하는 것과 관련하여)라는 좋은 것으로 합리화됩니다.
모든 사람이 TDD를 수행하면 좋을 것이며, 모든 개발자가 한 번의 대답으로 제안한 것처럼 두 번째 또는 세 번째 리팩터링하면 좋을 것입니다. 그러나 그것은 현실 세계에서는 일어나지 않습니다. 다양한 기술 수준의 개발자는 거의 항상 빠른 솔루션을 찾는 데 어려움을 겪고 있습니다. 결과적으로 코드는 유지 보수가 불가능한 코드의 산으로 붕괴되어 새로운 개발자가 해독하는 데 며칠이 걸리므로 생산성이 저하되고 마감 시간이 지연됩니다. "유지 불가능한"이란 복사 및 붙여 넣기 솔루션, 5000 개의 라인 클래스 등을 의미합니다.이 코드와 수정 사항에 대한 이러한 수정 사항은 모두 비즈니스의 핵심입니다! -첨가제 솔루션의 경우 YAGNI와 같은 것은 없다고 주장합니다! 항상 깨끗한 코드가 필요합니다. 코드가 깨끗하지 않으면 꼭 필요하지 않을 것입니다. 자기 충족 예언을 참조하십시오. 개발자는 코드를 전혀 사용하지 않기 때문에 그 코드를 전혀 사용하지 않기 위해 많은 노력을 기울일 것입니다. 그리고 악순환이 계속되어 진흙 전체가 뭉개져 다시 쓰여질 때까지 계속됩니다.
따라서 코드 리팩토링이 적절하고 독창적이며 가치가있는 독자적인 Agile 개념이 아니더라도 리팩토링 할 시간을 내야합니다. 일부 상점에서는 현재 팀이 스프린트의 20 %를 기술 부채에 지출하도록 요구하고 있습니다. 민첩한 지지자들이 YAGNI에 대한 생각을 바꾸고 별도의 시간 할당 된 활동으로 리팩토링 할 장소를 마련하기를 바랍니다. 그리고 그들이 이미 알고 있지만들은 적이 없다면, 내가 알고 싶어하는 부분을 설명해주십시오.
O(my God)-complexity아무것도 없으면 +1 해서 나를 웃게 만들었습니다.