상사에게 정중하게 자신의 코드에 의견을 말하도록 어떻게 요청할 수 있습니까?

나는 상사에 의해 가르치고 있습니다 (방금 학교를 마치고 약간의 프로그래밍 경험을 가진 사람을 원했기 때문에 회사가 전문화하는 것을 훈련하도록 선택했습니다). ASP.NET MVC 응용 프로그램, 일부 HTML 및 CSS 작업을 시작했습니다 . 나는 그가 나에게주는 웹 디자인 물건으로 괜찮습니다 (명백하지 않고 이해하는 것은 매우 간단합니다).

그러나 예를 들어, 그는 ASP.NET MVC와 관련된 작업을 제공합니다. 그러나 그는 그가 방금 준 코드에 아무것도 설명하지 않습니다. ( Visual Studio 2013 에서는 소스 제어를 사용합니다 ) 따라서 수행해야 할 작업에 대한 배경 지식없이 말 그대로 수백 줄의 코드입니다. 내가 본 종류의 코드는 이전에 본 적이없는 코드이므로 시도하고 알아내는 것이 실제로 어렵습니다.

나는 그에게 더 많은 질문을하려고 노력하지만, 그는 항상 일하고 있습니다 ( 그는 자신의 사업입니다).

그래서 내가 물건을 잡을 때까지 내 도움이 될만한 것, 어떻게 상사에게 자신의 코드에 주석을달라고 정중하게 요청할 수 있습니까?

당신은 '깊은 쪽'에 있으며, 제 생각에는 이것이 배우는 가장 좋은 방법입니다. 당신이 단서가없는 것을보고 있기 때문이 아니라, 그것은 당신이 더 많은 자원을 가지고 새로운 시스템에서 어떤 구성 요소가 어떤 역할을하는지 알아 내야하기 때문입니다.

상사가 호기심 많은 사람을 처리하기에는 너무 바빠서 도움이되지 않습니다 (그리고 당신은 호기심을 가질 권리가 완전히 있습니다. 당신은 배우고 싶어합니다. 좋습니다). 그러나 안타깝게도, 선배에게 자신의 스타일을 바꾸고 학습을위한 접근 방식을 요구하는 것은 특히 바쁘다고 말하는 사람을 상대하고 있기 때문에 잘 진행되지 않을 수 있습니다.

익숙하지 않은 수천 줄의 코드 앞에 앉는 것이 일반적입니다. 주석과 함께 항상 흑백으로 설명 할 수는 없습니다. 그러나 처음 배우는 동안 배우기 위해, 반드시 그에게 의견을 요청해야한다고 생각되면 이유를 설명하십시오. 자주 바쁘기 때문에 질문으로 귀찮게하고 싶지 않기 때문이라고 설명하십시오. 이것은 당신이 그에게 무언가를하라고 말하는 것처럼 훨씬 덜 나올뿐만 아니라, 그가 시간을내어 질문하는 것을 선호하는 방법에 대한 토론의 바닥을 열어줍니다.

첫째, 수천 줄의 생소한 코드를 크롤링하고 잃어버린 느낌은 모든 소프트웨어 프로젝트가 처음부터 모든 곳에서 이루어지는 방식입니다.

당신과 숙련 된 프로그래머의 가장 큰 차이점은 당신이 익숙하지 않다는 것입니다.

명심해야 할 몇 가지 사항 :

1. 충분한 노력으로 모든 코드를 이해할 수 있습니다. 몇 분 안에 무언가를 알아낼 수 없다면 많은 사람들이 좌절감을 느낍니다. 그것보다 더 인내심을 가지십시오.

2. 좋은 상사는 방해와 질문에 가능한 한 열려 있습니다. 훌륭한 직원은 방해와 질문을 최소화하기 위해 가능한 한 열심히 노력합니다. 그것을 의식하십시오.

3. 중단은 질문보다 비용이 많이 듭니다. 토론을 통합하고 혼란스러운 대화를 끝내지 않으면 서 시간과 상사의 시간을 더 잘 활용할 수 있습니다.

4. 당신의 상사는 당신보다 더 좋은 프로그래머입니다. (아마도) 그것은 당신이 어떤 분야에서 강해질 수는 없지만 전반적인 전문 지식이 더 크다는 것은 아닙니다. 당신이 많은 경험을 할 때까지, 당신이 할 수있는 한 그의 전문 지식으로부터 배우고 있는지 확인하십시오.

5. 더 많은 의견이 코드에 큰 도움이 될 것이라고 확신한다면 상사에게 문의하십시오. "어딘가에서 무슨 일이 일어나고 있는지 이해하기가 어렵습니다. 내가 알아낼 때 의견을 추가해도 될까요?" 아마 그는 의견을 싫어합니다. 어쩌면 그는 그것을 좋아할 것입니다. 아마 그는 무관심 할 것입니다.

그러나 결국 몇 달이 지난 지금이 ​​질문을 기억하고 "어, 내가 무슨 문제가 있었는지 궁금 하신가요? 이건 나쁘지 않습니다.

상사가 귀하의 모든 질문에 답변 할 시간이 없다면, 왜 그가 레거시 코드를 주석 할 시간이 있다고 생각하십니까? 또한, 그의 의견이 당신이 지금 이해하지 못하는 비트와 조각을 실제로 묘사한다고 생각하는 이유는 무엇입니까? 내 경험에 따르면, 상사에게 물어 보는 것만으로 상사 프로그래밍 스타일을 바꾸려고하면 정중하거나 작동하지 않을 것입니다.

이러한 상황에서 할 수있는 최선의 방법 : 작업 을 직접 수행하기 위해 이해해야하는 코드 부분에 주석을 답니다. -일단 당신이 그 부분들을 이해했다면, 그리고 당신의 상사로부터 약속을 얻은 후에 이것은 괜찮을 것입니다. 당신이나 당신의 상사가 당신이 의견을 추가하여 무언가를 깨뜨릴 수 있다고 두려워한다면, 별도의 지점에 의견을 추가하고 상사가 그들이 트렁크에 병합되기 전에 당신의 의견을 검토하는 데 시간이 걸리는지 물어보십시오. 상사는 제한된 시간 예산 만 가지고 있으므로, 적당한 시간을 투자하여 특정 부분이 먼저 무엇을하는지 알아 내십시오. 당신이 정말로 붙어 있다면, 질문을 목록에 적어두고 예를 들어 30 분 동안 그를 방해하는 대신 하루에 한 번 상사에게 물어보십시오. 내 경험에 비추어 볼 때,이 방법은 사람들이 당신을 기꺼이 도와 주기만하면 바쁘지만 대부분의 사람들과 함께 작동합니다.

이렇게하면 필요한 의견을 얻을 수 있으며 상사는 추가 정보가 필요한 위치와 상황이 올바른지 확인할 수 있습니다. 그리고 명백하지 않은 것들에 대해서만 댓글을 달도록 제한하는 한, 여러분의 의견은 코드 기반의 전반적인 품질을 향상시킬 가능성이 높으며, 이는 귀하뿐만 아니라 다른 사람에게도 이익을 가져다 줄 수 있습니다. 상사를 포함한 코드를 처리해야합니다.

먼저,이 코드를 메뚜기처럼 올바르게 주석 처리하는 예제가되게하십시오!

그런 다음 항상이 작업을 수행해야합니다. 내 로컬 사본을 체크 아웃했으며이를 통해 직접 의견을 작성했습니다. (내가 다시 확인하려고 할 경우 모두 다시 제거 할 수 있습니다. 또는 아무도 신경 쓰지 않으면 그대로 두십시오.) 그런 다음 더 이상 볼 수 없으면 누군가에게 물어볼 수 있습니다. 이것 (내가 언급 한 것), 맞습니까? 그래서 당신은 실제 주석을 다했을지 모르지만 그것이 끝났습니다.

이것은 단순한 개인적인 요청 이상입니다. 습관 / 문화를 바꾸려고하는데 쉽지 않습니다. 복도 대화 나 이메일로 달성 할 수있는 것은 아닙니다. 그것은 당신의 일부 노력을 기울일 것입니다.

세상에서보고 싶은 변화가 되십시오.

이 인용문은 Mahatma Gandhi에 허위로 귀속 될 수 있지만 적용 가능한 조언입니다. 코드베이스를 엉망으로 만들려고 할 때, 당신이보고 싶은 주석을 최선을 다해 작성하고 상사에 의해 검토 된 후 커밋하십시오. 장점 :

• 잔소리하는 대신 능동적으로 행동하고 있습니다.
• 좋은 모범을 보이고 있습니다. 가장 좋은 경우, 상사 / 팀이 혜택을보고 그에 따라 행동합니다.
• 의견 중 일부는 아마 말할 것이다 /* Mystery parameter 3 */나 /* 2015-02-09 AidanQuinn: Is this code ever called? */- 그 코드를 제대로 중 하나를 문서에 동료 기회 또는 잠재적 인 버그를 수정.
• 사전 커밋 검토 중에 작성한 주석이 정확하지 않은 것으로 밝혀지면 동료는 이제 코드가 명확하지 않다는 것을 알게됩니다.

이렇게하면 다시 쓰거나 리팩토링을 삼가야하며, 의견을 소개하는 것은 거의 위험이 없어야합니다. 아무 것도 다시 쓰지 않으면 해당 변경 사항을 별도의 커밋으로 유지하십시오.

(이 프로젝트를 시작하기 전에 의견에 대한 기대치가 합리적이어야합니다. 잘 작성된 코드에 대한 아이디어가 표준을 벗어난 경우 ( 예 1 , 예 2 ), 당신은 단지 바보 일 것입니다 당신 자신.)

추가 의견을 묻지 않지만 다음은 몇 가지 아이디어입니다.

1. 상사와 함께 앉아 일정을 짜서 높은 수준에서 코드를 통과하게하십시오. 시작해야합니다. 나는 당신이 속도에 도달 할 수 있도록 몇 시간 반 정도 아마 반 시간을 기대합니다. 여기에는 전반적인 디자인, 사용 된 패턴 등이 포함되어야합니다.
2. 테스트 프로젝트를 만들고 코드에 대해 단위 테스트를 작성하면 코드에 영향을주지 않고 이해하는 데 도움이됩니다. 당신은 또한 몇 가지 버그를 찾을 수 있습니다!
3. 특정 영역을 이해하기 위해 필요에 따라 코드를 디버깅하십시오.
4. 백 로그에서 개선 또는 버그를 제거하고 작업하십시오.

주석은 괜찮지 만 코드를 똑바로 작성하면 며칠 후에 이해할 수 있어야합니다.

또한 모든 것을 이해할 것으로 기대하지 말고 먼저 핵심 영역에 초점을 맞춘 다음 필요에 따라 코드 기반 지식을 확장하는 것이 좋습니다.

나는 대략 1 년 전에 당신과 매우 비슷한 상황에있었습니다. 나는 약간의 프로그래밍 경험을 가지고 일하기 시작했습니다 (처음에는 OO와 다른 언어를 약간 알고 있었지만). 그는 항상 도움이되었지만, 내가 가진 모든 질문을하고 싶지 않은 것 같습니다.

다른 사람들은 이미 여기에 매우 유용한 것들을 제안했습니다 (예를 들어 단위 테스트 작성, 그러나 내 자신의 경험에서 볼 때, 그것은 처음부터 나에게 너무 '너무 멀었습니다.'또는 코드의 일부에 주석을 달았습니다. 첫 번째 요점 / 질문에 따라 어려움을 겪을 수 있습니다. 다음 사항은 내가 한 일과 나를 도운 것을 요약하지만 문제가 정확히 어디에 있는지에 달려 있습니다.

또한 C #에서는 주석이 필요하지 않다고 말한 @AK_에 동의해야합니다. 100 % 정확하지 않을 수도 있지만 (반사가 많은 코드와 같이 주석이 확실히 도움이되는 영역이 있다고 생각합니다) 그러나 본질적으로 그렇습니다. 잘 이름이 지정된 메소드와 변수를 사용하여 실제로 '깨끗한 코드'를 작성하고 많은 작은 '비트'코드가 있으면 거의 완전히 불필요합니다. 지금까지 코드를 읽을 때 주석이 필요하다고 느꼈을 때마다 코드의 내용을 이해 한 후에는 코드가 작성된 방식에 매우 만족하지 못했고 처음부터 좋은 리팩토링을 통해 훨씬 명확해질 수 있다고 생각했습니다. 편집 : 나는 문서가 항상 중요하다고 생각하기 때문에 문서가 아닌 C # 주석 에 대해 이야기하고 있습니다 (별도의 문서 또는 XML 주석).

• 문제가 정확히 무엇인지, 그리고 분류 할 수 있는지 확인하십시오. 즉, 언어 자체에 여전히 문제가 있거나 특정 구문 (예 : 람다 식 및 LINQ 또는 리플렉션)을 이해하지 못합니까? 코드 줄을 이해하지 못하면 전체 메서드 / 블록의 기능을 이해하지 못하므로 직접 주석 처리하기가 어렵습니다. 오히려 좋은 책을 얻으십시오 ( 'C # in Nutshell'은 나에게 적합하지만 'C # in Depth'도 훌륭하다고 들었습니다). 이러한 문제를 미리 분류하면 '더 큰 격차'를 한 번에 채우거나 더 이상 질문이 많지 않기 때문에 상사에게 물어볼 수 있기 때문에 더 쉽게 만들 수 있습니다. 거대한 '부스트'를 얻을 수 있습니다

• 위와 마찬가지로 나는 '깨끗한 코딩'과 모범 사례 (언어에 국한되지 않음)에 익숙해 지려고 노력했다. 이것의 효과는 즉각적이지 않을 수도 있지만, 기존의 것들을 확장해야하거나 누군가가 왜 모든 것이 포함되어있는 것 대신 많은 방법을 만들 었는지 궁금 할 때 조만간 지불 할 것입니다. ;-)

• 일반적인 디자인 패턴을 파악하십시오. 그것들은 읽고있는 코드에 여기 저기에 나타날 수 있으며, 그것을 인식하면 즉시 당신에게 a-ha 순간을 줄 것입니다. 당신이 보는 코드가 무엇인지 이해하더라도, 왜 이런 식으로 수행되는지 궁금해 할 수 있으며, 스스로 혼자서 알아내는 것이 쉽지 않은 경우가 많습니다.

당신의 '기술'에 대한 가정을 할 때 위의 텍스트를 사용하지 마십시오. 종종 실수로 내 경험에 대한 이야기와 '당신에게 이야기하는 것'사이를 전환합니다. 그것은 대부분으로 의미가있어 내가 발견 무엇을 하고, 무엇을 내가했다 . 다른 사람들이 말했듯이, 이것은 매우 좋은 경험이 될 수 있으며 자신의 코드가 아니며 미리 알지 못하는 코드를 읽는 것이 표준입니다. 그러나 실제로 무슨 일이 일어나고 있는지 파악하고 자신이 특정 '기술'에서 나아지고 있음을 인식하는 것은 정말 만족 스러울 수 있습니다. 이것을 짧은 시간에 많은 것을 배울 수있는 기회 , 행운을 빌어 라! :)

당신은 아마 그의 스타일을 바꾸지 않을 것입니다.

당신이 할 수있는 일은 많은 질문을하고 답을 적어 두는 것입니다.

나는 마지막 직장에서 큰 코드 기반을 상속 받았으며 문서와 의견이 거의 없었습니다. 그래서 나는 같은 문제에 대해 30 분 동안 시도했지만 여전히 그것을 알아낼 수 없다면 그것을 쓰거나 사용 방법을 알고있는 사람에게 갈 것입니다. 그런 다음 그가 말한 모든 것을 문서화했습니다. 대부분은 문서에, 일부는 코드에 주석으로 들어갔습니다. 1 년 후 나는 문서의 상당 부분을 실제로 작성했으며 코드베이스에 대해 많이 알고있었습니다.

행운을 빕니다!

나는 같은 문제를 겪고 있었다. Phyzist의 학생이며 프로그래밍 경험이 풍부합니다. 나는 많은 언어로 프로그래밍하고 있었지만 프리미엄 응용 프로그램에는 아무것도 없습니다.

나는 웹 개발자를 위해 일을 신청했고 그들은 즉시 웹 프로그래밍의 백엔드에 나를 넣었다. 보스가 노드 REST 응용 프로그램의 기본 API를 보여 주었을 때 나는 버릴 것이라고 생각했습니다. 콜백과 너무 이상한 구문을 가진 함수를 본 적이 없습니다. 그리고 코드에 아무것도 없으면 내 상사에게 문제가 있는지 물어보십시오. 그는 슬퍼합니다. 그는 그것을 알아낼 데 1 개월이 걸린다는 것을 슬프고 그동안 다른 프론티어와 함께 테스트하기 위해 CMS를 만들 것입니다.

글쎄, 나는 당시에 한 줄의 코드를 사용했고 내가 알지 못하는 모든 것을 구글에 보냈다. 그래서 1 주가 지났고 프론트 엔더와 협력 할 수있을만큼 코드에 익숙했습니다. beginig의 코드는 엉망 이었지만 그 후 3 개월 만에 나를 찾아 냈습니다! 소프트웨어 아키텍트보다 더 나은 코딩을하고 있습니다!

나는 당신이 learninig를 멈추지 않을 것을 제안합니다! 내 모토-> 계속 배우고 침착하게 :) 보스에 의존하지 말고 직접 물어보십시오. 그러나 가장 어려운 문제 만. 당신이 당신의 resarch에 의해 그것을 알아 낸 후에 당신은 행복 할 것이기 때문에. 그리고 잘못된 것을 배우지 않을 때 좋은 프로그래머가되는 방법을 배우십시오.

보스로부터 배우면 자신의 표준을 설정하고 IDE, Linux wmii에 대한 블라인드 타이핑, VIM 또는 VIM 플러그인을 배우는 것보다 결코 나아지지 않을 것입니다. 따라서 언젠가 보스를 넘어서서 그보다 나을 것입니다!

SF-PD (safety-related stuff)를 주로 다루는 20 년의 소프트웨어 엔지니어로서, 나는 당신의 상사가 당신의 모범이되고 싶은 사람이 아닐 수도 있다고 말하고 싶습니다. 의견이 부족한 것은 일을 올바르게 수행하는 방법을 배우지 못한 자습 아마추어 코더 또는 경험이없는 엔지니어의 표시입니다. 또는 단순히 시간이없는 엔지니어 일 수도 있습니다. 마감일과 편의는 코드에 끔찍한 일을 할 수 있습니다! ;) 그것은 모든 유능한 소프트웨어 엔지니어에게는 확실히 안티 패턴입니다.

당신의 상사는 아주 좋은 코더 일지 모르지만, 그는 훌륭한 소프트웨어 엔지니어가 아닌 것 같습니다. 엔지니어는 집단적 그룹 경험을 사용하여 다른 사람들이 이미 잡은 함정을 피합니다. 효과적인 주석은 응력 분석이 기계 공학에 대한 집단 그룹 경험의 일부와 같은 방식으로 소프트웨어에 대한 집단 그룹 경험의 일부입니다. 효과적인 댓글 달기로 계산되는 것은 더 유동적이며 경험을 통해 얻는 것입니다.

가장 기본적인 것은 주석은 한 줄의 코드가하는 말을하지 않아야한다는 것입니다. 함수가하는 일에 대한 언급이 불필요한 경우도 있습니다 (특히 C #에서). 과도한 주석 처리는 드 로스에서 중요한 것을 찾을 수 없기 때문에 비효율적이며 경험 부족에 대한 포인터 일 수 있습니다. 초보자로서, 당신은 여전히 ​​코드의 "무엇"을 알아 내기 위해 노력하고있을 수 있으며, 그 때문에 그가 한 일을 읽고 이해하면됩니다.

그러나 주석의 중요한 점은 왜 코드 라인이나 함수가 기능을 수행하는지 명확하지 않을 수 있다고 말합니다 . 모듈 Y 전에 모듈 X를 설정해야합니까? 파일이 이미 열려 있는지 확인하기 위해 리턴 코드를 점검해야합니까, 아니면 다른 곳에서 점검되었으므로 의식적으로 리턴 코드를 무시하고 있습니까? 코드의 "왜"는 경험에 관계없이 모든 사람과 관련이 있으며, 특정 방식으로 무언가를하는 좋은 이유를 잊어 버린 6 개월 후에도 그와 관련이있을 것입니다. 주석은 다른 사람들을위한 것이 아니라 미래에도 도움을주기위한 것입니다.

상사를 성가 시게하지 않으려면 현명한 질문을하십시오. "왜"에 대한 질문에 집중하고, "무엇"을 스스로 해결하십시오 (진실이 모호하지 않은 경우 제외). R-ing TFM에서 찾을 수없는 것이 아니라면 좋은 상사는 질문을받지 않을 것입니다. 또한 훌륭한 엔지니어는 적은 비용으로 다른 엔지니어의 삶을 훨씬 쉽게 만들 수있는 일을하도록 신경 쓰지 않습니다. (그에게 전체 코드베이스에 대한 의견을 백필하도록 요청하지 마십시오!;)

비슷한 상황에 있었는데

1. 당신의 상사는 어떤 이유로 (당신이 단서가없는 코드를 통해) 더러운 방법을 배우기를 원할 수도 있습니다. 이것은 다른 답변에서 언급했듯이 대학에서 1 년보다 한 달에 직장에서 더 많은 것을 배우는 방법입니다.

2. 이것은 다른 답변에서 언급 된 "표준"입니다. 모든 코드 줄을 즉시 이해하려고 시도하는 것보다 시작 위치, 접근 방법 및 집중해야 할 사항에 대해 더 걱정해야합니다. 상사에게 올바른 도구와 코드를 디버깅 / 스텝하는 방법에 대해 문의하십시오. 이런 종류의 질문은 당신에게 몇 가지 포인트를 사줄 것입니다.

3. 정기적으로 상사에게 지속적으로 접근하여 피드백을 받으십시오. 상사가 같은 상황에서 많은 수의 사람들을 보았을 때 어떻게 백분위 수로 서 있는지 아이디어를 얻을 수 있습니다.

4. 이것을 기회로 삼고 코드를 이해하는 것이 좋을수록 원래 상사에게 물어볼 의견을 계속 추가하십시오.

실제로 코드에 주석을 달도록 요청하려면 (권장하지 않음) 실제로 일부 주석을 사용할 수있는 코드를 찾은 것이 좋습니다 (대부분 자체 설명이 필요합니다). "여기서이 코드를보고 있는데 [문제가 있음]을 알아 내려고하는데 설명에 도움이되는 의견을 찾을 수 없었습니다." 기본적으로 이해를 향한 노력을 기울 였다는 사실을 보여 주려고 노력하고 왜 의견이 있으면 도움을받을 수 있는지 설명하십시오.

잘 작성된 코드의 90 %는 주석이 필요하지 않습니다. 최적화되어 있고 다소 긴장된 코드 부분 만 문서화하려고합니다. 필자는 기본적으로 수정 한 모든 코드 조각을 문서화해야하는 회사에서 한 번 일하면서 주석은 인식을 넘어서 제거되거나 수정 된 코드를 참조하기 때문에 코드 가독성에 적극적으로 해가되었습니다. 나쁜 의견에주의를 기울였다. 나는 함수 디버깅에 일주일을 보냈고 결국 그런 플래그를 "false"로 설정하는 것에 대해 읽은 의견은 실제로 플래그를 "true"로 설정하고 모든 것이 효과가 있음을 발견했다. 예상대로.

코드에 주석을 작성하여 왜 무언가가 쓰여 졌는지 이해하고 싶다면 (새로운 것을 고려하면) 비즈니스 요구를 아직 이해하지 못했을 것입니다. 모든 구문을 알고 코드를 읽을 수 있다고 확신하지만 일부 코드의 목적을 모르는 경우 약간의 손실을 느낄 것입니다.

마음에 떠오르는 한 가지는 페어 프로그래밍입니다. 당신은 당신의 상사가 당신의 진보에 깊은 인상을 받았다고 말합니다. 이것은 장기적으로 두 사람을 도울 것입니다. 당신의 상사는 자신이 당연한 것으로 설명해야 할 것을 알게 될 것이며, 당신은 사업에 대해 더 많이 배울 것입니다.

다른 사람들이 언급했듯이, 이것은 매우 일반적이지만, 그것이 당신이 그것을 빨아 내고 쟁기질해야한다는 것을 의미하지는 않습니다. 생각하는 것만 큼 깊이있는 코드를 이해할 필요가 없으며 "깊은 끝"을 훨씬 더 얕게 만드는 구체적인 전략이 있습니다.

• 작업과 관련된 코드에서 무언가 를 찾으십시오 . 일반적으로 검색하기 가장 쉬운 것은 GUI의 버튼 레이블과 같이 사용자가 볼 수있는 것입니다. 찾은 곳에 적어 두십시오. 이것이 당신의 기준점이 될 것입니다.
• 이제 한 걸음 떨어진 곳에서 코드를 검색하고 적어 두십시오. 누가 버튼을 만드나요? 버튼을 클릭하면 어떤 코드가 호출됩니까?
• 소스 제어는 종종 한 걸음 떨어진 코드를 찾는 데 유용합니다. 보고있는 코드가 언제 추가 또는 변경되었는지 확인하고 동시에 체크인 된 코드와 그 이유를 확인하십시오.
• 변경 사항을 충분히 이해할 수있을 때까지 반복하고 한 단계 더 깊이 들어가서 빠진 것이 없는지 확인하십시오.
• 어느 시점에서든 막히게되면 매우 구체적인 질문을해야합니다. 예를 들어 "이 버튼이 어디에서 인스턴스화되는지 알 수 없습니다."

여기에 내 $ 0.02가 있습니다. 나는 독점적 인 대답을 제안하지 않고 있으며, 여기에서 말한 많은 것이 매우 관련이 있습니다.

나는 상사가 자신의 코드 중 일부에 대해 언급하지 않는 것보다 쉽고 시간이 덜 걸리는 것을 발견하기 위해 약간의 사회 공학을 시도 할 것입니다.

이제 큰 위험을 감수하고 귀찮게한다면 매우 쉬울 수 있습니다. 그러나 우리는 그렇게하고 싶지 않습니다. (주의 사항 : 당신은 요한에게 글을 쓰거나 의견을 말하지 않고 아무것도 할 수 없을 수 있습니다.

그렇다면 대안은 무엇입니까? 상황에 따라 몇 가지 아이디어.

옵션 1

1. 시간을내어 X를 수행하는 코드를 이해하십시오.
2. 이제 Y를 오해 하는 합리적인 방법을 생각 하십시오.
3. 당신이 현재 그것을 알아 내려고 있다고 보스에게 (전자 메일을 통해 또는 아침 식사 또는 기타 말로) 말하십시오.
4. 코드가 의미하는 바가 명확하지 않은 코멘트를 추가하지만, Y로 이해합니다. 이 댓글을 그에게 보이게하려고 노력하지만 너무 열심히 노력하지 마십시오!
5. Y라고 가정하고 상사가 자신의 행동 을 인지 하도록 하십시오 (따라서 잘못된 가정에 오랜 시간을 낭비하지 마십시오).
6. 상사는 당신을 바로 잡기 위해 주도권을 행사해야합니다. 이 시점에서 "이 코드에 잘못된 가정을하지 못하도록하기 위해 몇 개의 주석이 있었으면 좋겠다. 내가 직접 추가 한 주석을 수정하겠습니다. 일반적인 설명으로 나를 도울 수 있다고 생각하십니까?" 정확한 의도를 파악할만큼 경험이 부족하며 몇 문장만으로도 트릭을 수행 할 수 있습니다. " 또는 뭔가..

옵션 2

훈련 중입니다. 그와 함께 (추가?) 고정 주파수 주간 회의를 주선 해보십시오. 이 회의에서 몇 가지 코드를 살펴보십시오. 그러나 모든 줄을 설명하지 않아도되도록 준비해야합니다. 어떤 시점에서-희망 사항-그는 의견을 추가하면 회의를 건너 뛸 수 있음을 알게 될 것입니다.

옵션 3

다른 동료가 귀하와 동일한 코드를 이해하지 못하도록하십시오. 두 사람 모두 서로 다른 시간에 상사에게 다가 가서 같은 질문을합니다. 그것은 그가 무언가를하지 않았다는 것을 깨닫게하는 확실한 방법입니다. 그러나 모든 사람이 같은 프로젝트에 도움이되는 동료가있는 것은 아닙니다.

그래서 내가 물건을 잡을 때까지 내 도움이 될만한 것, 어떻게 상사에게 자신의 코드에 주석을달라고 정중하게 요청할 수 있습니까?

코드를 이해할 수 없다면 주석이 해결책이라고 생각하는 이유는 무엇입니까?

나는 그의 프로그래밍 스타일을 알지 못하지만 함수와 변수의 이름이 잘못되면 코드를 이해하는 것이 매우 어렵다는 것을 인정합니다. 그러나 이름과 기능 또는 프로그램 구성 (클래스, 메소드, 속성 등)이 코드를 이해할 수있게 만들면 코드가 실제로 사용자 자신과 대화하게됩니다.

그에게 프로그램 아키텍처를 요청하는 것이 좋으며 무언가를 요청하려면 더 의미있는 기능 이름을 요청하십시오. 그가하는 것이 더 편리합니다.

이것을 정중하게 요청할 수있는 방법이 있더라도, 상사가 자신의 코드에서 주석에 대해 어떻게 생각할 것인지에 대한 두 가지 가능성이 있습니다.

1. 그의 코드에있는 주석은 좋은 것이거나

2. 그의 코드에있는 주석은 좋은 것이 아닙니다.

당신의 상사는 자신의 코드에 주석이, 좋은 일을 가지고하지 않다고 생각하는 (그리고 즉이 매우 좋은 인자가있는 경우 코드가 문서 있어야하는데 , 그리고 어떤 문서는 그 어느 때보 다 정확하고 명확하게 무엇인가를 규정하지 않습니다 실제로 그것을 수행하는 코드 ), 아무 일도 일어나지 않을 것입니다.

우연히 상사가 자신의 코드에있는 주석이 좋은 것이라고 생각한다면, 코드를 연구하고, 코드의 작동 방식을 이해하고, 주석을 추가하도록 진행할 가능성이 상당히 높습니다 자신을 코딩 하십시오 . (이것에 대해서도 매우 좋은 주장이 있습니다. 즉 , 배워야합니다 . 그의 시간은 정의상 당신의 것보다 훨씬 더 가치가 있습니다 .)

따라서 이렇게 할 준비가되어 있지 않으면 아무 말도하지 않는 것이 좋습니다.