동료가 모양을 변경하기 위해 코드를 편집하는 경우 어떻게해야합니까?

동료가 코드를 편집하는 경우 어떻게해야합니까?

기능을 추가하거나 버그를 수정하지 않고 모양을 변경하기 만하면됩니다.

그들에 대해 이야기하십시오. "그들은 나를 귀찮게하려는 것이 아니거나 강박 장애가있는 형태이기 때문에 내 코드를 개선하기 위해 노력하고있다"는 태도로 대화에 참여하십시오.

당신이 틀릴 수 있기 때문입니다. 그것은 미묘한 버그 수정 일 수 있으며 당신은 그것을 발견하지 못했습니다.

또는 위반 한 사실에 대해 모르는 코딩 표준이있을 수 있으며이를 수정하는 중일 수 있습니다.

또는 그들이 당신을 귀찮게하려고하거나, 어떤 형태의 강박 장애가있을 수도 있습니다. 그런 경우에는 중지하도록 기꺼이 요청하십시오. 그래도 문제가 해결되지 않으면 상사와상의하십시오.

그러나 요청하지 않으면 절대 알 수 없습니다.

나는 내 코드가 나를 귀찮게하는 방법과 결혼하지 않았습니다. :) 나는 변화로부터 배우려고 노력한다. 동료가 변수 이름을 조정 했습니까? 보다 효율적인 루프를 작성 하시겠습니까? 더 읽기 쉬운 코드를 만드시겠습니까?

변경 사항이 이미 존재하는 부분을 어떻게 개선했는지 알 수없는 경우, 변경 내용을 작성한 동료에게 일반적으로 변경 내용의 동기가 무엇인지 묻습니다. 이점이 나에게 명백하지 않을 수도 있습니다. 그리고 내가 옳고 그들이 틀렸다면, 내가 왜 그렇게 썼는지 설명 할 수있을 것입니다.

다른 모든 방법이 실패하면 체크인을 되 돌리십시오. ;)

편집 : 그러나 외관상의 변화를 원한다면 버그가 발생하면 모든 베팅이 종료됩니다.

IMO 당신과 당신의 팀은 어쨌든 코딩 표준을 사용해야합니다. 이 경우 질문은 '원래 코드가 표준을 준수 했습니까?'가됩니다. '예'인 경우, 기능적으로 변경하지 않으면 동료가 코드를 건드리지 않아야합니다. '아니오'인 경우 동료가 코드를 정리할 권리가 있습니다. 프로젝트 리더로서 나는 항상 그것을하고 있음을 발견했습니다.

코딩 표준을 사용하지 않는다면 '좋은 코드'를 구성하는 것에 대한 모든 주장은 너무 주관적입니다. 따라서 코딩 표준을 사용해야하는 이유 :)

그 사람들 중 하나 (때로는 다른 사람들의 코드를 다시 포맷하는 사람들)로서 내가하는 주요 이유는 가독성입니다. 어떤 사람들은 들여 쓰기 나 믹싱 탭과 공백이 너무 엉성합니다.

내가 바꾸는 습관은 가로 줄을 스크롤하지 않고 전체를 읽을 수 있도록 긴 줄을 줄이는 것입니다. 복잡한 문장을 별도의 문장으로 나누거나 한 줄에 하나의 매개 변수가 모두 적합하지 않은 경우 한 줄에 하나의 매개 변수를 나열하도록 메서드 호출 / 선언을 다시 형식화합니다. 또한 영어 오류를 수정하거나 더 명확하게하기 위해 주석을 편집하겠습니다.

예, 혼자 남겨 둘 수는 있지만 코드를 읽는 데 필요한 정신적 노력을 줄이고 싶습니다.

그것에 대해 어떻게해야합니까? 먼저,이 사람이 귀하의 코드를 개선하고 있다고 생각하십시오. 또한 팀에서 코드의 형식을 지정하는 방법에 대한 합의가 이루어 지도록해야합니다. 사람마다 습관이 다르면 모두 속도가 느려집니다. 그들이 코드를 더 잘 만들지 않고 곡물에 반대하는 경우 코드에 대해 직면해야합니다. 그래도 문제가 해결되지 않으면 다른 사람들을 참여시켜야 할 수도 있습니다.

그들이 왜 그런지 물어보십시오. 올바른 설명은 좌절감을 감소시킬 수 있지만, 그것이 얼마나 귀찮게하는지 알려 주어야합니다. 누가 알 겠지, 아마도 그들은 그들이 당신에게 호의를 베풀 었다고 생각하고 그것이 당신을 화나게 할 때 멈추게 될 것입니다. 또는 의학적 상태로 고통받는 사람을 상대하고있을 수도 있습니다.

그는 허용됩니까? 변경 사항이 코드를 개선합니까? 그렇다면 자부심을 삼키십시오. 코드 품질이 떨어 졌다고 생각되면 동료와 함께 코드 품질을 변경하지 않아도 코드를 변경해야하는 이유를 물어보십시오. 정신이 나간 상태이거나 사람이 실수로 자신보다 나아 졌다고 느끼고 문제를 해결할 수없는 경우 상사에게 맡기십시오.

Visual Studio와 같은 IDE Format Document에는 사용자가 IDE에서 설정 한 규칙에 따라 코드를 형식화 하는 옵션 이 있습니다. 동료가 이것을 사용하고있을 수도 있습니다 (알지 못하거나 의도적으로 적용하여 자동으로). 아마도 그들의 IDE는 탭 대신 공백을 사용하거나 그 반대도 마찬가지이며, 알지 못하는 채 자동으로 적용됩니까? 그러나 당신은 그들을 찾기 위해 그들과 이야기해야합니다.

덧붙여서, 나는 어떤 종류의 형식 체계를 따르지 않는 경우 (즉, 모든 곳에서) 동료의 코드를 종종 형식화합니다. 그들이 눈치 채게하기를 바라는 미묘한 방법입니다. (단, 깔끔한 경우 다시 포맷하지는 않지만 원하는대로 다시 포맷하지는 않습니다).

팀의 코딩 표준에 맞도록 변경하는 경우 다음에 표준을 따라야합니다.

더 이상 팀의 코딩 표준을 따르지 않도록 변경 한 경우, 자신이 잘못한 것을 알려주고 다시 변경하도록하십시오.

... 귀하의 팀은 모든 사람이 사용하는 일련의 코드 형식 표준을 가지고 있습니까?

나는 때때로 지저분한 동료가 작성한 코드를 재정렬합니다 (또는 주석에서 오타를 수정합니다). 그들은 내가 코드 형식과 순서에 강박하다는 것을 알고 있으므로 너무 불평하지 않고 그렇게 할 수 있습니다. 때때로 그들은 또한 나에게 무료 음료수 또는 쿠키를 제공합니다.

물론 이것은 가끔 SVN의 "비난"기능을 깨뜨 렸기 때문에 수행되는 작업입니다.

이것은 일종의 코드 검토를 수행하는 매우 기본적인 방법이기도합니다 (저는 일반적으로 동료가 작업중인 모듈에서 커밋 한 코드를 대부분 읽습니다).

코드 규칙 입니다 대답. 직장에 있어야합니다. 그렇지 않은 경우 지금 시작하십시오 ( Google 스타일 가이드를 시작하는 것이 좋습니다 ). 규칙이 적힌 경우 (또는 적어도 일반적으로 알려진) 질문에 대한 대답은 사소한 것입니다.

그렇게하는 것이 불쾌하다고 생각합니다 ...? 예를 들어, 나는이 코드를 즉시 고칠 것이다.

int myFunction( ) {

    int i ;
  return  0;

}

되기 위해

int myFunction() {
    int i;
    return 0;
}

내 행동 때문에 벌을 받아야합니까? 실제로는 실제로 많은 SVN 로그에 '포맷'이 있습니다. ;-)

스타일 검사 도구 사용

StyleCop 또는 이와 유사한 것을 사용하여 시작 하고 코드 스타일 규칙을 시행하고 모든 개발자가이를 사용해야합니다. 모든 코드는 예외없이 동일하게 보입니다. 그리고 현명한 머리 와 함께 조직에 가장 적합한 규칙을 논의하십시오. 기본 규칙은 이미 .net 프레임 워크 코드 자체와 매우 유사합니다.

가장 쉬운 방법입니다. 나는 이전의 고용주 중 한 사람에서 다른 사람의 코드를 수정하는 것을 발견했습니다.이 다른 사람은 과도한 빈 줄과 들여 쓰기 규칙이없는 코드를 작성했기 때문입니다. 평범한 개발자는 실제로 코드를 읽을 수 없었습니다. StyleCop이 다시 존재한다면 많은 사람들이 정말 행복 할 것입니다.

이것은 인터넷에서 리팩토링 에 대해 이야기하고 누군가가 코드를 더 잘 만들기 위해 왜 설명 해야하는지 설명합니다.

왜?

리팩토링해야하는 두 가지 주요 이유가 있습니다.

1. 코드 / 디자인을 향상시키기 전에 코드 / 디자인을 향상시키는 방법 : 첫 번째 시도에서 좋은 코드를 만드는 것은 실제로 어렵습니다. 초기 디자인을 구현하려는 첫 번째 시도는 우리가 논리를 잘못 해석했거나 잊었 음을 보여줍니다.

2. 요구 사항의 변화에 ​​적응하기 위해. 소프트웨어 개발에서 변화가 일어납니다. 변화에 반응하는 것이 좋은 코드 기반을 갖는 것이 좋습니다. 두 가지 시나리오 모두 코드 경로 지정 또는 리팩터링의 두 가지 옵션이 있습니다. 코드를 패치하면 유지 관리 할 수없는 코드가 생성되고 기술 부채가 증가하므로 리팩토링하는 것이 좋습니다.

언제?

1. 빠를수록 쉬울수록 좋습니다.

2. 코드가 거의 완성 될 때까지 리팩토링을 기다리지 않고 최근 리팩토링 된 코드를 리팩토링하는 것이 빠르고 위험성이 적습니다.

뭐?

1. 모든 코드와 모든 디자인은 리팩토링 후보입니다.

2. 무언가를 리팩토링하지 않는 예외는 품질이 낮은 작동하는 코드 일 수 있지만 마감일이 가까워 지므로 계획을 위험에 빠뜨리기보다는 기술적 부채를 유지하는 것이 좋습니다.

두 사람 모두에게 좋을 것이며 앞으로 시간을 절약하려면 최선을 다해야합니다!

건배