참고로 새 직업을 찾으십시오. 이것은 나아지지 않을 것입니다.

검토중인 코드의 목표는 다음과 같습니다.

• 요구 사항에 따라 작동해야하는 기능을 제공합니다.

• 기술 부채의 증가를 줄입니다.

첫 번째 목표는 유닛, 통합, 시스템 및 기능 테스트가 여기에 있는지, 관련성이 있는지 그리고 테스트해야하는 모든 상황을 포괄하는지 점검하여 검토합니다. 또한 원래 작성자가 프로그래밍 언어에 대해 가질 수 있는 신념 을 확인해야합니다 . 이로 인해 미묘한 버그 나 실제 작업과 다른 행동을하는 코드로 이어질 수 있습니다.

두 번째 목표는 귀하의 질문에 중점을 둔 것입니다. 한편으로 새로운 코드는 기술 부채를 증가시키지 않을 것으로 예상됩니다. 반면에 검토 범위는 코드 자체이지만 전체 코드베이스의 맥락에서 볼 수 있습니다. 여기에서 검토 자로서 원래 작성자의 두 가지 접근 방식을 기대할 수 있습니다.

• 외부 코드는 내 잘못이 아닙니다. 방금 기능을 구현하고 전체 코드베이스에 신경 쓰지 않습니다.

  이러한 관점에서, 코드는 코드베이스의 결함을 복사하므로 필연적 으로 기술 부채가 증가 합니다. 코드가 많을수록 항상 더 나쁩니다.

  이 방법은 장기적으로는 유효한 단기 접근 방식이지만 지연이 증가하고 생산성이 낮아져 결국 개발 프로세스가 너무 비싸고 위험하게되어 제품의 진화가 중단됩니다.

• 새로운 코드를 작성하는 것은 레거시 코드를 리팩토링 할 수있는 기회입니다.

  이러한 관점에서, 레거시 코드의 결함이 새로운 코드에 미치는 영향은 제한 될 수 있습니다. 또한 기술 부채가 줄어들거나 코드 증가에 비례하여 증가하지 않을 수 있습니다.

  이것은 유효한 장기 접근 방식이지만 단기적인 위험이 있습니다. 주요 하나가, 단기, 그것은 것입니다 때로는 특정 기능을 제공하는 데 더 많은 시간이 걸릴. 또 다른 중요한 측면은 레거시 코드가 테스트되지 않은 경우 리팩토링하면 회귀가 발생할 위험이 크다는 것입니다.

격려하고자하는 관점에 따라 검토 자에게 리팩토링을 더 많이하거나하지 말라고 조언하는 경향이있을 수 있습니다. 모든 경우에, 깔끔한 코드베이스 안에 멋진 아키텍처와 디자인으로 완벽하고 깨끗한 코드 조각을 기대하지 마십시오. 권장 하지 않는 것은 엉터리 코드베이스 작업 을 해야하는 지식이 풍부한 개발자가 자신의 역할을 잘 수행하려고하는 행동 입니다. 일을 더 단순하게 만드는 대신 이전보다 더 복잡하게 만듭니다. 이제는 균일하지 않은 잘못된 코드 대신 디자인 패턴이있는 부분, 깨끗하고 명확한 코드가있는 부분, 시간이 지남에 따라 광범위하게 리팩토링 된 부분 및 일체가없는 부분이 있습니다.

예를 들어, 중간 크기 웹 사이트의 레거시 코드베이스를 발견한다고 가정하십시오. 일반적인 구조 가 부족 하고 로깅이 완료되면 로깅 프레임 워크 대신 텍스트 파일에 직접 물건을 추가하여 로깅한다는 사실에 놀랐습니다 . MVC 및 로깅 프레임 워크를 사용할 새 기능을 결정합니다.

동료가 다른 기능을 구현하고 있으며 완벽한 크기를 만들 수있는 ORM이 없기 때문에 매우 놀랍습니다. 그래서 그는 ORM을 사용하기 시작합니다.

귀 하나 동료 모두 MVC, 로깅 프레임 워크 또는 ORM을 사용하기 위해 수십만 줄의 코드를 사용할 수 없습니다. 실제로, 수개월의 작업이 필요할 것입니다. MVC 소개를 상상해보십시오. 얼마나 걸립니까? 또는 코드 내부에서 연결 (때때로 SQL 주입을위한 위치 포함)을 통해 SQL 쿼리가 혼란스럽게 생성 된 상황에서 아무도 이해할 수없는 ORM은 어떻습니까?

당신은 훌륭한 일을했다고 생각하지만, 이제는 프로젝트에 참여한 새로운 개발자가 이전보다 훨씬 더 복잡해 져야합니다.

• 요청을 처리하는 오래된 방법

• MVC 방식은

• 오래된 로깅 메커니즘

• 로깅 프레임 워크

• SQL 쿼리를 즉시 구축하여 데이터베이스에 직접 액세스

• ORM.

하나의 프로젝트에서 4 개의 로깅 프레임 워크가 나란히 사용되었습니다 (수동 로깅 포함). 그 이유는 누군가가 물건을 기록하려고 할 때마다 일반적인 접근 방식이 없었기 때문에 새로운 프레임 워크 (모든 경우에 코드베이스의 5 %에서만 사용됨)를 배우는 대신 단순히 다른 프레임 워크를 추가하기 때문입니다 이미 알고 있습니다. 혼란을 상상해보십시오.

더 나은 방법은 코드베이스를 한 번에 한 단계 씩 리팩터링하는 것입니다. 로깅의 예를 다시 한번 살펴보면 리팩토링은 다음과 같은 작은 단계로 구성됩니다.

• 레거시 로깅이 수행되는 모든 위치 (즉, 로그 파일에 직접 액세스하는 경우)를 찾아 모두 동일한 메소드를 호출하는지 확인하십시오.

• 해당되는 경우이 코드를 전용 라이브러리로 이동하십시오. 장바구니 클래스에서 로깅 저장소 논리를 원하지 않습니다.

• 필요한 경우 로깅 방법의 인터페이스를 수정하십시오. 예를 들어 메시지가 비공식인지 경고인지 오류인지를 나타내는 수준을 추가 할 수 있습니다.

• 새 기능에서 새로 리팩토링 된 메소드를 사용하십시오.

• 로깅 프레임 워크로 마이그레이션 : 영향을받는 유일한 코드는 전용 라이브러리 내의 코드입니다.

답변