누군가 코드가 엉망이라고 말하면 어떻게 반응하겠습니까?


86

나는 좋은 프로그래머입니다, 그래서 나는 전에 생각했습니다. 나는 항상 프로그램하는 것을 좋아합니다. 더 나은 프로그래머가되기 위해 프로그래밍에 대해 많은 것을 배우고 싶습니다. 나는 1 년 동안 프로그래밍을 공부했고 지금은 거의 2 년 동안 프로그래머로 일하고 있습니다. 한마디로, 거의 3 년의 프로그래밍 경험이 있습니다.

우리 팀은 5 명의 프로그래머로 구성되어 있으며 우리 중 4 명은 새롭고 1 명은 3 년 이상의 경험이 있습니다. 우리는 거의 1 년 동안 프로그램을 위해 일해 왔으며 아무도 내 코드를 검토 한 적이 없으며 작업 할 페이지가 주어졌습니다. 우리는 코드 검토를 한 적이 없으며 모두 새로워 서 깨끗한 코드가 무엇인지 알지 못합니다. 프로그래머가 스스로 배우는 것 같아요?

철저한 테스트없이 프로그램을 프로그램에 배포했습니다. 이제는 엄격하고 코드를 변경하기 전에 먼저 승인 및 코드 검토가 필요합니다. 처음으로 누군가 내 코드를 검토하고 엉망이라고 말합니다.

너무 슬프고 아파요. 나는 정말로 프로그래밍을 좋아하고 그들에게 그런 말을하게하면 정말 아프다. 나는 정말로 나 자신을 향상시키고 싶다. 그러나 나는 영화에서와 같은 천재 프로그래머가 아닌 것 같습니다. 더 나은 방법에 대해 조언 해 주시겠습니까? 코드를 비판하는 무언가를 경험 한 적이 있고 실제로 상처를받은 적이 있습니까? 그 사건들에 대해 무엇을합니까?


51
"그러나 그것은 영화에서와 같은 천재 프로그래머가 아닌 것 같습니다 . " 실수는 소프트웨어 개발자, 해커 및 실제 기술과 관련된 모든 것에 대해 영화에서 보는 것을 믿는 것입니다.
Stephen C

160
축하합니다! 오늘부터, 당신은 공식적으로 진짜 프로그래머입니다! 당신이 끔찍하다고 말하는 것은이 직업에서 가장 중요한 디딤돌 중 하나입니다. 나는 이것을 진술 할 수 없다 : 모든 전문 프로그래머는 자신이 쓴 어떤 것이 어느 시점에서 끔찍하다는 말을 들었으며, 처음 접했을 때 약간의 찌르는 소리이지만, 사실이며 코스에서 더 많은 시간을들을 것이다 당신의 경력의! 벅, 당신은 직업에 합류했습니다. 좋은 프로그래머는 그 bs을 가지고 같은 실수를하지 않는 법을 배웁니다 (대신 매번 다른 실수를합니다!)
Jimmy Hoffa

15
@newbie 당신이 새롭고 자존심을 조금 쌓았고 당신이 나쁘다는 것을 알기에 충분히 망쳐 놓지 않았습니다. 나도 나쁘고, 우리는 이것으로 정말 나쁩니다. 자아가 남아 있다면 더 많은 실수를 한 후에 나아갈 것입니다. 당신은 전문 엔지니어이고 데이터베이스 전에 실수로 날아 경우 진심으로, 손을 들어 손 제기
지미 호파

14
실망한? 도대체 왜 실망했을까요? 내 전 CTO (그는 특별히 나에게 이름을하지 못했지만, 우리 팀의 모든 사람들은 그가 무슨 말을 누가 알고 있었다) 그가 쓴 기사에서 나를 불러 내가 가진 첫 번째 기회가 여기 내 대답 중 하나의 기사를 인용했다 . 또한, 나는 이 질문에 설명 된 사악한 개발자 입니다. 나는 OP가 질문을 게시하도록 권유했으며, 심지어 대답했다.)
yannis

19
사람들이 코드가 잘못되었다고 말했기 때문에 사람들을 기억하십시오. "귀하의 코드가 엉망입니다"라는 말을 듣고 OP는 "그리고 여기에 이유가 있습니다." 그런 다음 분석 을 시작할 수 있습니다.
Tony Ennis 2016

답변:


175

진실은 아마도 2 년 안에 현재 코드를 볼 때 코드가 엉망이라는 데 동의 할 것입니다. 프로그래밍 학습은 끝이없는 과정이며 항상 당신보다 더 나은 사람이있을 것입니다.

따라서 코드가 엉망이라고 말한 사람이 단순한 의미가 아니며 프로그래머에게 공통적 인 "나는 더 잘 할 것"질병의 또 다른 사례가 아닌 경우 코드에 정확히 무엇이 잘못되었는지 어떻게 물어볼 수 있습니까? 그것을 개선하십시오.


27
네가 옳아! 나는 2 년 전에 내 코드를 비웃는 다. 그래서 나는 또한 2 년 후 내 코드를 비웃을 것입니다. 나는 그것에 대해 조금 감정적이되었습니다. 어쨌든, 나는 더 나은 사람이 되려고 노력할 것이다.
초보자

5
@ 초보자 : 당신은 간다. 그것이 당신이 정말로 알아야 할 것입니다. 나의 좌우명은 10 년 넘게 "지금부터 2 년이 될 것만 큼 좋은 사람은 아닙니다"였습니다. 그리고 나는 아직 틀리지 않았습니다. 나는 당신보다 내 경력에 훨씬 더까지까지 그것을 배우지 못했습니다. 동료가 큰 호의를 베 풀었습니다.
pdr

27
나는 6 개월이 코드를 싫어하는 데 많은 시간이 걸릴 것이라고 생각합니다. 언젠가 내가 전에 육개월를 작성하고 한 코드를 찾을 수 있음을 걱정 하지 그것에 대해 싫어 뭔가를 찾을 수 있습니다. 프로그래머로 성장하지 않았다는 신호일 것입니다.
zzzzBov

37
2 년! 나는 아침에 쓴 코드로 오후에 웃을 수 있습니다.
dan_waterworth

9
또한 코드 검토가 매우 유용한 프로세스라고 말합니다. 이 답변에서 알 수 있듯이, 훌륭한 프로그래머라면 시간이 지남에 따라 이것이 끔찍한 코드라고 생각할 것입니다. 또한 코드 검토자가 검토 프로세스에 올바르게 접근하지 않고 있다고 말하고 싶습니다. 그것은 검토되는 프로그래머가 중요하지 않다고 느끼는 부정적인 형벌 과정이 아니라 지식이 전달되는 건설적인 비판 과정이어야한다. 이것은 리뷰에서 얻을 수있는 많은 장점을 무효화합니다.
Mattygabe

68

코딩하는 데 자부심을 가지지 마십시오. 얼마나 잘 배우는지 자랑스럽게 생각하십시오. 그런 다음 코드를 개선해야한다는 사실을 알게되면 프로그래머가 얼마나 나쁜지에 대한 비판을받는 대신 배우는 것이 얼마나 좋은지를 보여줄 수 있습니다.

내가 무슨 말을하는지 모른다면 http://www.perlmonks.org/?node_id=270083을 읽으십시오 .


좋은 기사. :) 그래서 나는 단지 내 자존심을 다루고 있습니다.
초보자

2
@newbie 정확합니다. 코드에 대한 비판을 받으면 자아가 해당 코드의 품질에 묶여있는 경우에만 화가 날 수 있습니다. 코드에서 자아를 이혼하면 문제가 사라집니다.
btilly

5
나는 당신이 얼마나 잘 배우는 것에 자부심을 가지고 동의하지만, 코딩하는 방법에 자부심을 가져야합니다. 코딩 방법이 자랑스럽지 않다면 더 나아지지 않을 것입니다.
Bryan Oakley

1
또한 학습에 자부심을 가지고 조심해야합니다. 실제로 학습에 능숙하지 않으면 동일한 문제가 발생할 수 있습니다.
Nico Burns

나는 교만이 일곱 가지 치명적인 죄 중 하나라고 생각 했습니까? 요즘 모든 사람들이 추천하는 것은 무엇입니까? 당신이 좋은 일을했다고 만족감을 느끼는 것은 어떻습니까.

40

20 년이 지난 후에도 내 코드 중 일부가 여전히 엉망이라는 것을 알고 있습니다. 최고의 코드를 작성하는 것과 작업을 수행하는 데 필요한 것을 작성하는 것 사이에서 결정을 내려야합니다. 합의 된 기한 내에 업무를 수행하면 기술의 완성도를 향한 끊임없는 퀘스트보다 우선합니다.

요령은 그것을 받아들이는 법을 배우는 것입니다. 더 잘할 수 있다는 것을 받아들이는 법을 배우십시오. 결함과 함께 사는 법을 배웁니다. 이번에는 완벽하지 않을 것이며 다음 번에는 완벽하지 않을 수도 있으며 대안이 제공되지 않기 때문에 의도적으로 선택하는 것을 받아들이십시오. 그리고 그것은 더 나쁘다.

면책 조항 : 이것 중 어느 것도 "잘못된 코드는 괜찮습니다"라고 읽지 않아야합니다.


2
"일을 끝내려고"노력하는 것은 평범한 사람을 위해 노력하고 있습니다. 정확하고 효과적이며 효과적 일 수 있습니다. 중국 제품 만 살펴보십시오. 그러나 일을 훌륭하게 만들기 위해 노력하는 것이 20 년간의 프로그래밍 가치를 친구로 만드는 것입니다. 20 년을 되돌아 보면, 무엇을 보여 주는가? 일을 끝내거나 자부심을 가지고 일을 하는가?
kingdango

9
이상한 코드 기반 아트 프로젝트를 작성하지 않는 한 항상 "작업 완료"에 관한 것입니다. "good code"와 "mediocre code"를 작성하는 것은 즉각적인 작업을 완료하고 미래에 작업을 수행 할 수 있도록 코드를 유지 관리하기 쉽게 만드는 것입니다. 이것을 무시하면 완벽주의로 연결되어 아무런 작업도 수행하지 않습니다. 빠르게 작성된 평범한 코드는 일회성 스크립트를 위해 천천히 작성된 좋은 코드보다 낫습니다.
Steven Burnap

8
금전적 부채와 마찬가지로 기술 부채는 곧 증가하고 기술 부채를 관리하는 방법을 배우는 것은 실제 프로그래머의 기본 기술 중 하나입니다. 매번 완벽한 일 을 할 수있는 충분한 시간을 가진 사람은 믿을 수 없을만큼 훌륭하거나, 일을 진지하게 수행하고 있거나, 자신을 속이는 것입니다.
Mark Booth

1
적절한 균형을 유지하는 것은 어려운 일이 될 수 있습니다. 특히 평범한 디자인으로 진행하는 효과는 평범한 디자인이 유용한 수명 동안 완벽하게 적합한 것으로 판명되었을 때 디자인을 수정하는 데 너무 많은 시간을 소비하는 것보다 훨씬 더 눈에 잘 띄기 때문에 종종 눈에 since니다.
supercat

1
이것은 "일을 끝내는 것"과 "기술적 완벽 함"이 당신이 묘사하는 세상과 다를 필요가 없다는 점에서 나를 슬프게합니다. 개인적으로, 나는 완전히 제한되고 시간 제약 때문에 그런 식으로 릴리스 된 내 코드 코드에 대해 큰 만족을 얻지 못합니다. .
crmpicco

39

모든 사람의 코드는 혼란스럽고 훌륭한 프로그래머는 없습니다.

있습니다 :

  • 빠른 배송 프로그래머
  • 의미 적으로 올바른 코드를 제공하는 프로그래머
  • 항상 최적의 솔루션과 가장 빠른 알고리즘을 제공하는 프로그래머
  • 코드가 쉬운 프로그래머

그들은 거의 같은 사람이되는 일이 거의 없습니다.

그리고 성장해야 할 엉덩이 프로그래머가 있습니다.

  • 무슨 일인지 물어봐
  • 인간으로서의 가치의 척도로 개인적으로 언급하지 마십시오.
  • 팀에 구문 가이드 라인이 있다는 것을 알고, 그것들 따라야하고, 임의적이므로 , 최적의 솔루션이나 최종 단어가 없기 때문에 ad nauseam에 대해 논의 할 의도 가 없습니다.
  • 그들의 코드에 주석을 달아주십시오;
  • 그들의 코드에 주석을 달아주십시오; (sic)
  • 단순하고 평범한 작업에 대한 디버깅이 쉽고 덜 영리한 솔루션을 찾으십시오.
  • SQL로 수업을 들으십시오 (전 세계 인구의 절반을 SQL로 수업을
    보내면 안전합니다.)

예술이 아니라 공예품입니다.
우리는 당신이 영리하다는 것을 당연한 것으로 여깁니다. 당신은 컴퓨터 프로그래밍입니다.
그럼에도 불구 AMD64하고 x86당신의 산문의 힘으로 강요하지 않습니다. 일을 단순하게 유지하십시오.


3
말 그대로 크게 웃어보세요. 너무 좋아 roflcopters
kingdango

1
AMD64와 x86은 당신의 논문의 힘으로 강요되지 않습니다. - 엄청나 다.
샘 브린 크

SQL에서 수업을 수강하면 +1
HLGEM

28

글쎄, 당신의 코드가 엉망이라고 말하는 사람은 옳더라도 건설적이지 않습니다. 그들이 왜 엉망인지 이유를 알려 주었습니까? 마찬가지로, 방법이 너무 길고, 책임이 혼합되어 있고, 분기가 너무 많습니다. 솔직히, 1 년 전에 작성한 코드는 그 이후로 많은 것을 배웠기 때문에 완전한 쓰레기입니다. 따라서 기분 나빠하지 마십시오. 오래 전에 작성한 코드를 읽는 것을 좋아한다면 더 걱정할 것입니다.

코드베이스가 깨끗할수록 주어진 문제를 해결하기 위해 코드베이스와 싸우는 데 소요되는 시간이 줄어 듭니다. 1 년은 프로젝트 초반에 내린 디자인 결정의 고통을 느낄 수 있기 때문에 좋은 시점입니다.

현재 프로젝트에서 기술 스택에 익숙해지면 여러 번 리팩토링했습니다. 이것은 권장되어야하며 현재 코드 기반으로 인해 수행하는 것보다 오래 걸리는 작업을 기록해야합니다.

작성한 코드의 일부 오래된 부분을 살펴 보셨습니까? 지금 다르게하고 싶거나 리팩토링하고 싶은 것을 볼 수 있습니다.

또한 테스트가 부족하다고 언급 할 때는 항상 살펴 봐야합니다. 우리 프로젝트에는 자동화 된 테스트가 없었으며 결과적으로 많은 코드가 결합되었습니다. 단위 / 통합 / 테스트를 정기적으로 작성하지 않더라도 잠시 동안 수행하면 코드를보다 모듈화하고 결과적으로 혼란을 덜 수 있습니다.


26

너무 슬프고 아파요. 나는 정말로 프로그래밍을 좋아하고 그들에게 그런 말을하게하면 정말 아프다. 나는 정말로 나 자신을 향상시키고 싶다.

좋습니다. 그건입니다 많이 , "내 검토가 너무 까다 롭고이다"또는 그냥 "내 검토 나를 좋아하지 않는다"그들을 무시 "내 검토 그가 말하는 무엇을 모르고있다"와 같은 반응을하는 것보다 더 나은. 이 태도는 좋은 것입니다.

그러나 나는 영화에서와 같은 천재 프로그래머가 아닌 것 같습니다.

어떤 종류의 영화를 보았는지 모르지만 영화의 프로그래머 중 90 %가 너무 가짜이므로 시퀀스가 ​​끝날 때마다 눈물이납니다.

더 나은 방법에 대해 조언 해 주시겠습니까?

읽고 연습하십시오. Code Complete 또는 The Pragmatic Programmer 와 같은 책을 확인하십시오 . 비슷한 책을 아마존에서 찾으십시오.

코드를 비판하는 무언가를 경험 한 적이 있고 실제로 상처를받은 적이 있습니까? 그 사건들에 대해 무엇을합니까 ..

왜 아파요? 나는 처음에 그런 멍청한 사람이 된 것에 대해 실망했다. 나는 그 동기를 사용하여 코드를 정리하고 다시 같은 실수를하지 않도록한다 . 내가 하고 싶은 마지막 일은 그것을 배우지 않습니다. 당신은 한 번 내려졌다 같은 이유로 같은 일이 다시 발생하지 않도록하십시오.

완벽하거나 가까운 프로그래머는 없습니다. 더 많은 코드를 작성할수록 더 많은 리뷰와 더 많은 리뷰를 제공 할 수 있습니다.


2
+1과 reviews you provide다른 사람을 비판하는 것이 더 좋은 품질을 내기 위해 자신의 코드를 비판하는 데 더 중요한 관례가 될 수 있기 때문에 +1 .
지미 호파

2
"영화의 프로그래머 중 90 %가 너무 가짜이기 때문에 시퀀스가 ​​끝날 무렵 눈물이났습니다." 90 %? 어떤 영화 보십니까? : PI 는 우리가하는 일을 정확하게 묘사 영화를 보지 못했습니다 . 그리고 ... "황새치"와 "독립 기념일"이 있었다
닉 Bougalis에게

글쎄요 그리고 간결하게 그렇게!
kingdango

16

개발자가되는 가장 좋은 점 중 하나는 매일 학습 과정이라는 것입니다. 당신이하는 것을 모르는 사람이 항상있을 것이고, 당신이 모르는 것을 알고있는 사람이 항상있을 것입니다. 나는 자신이 어느 곳이든 입국 / 후배 수준이라고 생각하지는 않지만, 정당화되고 존중받는 한 비판을받을 수 있다는 점에 감사한다.

적합 할 수있는 비유는 제가 대학에서 작문 교사로 일했던시기와 창의적인 작문 과정에 참여한시기와 관련이 있습니다. 모든 의도와 목적을위한 코드 작성은시, 에세이, 단편 또는 소설을 작성하는 것과 매우 유사합니다. 각 개인은 각자의 방식으로 작업을 수행하지만 동시에 최고의 작가 (또는이 경우 개발자)조차 실수를 범하거나 일이 벌어 지도록합니다. 우리는 종종 우리 자신의 목소리에 익숙해지기 때문에 (또는이 경우 코드 스타일) 이러한 것들을 알아 차리지 못할 수 있습니다.

다른 분야와 마찬가지로 전문가로 간주되는 사람들이 있습니다. 그 사람들이 존재하지 않았다면 배울 사람이 없을 것입니다. 해당 개인이 진정으로 전문가라고 가정하면, 그가 말한 내용을 듣고 코드 개선을 위해 제안한 사항을 묻습니다. 그러나 그가 자신의 도움을 줄 수있는 유일한 사람이 아니라는 것을 잊지 마십시오. 우리는 SE / SO와 같은 과다한 자원이 존재한다는 행운을 빕니다.


9
" 당신이하는 것을 모르는 사람이 항상있을 것이고, 당신이 모르는 것을 알고있는 사람이 항상있을 것입니다 ."-최고; +1.
Maximus Minimus

그래, 그리고 내가 할 수있는 모든 것을 배우고 싶다
초보자

@mh : 저는 현명한 사람이 일반적으로 옳은 것보다 틀린 것보다 훨씬 많은 것을 배울 것이라고 덧붙입니다. 그것은 사물에 대해 틀리려고 노력하는 것이 아니라 배우는 기회를 이용한다면 낙심하지 말아야한다는 말은 아닙니다.
supercat

10

엉망은 오히려 주관적입니다. 당신이 할 수있는 가장 좋은 일은 실제로 그 사람 (또는 리뷰 보고서)에게 물어 보는 것입니다 : 왜 지저분합니까? (그들의 관점에서, 즉)

그들은 당신에게 대답해야하며 다음 중 하나를 수행 할 수 있습니다.

  • 그것에 반대하는 주장 (물론 정당한 이유가 있다면)
  • 새로운 것을 배우고 미래의 코드가 더 어려워지기 때문에 그들의 조언 덕분에 덜 복잡하게 만드는 방법을 알고 있기 때문에 매우 행복합니다.

그는 언급하지 않았다 :( 그러나 여기 내 코드가 있습니다-> codereview.stackexchange.com/questions/18719/…
초보자

왜 지저분하다고 생각합니까?
초보자

7
@ 초보자 : 그럼 그 리뷰어는별로 좋지 않습니다. 코더는 문제가 무엇인지 알지 못하고 어떻게 단서를 개선해야합니까?
오메가

1
알았어 고마워 ... 나도 jquery 프로그래머가 아니야. 나는 자바 프로그래머입니다 ....
초보자

1
그 당시에는 내 코드 만 사용할 수 있습니다. 어쨌든, 당신 말이 맞아요. 자세한 내용을 물어 볼게요. 감사합니다 :)
초보자

8

당신이 걱정한다는 사실은 좋은 징조입니다. 그것부터 시작하겠습니다. 당신은 프로그래밍을 좋아하지만 전문 프로그래머가되는 것을 좋아합니까? 애호가와 전문가 사이에는 큰 차이가 있습니다. 전문가는 업무용 제품에 대한 지속적인 감시를받습니다.

Our team is composed of 5 programmers, and 4 of us are new

당신이 대립없이 2 년을 일했다는 사실은 당신이 매우 느긋한 직장에서 일하고 있다는 것을 말해줍니다. 당신이 실제로 전문가로 나아가기를 원한다면 그렇게 좋지 않습니다. 세계 최고의 프로그래머 중 일부는 Linux 기반을 위해 일하고 있으며 약간의 실수를 할 때 친절하게 대우받지 않습니다 .

상당히 표준적인 코딩 지침에 대한 빠른 검토를 위해 Linux Community Contributors Standards 는 제품에 대한 책임 수준에 대한 아이디어를 제공해야합니다. 올바른 코드 얻기를 참조하십시오.

그 주장을 더욱 발전시키기 위해서는 대부분의 훌륭한 소프트웨어가 철저히 검토되므로 검토를 수용하는 법을 배워야합니다. 이것은 Linus의 법칙을 지지합니다 ...

"검토자가 충분하면 모든 문제를 쉽게 해결할 수 있습니다."

개인적으로, 나는 고도로 숙련되고 책임감 있고 신뢰할 수있는 개발자가 코멘트를 남기는 것을 잊어 버리는 것만 큼 단순한 도끼를 얻는 것을 보았습니다 ... 그래서 누군가가 코드를 엉망으로 만든다면 아마도 ... 극복하십시오 ... 리팩토링. 공연의 일부입니다.

I feel so sad and hurt. 

당신이 자신을 적용하지 않을 때 얼마나 화나게하는지 측정하기 위해 슬픔을 느끼십시오.

당신은 당신의 문제에 대답했습니다 ... 당신은 테스트하지 않습니다!

귀하의 자바 개발자에 대한 의견을 본 후 거의 화가났습니다. 따라서 귀하와 귀하의 개발 팀이 Java 상점에서 일하고 있으며 응용 프로그램에 대한 테스트 프레임 워크가 없다는 말을 올바르게 이해하면 ...

거기에 문지름 거짓말

"우리는 철저한 테스트없이 프로그램을 프로그램에 배포했습니다."

UML Creator Grady Booch 크 리빙 ...

아마추어 소프트웨어 엔지니어는 항상 소프트웨어 개발을 사소하게 표현할 수있는 놀라운 방법이나 도구 인 마법을 찾아야합니다. 그러한 만병 통치약이 존재하지 않음을 아는 것은 전문 소프트웨어 엔지니어의 마크입니다.

Alistair Cockburn 은 민첩한 방법론을 사용하여 사용자와 팀의 성능과 품질을 향상시키는 방법에 대한 풍부한 정보를 자신의 사이트에 제공합니다.

프로그래밍 {및 인생}의 가장 중요한 측면 중 하나는 강점과 약점을 아는 것입니다. 약점을 해결하지 않으면 다방면의 기술을 갖지 못합니다.

Outro ... 당신이 잘하고-그냥 울지 마십시오. 당신의 기술을 개발하는 데 전진하고 프로그래밍에 대한 열정이 당신을 계속 진행하게하십시오. 행운을 빕니다 :-)


5

감정이 코드를 향상시키는 데 방해가되지 않도록하십시오. 코드 검토의 목표는 문제를 찾는 것이므로 문제가 생겼을 때 너무 놀라지 않아야합니다. 즉, 그들은 코더-bashing 세션이 아니어야합니다.

그들은 또한 단지 'Ewwww'라고 말하고 그것을 그대로 두어서는 안됩니다. 프로그래밍에 문제가있는 이유는 항상 있습니다. 예를 들어, 주석 처리 된 코드를 많은 곳에 두는 것은 잘못된 일이지만 누군가가 책에서 그렇게 말한 것이 아니라 코드를 어지럽히고 읽기 어렵게하기 때문에 잘못되었습니다.

당신의 코드는 당신이 아닙니다. 기억.


4

나는 여기서 거시기가 될 것입니다. 분명히, 당신의 코드는 엉망이거나 당신이 묻는 질문은 "왜 누군가가 내 코드가 엉망이라고 말하는가?"입니다. 그러나 당신은 가정에 도전하지 않습니다. 당신은 다치게 행동하고 있고 솔직하게 울고 있을지도 모르지만 프로그래밍을 정당화하는 데 아무런 느낌이 없습니다.

근데 왜 물어? 코드가 짜증나거나 다른 질문을 할 것입니다. 누군가 내 백엔드 웹 코드가 멈췄다 고 말하면 웃으면 서 "괜찮아?" 그들이 내 JavaScript stank를 말해 준다면, 나는 소셜 프로그래머에게 뚱뚱한 입술에 해당하는 것을 줄 것이고 작은 암캐가 분명하게 잘못되어 있기 때문에 어떻게 대응 해야하는지에 대한 조언을 묻지 않을 것입니다! @ # $ ing 잘못되었습니다.

당신이 잘하는 것을 소유하십시오. 그리고 저는 정말로 책임을 져야합니다. 왜냐면 어떤 재치가 당신을 다시 추측하는 데 단 한 번의 방해 만 있기 때문입니다. 좋은 것을 허락하지 마십시오. 당신의 물건을 알아라. 끝.


아멘. 그리고 당신의 물건을 아는 것은 당신의 물건을 알기위한 노력이 필요합니다. 그러나 당신의 옷깃을 튀어 나와야합니다. 그것이 모든 엘리트 아이들이 요즘하는 일입니다. : /
kingdango

예, 더 경험이 많은 개발자가 자신의 잘못을 인정한 첫 번째 사람에 대한 조언을 한 것 같습니다. 여러 성격을 가질 수 있습니다.
Erik Reppen

4

이것을 기억하십시오 : 당신이 보게 될 최악의 코드는 당신 자신의 것입니다!

codinghorror.com의 Jeff Atwood는이 주제에 대해 많은 글을 썼습니다. http://www.codinghorror.com/blog/2009/07/nobody-hates-software-more-than-software-developers.html

개선하고 싶다면 코딩 스타일, 패턴, 워크 플로, 기본적으로 손가락으로 사용할 수있는 모든 것에 대해 읽어보십시오. 또한 더 많은 프로그래밍 언어를 배우고 어떻게 작동하는지 확인하십시오. OOP를 수행중인 경우 다음을 읽으십시오. http://en.wikipedia.org/wiki/Design_Patterns

또한 다른 프로그래머와 대화하고 프로그래밍을하거나 다른 코드를 시청하십시오.

실수하는 것은 불가피하며 반복하는 것입니다.


좋은 감정 (응용 프로그램의 문제가 내 잘못이라고 가정하여 시작하는 점에서 가장 좋아하는 것이 가장 좋아합니다)이지만 유감스럽게도 안됩니다. 당신이 여기에 있고 처음부터 그것에 대해 묻기에 충분히 똑똑하지 않다면 ...
Murph

4

대부분의 경우이 말을 한 사람에게 "감사합니다"라고 말해야합니다.

그들이 직업에 관심이 있고, 일에 관심이 있고, 팀에 관심이 있고, 당신에 대해 관심을 가질 가능성이 있습니다.

비판하기가 어려울 수 있습니다. 그것에 대해 화 내지 마십시오. 그들이 당신에게 무엇을 말하려고하는지 생각하고 감정이 나아지도록하십시오.

나는 오랫동안 (30 년 동안) 프로그래밍을 해 왔으며 스타일과 코드가 항상 향상되고 있습니다. 내가 향상을 아는 유일한 방법은 다른 사람들이 나에게 이야기하거나 돌아와서 내 코드를 검토하는 것입니다.

경력을 시작할 때 작성한 코드를 살펴보십시오. 지금은 어떤 모습입니까? 당신이 그것을 쓸 때 생각했던 것만 큼 좋아 보입니까;)


3

우선, 프로그래밍은 기사 나 책을 쓰는 것과 매우 유사한 과정이라는 것을 이해해야합니다. 먼저 프로그램의 "초안"을 작성하십시오. 이 단계에서 코드가 엉망이 될 것입니다. 따라서 코드를 깨끗하게 만들기 위해 리팩터링합니다. 그런 다음 프로파일 링하고 최적화하기 위해 무엇이 필요한지 확인하십시오. 트릭은 지속적으로 리팩토링하는 것입니다. 그렇지 않으면 혼란이 커질 것입니다. 집을 청소해야하는 것처럼 정기적으로 코드를 청소해야합니다.

코드 검토는 필수적입니다. 적어도 한 쌍의 눈으로 코드를 살펴 봐야합니다. 코드를 보면서 수많은 시간을 보내면 익숙해지며 동료가 즉시 알아 차릴 수있는 버그 나 코드 냄새를 쉽게 놓칠 수 있습니다.

또한 다른 사람에게 코드를 설명하는 행동은 무엇을 놓쳤는 지 확인할 수있는 좋은 방법입니다. 이것은 당신이 크게 쓰고있는 논문을 읽는 것과 같습니다. 뇌는 청각 및 시각 정보를 다양한 방식으로 처리하며, 양식을 전환하여 추론에서 결함을 찾을 수 있습니다. 또한 코드를 동료에게 설명하고 이해가되지 않는 경우 코드를 리팩터링해야한다는 것을 나타냅니다.

코드 검토를 수행 할 때 작성자와 검토자가 자신의 자아를 문에서 확인하는 것이 매우 중요합니다. 목표는 코드를 개선하는 것입니다. 따라서 검토자는 존중해야하며 저자는 열린 마음을 유지해야합니다. 동료는 코드를 유지 관리해야하는 직원이므로 명심해야합니다. 검토자가 변수의 기능을 이해하지 못하면 이름을 바꿉니다. 검토자가 코드 블록의 기능을 이해할 수 없으면 설명이 포함 된 함수로 코드를 리팩터링하십시오. 생각하는 것과 상관없이 동료가 코드를 이해할 수 없으면 좋지 않습니다.

리팩토링에 대해 말하면 단위 테스트 프레임 워크가 있어야합니다. 단위 테스트 프레임 워크가 없으면 리팩토링 할 수 없기 때문입니다.

마지막으로 Robert C. Martin의 "Clean Code"를 읽는 것이 좋습니다. 코드가 왜 엉망인지, 정리하기 위해 무엇을 할 수 있는지 알려줍니다.


3

더 나은 방법에 대해 조언 해 주시겠습니까?

책을 추천하는 Jay의 대답은 좋은 것이지만, 이미 직장에서 전환점에있는 것처럼 들립니다.

과거:

우리 팀은 5 명의 프로그래머로 구성되어 있으며 우리 중 4 명은 새롭고 1 명은 3 년 이상의 경험이 있습니다. 우리는 거의 1 년 동안 프로그램을 위해 일해 왔으며 아무도 내 코드를 검토 한 적이 없으며 작업 할 페이지가 주어졌습니다.

선물:

이제는 엄격하고 코드를 변경하기 전에 먼저 승인 및 코드 검토가 필요합니다.

프로젝트와 팀 관리 및 프로그래밍 측면에서 회사 / 팀 / 부서가 전체적으로 배우는 것처럼 들립니다. 코드를 검토하기 시작하면 적절한주의를 기울이면 거의 모든 영역에서 개선 할 수있는 좋은 기회입니다.

이것을 기회로 사용하십시오. 동료 검토를 수행한다고 가정하면 (팀의 다른 개발자와 함께)이 프로세스가 중요하며 모든 사람이 배울 수 있다고 제안합니다.

기본적으로 결과는 "예, 괜찮아 보인다"는 빠른 검토가 될 것입니다. 좀 더 집중된 노력으로 서로 아이디어를 튀길 수 있습니다. "그렇습니다.하지만 이런 식으로 접근 할 수 있었기 때문에 목표가 더 명확 해졌습니다." 코드를 배포해도 괜찮다고 생각 되더라도 나중에 참고하십시오.

이것이 성공하려면 팀과 관리자를 옆에 두어야합니다. 이는 종종 그들에게 이점을 설명하는 것을 의미합니다. 다른 개발자에게는 이것이 배울 수있는 기회입니다. 관리자에게 이것은 적은 비용으로 팀을 숙련시킬 수있는 기회이므로 a) 더 많은 가치 또는 b) 더 빠른 c) 유지 보수 비용이 적은 (보통 큰 문제입니다!)

이것은 문화 변화이며, 스스로 힘을 낼 수는 없지만 올바른 방향으로 물건을 조금씩 움직일 수 있습니다!

잊지 마세요, 이것은 일종의 문화 변화가 조직에 큰 도움이 될 수 있습니다. 훌륭한 관리자는 팀 전체를 개선하기 위해 노력하고 있다는 점을 인정할 것입니다.


3

더 나은 방법에 대해 조언 해 주시겠습니까? 코드를 비판하는 무언가를 경험 한 적이 있고 실제로 상처를받은 적이 있습니까? 그 사건들에 대해 무엇을합니까?

이에 대한 답변은 새로운 세대 회사에서 찾을 수 있습니다. 나는 구글이나 페이스 북과 같은 회사에 다녀 왔고, 만약 당신이 종교적으로 애자일 / 스크럼 프로세스를 따른다면, 더 나은 코드를 작성하고 모든 스프린트마다 그것을 향상시킬 수 있다는 것을 안다.

How to be better? 

답은 지속적인 리팩토링입니다. Visual Studio와 같은 최신 개발 도구에는이 프로세스에서 도움이되는 많은 도구가 있습니다. Scrum 소프트웨어 개발 프로세스를 따르는 경우 예를 들어 스프린트 사이클 1에서 잘못된 코드를 작성했으며 누군가 검토 중에 지적한 경우 스프린트 2에서 스프린트 2에서 코드를 리팩토링 할 수 있습니다.

이러한 문제는 좋은 프로세스가 없기 때문에 처음에 발생합니다. 따라서 솔루션은 팀을위한 좋은 소프트웨어 개발 프로세스를 제시하고 지속적인 리팩토링을 연습하는 것입니다.


3

피드백에 대해 감사의 말을 전한 후 무엇이 나쁜지 그리고 어떻게 개선해야하는지 설명해달라고 요청합니다.

피드백을 제공하는 사람이 말이된다는 데 동의하면 나중에 변경을 고려하십시오. 그러나 누군가가 그렇다고해서 그것이 사실임을 의미하지는 않는다는 것을 기억하십시오.

"엉망"이라고 불리는 것에 대한 구체적인 예를들 수 있습니까?


감정은 때때로 어려울 수 있지만, 이것이 내가 어떻게 반응하기를 바라는 지 확실합니다.
Thomas Padron-McCarthy

3

먼저 코드가 엉망 이라고 말하는 사람 은 매우 모호하고 주관적입니다. 그것은 다른 사람들에게 다른 것들을 의미 할 수 있습니다. 이유는 다음과 같습니다. 고려해야 할 두 가지 다른 것이 있습니다.

구조

코드 구조는 언어, 산업 표준 및 회사 표준에 따라 결정됩니다. 분명히 다른 요인들도 있습니다.

보푸라기, 테스트 도구 및 유사한 제품이 식별하도록 설계된 실수 유형입니다. 그것들은 잘 정의되어 있으며 귀하 또는 귀하의 도구는 유효성 / 정확성에 대해 객관적인 결정을 내릴 수 있습니다.

스타일

코드의 표준화 된 구조 / 규칙에도 불구하고 모든 개발자는 문제 나 작업을 작성하고 접근하는 방식에 따라 특정 스타일을 갖습니다. 모든 팀 환경에서 코드 유지 관리를 수행하고 시간이 지남에 따라 스타일을 기반으로 코드를 작성한 사람에 대한 교육 된 추측을 할 수 있습니다. 당신은 또한 당신의 자신의 스타일을 개발하고 경험을 얻고 공예를 배우면서 변화 할 것입니다.

따라서 누군가 코드가 엉망 이라고 할 때마다 구조스타일에 대해 이야기하고 있는지 이해해야합니다 . 그것들은 매우 다른 두 가지입니다. 구조 는 객관적인 반면 스타일 은 절대적으로 주관적입니다.

즉, 다른 프로그래머의 건설적인 피드백은 매우 귀중 할 수 있습니다. 그것은 모두 당신에게 달려 있으며 비판을받는 방법에 달려 있습니다. 시간이 지남에 따라 누가 마음에 가져갈 것인지와 소금 한 알을 가지고 갈 것인지를 배우게됩니다.

경력을 쌓으면서 자신의 코드를 되돌아보고 다르게, 더 좋고, 깨끗하고, 더 빨리 할 수있는 일을 보게됩니다. 그것은 학습 과정의 일부이며 자신의 과거 실수를 보는 것은 공예를 연마하고 향상시키고 있다는 사실을 나타내는 것입니다.

약간의 비판이 당신의 영혼을 약화시키지 마십시오. 당신이 할 수있는 것을 가지고 의미 있고 가치가 있다면 그것을 지식 저장소에 추가하십시오.


3

자신의 코드가 엉망인 경우 (특히 프로그래머가 경험이 많고 코드 수명이 오래됨에 따라 매우 일반적인 느낌)를 인식하는 것이 중요하지만 다른 사람이 말할 때 듣는 것이 중요합니다.

현재 프로그래밍 지식의 제약 조건에서 생성되었으므로 자신의 코드에서 인식 할 수있는 문제는 너무 많습니다.

코드 검토는 코드 를 작업하는 동안 가지고 있지 않은 새로운 지식에 노출 될 가능성이 있기 때문에 필수 학습 기회입니다 (그렇지 않으면 코드를 사용하면 혼란이 없습니다).

부정적인 피드백을 처리하는 데는 두 가지 부분이 있다고 생각합니다.

1. 제기 된 이슈의 성격과 그로부터 배워야 할 사항 결정

코드를 검토하거나 검토 할 때 대략 같은 버킷에서 코드 문제에 대한 정보를 정렬합니다.

  • 엄격한 기술 요구 사항을 위반 함
    • 명백한 잘못
    • 다른 상황에서는 실패합니다 (환경 / 구성 변경)
    • 더 이상 사용되지 않는 기능을 사용하며 가까운 미래에 침입 할 것입니다
  • 업계 모범 사례를 위반하여 다음과 같은 사항이 부족함
    • 특정 문제에 대한 검증 된 접근법 사용
    • 공연
    • 이전 버전과의 호환성
    • 유지 보수 용이
    • 코딩 스타일
    • 문서
  • 직장 내 모범 사례 위반
    • 업종과 동일하지만 회사 / 동료에게 더 구체적이며 업종과 다를 수 있음
  • 개인 전문 지식과 일치하지 않는
    • 검토하는 사람의 의견에 따라 어떤 방식 으로든 개선 될 수 있습니다.

이는 매우 객관적인 것 ( "프로덕션 서버에 배포 할 때 깨짐")에서 매우 주관적인 것 ( "변수 이름 지정 방법이 마음에 들지 않음")에 이르기까지 다양합니다.

2. 검토 결과로 코드가 변경 될 경우 (있는 경우) 결정

정보가 처리 된 후 실행 가능한지 여부와 코드를 변경해야하는지 여부가 결정됩니다. 이것은 반드시 귀하의 결정은 아니며, 귀하의 의견은 관련 당사자 및 귀하의 상황의 세부 사항 (노인 등)에 따라 중요하거나 중요하지 않을 수 있습니다. 그러나 가능한 결과는 대략 다음과 같습니다.

  • 전체 문제 해결
    • 고장 수리
    • 필요한 코딩 스타일로 포맷
    • 등등
  • 문제가 전혀 또는 부분적으로 해결되어야한다면 타협해야합니다.
    • 자원 없음 (예 : 시간 또는 예산)
    • 불필요 (미미한 개선, 안정성 저하 등 달성)
  • 제기 된 문제가 잘못되었음을 이해
    • 피드백 (특히 주관적인 의견 카테고리에서)은 매우 해로울 수 있으며 맹목적으로 행동해서는 안됩니다

당신은 부정적인 피드백을받는 것이 고통스럽고 앞으로 매번 고통 스러울 수 있다는 것을 배웠습니다. 그러나 중요한 학습 기회가 무엇인지, 프로세스가 전문성과 직장을 개선하여 더 나은 코드 기반을 달성하는 데 어떻게 도움이되는지 배웠습니다.


1

기분이 나쁘지 않습니다. 결국 당신은 실수로부터 배울 것입니다. 문제가 해결되면 다른 사람과 대화 할 수 있으므로 개선하고 싶다고 느끼게됩니다. 더 많이 듣고 덜 주장하십시오.

나는이 상황을 겪었고 이해할 수있다.


0

TL; DR

누군가 코드가 엉망이라고 말하면 어떻게 반응하겠습니까?


"직접 이해하지 못했습니다 (모든 답변-사과합니다. 나중에 시간을 찾아서 필요한 경우 수정 / 수정할 것입니다)"답변 / 팁 :

  • 좋은 오래된 동료 검토. 집단 정신, 전문 지식 수준 및 / 또는 공격 수준이 다른 여러 승무원에게 코드를 검토하도록 요청하십시오.
  • "다른"피어 그룹이 의미하는 바를 조금 더 설명하기 위해 : StackExchange 디아스포라는 아마도 Reddit과 비교할 때 상대적으로 어려움이 있기 때문에 아마도 가장 성 가시고 전문적이며 존경받는 그룹 일 것입니다. Reddit은 인기있는 하위 reddits에서 매우 공격적인 경향이 있지만 프로그래밍 하위 reddits는 매우 친숙합니다 (내가 경험 한 것).

공격적인 갱스터 유형의 클리닉 정신의 좋은 예는 XDK 포럼 군중이며, 안드로이드 포럼 / IRC 채널 대중을 위해 CyanogenMod에게 전달하는 최악의 최악의 트로피입니다.

그것은 내가 의도 한 것보다 조금 더 길었다. 나의 요점은 다양한 평가를 받았지만 그들의 거래를 아는 사람들로부터 정직한 비판을받는 데 집중하고 건설적인 비판이 무엇인지 아는 것에 집중해야했습니다 . 아, 그리고 당신을 실망시키지 않고 어떤 형태의 비판도 취할 수 있습니다. 경험 법칙 : 의견과 상호 작용할 수있는 것에 관한 유사한 논평을 듣기 시작하면 좀 더 철저한 조사를 수행하십시오.

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