코드가 "나쁜"상태 일 때 검토 자로 무엇을해야합니까?

몇 달 전에 필수 코드 검토가 도입 된 잘못 설계되고 과도하게 엔지니어링 된 프로젝트에서 일하고 있습니다.

새로운 기능을 구현하는 실질적인 코드를 검토하라는 요청을 받았습니다. 다른 코드베이스와 같은 결함이 있습니다. 나는 그 결함이 예를 들어 새로운 코드에 들어간다는 것을 이해합니다. 호환성을 유지하면서 잘못 설계된 클래스에서 상속하거나 잘못 설계된 인터페이스를 구현해야하므로 코드베이스의 절반을 다시 작성하지 않아도되는 더 나은 솔루션을 실제로 제공 할 수는 없습니다. 그러나 엔지니어링 관점에서 볼 때 이미 깨진 코드베이스가 더 많은 것을 깨뜨리는 것은 좋지 않다고 생각합니다. 내가 검토중인 코드는 분명히 나쁘지만 기능을 구현하려면 반드시 있어야합니다.

이 특정 검토와 관련하여 어떻게 행동해야합니까? 무결성을 유지하고 건설적인 자세를 유지할 수있는 방법이 있습니까?

이 맥락에서 코드 검토의 경계에 대해 묻고 있습니다. 문제는 조직 및 직장 문화를 포함한 다른 요인으로 인해 발생한다는 것을 알고 있지만 알고 싶은 것은 검토 자체를 처리하는 방법입니다.

단순한:

1. 기술 부채를 문서화하십시오

작동하지만 기술적 인 문제가있는 코드를 확인했습니다. 이것은 기술적 부채 입니다. 다른 종류의 부채와 마찬가지로 처리하지 않으면 시간이 지남에 따라 악화됩니다.

기술적 부채를 다루는 첫 번째 단계는이를 기술하는 것입니다. 부채를 설명하는 항목을 이슈 트래커에 추가하여이를 수행하십시오. 이를 통해 문제의 규모를 명확하게 파악하고 문제를 해결할 계획을 세울 수 있습니다.

2. 빚을 점진적으로 상환

기술 부채를 상환하기 위해 소프트웨어 개발 프로세스를 수정하십시오. 스프린트를 가끔씩 강화하거나 단순히 일정한 간격 (예 : 주당 2 개 항목)으로 부채 항목을 해결하는 것이 포함될 수 있습니다. 빚이 발생하는 것보다 빨리 부채를 깎아내는 데 중요한 부분입니다 (부채, 기술 부채조차도 관심이 있습니다).

더 이상 기술적 인 결함 이없는 지점에 도달 하면 더 건강한 코드베이스로 향합니다. :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• MVC 방식은

• 오래된 로깅 메커니즘

• 로깅 프레임 워크

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

• ORM.

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

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

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

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

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

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

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

개발 프로세스의 일부로 코드 검토를 수행하는 경우 그런 다음 검토중인 코드를 '심판'하는 규칙을 설정해야합니다.

이것은 당신의 '완료된 정의'로 들어가야하며 스타일 가이드, 코드베이스 또는 정적 분석을위한 아키텍처 문서, 회사가 결정하는 모든 것이 '코드 품질'에 대한 요구 사항인지 확인하는 법적 요구 사항을 확인할 수 있습니다.

일단 코드 검토가 문제가되면 스타일 가이드를 따르고 테스트 커버리지 등의 필수 백분율을 얻었습니까?

이것을 가지고 있지 않다면 코드 검토는 코딩 능력이 가장 큰 사람과의 싸움이 될 수 있습니다. 그것은 모두의 시간 낭비입니다.

주요 문제는 중요한 새로운 기능에 대한 코드 검토가이 토론에 잘못된 시간이라는 것입니다. 이 시점에서 사소한 변경 이외의 작업은 너무 늦었습니다. 올바른 장소는 계획 단계 또는 최신 예비 설계 검토 단계입니다. 회사에서 적어도 비공식적으로 초기 검토를 수행하지 않는 경우 먼저 해당 문화를 변경하는 작업을 수행해야합니다.

다음 단계는 회의에 자신을 초대하고 회의에서 생산적인 아이디어를 얻는 것입니다. 대부분은 밤새 모든 것을 바꾸려고하지 않지만, 한 입 크기의 덩어리를 찾아서 격리 할 수 ​​있습니다. 그 덩어리는 시간이 지남에 따라 크게 늘어납니다.

다시 말해서, 핵심은 프로젝트의 시작을 향한 작은 변화를 정기적으로 제안하는 것입니다.

코드 검토를 수행 한 곳에서는 리팩토링을 수행하겠다고 약속 한 경우 코드 제출을 수락하고 확인합니다. 파일 버그, 이야기 또는 리팩토링을 수행하여 다른 리뷰를 보내겠다고 약속하십시오.

이 경우, 검토 할 코드를 작성하는 사람인 경우 일반적으로 새 기능이나 버그 수정이있는 변경 사항과 정리가 필요한 변경 사항을 두 가지 준비합니다. 그렇게하면 정리 변경 사항이 새로운 기능이나 버그 수정을 방해하지 않지만 토큰으로 쉽게 지적됩니다. "그렇습니다.이 문제를 해결하지는 않지만," 순수한 청소 "