상대방이 지나치게 복잡한 솔루션을 만들 때 코드 검토에서 무엇을 말합니까? [닫은]


37

다른 날에는 팀의 누군가가 작성한 코드를 검토했습니다. 이 솔루션은 완벽하게 작동하지 않았으며 설계가 복잡해졌습니다. 불필요한 정보를 저장하고 불필요한 기능을 구축했으며 기본적으로 코드에는 금도금과 같은 불필요한 복잡성이 많았으며 존재하지 않는 문제를 해결하려고 시도했습니다.

이 상황에서 나는 "왜 이런 식으로 되었습니까?"라고 묻습니다.

대답은 다른 사람이 그렇게하는 것처럼 느꼈다는 것입니다.

그런 다음 이러한 기능 중 일부가 프로젝트 사양의 일부인지 또는 최종 사용자에게 사용되는지 또는 추가 데이터가 최종 사용자에게 제공되는지 묻습니다.

내 대답은 아니오 야.

그래서 그는 불필요한 모든 복잡성을 삭제하는 것이 좋습니다. 내가 일반적으로 얻는 대답은 "잘 끝났습니다"입니다.

내 견해는 그것이 완료되지 않았고, 버그가 있고, 사용자가 원하는 것을하지 않으며, 유지 보수 비용이 내가 제안한 간단한 방법으로 수행 된 것보다 높습니다.

이에 상응하는 시나리오는 다음과 같습니다.
동료는 Resharper에서 10 초 안에 자동으로 수행 할 수있는 코드를 직접 리팩토링하는 데 8 시간을 소비합니다. 당연히 나는 리팩토링이 모호한 품질이며 완전히 테스트되지 않았기 때문에 수작업으로 신뢰하지 않습니다.
다시 한 번 내가받은 답변은 "완료되었습니다."입니다.

이 태도에 대한 적절한 반응은 무엇입니까?



47
"너무 복잡한 솔루션을 만들었습니다"
Dante

2
이 문제의 초점은 프로그래머의 정신 / 태도, 프로젝트 관리 (특히 시간 관리) 또는 기술 수준 중 어느 문제입니까?
rwong

6
이것은 아마도 직장에 속할 것입니다-이것은 프로그래밍 문제가 아닙니다.
GrandmasterB

답변:


25

정신 / 태도

  • 예를 들면
  • 비공개로 훈계 (일대일, 코드 검토 외부)
  • 팀원들 사이에 간결한 정신을 가지십시오

팀 관리

  • 작업 항목의 사양에 더 많은 시간을 투자하십시오 (예 : 아키텍처, 알고리즘 개요, UI 와이어 프레임 등)
  • 팀 구성원에게 작업 항목의 범위에 대한 설명을 찾도록 권장
  • 팀 구성원에게 작업 항목을 구현하는 방법에 대해 토론하도록 장려
  • 시작하기 전에 각 작업 항목에 대해 합리적인 견적을 작성하고이를 충족시키기 위해 최선을 다하십시오.
  • 팀원의 "개선"을 모니터링하십시오.
    • 훈계를 받거나 올바른 일을하는 방법을 보여준 후 팀원이 향상되는지 확인하십시오.

기술 수준

  • 개발자 도구 (리팩토링, 코드 검토)를 최대한 활용하기 위해 페어 프로그래밍 세션 또는 일대일 교육 세션에 시간을 할당하십시오.

프로젝트 (위험) 관리

  • 비동기 적으로 코드 검토를 더 자주 수행 (주)
    • "비동기 적으로"에 대한 참고 사항
      • 코드 검토자는 커밋하자마자 변경 사항을 검토하라는 알림 / 초대장을 받아야합니다.
      • 코드 검토자는 개발자와 만나기 전에 코드를 검토 할 기회가 있어야합니다.
      • 개발자의 설명이 필요한 경우 부정적인 의견을 제시하지 않고 IM / 이메일로 비공식적으로 수행하십시오.

69

상대방이 지나치게 복잡한 솔루션을 만들 때 코드 검토에서 무엇을 말합니까?

"너무 복잡한 솔루션을 만들었습니다."

그래서 그는 불필요한 모든 복잡성을 삭제하는 것이 좋습니다. 내가 보통받는 대답은 "이미 끝났습니다"입니다.

변경하기에 너무 늦었다면 왜 코드 검토를하고 있습니까?


기본적으로 코드 검토는 항상 좋고 합리적이며 합리적 인 캐릭터와 만 작동한다고 말하고 있습니다. 실제 세계는 다르게 보입니다 ...
Philip

3
때로는 하루 종일 작업을 한 사람에게 복잡한 코드를 작성하는 데 "좋지 않다, 다시 굴려서 다시 시작"또는 그 라인을 따라 무언가를 말하는 것과 같이 원하지 않는 일을해야하는 경우가 있습니다. 그것은 짜증나지만 당신은 당신에게 감사합니다.
joshin4colours

3
상황을 정확히 요약 한 간단한 답변. "이미 완료되었습니다"에 대한 귀하의 다른 답변은 지나치게 복잡한 솔루션은 유지 보수에서 시간을 낭비하고 재 작업하면 장기적으로 시간을 절약 할 수 있다고 설명하는 것입니다.
DJClayworth

30
+ ∞ "어쨌든 변경하기에 너무 늦었다면 왜 코드 검토를하고 있습니까?"
mskfisher

16

"이미 끝났다"는 만족스러운 답변이 아닙니다. 완료는 테스트와 작업을 의미합니다. 유용한 작업을 수행하지 않는 모든 추가 코드는 올바른 방법으로 유지해야합니다 (삭제).

솔루션을 리팩토링하고 최적화하도록이 태스크를 다시 지정하십시오. 그렇게하지 않으면, 페어 프로그래머를 지정하고 동료로부터 무언가를 배우기를 바랍니다.


추가 코드를 제거하기 위해 실제로 싸우는 경우, 계속 작동하는지 확인하기 위해 전체 단위 테스트 스위트를 생성 할 수있는 경우 계속 유지할 수 있습니다. 어느 쪽이든, 그는 실제로 일을 끝내야합니다.
마이클 코네

코드에 (명백한) 버그가있어 테스트되지 않은 간단한 사실에 대해서는 +1입니다.
Ramhound

8

그래서 그는 불필요한 모든 복잡성을 삭제하는 것이 좋습니다. 내가 일반적으로 얻는 대답은 "잘 끝났습니다"입니다.

그것은 받아 들일만한 대답이 아닙니다 :

  • 이 경우 정말 너무 늦게 변경하려면 다음 코드 검토는 크게 시간 낭비를 WSS 및 관리는이를 알 필요가있다.

  • 그것이 실제로 "변경하고 싶지 않다"고 말하는 방법이라면, 나중에 발생할 문제 / 비용 때문에 코드베이스에 대한 추가 복잡성이 나쁘다는 입장을 취해야합니다. 그리고 미래의 문제에 대한 가능성을 줄이는 것은 코드 검토를 처음부터하는 실제 이유입니다.

그리고 ...

... 솔루션이 완벽하게 작동하지 않았습니다 ...

그것은 불필요한 복잡성의 직접적인 결과 일 것입니다. 프로그래머는 그것을 더 이상 완전히 이해하지 못하도록 복잡하게 만들었고 기능 포인트보다는 복잡성을 구현하는 데 시간을 낭비했습니다. 복잡성을 줄이면 실제로 작업 프로그램에 더 빨리 도달 할 수 있음을 프로그래머에게 지적하는 것이 좋습니다.

지금, 그것은 같은 소리 이의 "다시 세게 밀어"전원 (또는 어쩌면 자신감)가 없습니다. 그러나 그럼에도 불구하고 문제가있는 코더가 다음에 더 나은 작업을 수행하기를 희망하면서 (개인화하지 않고) 약간의 소음을 낼 가치가 있습니다.

이 태도에 대한 적절한 반응은 무엇입니까?

궁극적으로, 스스로 해결할 힘이 없다면 경영진의 관심을 끌 수 있습니다. (물론 이것은 인기가 없습니다.)


7

네 말이 맞았 어, 틀렸어.

  • 깨진 YAGNI 원칙
  • 깨진 KISS 원칙
  • 코드가 완전히 테스트 되었습니까? 아니라면 완료되지 않습니다

이 태도에 대한 적절한 반응은 무엇입니까?

적절한 코드 검토를 수행하십시오. 그들이 이유없이 제안 된 변경 사항을 구현하지 않으면 코드 검토에 시간을 낭비하지 마십시오. 또한 문제를 상사에게 전달할 수도 있습니다 .


5

이러한 경우 상황을 획기적으로 개선하기 위해 우리 팀이 취한 조치 중 하나는 훨씬 더 작은 변경 세트 로의 이동이었습니다 .

하루에 한 번 이상의 작업을 수행 한 후 (대규모) 코드 검토를 수행하는 대신 훨씬 자주 (하루에 최대 10 회) 체크인을 시도합니다. 물론 이것은 또한 몇 가지 단점이있다. 예를 들어, 리뷰어는 매우 반응이 필요하다.

장점은 잘못된 방식으로 많은 양의 작업을 수행하기 전에 문제를 감지하고 조기에 해결할 수 있다는 것입니다.


나는 하루에 10 번은 조금이라고 말합니다. 실제로 푸시하려면 3 또는 4 체크인이 괜찮을 것입니다. 이는 평균 2 시간마다 평균 8 시간의 체크인을 의미합니다. 그러나 10 개의 체크인은 실제로 리뷰 자체를 기반으로 무언가를 검토하거나, 다시보고하거나, 변경 사항을 구현할 시간이없는 것 같습니다.
Ramhound

@Ramhound 예, 10 체크인은 극단적 인 경우이며, 3-4 배가 훨씬 더 일반적입니다. 그리고 그것에 익숙해지기까지 약간의 시간이 필요합니다 ...
stefan.s

2

문제의 근본 원인에 집중해야합니다.

  1. 프로그래머 교육은 프로그래머 에게 주어진 복잡성 증가에 중점을 둡니다 . 이를 수행하는 능력은 학교에서 테스트했습니다. 따라서 많은 프로그래머는 간단한 솔루션을 구현하면 올바르게 작업하지 않았다고 생각할 것입니다.
  2. 프로그래머가 같은 패턴을 따르는 경우 대학에서, 그것은 프로그래머가 생각하고 얼마나있는 동안 그는 시간의 완료 수백이있다 - 더 복잡 더 도전하고 따라서 더.
  3. 따라서이 문제를 해결 하려면 프로그래머 교육에서 일반적으로 요구되는 것과 비교하여 회사 요구 사항이 복잡성에 비해 엄격하게 분리 되어 있어야합니다. 좋은 계획은 "최고의 복잡성 수준은 기술을 향상시키기 위해 설계된 작업에만 예약해야하며 프로덕션 코드에는 사용해서는 안됩니다"와 같은 규칙입니다.
  4. 많은 프로그래머에게 중요한 프로덕션 코드 환경에서 가장 까다로운 디자인을 할 수 없다는 것은 놀라운 일이 될 것 입니다. 프로그래머가 실험 설계를 할 시간을 예약 한 다음 울타리의 측면에서 모든 복잡성을 유지하십시오.

(코드 검토에서 이미 변경하기에는 너무 늦었습니다)


2

코드가 작성된 후 작동하는 것을 모릅니다.

코드를 작성하기 전에 사람들은 코드를 대체 할 수있는 다른 방법을 논의 할 수 있습니다. 열쇠는 서로에게 아이디어를 제공하는 것이기 때문에, 합당한 아이디어가 선택되기를 바랍니다.

고정 가격 계약-계약자와 함께 작동하는 또 다른 접근 방식이 있습니다. 솔루션이 간단할수록 프로그래머는 더 많은 $$를 유지할 수 있습니다.


1

당신은 세상을 고칠 수 없습니다.

프로젝트의 모든 코드를 수정할 수도 없습니다. 적어도 이번 달에는 프로젝트의 개발 방식을 고칠 수 없습니다.

안타깝게도 코드 검토에서 겪고있는 것은 너무 일반적입니다. 필자는 10 개로 작성 될 수있는 100 줄의 코드를 검토하는 것을 자주 발견 한 두 조직에서 근무했으며 "이미 작성하고 테스트했습니다"또는 "우리는 찾고 있습니다. 재 설계가 아닌 버그 "

그것은 당신의 동료들 중 일부는 당신이 할 수있는 것만 큼 프로그램 할 수 없다는 사실입니다. 그들 중 일부는 꽤 나쁠 수 있습니다. 그것에 대해 걱정하지 마십시오. 보충이 나쁜 클래스 몇 개는 프로젝트를 중단시키지 않습니다. 대신, 다른 사람들에게 영향을 줄 그들의 일에 집중하십시오. 단위 테스트가 적절합니까 (있는 경우)? 인터페이스를 사용할 수 있습니까? 문서화되어 있습니까?

나쁜 코드 인터페이스가 정상이라면, 하지 않습니다 당신이 그것을 유지하기 위해 때까지 걱정, 다음 을 다시 작성합니다. 누군가 불평하면 리팩토링이라고 부릅니다. 그래도 불만이 있으면보다 정교한 조직에서 직책을 찾으십시오.


0

프로젝트에는 제공 가능한 품질 검사 절차와 사용 된 도구를 제어하는 ​​표준 정책이 있어야합니다.

사람들은이 프로젝트에서 어떤 작업을 수행하고 어떤 도구를 사용할 수 있는지 알아야합니다.

아직이 작업을 수행하지 않았다면 생각을 정리하고 수행하십시오.

코드 검토에는 표준 항목의 체크리스트가 있어야합니다. "이미 완료되었습니다"라는 메시지가 표시되고 개인적으로 그렇지 않은 경우이 개발자의 프로젝트 관리자 또는 선임 개발자로서의 책임을지지 않습니다. 이 태도는 용납되어서는 안됩니다. 나는 어떤 일이나 모든 일을하는 방법에 대한 논쟁을 이해할 수 있지만, 일단 해결책이 받아 들여지면 거짓말은 용납되어서는 안되며 명확하게 언급되어야합니다.


0

매장에서는 일부 설계 방법론을 시행해야합니다.

  • 요구 사항을 명확하게 정의해야합니다.
  • 요구 사항을 지원하는 사용 사례를 개발해야합니다.
  • 사용 사례를 구현하는 데 필요한 기능을 지정해야합니다.
  • 비 기능 요구 사항 (응답 시간, 가용성 등)을 지정해야합니다.
  • 각 시스템 기능을 사용 사례 및 실제 요구 사항에 다시 매핑하려면 RTM (Requiements Tracabilty Matrix)이 필요합니다.
  • 실제 요구 사항을 지원하지 않는 기능은 삭제하십시오.
  • 마지막으로 코드 검토에서 정의 된 기능을 직접 구현하거나 지원하지 않는 코드를 표시하십시오.

0

아마도 대부분의 사람들이 나중에 기분이 나 빠지기 때문에 지나치게 복잡하지는 않을 것입니다. 나는 이것이 일어날 때 많은 코드가 그것에 대해 한 마디도 말하지 않고 작성되었다고 가정합니다. (그 이유는 무엇입니까? 그 사람이 충분한 권한을 가지고 있기 때문에 코드를 실제로 검토 할 필요가 없습니까?)

그렇지 않으면 코드 검토가 덜 공식적이지만 더 자주 이루어집니다. 그리고 큰 모듈을 작성하기 전에 어떤 접근 방식을 신속하게 논의해야 할 수도 있습니다.

"이것이 너무 복잡하다"는 말은 어디에도 없습니다.


0

불행히도 코드 리뷰는 현재보다 미래에 더 많습니다. 특히 엔터프라이즈 / 기업 환경에서 선적 된 코드는 항상 선적되지 않은 코드보다 더 중요합니다.

물론 이것은 코드 검토가 완료된 시점에 따라 다릅니다. 그것이 개발 과정의 일부라면 지금 당장 이점을 얻을 수 있습니다. 그러나 CR이 사후 부검으로 취급된다면 향후 더 잘할 수있는 일을 지적하는 것이 가장 좋습니다. 귀하의 경우 (다른 사람들이 말했듯이) 일반적으로 YAGNI와 KISS 및 이러한 원칙을 적용 할 수있는 특정 영역을 지적하십시오.


0

지나치게 복잡한 것은 무엇을 의미합니까? 모호한 진술을하면 모호하고 불만족스러운 답변을받습니다. 한 사람에게 지나치게 복잡한 것은 다른 사람에게 완벽합니다.

검토의 목적은 특정 문제와 오류를 지적하는 것이며, "과도하게 복잡하다"라는 문구가 의미하는 것은 아닙니다.

문제가 지나치게 복잡하면 다음과 같이 더 구체적으로 말하십시오.

  • X 부분을 Y로 변경하지 않아도 코드가 간단 해 지거나 이해하기 쉬워 집니까?
  • 나는 당신이 X 부에서 무엇을하고 있는지 이해하지 못한다. 나는 당신이하려고했던 것이 이것이라고 생각한다. 더 깨끗한 방법을 제시하십시오.
  • 이것을 어떻게 테스트 했습니까? 이것을 테스트 했습니까? 지나치게 복잡하면 일반적으로 빈 응시가 발생합니다. 테스트를 요청하면 원래 코드를 테스트하는 방법을 알 수 없을 때 코드를 자주 단순화하게됩니다.
  • 여기에 오류가있는 것 같습니다. 코드를 변경하면 문제가 해결됩니다.

누구나 모호한 문제를 지적 할 수 있습니다. 솔루션을 제공 할 수있는 훨씬 더 작은 하위 집합이 있습니다. 검토 의견은 가능한 구체적이어야합니다. 무언가가 지나치게 복잡하다고해서 그다지 많은 의미가있는 것은 아니며, 다른 사람들이 귀하가 코드를 이해하지 못하는 능력이 없다고 생각할 수도 있습니다. 대부분의 개발자는 좋은 디자인과 나쁜 디자인의 차이점에 대한 단서가 없습니다.


코드에는 명백한 버그가 있습니다. 저자는 또한 솔루션 자체가 틀렸다고 생각한다는 사실은 버그가 있다는 사실을 강조합니다. 코드에 버그가 있고 완전한 회귀 테스트없이 잡을 수없는 명백한 버그에 대해 이야기하고 있지 않다면 해당 코드에 문제가 있습니다.
Ramhound

@Ramhound : 버그가있는 경우 특정 버그를 지적하십시오. 버그 수정이 검토 프로세스의 일부가 아닌 경우 검토를 유지하는 요점은 무엇입니까? 내가 말했듯이, 지나치게 복잡한 것은 버그가 아닙니다. 그것은 확실히 단점이지만 그것이 너무 복잡하다고 믿는 유일한 사람이 OP이고 다른 누구도 오 잘하지 않는다면. 그 때 열심히 노력하고 리드가되고 표준에 따라 품질을 선언하십시오. 나는 OP와 공감할 수 있고, 같은 문제를 겪었고, 이제 사람들에게 내가 원하는 것을 변경하도록 지시 할 권한이 있기 때문에 다른 것들이 더 높은 우선 순위가된다는 것을 알게되었습니다.
덩크

0

때때로 "애자일"원칙에 중점을 두는 것이 가치가 있습니다. 그룹이나 개인이 조금 벗어난 것처럼 보일 수도 있습니다.

초점을 맞추는 것이 팀의 큰 재 작업을 의미 할 필요는 없지만, 모든 팀원이 자신에게 가장 중요한 관행을 논의하고 논의해야합니다. 나는 적어도 이것들에 대해 논의 할 것을 제안한다.

  • 가장 간단한 방법으로 작동합니까?
  • 당신은 그것을 필요로하지 않을 것입니다 (사양에없는 문제를 해결하고 있습니까)
  • 코딩하기 전에 테스트 작성 (코드 집중에 도움이 됨)
  • 자신을 반복하지 마십시오

또한 작동하는 것, 그렇지 않은 것 및 여전히 필요한 것을 가끔 (매주?) 검토하는 것이 실제로 도움이 될 수 있습니다.


0

기술적으로 생각하는 관리자가있는 경우 이관합니다. 이것은 깨져야 할 습관처럼 들립니다.

코드가 사양에 맞게 작성되지 않은 경우 정의에 따라 코드 검토에 실패해야합니다. "아무도 요청하지 않은 작업을 수행했지만 작동하지 않아서 누군가가 요청한 작업을 수행하지 않고 그대로 두겠다"는 개념을 이해하지 못합니다.

이것은 모든 개발자가 들어가는 나쁜 습관입니다. 디자인 사양에 따라 작업했다면 정당한 이유없이 일치하지 않는 것은 아닙니다.


0

한마디 : 민첩

확실히 모든 것을 해결하지는 못합니다. 그러나 반복 작업 (예 : 1-2 주)을 처리하고 진행중인 작업을 제한하고 스프린트 계획 / 검토를 활용하여 폭포 같은 실수를 피해야합니다. 실제로 수행중인 작업에 대한 가시성이 향상되어야합니다.

일반적인 프로젝트 기반 개발의 경우 스크럼 접근 방식을 채택하는 것이 좋습니다 . 지속적인 개발 / 통합 환경, 특히 동일한 또는 관련 프로젝트를 수행하는 많은 개발자가있는 경우 Kanban 요소 통합을 고려하십시오 . 또 다른 효과적인 접근 방식은 극한 프로그래밍 의 정의 된 방식 페어 프로그래밍 을 활용 하는 것 입니다.

당신의 상황은 거의 독특하지 않습니다. 소규모 팀이라도 프로세스를 통해 현재 상황을 피할 수 있습니다. 적절한 가시성과 합리적으로 정리 된 백 로그를 통해 이와 같은 질문은 스프린트 계획 결정이되어 기술 부채관리하지 않아도 됩니다.


-1

과거에 내가 말한 것은 "이 코드는 복잡하고 코드가 무엇을 하려는지 확신하지 못합니다. 코드를 단순화하거나 더 명확하게 작성할 수 있습니까?"


-2

코드를 삭제 / 롤백 한 후 코더에게 : "죄송합니다. 코드를 다시 작성하십시오. 이미 한 번 작성 했으므로 20 분 이내에 사양에 필요한 코드 만 제공해야합니다.

"다음 리뷰는 20 분 안에 있습니다.

"좋은 날."

어떤 주장도 받아들이지 마십시오!

이모 완료

크리스


상사가 그렇게하지 않아서 다행입니다.

@Jon : 6 살짜리 아이가 말했듯이 사람들이 "이미 끝났어요"와 같이 비전문적으로 반응 할 때는 아이들처럼 대해야합니다.
cneeds

2
동의한다고 말할 수 없습니다. "어린이처럼 대우"한다면 사람들로부터 어떤 결과를 얻을 것으로 예상됩니까? IMHO가 더 건설적인 다른 접근법이 있습니다.

나는 cildren과 같은 치료 전문가를 옹호하지 않습니다. 주어진 예에서 우리는 기능 불능으로 버그가있는 코드를 작성하고 합법적 인 질문에 유치한 답변을 반환하는 완고하고 화려한 누군가가 있습니다. Dan은이 문제를 해결하는 가장 좋은 방법을 요구하고 있습니다. 가장 인기있는 방법은 아닙니다.
16:18에

다행히도 나는 팀에 "자녀"가 없기 때문에 그들이 전문가 인 것 이외의 것으로 취급 할 필요가 없습니다. 그들은 기능 (내 시간과 돈을 낭비)에 대해 묻지 않고 추가 코드를 작성하고 무언가를 다시 방문하거나 수정하도록 요청 받았을 때 경험을 통해 배웁니다.
cneed
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.