코드 검토를 통해 보이 스카우트 규칙 및 기회 적 리팩토링 조정

나는 보이 스카우트 규칙 에 대한 위대한 신자입니다 .

모듈을 체크 아웃 할 때보 다 항상 깨끗하게 점검하십시오. "원래 작성자가 누구든, 모듈을 개선하기 위해 항상 작은 노력을 기울이면 어떤 결과를 얻었습니까? 결과는 어떻습니까? 우리 모두는이 단순한 규칙을 따랐고, 우리는 소프트웨어 시스템의 끊임없는 열화의 종말을 보게 될 것입니다. 대신 우리의 시스템은 진화함에 따라 점차 더 나아질 것입니다. 단지 자신의 작은 작은 부분을 돌보는 개인보다.

또한 기회 리팩토링 관련 아이디어를 잘 알고 있습니다 .

예정된 리팩토링 노력을위한 장소가 있지만, 코드를 정리할 필요가있을 때마다 언제 어디서나 수행 할 수있는 기회 활동으로 리팩토링을 권장합니다. 이것이 의미하는 바는 누군가 누군가가 명확하지 않은 코드를 볼 때마다 즉시 수정하거나 최소한 몇 분 안에 고칠 수있는 기회를 가져야한다는 것입니다

특히 리팩토링 기사에서 발췌 한 다음 내용을 참고하십시오.

기회 리팩토링에 마찰을 유발하는 개발 관행에주의를 기울입니다 ... 대부분의 팀은 리팩토링을 충분히 수행하지 않으므로 사람들이 방해하는 일에주의를 기울이는 것이 중요합니다. 작은 리팩토링을하지 않는 것이 좋다고 생각 될 때마다 1 ~ 2 분 밖에 걸리지 않는다는 사실을 알아 차리려면 도움이됩니다. 그러한 장벽은 대화를 불러 일으키는 냄새입니다. 낙담을 기록하고 팀과 함께하십시오. 최소한 다음 회고 중에 논의해야합니다.

내가 일하는 곳에서는 코드 검토 (CR) 라는 큰 마찰 을 일으키는 한 가지 개발 방법이 있습니다. "할당"범위에없는 내용을 변경할 때마다 검토자가 변경 내용을 검토하기 어렵게 만드는 것에 대해 책망하고 있습니다. 이것은 "라인 별"diff 비교를 어렵게하기 때문에 리팩토링이 관련된 경우 특히 그렇습니다. 이 접근법은 여기의 표준이며, 기회 주의적 리팩토링은 거의 수행되지 않으며 "계획된"리팩토링 (일반적으로 너무 작거나 너무 늦음) 만 발생합니다.

나는 이점이 가치가 있다고 주장하며 3 명의 검토자가 조금 더 열심히 노력할 것입니다 (줄이 바뀌는 좁은 범위를 보지 않고 실제로 전후 코드를 이해하기 위해-검토 자체만으로 인해 더 좋을 것입니다) ) 코드를 읽고 유지 관리하는 다음 100 명의 개발자에게 도움이됩니다. 이 검토 자에게 리뷰어를 제시 할 때, 동일한 CR에 있지 않는 한 리팩터링에 문제가 없다고 말합니다. 그러나 나는 이것이 신화라고 주장한다.

(1) 대부분의 경우 과제 중일 때 리팩토링하려는 항목과 방법 만 알 수 있습니다. Martin Fowler는 다음과 같이 말합니다.

기능을 추가 할 때 추가하는 일부 코드에 기존 코드와 중복되는 내용이 포함되어 있으므로 기존 코드를 리팩터링하여 정리해야합니다. 기존 클래스와의 상호 작용이 변경된 경우 더 좋습니다. 자신이 행한 것을 고려하기 전에 그 기회를 잡으십시오.

(2) 아무도 당신이하지 말아야 할 "리팩토링"CR을 공개하는 것을 좋아하지 않을 것입니다. CR에는 특정 오버 헤드가 있으며 관리자는 리팩토링에 "시간을 낭비"하기를 원하지 않습니다. 변경 사항이 번들로 묶여 있으면이 문제가 최소화됩니다.

Resharper는 변경에 추가하는 각각의 새 파일 (그리고 어떤 파일이 변경되었는지 정확히 알 수 없음) 에 오류와 제안이 흩어져 있기 때문에 Resharper에 의해 문제가 더욱 악화됩니다. 고정.

최종 결과는 끔찍한 코드를 보았을뿐입니다. 아이러니하게도, 나는 그러한 코드를 고치는 것이 나의 지위를 향상시킬뿐만 아니라 실제로 그것들을 낮추고 나를 초점을 맞추지 않은 사람으로 나를 태워서 그의 일을하는 대신에 아무도 신경 쓰지 않는 것을 고치는 시간을 낭비한다고 생각한다. 나는 실제로 나쁜 코드를 멸시하고 그것을 볼 수 없기 때문에 그것에 대해 기분이 좋지 않습니다.

이 상황을 어떻게 해결할 수 있습니까?

좋아요, 이제 주석에 적합한 것보다 더 많은 것들이 있습니다.

tl; dr

해야 할 일 (리팩터링) 에 대한 직관 이 정확합니다.

잘못된 코드 검토 시스템을 해결해야한다는 점을 감안하면이를 구현하기가 어렵다는 점은 소스 코드와 VCS를 조작하는 데 어려움이 있다는 것입니다. 여러 사람들이 변경 사항 (예, 파일 내에서도)을 여러 커밋으로 나눌 수 있고 분할 해야한다고 말 했지만 이것을 믿기가 어렵습니다.

당신은 정말로 이것을 할 수 있습니다 . 그건 정말 우리가 제안하는지. 당신은 정말해야 당신의 편집, 소스 조작 및 버전 관리 도구를 최대한 활용하는 법을 배워야. 잘 사용하는 법을 배우는 데 시간을 투자하면 인생이 훨씬 쉬워집니다.

워크 플로 / 사무실 정치 문제

나는 본질적으로 두 개의 커밋을 만드는 GlenH7과 동일한 권장 사항을 제시합니다. 하나는 리팩토링 만 있고 기능적으로는 변경되지 않고 다른 하나는 문제가 있습니다.

많은 오류를 발견 하는 경우 단일 CR 내에서 수정하기 위해 단일 범주의 오류를 선택하는 것이 유용 할 수 있습니다 . 그런 다음 "dedupe code", "fix type-X errors"등의 주석이 포함 된 커밋이 있습니다. 여러 위치에서 단일 유형의 변경이 이루어 지므로 검토하기 가 쉽지 않습니다 . 그것은 당신이 찾은 모든 오류를 고칠 수는 없지만 밀수를 덜 고통스럽게 만들 수 있음을 의미합니다.

VCS 문제

작업 소스의 변경 사항을 여러 커밋으로 나누는 것은 어려운 일이 아닙니다. 사용중인 내용을 말하지 않았지만 가능한 워크 플로는 다음과 같습니다.

1. git을 사용하는 경우 훌륭한 도구가 있습니다.

   • git add -i명령 행에서 대화식 스테이징에 사용할 수 있습니다.
   • git gui개별 덩어리와 행을 사용하여 스테이지 할 수 있습니다 (실제로는 명령 행보다 선호하는 몇 가지 VCS 관련 GUI 도구 중 하나이며 다른 하나는 우수한 3 방향 병합 편집기 임)
   • 작은 커밋을 많이 수행하고 (개별 변경 또는 여러 장소에서 동일한 종류의 버그 수정) 재정렬, 병합 또는 분할 할 수 있습니다 rebase -i

2. git을 사용하지 않는 경우 VCS는 여전히 이런 종류의 도구를 사용할 수 있지만 어떤 시스템을 사용하는지 모르면 조언을 할 수 없습니다.

   TFS를 사용한다고 언급했는데 TFS2013 이후 git과 호환된다고 생각합니다. 리포지토리의 로컬 git 복제를 사용하여 실험 해 볼 가치가 있습니다. 이것이 비활성화되었거나 작동하지 않는 경우에도 소스를 로컬 git 리포지토리로 가져 와서 작업 할 수 있습니다. 최종 커밋을 내 보냅니다.

3. diffand와 같은 기본 도구에 액세스 할 수 있으면 모든 VCS에서 수동으로 수행 할 수 있습니다 patch. 더 고통 스럽지만 확실히 가능합니다. 기본 워크 플로우는 다음과 같습니다.

   1. 모든 변경, 테스트 등
   2. diff마지막 커밋 이후의 모든 변경 사항으로 (컨텍스트 또는 통합) 패치 파일을 만드는 데 사용
   3. 두 개의 파일로 분할 : 리팩토링을 포함하는 패치 파일 하나와 기능 변경이있는 패치 파일 하나
      • 이것은 완전히 사소한 것이 아닙니다-emacs diff 모드와 같은 도구가 도움이 될 수 있습니다
   4. 모든 것을 백업
   5. 마지막 커밋으로 되돌리고 patch패치 파일 중 하나를 재생하고 변경 사항을 커밋하는 데 사용
      • NB. 패치가 깨끗하게 적용되지 않으면 실패한 덩어리를 수동으로 수정해야 할 수도 있습니다
   6. 두 번째 패치 파일에 대해 5를 반복하십시오.

이제 변경 사항이 적절하게 분할 된 두 개의 커밋이 있습니다.

이 패치 관리를 더 쉽게하기위한 도구가있을 수 있습니다. git이 나를 위해 사용하기 때문에 사용하지 않습니다.

회사에서 변경 요청이 크고 공식적이라고 가정하겠습니다. 그렇지 않은 경우 (가능한 경우) 많은 작은 커밋으로 변경하십시오 (예 : 예상대로).

이 상황을 어떻게 해결할 수 있습니까?

하고있는 일을 계속합니까?

당신의 생각과 추론은 모두 정확합니다. 당신이 보는 것을 고쳐야합니다. 사람들은 리팩토링을 충분히 계획하지 않았습니다. 그리고 전체 그룹에 대한 혜택은 몇 가지 불편 함보다 중요합니다.

도움이 될 수있는 것은 덜 전투적인 것입니다. 코드 리뷰는 "왜 그렇게 했습니까?"라고 격투해서는 안되며, 협업 적이어야합니다. "내가 여기있는 동안 나는이 모든 것을 고쳤습니다!". 문화를 변화시키기 위해 (가능하면 리드 / 매니저와 함께) 일하는 것은 어렵지만, 고기능 개발 팀을 만드는 데 매우 중요합니다.

또한 가능하면 책임자 / 관리자와 함께 작업하여 동료와 함께 이러한 아이디어의 중요성을 진척시킬 수 있습니다. "당신은 왜 품질에 관심이 없습니까?"라고 묻습니다. "왜 항상 쓸모없는 일을하는거야?"

나는 당신의 상황에 동정심이 많지만 구체적인 제안은 거의 없습니다. 다른 것이 없다면 어쩌면 상황만큼 나쁘면 더 나쁠 수 있다고 확신시킬 것입니다. 항상 더 나빠질 수 있습니다. :-)

첫째, 나는 당신이 하나 이상의 문화에 대해 적어도 두 가지 문제를 가지고 있다고 생각합니다. 한 가지 문제는 리팩토링에 대한 접근 방식이지만 코드 검토는 별개의 문제처럼 보입니다. 나는 내 생각을 분리하려고 노력할 것이다.

코드 리뷰

나는 코드가 HATED 된 그룹에 있었다. 그룹은 회사의 개별 부분에서 두 그룹을 병합하여 구성되었습니다. 몇 년 동안 코드 검토를 해 온 그룹에서 왔으며 일반적으로 좋은 결과를 얻었습니다. 우리 대부분은 코드 리뷰가 우리 시간을 잘 활용한다고 믿었습니다. 우리는 더 큰 그룹으로 합병했으며, "다른"그룹은 코드 검토에 대해 들어 본 적이 없었습니다. 이제 우리는 모두 "그들의"코드베이스를 연구하고있었습니다.

우리가 합병했을 때 상황이 좋지 않았습니다. 새로운 기능은 매년 6-12 개월 늦었습니다. 버그 백로 그는 거대하고 성장하며 생명을 빼앗 았습니다. 코드 소유권은 특히 가장 고위의 "전문가들"사이에서 강력했습니다. "기능 지점"은 때때로 몇 년 동안 지속되었으며 몇 번의 릴리스로 확장되었습니다. 때로는 NOBODY이지만 한 명의 개발자가 메인 브랜치에 도달하기 전에 코드를 보았습니다. 실제로 "기능 분기"는 코드가 저장소의 어딘가에 있음을 시사하기 때문에 오해의 소지가 있습니다. 더 자주 개발자의 개별 시스템에만있었습니다.

경영진은 품질이 수용 할 수 없을 정도로 낮아지기 전에 "무엇을해야"한다는 데 동의했습니다. :-) 그들의 답변은 코드 리뷰였습니다. 코드 검토는 모든 체크인 전에 공식 "Thou Shalt"항목이되었습니다. 우리가 사용한 도구는 Review Board였습니다.

내가 설명한 문화에서 어떻게 작동 했습니까? 아무것도 아닌 것보다는 낫지 만 최소한의 수준의 규정 준수에 도달하는 데 고통스럽고 1 년 이상이 걸렸습니다. 우리가 관찰 한 것들 :

1. 사용하는 도구는 특정 방식으로 코드 검토에 집중하는 경향이 있습니다. 문제가 될 수 있습니다. Review Board는 멋지고 화려한 라인 별 diff를 제공하며 주석을 라인에 첨부 할 수 있습니다. 따라서 대부분의 개발자는 변경되지 않은 모든 행을 무시합니다. 작고 고립 된 변경에는 좋습니다. 큰 변화, 새로운 코드의 큰 덩어리 또는 이름이 바뀐 함수의 500 인스턴스가 10 줄의 새로운 기능과 혼합 된 코드에는 그렇게 좋지 않습니다.
2. 비록 우리가 이전에 검토 한 적이없는 낡고 아픈 코드 기반에 있었음에도 불구하고, 검토자가 변경 라인이 아닌 것에 대해 언급하는 것은 명백한 버그를 지적하는 것이 "무례한"상태가되었습니다. "저를 귀찮게하지 마십시오. 이것은 중요한 체크인이며 버그를 고칠 시간이 없습니다."
3. "쉬운"검토자를 구매하십시오. 어떤 사람들은 3 분 동안 2000 개의 변경된 줄로 10- 파일 검토를보고 "Ship It!"을 클릭합니다. 모두가 그 사람들이 누구인지 빨리 배웁니다. 코드를 처음부터 검토하지 않으려면 "쉬운"검토 자에게 보내십시오. 체크인 속도가 느려지지 않습니다. 그의 코드에 대해 "쉬운"검토자가되어 호의를 돌려 줄 수 있습니다.
4. 코드 검토가 싫다면 Review Board에서받은 이메일을 무시하십시오. 팀원의 후속 조치는 무시하십시오. 몇 주 동안. 대기중인 리뷰가 12 개이고 그룹 회의에 이름이 몇 번 나타날 때까지. 그런 다음 "쉬운"검토자가되고 점심 시간 전에 모든 검토를 지우십시오.
5. "열심 한"검토 자에게 코드를 보내지 마십시오. (이와 같은 질문을하거나 대답하는 개발자의 종류) 쉬운 사람을 배우는 것처럼 누구나 "열심 ​​한"검토자가 누구인지 빨리 배울 수 있습니다. 코드 검토가 시간 낭비 (™) 인 경우 사용자가 소유 한 코드에 대한 자세한 피드백을 읽는 것은 시간 낭비 (™)와 모욕입니다.
6. 코드 검토가 힘들면 사람들은 코드 검토를 중단하고 더 많은 코드를 작성합니다. 코드 검토 횟수는 줄어들지 만 각각은 큰 편입니다. 더 작은 코드 검토가 필요합니다. 즉, 팀은 가능한 한 고통없이 만드는 방법을 찾아야합니다.

코드 리뷰에 대한 몇 가지 단락을 작성하려고 생각했지만 대부분 문화에 대해 쓰고있었습니다. 코드 검토는 프로젝트에 좋을 수 있지만 팀은 얻을 수있는 이점 만 얻습니다.

리팩토링

내 그룹이 코드 검토가 싫어하는 것보다 리팩토링을 멸시 했습니까? 물론이야! 이미 언급 된 모든 명백한 이유 때문입니다. icky 코드 검토로 시간을 낭비하고 있으며 기능을 추가하거나 버그를 수정하지도 않습니다!

그러나 코드는 여전히 리팩토링이 절실히 필요했습니다. 진행하는 방법?

1. 리팩토링 변경과 기능 변경을 혼합하지 마십시오. 많은 사람들이이 점을 언급했습니다. 코드 검토가 마찰 점이라면 마찰을 증가시키지 마십시오. 더 많은 작업이 필요하지만 별도의 검토 및 별도의 체크인을 계획해야합니다.
2. 작게 시작하십시오. 매우 작은. 그것보다 작습니다. 아주 작은 리팩토링을 사용하여 리팩토링과 코드 리뷰가 순수한 악이 아니라는 점을 사람들에게 점진적으로 가르치십시오. 너무 많은 고통없이 일주일에 하나의 작은 리팩토링에 몰래 들어가면 몇 달 안에 일주일에 두 번 도망 갈 수 있습니다. 그리고 그들은 조금 더 클 수 있습니다. 아무것도없는 것보다는 낫다.
3. 본질적으로 단위 테스트는 없었습니다. 리팩토링은 금지되어 있습니다. 반드시 그런 것은 아닙니다. 일부 변경의 경우 컴파일러는 단위 테스트입니다. 테스트 할 수있는 리팩토링에 집중하십시오. 테스트 할 수없는 변경은 피하십시오. 대신 단위 테스트를 작성하는 데 시간을 할애하십시오.
4. 일부 개발자는 모든 코드 변경이 두렵기 때문에 리팩토링이 두렵습니다. 이 유형을 인식하는 데 시간이 오래 걸렸습니다. 코드 덩어리를 작성하고 "작동"할 때까지 코드를 변경 한 다음 절대로 변경하고 싶지 않습니다. 왜 작동하는지 이해하지 못할 수도 있습니다. 변화는 위험합니다. 그들은 자신이 어떤 변화를한다고 믿지 않으며 확실히 당신을 믿지 않습니다. 리팩토링은 동작을 변경하지 않는 작고 안전한 변경에 관한 것입니다. "행동을 바꾸지 않는 변화"라는 개념을 생각할 수없는 개발자들이 있습니다 . 이 경우에 무엇을 제안해야할지 모르겠습니다. 나는 그들이 신경 쓰지 않는 영역에서 일하려고 노력해야한다고 생각합니다. 이 유형이 오래 지속될 수 있다는 사실을 알고 놀랐습니다.

왜 둘 다하지 않고 별도의 커밋을 사용합니까?

당신의 동료는 요점을 가지고 있습니다. 코드 검토는 다른 사람이 변경 한 코드를 평가해야합니다. 당신은 그 리뷰어와 같은 역할을 바이어스 당신이 다른 사람을 위해 검토하고 코드를 만지지해야한다.

그러나 많은 눈부신 문제가 발생하면 따라갈 수있는 두 가지 옵션이 있습니다.

1. 코드 검토에 문제가 없으면 검토 한 부분을 커밋 한 다음 다시 체크인하여 코드를 리팩터링하십시오.

2. 코드 검토에 수정이 필요한 문제가있는 경우 개발자에게 Resharper 권장 사항에 따라 리팩터링하도록 요청하십시오.

나는 사후 커밋 코드 검토의 아이디어를 개인적으로 싫어합니다. 코드를 변경할 때 코드 검토가 수행되어야합니다. 물론 여기서 이야기하고있는 것은 페어 프로그래밍입니다. 페어링하면 리뷰가 무료로 제공되고 더 나은 코드 리뷰가 제공됩니다. 자, 나는 여기에 내 의견을 표현하고 있습니다. 다른 사람들이 이것을 공유한다는 것을 알고 있습니다. 아마도 이것을 증명하는 연구가 있습니다.

코드 검토자가 귀하와 쌍을 이룰 수 있으면 코드 검토의 전투 요소가 증발해야합니다. 이해되지 않는 변경을 시작하면 변경 시점에서 논의 될 수 있고 개선 된 리팩토링으로 이어질 수있는 대안을 탐색 할 수 있습니다. 쌍이 변경의 넓은 범위를 이해할 수 있고 코드 단위로 비교할 때 줄 단위 변경에 너무 집중하지 않으므로 고품질 코드 검토를 얻을 수 있습니다.

물론 이것은 리팩토링이 변경되는 범위를 벗어나는 문제에 대한 직접적인 대답은 아니지만 변경 사항이있을 때 동료가 변경의 이유를 더 잘 이해할 것으로 기대합니다.

따로, TDD 또는 어떤 형태의 적색 녹색 리 팩터를 수행한다고 가정 할 때 동료와의 교류를 보장하는 한 가지 방법은 탁구 페어링 기술을 사용하는 것입니다. RGR주기의 각 단계마다 드라이버가 회전함에 따라 간단히 설명됩니다. 즉, 페어 1은 실패한 테스트를 작성하고, 페어 2는이를 수정하고, 페어 1 리 팩터, 페어 2는 실패한 테스트를 작성합니다.

아마도이 문제는 조직 문화의 훨씬 더 큰 문제를 반영합니다. 사람들은 제품을 개선하는 것보다 "자신의 일"에 더 관심이있는 것 같습니다. 아마도이 회사는 협력 문화 대신 "비난"문화를 가지고 있고 사람들은 전체 제품 / 회사 비전보다 커버 자체에 더 관심이있는 것 같습니다 .

내 의견으로는, 당신은 완전하게 맞습니다. 당신의 코드를 검토하는 사람들은 당신이 "당신의 임무"외부에있는 것들을 "만져"서, 그 사람들을 설득하려고하지만 당신의 원칙에 반하지 않기 때문에 불평을한다면 완전히 잘못되었습니다. 진정한 전문가의 가장 중요한 품질.

그리고 옳은 일이 당신의 일을 평가하기 위해 어리석은 회사 방식으로 나쁜 숫자를 주면, 무슨 문제?, 누가이 평가 게임을 미친 회사에서 "승리"하고 싶은가? 그것을 바꾸려고 노력하십시오! 당신은 피곤하고 다른 곳을 찾지 만 결코 절대로 당신의 원칙에 위배되지 않습니다.

때로는 리팩토링이 나쁜 것입니다. 그러나 코드 검토자가 제공하는 이유가 아닙니다. 그들은 실제로 코드의 품질에 관심이없는 것처럼 들리 며, 당신 은 신경 쓰지 않습니다 . 그러나 리팩토링을 막아야하는 두 가지 이유가 있습니다 . 1. 자동화 된 테스트 (단위 테스트 등)로 변경 한 사항을 테스트 할 수 없거나 2. 이해하지 못하는 일부 코드를 변경하고 있습니다. 잘; 즉, 변경 해야 할 사항을 알 수있는 도메인 별 지식이 없습니다 .

1. 자동화 된 테스트로 변경 한 내용을 테스트 할 수없는 경우 리팩터링하지 마십시오.

코드 검토를 수행하는 사람은 변경 한 내용으로 인해 이전에 작동했던 내용이 중단되지 않았는지 확인할 수 있어야합니다. 이것이 작업 코드를 그대로 두는 가장 큰 이유입니다. 예, 1000 줄 길이의 함수 (실제로 가증 한 것입니다)를 여러 함수로 리팩터링하는 것이 더 낫지 만 테스트를 자동화 할 수 없다면 다른 사람들에게 모든 것을했다고 설득하기가 어려울 수 있습니다 권리. 나는 전에이 실수를 분명히했다.

리팩토링하기 전에 단위 테스트가 있는지 확인하십시오. 단위 테스트가 없으면 몇 가지를 작성하십시오! 그런 다음 리팩터링하면 코드 검토자가 화를내는 데 대한 (법적) 변명이 없습니다.

보유하고 있지 않은 도메인 별 지식이 필요한 코드를 리팩터링하지 마십시오.

내가 일하는 곳에는 많은 화학 공학이 많은 코드가 있습니다. 코드베이스는 화학 엔지니어에게 공통적 인 관용구를 사용합니다. 필드를 관용적으로 변경하지 마십시오. 라는 변수 이름을 바꿀 수있는 좋은 생각처럼 보일 수도 x로를 molarConcentration,하지만 추측? 에서는 모든 화학 교과서, 몰 농도는로 표현된다 x. 이름을 바꾸면 해당 분야의 사람들을 위해 실제로 코드에서 무슨 일이 일어나고 있는지 알기가 어렵습니다.

관용 변수의 이름을 바꾸는 대신 변수가 무엇인지 설명하는 주석을 넣으십시오. 이러한 경우 하지 관용적, 이름을 바꾸십시오. 방치하지 마십시오 i, j, k, x, y, 등 더 나은 이름이 작동 할 때 주위에 떠있는.

약어의 경험 법칙 : 사람들이 이야기 할 때 약어를 사용하는 경우 코드에서 해당 약어를 사용하는 것이 좋습니다. 직장에서 코드베이스의 예 :

"관심 영역"은 "AOC"가되고, "Vapor cloud explosion"은 VCE가됩니다. 우리의 코드베이스에서 누군가 aoc라는 AreaOfConcern, VCE를 vaporCloudExplosion, nPlanes를 confiningPlanesCount로 리팩토링했습니다. 이로 인해 도메인 고유의 지식을 가진 사람들이 코드를 실제로 읽기가 훨씬 어려워졌습니다. 나도 이런 일을 저지른 죄를 지었다.

이것은 실제로 귀하의 상황에 적용되지 않을 수도 있지만 문제에 대한 내 생각이 있습니다.

이 질문에는 이제 코드 검토의 변경 사항을 쉽게 검토 할 수 있고 리팩토링에 소요되는 시간이라는 두 가지 고유 한 문제가 있습니다.

내가 일하는 곳에서는 코드 검토 (CR)라는 큰 마찰을 일으키는 한 가지 개발 방법이 있습니다. "할당"범위에없는 내용을 변경할 때마다 검토자가 변경 내용을 검토하기 어렵게 만드는 것에 대해 책망하고 있습니다.

다른 답변에서 말했듯이 리팩토링 체크인을 코드 변경 체크인과 분리 할 수 ​​있습니까? 코드 검토를 수행하는 데 사용하는 도구에 따라 특정 개정 사이의 차이점 만 볼 수 있어야합니다 (Atlassian 's Crucible은이를 확실히 수행합니다).

(2) 아무도 당신이하지 말아야 할 "리팩토링"CR을 공개하는 것을 좋아하지 않을 것입니다. CR에는 특정 오버 헤드가 있으며 관리자는 리팩토링에 "시간을 낭비"하기를 원하지 않습니다. 변경 사항이 번들로 묶여 있으면이 문제가 최소화됩니다.

리팩토링이 간단하고 코드를 이해하기 쉽게 만드는 경우 (리팩토링 일 경우 수행해야 할 모든 것) 코드 검토를 완료하는 데 시간이 오래 걸리지 않으며, 오버 헤드가 최소화되어야합니다. 앞으로 코드를 다시 살펴 봐야합니다. 보스가이 문제를 해결할 수 없다면, 보이 스카우트 규칙이 왜 코드와 더 생산적인 관계를 이끄는 지 논의하는 리소스를 향해 살짝 밀어 내야 할 수도 있습니다. "시간 낭비"가 나중에 다른 사람이 해당 코드에 대해 더 많은 작업을 수행 할 때 2, 5 또는 10 배나 더 많은 시간을 절약 할 수 있다고 확신 할 수 있다면 문제는 해결되어야합니다.

Resharper는 변경에 추가하는 각각의 새 파일 (그리고 어떤 파일이 변경되었는지 정확히 알 수 없음)에 오류와 제안이 흩어져 있기 때문에 Resharper에 의해 문제가 악화됩니다. 고정.

이러한 문제를 동료의 관심을 끌고 해결해야하는 이유에 대해 논의 해 보셨습니까? 또한 자동 리팩토링으로 인해 문제가 발생하지 않았 음을 확인하기에 충분한 테스트 범위가 있다고 가정하면 자동으로 고칠 수 있습니까? 때로는 그것이 정말로 까다로운 물건이라면 리팩토링을 수행하는 것이 "시간을 가치있게"하지 않는 경우가 있습니다. 팀 전체가 ReSharper를 사용합니까? 그렇다면, 어떤 경고 / 규칙이 시행되고 있는지에 대한 공유 정책이 있습니까? 그렇지 않다면, 아마도 도구가 미래의 고통의 원인이 될 수있는 코드 영역을 식별하는 데 도움이되는 위치를 보여 주어야 할 것입니다.

25 년 전쯤에 다른 목적으로 작업 한 코드를 정리하는 것을 기억할 수 있습니다. 대부분 주석 블록과 탭 / 열 정렬을 다시 포맷하여 코드를 깔끔하고 이해하기 쉽도록 만들었습니다 (실제 기능 변경 없음). . 깔끔하고 잘 정리 된 코드 를 좋아 합니다. 수석 개발자들은 분노했습니다. 그들은 어떤 종류의 파일 비교 (diff)를 사용하여 파일의 개인 사본과 비교하여 변경된 내용을 확인했으며 이제는 모든 종류의 오 탐지를 보였습니다. 코드 라이브러리가 메인 프레임에 있고 버전 제어 기능이 없다고 언급해야합니다. 기본적으로 모든 것을 덮어 씁니다.

이 이야기의 교훈? 난 몰라 때때로 당신은 자신을 제외한 다른 사람을 기쁘게 할 수없는 것 같아요. 나는 시간을 낭비하지 않았습니다 (내 눈에). 정리 된 코드 는 읽고 이해하기 가 더 쉬웠 습니다 . 다른 사람들이 사용하는 기본 변경 제어 도구가 추가 원샷 작업을하는 것입니다. 이 도구는 공간 / 태빙 및 리플 로우 된 주석을 무시하기에는 너무 원시적이었습니다.

@Useless, @Telastyn 및 다른 사람들이 지적한 것처럼 요청 된 변경 사항과 요청되지 않은 리 팩터를 (많은) 별도의 커밋으로 나눌 수 있다면 이것이 최선의 방법입니다. "리팩토링"을 생성하는 데 따른 관리 오버 헤드없이 단일 CR을 계속 작업하고 있습니다. 커밋을 작고 집중적으로 유지하십시오.

그것을하는 방법에 대한 조언을하는 대신, 나는 당신이 전문가로부터 훨씬 더 큰 설명 (사실, 책)을 지적하는 것을 선호합니다. 이렇게하면 더 많은 것을 배울 수 있습니다. 읽기 (마이클 깃털에 의해) 레거시 코드와 함께 효과적으로 작동 . 이 책은 기능 변경에 따라 리팩토링하는 방법을 알려줍니다.

다루는 주제는 다음과 같습니다.

• 소프트웨어 변경 메커니즘 이해 : 기능 추가, 버그 수정, 디자인 개선, 성능 최적화
• 레거시 코드를 테스트 하네스로 가져 오기
• 새로운 문제가 발생하지 않도록 보호하는 테스트 작성
• Java, C ++, C 및 C #의 예제와 함께 모든 언어 또는 플랫폼에서 사용할 수있는 기술
• 코드 변경이 필요한 위치를 정확하게 식별
• 객체 지향이 아닌 레거시 시스템에 대처
• 구조가없는 것으로 보이는 응용 프로그램 처리

이 책에는 또한 프로그램 요소를 사용하여 작업하고보다 안전하게 변경하는 데 도움이되는 24 가지 종속성 중단 기술 카탈로그가 포함되어 있습니다.

저도 보이 스카우트 규칙과 기회 리팩토링을 잘 알고 있습니다. 문제는 종종 경영진을 구매하는 데 있습니다. 리팩토링에는 위험과 비용이 함께 있습니다. 경영진이 종종 간과하는 것은 기술 부채도 마찬가지입니다.

인간의 본성입니다. 우리는 실제 문제를 다루는 데 익숙하지만 문제를 예방하려고하지는 않습니다. 우리는 사전 대응 적이 아닌 사후 적입니다.

소프트웨어는 무형이므로 자동차처럼 서비스가 필요하다는 것을 이해하기가 어렵습니다. 합리적인 사람은 자동차를 사고 결코 서비스를하지 않을 것입니다. 우리는 그러한 태만으로 인해 수명이 줄어들고 장기적으로 더 많은 비용이 든다는 것을 인정합니다.

많은 관리자가이를 이해하고 있지만 프로덕션 코드 변경에 대한 책임은 관리자에게 있습니다. 혼자서 쉽게 떠날 수있는 정치가 있습니다. 설득력이 필요한 사람은 실제로 관리자보다 높으며 단순히 "좋은 아이디어"를 제작하기 위해 싸우고 싶지 않습니다.

솔직히 말해서, 당신의 매니저는 당신의 구제책이 실제로 당신이 생각하는 것만 큼 크다고 확신하지는 않습니다. (뱀 오일?) 세일즈맨이 있습니다. 그가 혜택을 볼 수 있도록 돕는 것이 당신의 일입니다.

경영진은 우선 순위를 공유하지 않습니다. 관리 모자를 쓰고 관리의 눈으로보십시오. 올바른 각도를 찾을 수 있습니다. 끈기있게 행동하십시오. 첫 번째 부정적인 반응이 당신을 막지 못하게함으로써 더 많은 변화에 영향을 줄 것입니다.

@ GlenH7에서 언급 한 것처럼 요청 된 변경과 요청되지 않은 리 팩터를 두 개의 개별 변경 요청으로 분할 할 수 있다면 이것이 최선의 방법입니다. 당신은 "시간을 낭비하는 사람"이 아니라 "두 배나 열심히 일하는 사람"입니다.

요청 된 작업에 요청하지 않은 리 팩터가 컴파일되어야하므로 분할 할 수없는 상황에 처한 경우가 많으면 여기에 설명 된 인수 (Resharper 스스로 경고하는 것이 좋은 후보가 될 수 있습니다. 이러한 주장은 모두 유효합니다,하지만 당신은 당신의 이점에 사용할 수있는 하나의 여분이 : 지금 그 시험을 가진 그에게 할 의무를 각 커밋에 시험을 통과 할 수 있습니다.

회사에서 "리팩토링에 시간 낭비"(부정확 한 표시)를 원하지 않는 경우 "경고 억제"파일 (각 도구에는 고유 한 메커니즘이 있음)을 제공하여 더 이상 짜증나 지 않도록해야합니다. 그러한 경고. 다른 시나리오, 심지어 최악의 경우에 대한 옵션을 제공하기 위해 이것을 말합니다. 또한 각 측면에 대한 암시적인 가정보다는 예상 코드 품질에 대해 귀하와 회사 간의 계약을 명확하게 밝히는 것이 좋습니다.