검토 중에 다른 사람이 잘못 디자인 한 코드의 개선을 전략적으로 제안하려면 어떻게해야합니까?

나는 깨끗한 코드와 코드 장인 정신을 잘 믿는 사람이지만, 현재 이것이 최우선 순위로 여겨지지 않는 직장에 있습니다. 때로는 동료의 코드가 지저분한 디자인으로 가득 차고 향후 유지 보수에 대한 관심이 거의 없지만 상황에 따라 기능이 있고 버그가 거의 없거나 전혀없는 경우가 있습니다.

변경해야 할 것이 너무 많고 마감 기한이 있다고 생각할 때 코드 검토에서 개선 사항을 제안하는 방법은 무엇입니까? 마감일 이후에 개선이 이루어 졌다는 제안은 새로운 기능과 버그 수정이 들어 오면 우선 순위가 낮아질 수 있음을 의미합니다.

1. 동기를 재확인하십시오. 코드를 변경해야한다고 생각되면 코드를 변경해야하는 이유를 명확하게 설명 할 수 있어야합니다. 그리고 그 이유는 "내가 다르게 했었을 것"또는 "못생긴 것"보다 더 구체적이어야한다. 제안 된 변경으로 인한 혜택을 지적 할 수없는 경우 변경하는 데 시간이 많이 걸리지 않습니다 (일명 돈).

2. 프로젝트의 모든 코드 줄은 유지해야하는 줄입니다. 코드는 작업을 완료하고 쉽게 이해할 수 있어야하고 더 이상 이해되지 않는 한 길어야합니다. 명확성을 희생하지 않고 코드를 줄일 수 있다면 좋습니다. 선명도를 높이면서 할 수 있다면 훨씬 좋습니다.

3. 코드는 구체적과 비슷합니다. 잠시 앉아있다가 변경하기가 더 어렵습니다. 변경 비용과 위험을 최소화 할 수 있도록 가능한 빨리 변경을 제안하십시오.

4. 모든 변화는 돈이 든다. 작동하고 변경할 필요가없는 코드를 다시 작성하는 것은 노력을 낭비 할 수 있습니다. 변경 될 수 있거나 프로젝트에 가장 중요한 섹션에주의를 집중하십시오.

5. 형태는 기능을 따르며 때로는 그 반대도 마찬가지입니다. 코드가 지저분하면 버그도 포함되어있을 가능성이 높습니다. 이러한 버그를 찾아 코드의 미적 매력보다는 결함이있는 기능을 비판하십시오. 코드 작동을 개선 하고 코드 작동을보다 쉽게 확인할 수있는 개선 사항을 제안하십시오 .

6. 디자인과 구현을 차별화하십시오. 엉터리 인터페이스가있는 중요한 수업은 암과 같은 프로젝트를 통해 퍼질 수 있습니다. 그것은 나머지 프로젝트의 품질을 떨어 뜨릴뿐만 아니라 손상 복구의 어려움을 증가시킵니다. 반면에 잘 설계된 인터페이스를 가지고 있지만 구현이 까다로운 클래스는 그리 중요하지 않습니다. 더 나은 성능 또는 안정성을 위해 클래스를 항상 다시 구현할 수 있습니다. 또는 올바르게 작동하고 충분히 빠르면 혼자 남겨두고 부스러기가 잘 캡슐화되어 있다는 것을 알고 안심할 수 있습니다.

위의 모든 사항을 요약하려면 다음과 같이 하십시오. 제안 된 변경 사항이 값을 추가해야합니다.

리팩토링을 통해 가치를 추가 할 수있는 스위트 스팟이 있습니다. 변경 사항은 다음 세 가지를 달성해야합니다.

• 변경 될 가능성이있는 코드 개선
• 선명도를 높이다
• 최소한의 노력

고려 사항 :

1. 깨끗한 코드는 작성 및 유지 관리 비용이 저렴하며 작업하기가 더 재미 있다는 것을 알고 있습니다. 당신의 임무는 그 아이디어를 회사의 사람들에게 판매하는 것입니다. 오만한 그라우트가 아니라 판매원처럼 생각하십시오 (예 : 저를 좋아하지 않음).
2. 당신은 이길 수 없습니다, 당신은 덜 느슨하게 할 수 있습니다.
3. 아름다움뿐만 아니라 진정한 가치를 더하는 데 집중하십시오. 나는 코드가 멋지게 보이기를 원하지만 때로는 저렴한 문제를 더 받아 들여야합니다.
4. 스위트 스팟을 찾는 좋은 방법은 보이 스카우트 원칙을 따르는 것입니다. 코드 영역에서 작업 할 때는 항상 찾은 것보다 더 나은 모양을 유지하십시오.
5. 작은 개선은 개선이없는 것보다 낫습니다.
6. 자동화 된 도구를 잘 활용하십시오. 예를 들어, 약간의 서식을 정리하는 도구는 세상 을 변화 시킬 수 있습니다 .
7. 우연히 코드 선명도를 향상시키는 다른 아이디어를 판매하십시오. 예를 들어, 단위 테스트는 큰 방법을 더 작은 방법으로 분해하도록 권장합니다.

코드가 심각한 버그없이 작동하고 주요 기한 (효과적인 P & L 또는 회사 PR)이 임박한 경우 주요 변경이 필요한 개선을 제안하기에는 너무 늦습니다. 코드를 개선하더라도 프로젝트 배포에 위험이 발생할 수 있습니다. 코드베이스의 향후 견고성에 투자 할 시간이 더 많았을 때, 개선의 시간은 프로젝트 초기에있었습니다.

코드 검토는 3 가지 목적을 제공합니다.

1. 버그 확인

2. 코드를 개선 할 수있는 곳 확인

3. 코드를 작성한 사람을위한 교육 도구.

디자인 / 코드 품질 평가는 물론 # 2와 # 3에 관한 것입니다.

# 2까지 :

• 제안 된 변경과 수정 비용의 이점이 무엇인지 명확하게 설명하십시오. 비즈니스 결정으로 비용 / 이익 분석에 관한 것입니다.

  예를 들어 "디자인에 대한 X 접근 방식은 변경 Z를 수행 할 때 버그 Y가 발생할 가능성을 크게 줄이며,이 코드는 2 주마다 Z 유형이 변경되는 것을 알고 있습니다. 버그 Y에서 생산 중단을 처리하는 비용 + 버그 찾기 픽스를 수정하고 해제하는 것 다음 기회를 제공하지 않아 발생하는 기회 비용은 $A현재 코드를 정리하는 데 드는 비용과 기회 비용 (예 : 배송료가 늦거나 기능이 적은 비용)입니다 $B. 팀 리더 / 관리자가 - 평가 $A대 $B하고 결정한다.

  • 이를 통해 스마트 팀이이를 효과적으로 관리 할 수 ​​있습니다. 예를 들어 그들은 전체 정보를 사용하여 합리적인 결정을 내릴 것입니다

  • 이것은 (특히 당신이 잘 말하면) 당신의 지위를 상승시킬 것입니다. 예를 들어, 당신은 더 나은 디자인의 이점을 볼 수있을만큼 똑똑한 사람이며, 비즈니스 고려 사항을 고려하지 않고 종교적으로 그것을 요구하지 않을만큼 똑똑합니다.

  • 버그 Z가 발생할 가능성이 높을 경우 다음 제안에 더 많은 이점을 얻을 수 있습니다.

# 3까지 :

• "이것은 최선의 방법이며 리소스를 절약 할 수있는 경우 실제로 수정해야합니다-첨부 된 프로 / 콘 분석 참조"설계 개선 (위의 # 2에 설명 된 내용 첨부) vs. 다음은 코드 견고성을 개선하여 코드를보다 쉽게 ​​유지 관리 할 수 ​​있도록 도와주는 일반적인 지침입니다 ( "옵션 변경 사항"). "내가 원하는대로 코드를 작성"하는 것이 아니라 "이렇게하면 혜택 a, b, c를 얻는다"라는 문구에 유의하십시오. 어조와 접근 방식이 중요합니다.

마감 시간이 다가 오면 전투를 선택하십시오. 다음에 다른 사람이 코드를 검토하거나 유지 관리 할 때 코드에 계속 문제가 발생하면 팀이 코드를 검토 할 때 코드 품질에 더 중점을 두어야 나중에 나중에 큰 문제가 발생하지 않도록해야합니다.

그들은 여분의 일을하기 전에 그 가치를 알아야합니다.

나는 항상 "나는 할 것"으로 내 의견을 시작한다. 이것은 나의 견해가 단순히 많은 견해 중 하나라는 것을 나타낸다.

나는 또한 항상 이유를 포함합니다.

" 가독성 때문에이 블록을 메소드로 추출 할 것입니다."

나는 모든 것에 대해 언급한다. 크고 작은. 때로는 변경 사항에 대해 백 개가 넘는 의견을 제시합니다.이 경우 페어 프로그래밍을 권장하고 자신을 윙맨으로 제공합니다.

이유 때문에 공통 언어를 설정하려고합니다. 가독성, DRY, SRP 등

또한 Clean Code and Refactoring에 대한 이유와 방법을 설명하는 프레젠테이션을 만들었습니다. 나는 지금까지 그것을 세 번 개최했으며, 우리가 사용하는 컨설팅은 그것을 위해 다시 개최하도록 요청했습니다.

그러나 어떤 사람들은 어쨌든 듣지 않을 것입니다. 그런 다음 나는 계급을 뽑아두고 있습니다. 저는 디자인 책임자입니다. 코드 품질은 저의 책임입니다. 이 변경 사항은 현재 시계의 시계에서는 적용되지 않습니다.

내가 한 의견에 대해서는 기꺼이 거절 할 것입니다. 기술적 인 이유, 마감일, 프로토 타입 등. 나는 여전히 코딩에 대해 많은 것을 배워 왔으며, 항상 이성을들을 것입니다.

아, 그리고 최근에 내가 없었있는 적지 않은 변화를 제출 우리 팀에 첫 번째로 점심을 사기 위해 제공하는 어떤 코멘트를. (야, 너도 재미 있어야 해. :-)

때로는 동료의 코드가 지저분한 디자인으로 가득 차고 향후 유지 보수에 대한 관심이 거의 없지만 상황에 따라 기능이 있고 버그가 거의 없거나 전혀없는 경우가 있습니다.

이 코드는 완료되었습니다. 특정 시점에서 재 설계는 정당화하기에는 너무 비용이 많이 듭니다. 코드가 버그가 거의 없거나 전혀없는 상태에서 작동한다면 판매가 불가능할 것입니다. 앞으로 이것을 정리하고 앞으로 나아갈 몇 가지 방법을 제안하십시오. 나중에 코드가 중단되면 재 설계의 가치를 다시 평가하십시오. 절대로 깨지지 않을 것입니다. 어느 쪽이든, 당신은 지금이나 나중에 비용이 같을 것이므로 깨지지 않을 것이라고 도박하는 것이 합리적 인 시점에 있습니다.

앞으로해야 할 일은 개발 반복이 더 엄격하다는 것입니다. 버그를 다듬기위한 모든 노력이 투자되기 전에이 코드를 검토 할 수 있었다면 재 설계를 제안하는 것이 합리적 일 것입니다. 끝으로, 코드가 기본적으로 유지 관리 할 수없는 방식으로 작성되고 릴리스 후 곧 코드를 변경해야한다는 것을 알지 않는 한 주요 리팩토링을 수행하는 것은 결코 의미가 없습니다.

두 가지 옵션 (리 팩터 또는 리 팩터 없음) 중 하나를 선택하면 더 스마트하게 판매되는 사운드를 생각해보십시오.

사장님, 우리는 일정을 잡았고 모든 것이 작동했지만 이제는 기능 X를 추가하여 나중에 기능 X를 추가 할 수 있습니다.

또는

사장님, 우리는 풀 준비가되었습니다. 기능 X를 추가해야하는 경우 며칠이 더 걸릴 수 있습니다.

둘 중 하나를 말하면 상사는 다음과 같이 말할 것입니다.

누가 기능 X에 대해 말했습니까?

결론은 값 비싼 초기 결함 (초기 반복)을 되돌릴 수 없다면 때때로 약간의 기술적 부채가 의미가 있다는 것입니다. 완성 된 기능과 마감일에 가까워 질수록 품질이 우수한 코드 디자인으로 수익이 감소합니다.

[이 답변은 코드 검토에 대한 다른 많은 질문에 대한 경로 재 지정이므로 원래 제기 된 질문보다 약간 더 넓습니다.]

내가 유용하다고 생각하는 몇 가지 원칙은 다음과 같습니다.

개인적으로 비판하고 공개적으로 칭찬하십시오. 코드의 일대일 버그에 대해 누군가에게 알리십시오. 그들이 화려한 일을하거나 아무도 원하지 않는 일을한다면, 그룹 회의 나 팀에게 이메일로 칭찬하십시오.

자신의 실수를 공유하십시오. 나는 비참한 첫 번째 코드 검토 (수신)에 대한 이야기를 학생 및 후배들과 공유합니다. 또한 학생들이 내 앞에서 버그를 만들었 기 때문에 버그를 너무 빨리 잡았다는 것을 학생들에게 알 렸습니다. 코드 검토에서 이것은 "여기서 색인 변수가 잘못되었다고 생각합니다. 색인이 잘못되어 데이터 센터가 다운 된 시간 때문에 항상 확인합니다." [예, 이것은 실제 이야기입니다.]

긍정적 인 의견을 말하십시오. 간단한 "좋은!" 또는 "깔끔한 트릭!" 주니어 또는 불안전 한 프로그래머의 하루를 만들 수 있습니다.

상대방이 똑똑하지만 때로는 부주의하다고 가정하십시오. "실제로 반환하지 않으면 발신자가 반환 값을 어떻게 얻을 것으로 예상합니까?" "반환 문을 잊어 버린 것 같습니다."라고 말합니다. 초기에 끔찍한 코드를 작성했음을 기억하십시오. 누군가가 한 번 말했듯이 "1 년 전에 코드가 부끄럽지 않다면 배우지 않는 것입니다."

직장에 있지 않은 친구들을 위해 풍자 / 속박을 저장하십시오. 코드가 매우 끔찍한 경우 다른 곳에서 농담하십시오. (동료 프로그래머와 결혼하는 것이 편리하다고 생각합니다.) 예를 들어 다음 만화 (또는 이 만화 )를 동료와 공유하지 않습니다 .

한 숟가락의 설탕이 약을 내리는 데 도움이되고 잘못된 것을 간결하게 표현할 수 있습니다-20 가지가 잘못되지 않았습니다. 들리다. 일반적으로 다음과 같습니다.

나는 그것이 더 나은지 궁금합니다 ...

또는

어떤 의미가 있습니까?

그 이유가 분명하다면, 나는 그 이유를 밝히지 않습니다. 이것은 다른 사람들이 다음과 같이 제안에 대한 지적 소유권을 가질 수있는 기회를 제공합니다.

"그렇습니다. < 확실한 이유가 여기에 있기 때문 입니다."

개선이 상당히 분명하지만 그것을 생각하지 못해서 바보처럼 보이게하지 않고 그렇게하는 이유가 듣는 사람과 공유 된 가치를 반영하면 언젠가는 제안하지도 않습니다.

방법이 있는지 궁금합니다 ... <공유 가치 명세서는 여기>

이것은 정말 감동적인 사람들을 다루기위한 것입니다-대부분의 동료들과 함께, 나는 그것을 가지고있게했습니다!

코드 검토가 항상 개선을 목표로하는 것은 아닙니다.

프로젝트가 끝날 무렵에 검토하는 것은 모든 사람들이 버그가 들어올 때 어디를보아야하는지 또는 나중에 더 잘 재사용 할 수있는 더 나은 디자인 프로젝트를 찾도록하기위한 것입니다. 검토 결과에 상관없이 아무것도 바꿀 시간이 없습니다.

실제로 변경하려면 프로젝트에서 훨씬 일찍 코드와 디자인을 논의해야합니다. 코드는 가능한 접근 방식에 대한 이야기로만 존재하는 경우 변경하기가 훨씬 쉽습니다.

귀하의 질문은 "잘못 디자인 된 코드를 코드 검토하는 방법"입니다.

정답 IMO는 간단합니다. 코드의 디자인과 디자인에 결함이 있거나 요구 사항을 충족하지 않는 방법에 대해 이야기하십시오. 결함이있는 디자인 또는 "요구 사항을 충족하지 않음"을 지적하면 개발자는 코드를 변경하지 않아도됩니다.

코드가 "기능적으로 충분"및 / 또는 "사양 충족"및 / 또는 "요구 사항 충족"인 경우 :

귀하가이 개발자의 동료 인 경우, 변경을 "그에게 알려줄"수있는 직접적인 힘이 없습니다.

몇 가지 옵션이 남아 있습니다.

1. 자신의 개인적 "영향"(간접적 인 "파워"의 형태) 및 / 또는 "설득력있는"능력을 사용해야합니다.
2. 조직의 "코드 프로세스"그룹에 참여하고 "코드 유지 관리"를 더 높은 우선 순위로 만들기 시작하십시오.
3. 총알을 깨물고 크 래피 코드를 더 빠르고 유창하게 읽는 방법을 배우십시오. 그래서 크 래피 코드에서 전화를 끊지 마십시오.
   • 이것은 또한 당신을 더 강한 프로그래머로 만들 것입니다.
   • 그리고 크 래피 코드 작업을 할 때 크 래피 코드를 수정할 수 있습니다.
   • 또한 많은 프로젝트에는 기능적인 크 래피 코드가 있지만 많은 크 래피 코드가 있기 때문에 더 많은 프로젝트에서 작업 할 수 있습니다.
4. 예를 들면. 코드를 향상 시키십시오. 그러나 완벽 주의자가 되려고하지 마십시오.
   • "당신은 마감일을 맞출 수없고, 항상 비판을 받고, 다른 사람들보다 더 낫다고 생각하는 느린 사람이 될 것입니다."

나는 총알이 없다는 것을 알았습니다. 세 가지를 모두 사용해야하며 세 가지 모두를 창의적으로 사용해야합니다.

디자인이 끔찍한 경우 캡슐화 를 최대화하는 데 집중해야합니다 . 이렇게하면 개별 클래스 / 파일 / 서브 루틴을 더 나은 디자인 클래스로 대체하기가 더 쉬워집니다.

구성 요소의 공용 인터페이스가 잘 설계되고 내부 작업이 신중하게 숨겨 지도록하는 데 중점을 둡니다. 또한 데이터 스토리지 랩퍼가 필수적입니다. (대량의 저장된 데이터는 변경하기가 매우 어려울 수 있으므로 시스템의 다른 영역으로 "구현 블리드"가 발생하면 문제가있는 것입니다).

구성 요소 사이에 장벽이 생기면 주요 문제를 일으킬 가능성이 가장 큰 구성 요소에 집중하십시오.

마감일까지 또는 시스템이 "완벽"할 때까지 반복하십시오.

누군가의 코드에 대한 직접적인 사전 비판이 아니라 코드 검토 중에 의견에 항상 체계적으로 대응하는 것이 좋습니다.

내가 따르는 한 가지 방법은

1. 이렇게하면 최적입니다.
2. 이 방법으로 작성하면 더 빨리 실행됩니다.
3. "this" "this"및 "this"를 수행하면 코드를 훨씬 쉽게 읽을 수 있습니다.

마감일이 다가 오더라도 이러한 의견은 진지하게 받아 들여질 것입니다. 그리고 아마도 다음 개발주기에서 구현 될 것입니다.

작동하려면 문화 및 개발주기와 코드 검토를 통합해야합니다. 기능 X의 개발이 끝날 때 큰 코드 검토를 예약하는 것이 효과가 없을 것입니다. 우선, 변경하는 것이 더 어려워지고 누군가가 창피하게 느껴져 활동에 대한 저항을 만듭니다.

커밋 수준의 검토와 함께 초기 및 빈번한 커밋이 있어야합니다. 코드 분석 도구를 사용하면 대부분의 검토가 빠릅니다. FindBugs 및 PMD 와 같은 자동화 된 코드 분석 / 검토 도구를 사용 하면 대규모 설계 오류 를 즉시 해결할 수 있습니다. 그러나 아키텍처 수준의 문제를 해결하는 데 도움이되지 않으므로 견고한 디자인이 있어야하며 해당 디자인과 비교하여 전체 시스템을 판단해야합니다.

코드 검토의 품질을 높이십시오.

검토중인 코드의 품질 외에도 코드 검토 자체의 품질과 같은 것이 있습니다.

• 제안 된 변경 사항이 실제로 개선 사항 입니까?
• 아니면 그냥 의견의 문제?
• 매우 명백한 것이 없다면, 검토자가 올바르게 설명한 이유는 무엇입니까?
• 얼마나 걸렸어? (수개월 동안 지속되는 리뷰를 보았으며 개발자는 수많은 병합 충돌을 해결하기 위해 책임을지고 검토했습니다).
• 음정?

대부분 의심스러운 자아 정리보다 양질의 코드 검토를 받아들이는 것이 훨씬 쉽습니다.

문제에는 두 가지 주목할만한 문제가 있습니다. 전술 부분과 마감일 부분입니다. 이것들은 뚜렷한 문제입니다. 첫 번째는 의사 소통과 팀 역학의 문제이고, 두 번째는 계획과 우선 순위의 문제입니다.

재치있게 . 나는 당신이 솔직한 자존심과 리뷰에 대한 부정적인 푸시 백을 피하고 싶다고 가정합니다. 몇 가지 제안 :

• 코딩 표준 및 디자인 원칙에 대한 이해를 공유하십시오.
• 코드 만 개발자를 비판하거나 검토하지 마십시오 . "귀하"또는 "귀하의 코드"라는 단어는 사용하지 말고 개발자와 분리 된 검토중인 코드에 대해 이야기하십시오.
• 완성 된 코드 의 품질에 자부심을 갖고 최종 결과를 개선하는 데 도움이되는 검토 의견이 있으면 감사하겠습니다.
• 수요보다는 개선을 제안하십시오 . 동의하지 않으면 항상 대화하십시오. 동의하지 않을 때는 다른 관점을 이해하십시오.
• 리뷰가 양방향으로 진행되도록하십시오. 즉, 검토 한 사람이 다음에 코드를 검토하도록합니다. "단방향"리뷰가 없습니다.

두 번째 부분은 우선 순위 입니다. 개선에 대한 많은 제안이 있지만 마감일이 다가오고 있으므로 몇 가지만 적용 할 수 있습니다.

글쎄, 당신은 처음에 이런 일이 발생하지 않도록하고 싶습니다! 지속적인 점진적 검토를 수행하여이를 수행합니다. 개발자가 기능에 대해 몇 주 동안 작업 한 다음 마지막 순간에이를 모두 검토하지 마십시오. 둘째, 코드 검토 및 검토 제안 구현 시간은 모든 작업에 대한 정기 계획 및 추정의 일부 여야합니다. 제대로 검토 할 시간이 충분하지 않으면 계획에 문제가있는 것입니다.

그러나 프로세스에서 문제가 발생했다고 가정 해 봅시다. 이제 많은 검토 의견에 직면하게되었으며이를 모두 구현할 시간이 없습니다. 우선 순위를 정해야합니다. 그런 다음 연기 할 경우 나중에 변경하기가 가장 어렵고 가장 위험한 변경 사항으로 이동하십시오.

소스 코드에서 식별자의 이름을 지정하는 것은 가독성과 유지 관리에 매우 중요 하지만 향후 변경이 매우 쉽고 위험도 적습니다. 코드 형식과 동일합니다. 따라서 그 물건에 집중하지 마십시오. 반면에 공개적으로 노출 된 인터페이스의 안전성은 미래에 실제로 변경하기 어렵 기 때문에 우선 순위가 가장 높아야합니다. 영구 데이터는 변경하기가 어렵습니다. 데이터베이스에 불일치 또는 불완전한 데이터를 처음 저장하기 시작하면 나중에 수정하기가 어렵습니다.

단위 테스트로 다루는 영역은 위험이 낮습니다. 나중에 언제든지 수정할 수 있습니다. 아니라, 지역이 수 단위 테스트가 지역보다 낮은 위험하다 할 수 없습니다 단위 테스트합니다.

외부 서비스에 대한 하드 코딩 된 종속성을 포함하여 단위 테스트 및 모든 종류의 코드 품질 문제가없는 큰 코드 조각이 있다고 가정하십시오. 대신이 종속성을 주입하면 코드 청크를 테스트 할 수 있습니다. 이것은 당신이 미래에 테스트를 추가 할 수 있습니다 의미 다음 문제의 나머지 부분을 고정에서 작동합니다. 하드 코드 된 종속성을 사용하면 테스트를 추가 할 수도 없습니다. 먼저이 수정을 수행하십시오.

그러나 처음에는이 시나리오에서 끝나지 않도록하십시오!