기분을 상하게하지 않고 어떻게 코딩합니까?

내가 의미하는 바는, 몇 년 동안 작업 해왔고 매우 친숙한 개발자와 공유하는 코드 기반을 어떻게 개발할 것인가?

나는 누군가의 발끝을 밟고 싶지 않지만 코드를 공백으로 만드는 방법이나 SVN에 얼마나 자주 체크인하는지에 관계없이 내가하는 일에 대해 미묘한 불만을 얻지 못합니다. 따라서 이러한 사항을 쉽게 변경할 수 있지만 일반적으로 더 나은 팀 개발자가되고 싶습니다.

물어 보는 것 외에는 무엇을해야할지 모르겠지만, 아마도 여러분은 연습 할 수있는 몇 가지 생각을 가지고있을 것입니다.

최신 정보

말할 스타일 가이드는 없습니다. 사람들은 코드베이스를 공유하는 데 익숙하지 않습니다. 누구나 자신의 작은 코드 세계를 가지고 있습니다.

이것은 펄 샵이지만 모든 언어에 적용됩니다.

업데이트 2

나중에 CEO가 된 CTO는 완전한 거대 매니아였으며 이러한 불만의 주요 원인이었습니다. Mac이나 Emacs를 사용하든 2 개가 아닌 4 개의 탭 공간을 사용하든 특정 방식으로 옷을 입든 상관없이 그가 좋아하는 방식으로 정확하게 작업을 수행하지 않았다면 열등한 상태였습니다. 내가 옳은 일을하려고 끔찍한 상황 이었지만 나를위한 유일한 정답은 떠났다.

나는 이것이 직장에서 괴롭힘 의 사례라고 확신하며 , 그 결과 직장 환경에서 미묘한 괴롭힘과 부적절한 행동이 무엇인지 더 잘 알고 있습니다.

이와 같은 상황에 대한 해답을 찾는 개발자에게는 즉시 떠나십시오. 나쁜 팀 상황에서 팀워크를 할 수 없습니다.

청하다. 즉, 함께 일하는 사람들에게 물어보십시오. 기존 코드의 기존 스타일에 충실하도록 최선을 다하십시오. 특히 코딩 표준의 문서 목록이 있는지 물어보고 따르십시오. 없는 경우 코드에서 관찰 한 내용에 따라 첫 번째 초안을 작성한 다음 다른 팀원에게 비평을 요청하십시오. 승인 된 코딩 방법을 문서화하기 시작하면 회사 (및 새로운 개발자)가 서비스를 수행하게됩니다. 구식 타이머가 수용 할 수 있거나 받아 들일 수없는 것에 대해 서로 동의하지 않는 것으로 밝혀지면 유일한 위험은 중간에 빠질 수 있습니다.

또한 자신 이되는 것을 두려워하지 마십시오 . 당신은 새로운 사람 일지 모르지만 당신은 팀의 일원이며 당신의 의견은 유효합니다. 더 좋은 방법을 생각할 수 있다면 제안하십시오. 다른 팀원과 일을하는 기존 방식을 존중하십시오. 귀하의 의견을 소중히 여기지 않는다면 회사는 귀하를 고용하지 않았을 것입니다.

팀에서 친근 하고 특히 질문에 대답 할 사람을 찾을 수 있다면 많은 도움이 될 것 입니다. (좋은 팀이라면 모든 사람이되어야하지만 팀이 항상 그런 것은 아닙니다.) 상사는 당신을 시작할 수 있도록 누군가를 지명했을 수도 있습니다. 그 사람을 자원으로 사용하십시오. 귀하에게 발생하는 질문을 적어두고 도움이 필요한 사람에게 수시로 답변하도록 요청하십시오.

코드 "너무 자주"를 체크인하는 경우 주기적 커밋을 위해 자체 분기 를 만든 다음 코드가 준비되면 트렁크로 다시 병합 되지 않는 이유 는 무엇입니까? 다른 사람에게는 그렇게하는 데 아무런 해가 없으며 동료가 SVN의 혜택을 받고 있음을 알게되면 동료를 따라갈 수 있습니다.

공백과 관련하여 : 코드를 이미 수행하십시오. 흐름과 함께 가십시오.

SVN 체크인 관련 : 매우 명확하게 문서화하십시오. 이를 통해 사람들은 코드에서 무슨 일이 일어나고 있는지 이해할 수 있습니다. (사후 조사 : 빈번한 체크인에 대한 반대 의견은 무엇입니까?)

일반적으로 : 코딩 표준 문서 작성을 시작하십시오. 100 개의 규칙으로 채우려 고하지 마십시오. 규칙이 올라 오면 추가하면됩니다.

또한 : 동료 개발자에게 질문하십시오. 그것은 그들이 당신이 원하지 않는 것을하기 전에 무게를 opportunity 수있는 기회를줍니다. 또한 관계를 구축합니다. 또한 상점의 작동 방식에 대해 자세히 알아 봅니다.

코드 서식 스타일 (공백, 탭, 괄호 등)에 대해서는 코드의 일반적인 표준을 따라야합니다. 하나도 없다면, 그들이 불평 할 것이 많지 않다고 생각합니다. 그 자체로 중괄호를 넣든 말든 메소드 매개 변수 목록 주위에 공백을 넣는 것은 개인적인 취향입니다. 장기적으로는 일반적인 스타일을 나타내지 않아야합니다. 문제 . 중요한 것은 일관성입니다.

SVN에 코드를 검사 할 때, 내가 느끼는 것이 나 자신을 강압하지 않고 일을하는 올바른 방법이라고 복음화하려고합니다. 코드를 빌드하고 테스트를 통과하지 않으면 코드를 체크인하지 않으며 관련이없는 변경을 여러 번 수행하는 경우 작업을 여러 커밋으로 나눕니다. 잠시 동안 무언가가 깨질 경우 지점을 만들고 그곳에서 일을합니다. 커밋은 설명적인 주석을받습니다. 이것은 "금요일 5:00에 변경 내용을 확인하십시오"방법보다 내 경험에서 더 잘 작동하며 여기 및 다른 곳에서 읽은 대부분의 내용에 따라 일반적인 "모범 사례"인 것 같습니다.

먼저 코딩 규칙 문서를 읽으십시오 (없는 경우 코딩 규칙을 따르십시오).

그런 다음 그 내용과 그 말을 따르기 위해 의식적으로 노력하십시오. 그것들은 가혹하지만 코딩 표준이 중요하다고 생각할 수도 있습니다. 나중에 더 큰 변화를 겪을 때 문제로 발전하는 것보다 지금 무엇이 잘못되었는지 지적하는 것이 좋습니다.

나는 초보자가 발가락을 밟을 때 1-2 년 안에 같은 일을 할 것이라고 확신합니다. :)

회사 코드 표준을 요구하십시오. 세부 사항에 더주의를 기울이십시오. 다른 사람들이 매우 특정한 형태의 공백과 브레이스 패턴을 따르는 것을 본다면 그 패턴을 따르십시오. Sr.은 이것을 까다로운 것으로 주장 할 수 있지만, 프로젝트의 Jr. 또는 새 녀석은 리드하기 전에 따라갈 수 있음을 보여 주어야합니다.

또한 프로젝트의 모든 새로운 개발자는 실제로 필요한 "램프 업"시간이 있다는 것을 이해하십시오 . 따라서 걱정하지 마십시오.

당신이 할 수있는 최선의 방법은 그들이주는 조언을 따르는 것입니다. 원하는 것을 미리 알 수있는 방법이 없습니다. 당신이 심령하지 않는 한.

그러나 나는 사람들이 당신에게 조언을 할 때 그것을 문서화 할 것을 제안합니다. 위키가 있습니까? 그렇다면 사용하십시오. 그렇지 않은 경우 소스 코드로 체크인 한 텍스트 파일이 좋습니다. 잘 구성된 프로그래밍 안내서를 작성하십시오. 그것은 당신이 일을하는 방법을 기억하는 데 도움이되며 누군가가 당신이 이전에받은 조언과 모순되면 불일치에 대해 토론 할 수있는 기준을 제공합니다. 또한 다음 사람이 팀에 합류 할 때 진행중인 작업을 수행 할 필요가 없습니다.

나는 문서의 조언을 개인들에게 귀속시키지 말 것을 제안한다 (따라서 "코드 블록은 3 개의 공백으로 들여 쓰기되어야한다"는 말이 아니라 "코드 블록은 3 개의 공백으로 들여 쓰기되어야한다"). 그러나 그 정보를 눈에 거슬리지 않게 기록 할 수 있다면 (예 : 커밋 주석에서 "Bill의 조언에 따라 들여 쓰기에 대한 추가 규칙"을 작성하십시오), 즉시 두 가지 관점을 얻을 수 있기 때문에 모순을 해결하는 데 도움이 될 수 있습니다 무언가에. 내가 여기서 생각하고있는 것은 실제로, 당신이 모순되는 조언을받는다면, 어떤 것에 동의하지 않는 두 동료가 축구를하게되는 것을 피해야한다는 것입니다. 약간의 엄폐물 접근 방식이지만 신중할 수도 있습니다.

쉬운 방법은 스타일 가이드를 찾아서 따르는 것입니다. 대부분은 그들에게 너무 공격적인 것이 없으며 다른 사람들을 화나게하지 못하게합니다.