경험이 적은 프로그래머의 코드를 수정하려면 어떻게해야합니까?


19

약간의 배경 지식 : 저는 10 명의 직원으로 구성된 두 명의 프로그래머 중 한 명입니다 (나머지는 예술가와 경영진입니다). 우리 둘은 흐름을 잘 만들고 필요한 프로젝트를 개발하는 데 필요한 모든 코딩 작업을 수행합니다. 나는 약 4 년 동안 프로그래밍을 해왔으며, 이것이 그의 첫 번째 "실제"직업이다. 우리는 일반적으로 언제든지 다른 프로젝트를 진행하고 있습니다.

몇 달 전에 나는 나중에 프로젝트에 사용될 일련의 클래스를 개발했다. 이 프로젝트의 상당 부분이 GUI 인터페이스를 설계하고 프로그래밍하기 위해 (청구상의 이유로) 그에게 위임되었습니다. 그가 새롭기 때문에 나는 디자인에 약간 도움을 받았고 나머지 사람들에게 도움이 필요한지 물어 보라고 말했다. 그는 몇 주 전에 인터페이스를 완성했으며, 약간 느리지 만 인터페이스가 작동한다는 것을 보여주었습니다.

그 프로젝트의 다음 부분이 시작 되었습니다. 다음 단계로 시작하기 위해 인터페이스를 열고 즉시 문제가 발생했습니다 (약간의 속도 저하, 일반적인 조치 오류 등). 나는 몇 가지 문제에 대한 코드를 들여다 보았고 발견하고 O(n^n)있어야한다 전화에 O(n), 아니 오류 검사와 형 가정 (이 파이썬에서의), 원래의 코드에 추가 된 GUI에 대한 참조, 등등.

이제 나는 그에게 무엇이 잘못되었고 어떻게 고쳐야하는지 가르치고 싶지만, 그는 이미 다음 프로젝트로 넘어갔습니다. 몇 주 전이었습니다. "돌아가서 바로 해!"라고 말하는 것이 두렵습니다. (물론 도움으로) 너무 가혹하며, 그 동안 계속해야 할 다른 프로젝트가 있습니다. 지금 코드를 직접 수정하고 미래에 물건을 잡아야합니까?


4
앞으로 코딩 지침에 동의 할 가능성이 있습니까?
Benni

5
경영진에게 즉시 달려 가서 그에게 말하지 않는 것이 좋습니다. 일부 회사는 책임 중심입니다. 수정 사항을 체크인 할 때 수정 사항을 그룹화 한 후이 사람이 나중에 보도록하십시오. 반면에, 신입생조차도 O(n^n)다른 방법 이 없다면 코딩을해서는 안됩니다 . 그렇다면 알고리즘에서 C를 얻었거나 가져 오지 않았거나 엉터리 선생님이 있었을 것입니다. 일반적인 문제를 찾기 위해 일종의 도구를 활용하는 것이 좋습니다. 아마도 다음 작업으로이 사람이 성능 테스트를 작성할 수 있습니까?
Job

왜 단순히 잘못된 기간에 관한 문서가없는 O (n ^ n). 당신이 진정으로 그렇게해야한다면 의견이 그 이유를 더 잘 설명했습니다.
Loren Pechtel

"이봐, O (n * n)은 그렇게 나쁘지 않다, 많은 응용 프로그램이 그것을 필요로한다 ..."라고 쓰려고했지만 나는 곱셈 부호가 아니라 살인자라는 것을 깨달았다.
Max

O (n)에 큰 상수가 있고 n이 작은 경우 O (n ^ n)은 O (n)보다 10 배 빠릅니다. codinghorror.com/blog/2007/09/… 그리고 다시, n ^ n은 극단적입니다 : D
Coder

답변:


33

일종의 코드 검토 정책을 설정하는 것이 여러 수준에서 유리할 수 있습니다. 몇 가지 즉각적인 이점 :

  • 코드가 커밋되기 전에 코드 품질에 직접 영향을 줄 수 있으므로 코드 기본 품질을 높게 유지
  • 다른 눈이 잡을 수있는 유사한 실수를하지 않도록합니다.
  • 코딩 지침이없는 경우 리뷰는 자연스럽게 코딩 스타일의 일관성을 이끌어냅니다.
  • 지식 공유. 둘이 있고 버스에 치면 ...

이제 코드를 정리하기 시작하면이 코드를 검토 할 때이를 강의 연습으로 사용하십시오. 당신은 당신의 물건을 검토하게 될 것이고, 그는 다음에 더 잘하는 법을 배울 수 있습니다.


3
+1 코드 검토는 이에 대한 좋은 방법입니다. "여기에서 코드를 개선하는 방법은 다음과 같습니다.
Steve Jackson

1
하나는 내가하지 많은 것들이 없습니다 .. 코드 검토는 어떤 '황금률 코딩 가이드 라인'보다 훨씬 더 적합 말하고 싶지만 결코 좋아.
Max

이 아이디어가 정말 마음에 듭니다. 감사합니다. 이제 코드 검토를 수행하는 좋은 방법에 대해 조금 연구해야합니다!
TorelTwiddler

1
mumak.net/stuff/your-code-sucks.html 에는 기본적으로 훌륭하고 재미있는 종이가 있습니다 . 검토는 건설적인 방식으로 검토를 수행하기위한 행동 기술에 관한 것입니다. 이는 성공적인 검토에 매우 중요합니다.
nithins

@TorelTwiddler, 코드 리뷰는 비난이 아니라 학습을위한 것임을 기억하십시오. 그가 잘한 일을 지적하여 개선 할 수있는 방법을 제안하는 것과 동시에 그들이 좋다는 것을 알게된다.
CaffGeek

5

절대로 코드를 수정하지 마십시오. 그렇지 않으면 실수를 저지르는 경우를 제외하고는 다른 것을 배우지 않습니다. 이 때까지 작업이 수행되지 않습니다 . 전문직을 시작했을 때 정말 운이 좋았고 직속 상사가 내가 저지른 모든 것을 재확인했으며, 더 나은 해결책이 있거나 어리석은 실수를했을 경우 저의 기술이 나아 졌다는 것을 의미했습니다. 더 단단한 피부.

미끄러지게하면 나쁜 습관이 번식하고, 이제 시정하면 비판에 더 잘 대처할 수 있고, 주장을 마치기 전에 삼중 점검을 할 수 있습니다.


2

프로젝트가 "작동"하고 합리적인 시간 내에 완료되었다고 추론 할 수 있습니까 (심지어 있지만 고칠 수있는 디자인 문제가 있지만)? 그렇다면 몇 년 동안 본 많은 프로젝트보다 훨씬 나은 모양입니다.

더 많은 커뮤니케이션이 팀에 도움이 될 것이라고 생각합니다. 정기적 인 코드 검토를 통해이 작업을 수행 할 수 있습니다.

"너무 가혹한"태도에 민감하다는 것이 좋으며, 코드 리뷰는 중학교 사람들이 구워서 면밀히 조사하는 데 열중하고 열악한 경험 일 필요는 없다는 것을 명심해야합니다. 또한 선임 개발자가 모범 사례를 보여주고 "실수"가있는 상황에서도 정중하고 친절하게 서로 신뢰하는 방법이 될 수 있습니다.

사람들은 정말 좋은 물건이 어떻게 보이는지 잘 알게됩니다. 이것은 모든 작은 결함을 체계적으로 지적하는 것보다 낫습니다. 그러나 O (n ^ n)는 부드럽고 건설적으로 지적되어야합니다.


0

지식을 공유하십시오.

나는 선배에서 후배로의 가르침과 교환하여 그의 새로운 프로젝트에 도움을 줄 것입니다.

두 프로젝트 모두에서 프로그래밍을 페어링하지 않는 이유는 무엇입니까?

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.