팀에서 다른 프로그래밍 스타일을 다루는 방법?


14

소규모 개발자 팀 (개발자 3 명)이 있으며 최근에 새로운 팀원이 생겼습니다. 그는 스마트 코더이지만 그의 코딩 스타일은 우리와 완전히 다릅니다. 기존 코드베이스에는 대부분 읽기 쉽고 깨끗하며 유지 관리가 가능한 코드가 포함되어 있지만 새로운 팀원은 많은 파일을 빠르게 변경하고 추악한 해킹 및 바로 가기를 소개하며 모든 곳에서 정의를 사용하고 잘못된 장소에 함수를 추가하는 등의 작업을 수행하고 있습니다.

내 질문은 다른 사람들이 이전에 그러한 상황을 경험했는지, 누군가가 그와 대화하는 방법에 대한 팁이 있는지 여부입니다.


2
동료 검토를 사용하여 추악한 해킹 및 바로 가기가 저장소에 도달하기 전에 포착하는 것을 고려 했습니까?

가능하면 편견이없는 우수한 자동 도구를 사용하십시오.
Job

오늘날 코딩 표준은 대부분 자동화 될 수 있습니다. 사람들이 파일을 체크인하기 전에 사용중인 도구를 통해 각 소스 파일을 실행하도록 요구하면 대부분의 코딩 표준 위반을 방지 할 수 있습니다. 도구가 포착하지 못하는 것은 OP의 새로운 사람 소리와 같은 실제로 추악한 관행을 가진 해커입니다. 코드 검토와 같은 것처럼 보이고 원하지 않는 스타일을 거부하는 것은 해커를 고치는 유일한 방법입니다.
Dunk

답변:


22

1 년 이내에 2 명의 개발자에서 10 명으로 성장한 팀과 함께 일합니다. 저는 3 위였으며 코딩 표준 문제를 최초로 제기했습니다. 두 명의 원래 개발자는 몇 년 동안 나란히 일해 왔으며 외계인처럼 보이는 공통 표준을 채택했습니다. 우리는 당신이 묘사하는 것과 똑같은 문제가있었습니다.

우리가 한 일은 :

연구 코딩 표준

우리는 며칠 동안 기존의 오픈 소스 프로젝트를 조사했습니다. 우리는 팀이 빠르게 확장 할 것이라는 것을 알았고 일반적인 지침이 아닌 실제 프로젝트를 기반으로 실제 솔루션을 찾고있었습니다. 또한 우리는 최적의 코딩 표준을 신경 쓰지 않았지만 모든 코드베이스의 리팩토링을 요구하지 않는 일련의 규칙과 지침이 필요했습니다. 우리는 당신이 원한다면 코딩 표준 해킹을 찾고있었습니다.

우리 셋은 기존 PHP 프로젝트를위한 최상의 코딩 표준이 Zend Framework가 따르는 표준이라고 결정했습니다. 다행히 Zend Framework 사람들은 매우 포괄적 인 코딩 표준 문서를 제공합니다 .

자체 코딩 표준 만들기

물론 우리 프로젝트에 다른 프로젝트의 코딩 표준을 적용하는 것은 의미가 없었습니다. Zend Framework 문서를 템플릿으로 사용합니다.

  • 먼저 우리는 프로젝트에 적용되지 않은 모든 것을 제거했습니다
  • 그런 다음 스타일 문제로 인식 한 모든 것을 스타일로 변경했습니다.
  • 그리고 마침내 우리는 모든 것을 썼습니다

그래서 우리는 멋진 위키에 저장된 상당히 큰 문서를 가지고 있었고, 우리 모두가 동의 한 멋진 독서였습니다. 그리고 그 자체로는 전혀 쓸모가 없습니다.

우리의 약속을 지키십시오

당시 우리의 코드베이스는 약 1 * 10 ^ 6 슬로크였습니다. 우리는 공식적인 코딩 표준을 채택한 이후에 코드 리팩토링을 시작해야한다는 것을 알고 있었지만 그 당시에는 다른 문제가있었습니다. 그래서 우리는 단지 5 * 10 ^ 3 슬럭으로 핵심 라이브러리를 리팩토링하기로 결정했습니다.

우리는 (우리가 대신 현지 욕설을 사용하는 코딩 표준의 마스터로 우리 중 하나를 할당 마스터 확인하고 표준을 적용의 책임). 스프린트마다 역할을 재활용합니다. 나는 처음이었고 거의 모든 커밋을 모니터링해야했기 때문에 많은 작업이었습니다.

우리는 재임 기간 동안 원본 문서에 대한 몇 가지 새로운 토론과 작은 부록을 가졌으며 마침내 다소 안정적인 문서를 가졌습니다 . PHP 5.3은 이름이 아닌 주요 릴리스이기 때문에 우리는 지금 그것을 바꾸고 있습니다. 그러나 이러한 변화의 대부분은 언어의 새로운 기능에 있습니다.

새로운 사람을 다루기

다음에 새로 온 사람이 도착했을 때, 우리의 코딩 표준을 테스트 할 때가되었습니다. 코드베이스에 대한 간단한 소개 후 코딩 표준 문서를 평가하도록 요청했습니다. 그는 거의 울었다. 그가 모든 것을 다르게 한 것처럼 보였다.

당시 코딩 표준 마스터 였으므로 입력 내용을 평가하고 그에 따라 문서를 수정해야했습니다. 그의 제안은 다음과 같습니다.

  • 개인 스타일의 문제 (요약)
  • 그의 Java 배경에는 의미가 있지만 PHP에서는 그다지 중요하지 않은 표준 (해산)
  • 그가 PHP에 대한 그의 짧은 노출로부터 수행 한 협약 (일부는 기각되었지만 많은 사람들이 우리가 처음 연구에서 결코 생각하지 않았거나 발견하지 못한 대중적인 협약임이 입증되었습니다)

다음 몇 주 동안 그는 간단한 작업을 배정 받았다. 표준에 따라 코드베이스의 여러 부분을 최신 상태로 유지한다. 몇 가지 규칙에 따라 신중하게 부품을 선택해야했습니다.

  • 코드베이스와 PHP에 익숙하지 않은 사람에게는 코드가 비교적 쉬워야합니다.
  • 코드는 그가 고용 한 것에 관한 것이어야한다

나는 그의 과정을 모니터했고 그는 훌륭한 일을했다. 우리는 문서에 적합하지 않은 코드의 여러 부분을 식별하고 그에 따라 수정했습니다 (코드 및 / 또는 표준 중 더 의미가있는 것)

그리고 또 다른 새로운 남자가 도착했습니다. 프로세스를 반복하고 (이번에는 다른 마스터) 다시 작동했습니다. 그리고 다시.

결론적으로

  1. 코딩 표준 문서를 작성하되, 표준이 독점적으로 자신의 것이 아니라 플랫폼의 더 넓은 커뮤니티에서 공통 표준을 반영하는지 확인하십시오.
  2. 코딩 표준 마스터와 유사한 역할을 할당하십시오. 적어도 새로운 코드, 특히 새로운 멤버의 새로운 코드를 모니터링하는 사람. 지루하기 때문에 역할을 재활용하십시오.
  3. 항상 새 멤버의 입력을 평가하십시오. 말이 되더라도 항상 표준을 수정하십시오. 코딩 표준 문서는 발전해야하지만 느리게 진행되어야합니다. 반복 할 때마다 코드베이스를 리팩토링하고 싶지 않습니다.
  4. 각 신입 회원이 귀하의 표준과 규칙을 배우고 적응할 수 있도록 시간을주십시오. 이러한 상황에서 가장 잘 작동하여 학습하십시오.
  5. Wiki는 그러한 문서를 위해 놀라운 일을합니다.
  6. 코드 검토는 모든 상황에서 놀라운 일을합니다!

프로세스의 어느 시점에서 우리는 커밋 사전 후크 를 사용 하여 표준 확인을 자동화 하는 것이 좋습니다 . 우리는 여러 가지 이유로 그것에 대해 결정했습니다.이 문제에 관한 StackOverflow에 대한 흥미로운 토론이 있습니다.

일부는 PHP에 따라 다르지만 모든 플랫폼에 적용됩니다.


모든 개발 관리 방법 만 잘 대답 할 수 있다면 ... 감사합니다!
jleach

3

예, 나는 전에 그것을 경험했습니다. 팀에서 일할 때 팀 구성원은 특정 규칙과 규칙에 동의해야하며 여기에는 스타일이 포함됩니다.

당신은 당신의 팀이 함께 앉아 체크인 한 코드의 모든 부분을 준수해야하는 일련의 규칙, 코딩 표준 을 작성해야합니다.

아마도 스타일링에 대한 규칙 세트의 기본은 기존 코드 일 것입니다. 완료되면 모든 사람이 준수해야하며 코드 검토의 일부로 검사해야합니다 . 표준을 준수하지 않는 코드는 체크인 할 수 없습니다.

그건 그렇고, 민주당 투표일 필요는 없습니다. 팀 리더가 실제로 어떤 권한을 실행할 수있는 것 중 하나입니다. 그러나 그 말에 따르면, 대다수 팀이 거부하는 표준을 강요 할 수 있다고 생각하지 않습니다. 한 사람, 특히 새로운 사람이 거부하는 표준을 강요 할 수 있습니다 .

그와 대화하는 방법에 관해서는 ... 모든 숙련 된 프로그래머는 각 장소와 팀이 고유 한 규칙과 스타일을 가지고 있다는 것을 알고 있습니다. 개선 제안을 환영하는 것 이상이지만 팀의 규칙을 준수해야하며 기존 코드의 스타일을 변경하지 말고 새 코드를 추가 할 때 동일한 스타일을 사용해야합니다.

또한 부적절하다고 판단되는 특정 사항 (정의, 주문, 해킹 및 바로 가기 등을 언급하지 않음)을 해당 사람 에게 말하지 않을 수도 있습니다 (관리자 인 경우 관리자에게 이야기하거나 관리자와 이야기 할 수 있음).


이것이 우리 팀에서 수행 한 방식입니다. 코딩 표준 문서를 논의하고 승인했으며 각 체크인마다 코드 검토를 사용합니다. 꽤 잘 작동합니다.
조르지오

3
  1. 누군가 책임이 있습니다-그들은 그렇게 행동해야합니다.
  2. 코딩 스타일이 매우 중요하다면 왜이 사람에게 설명하지 않았으며 규칙을 배우기 전까지는 코드에 액세스 할 수 없음을 알려주십시오.
  3. 코드 검토-분명히 당신은 아무것도 없거나 매우 약합니다. # 1을 참조하십시오.

채용 과정에서 승인 된 코딩 스타일을 따르는 것이 고용의 필수 조건이라는 점에 유의하십시오. 이제 규칙을 따르지 않는 사람들에게 어떻게해야합니까? 프로그램에 도달 할 때까지 라이브 코드에 대한 액세스 권한을 제거하여 시작하십시오.

.


1

수행 할 수있는 작업은 다음과 같습니다.

  1. 필요한 코딩 스타일을 설명하는 문서를 작성하고 팀의 모든 사람들이 그것을 배우게하십시오. 모든 팀원으로부터 정보를 수집하십시오.
  2. 모든 팀원이 자신의 책임을지게하는 방식으로 작업을 나누고 코드의 해당 부분에 대한 규칙을 결정할 수 있습니다. 문제가 발견되면이를 작성한 사람이 문제를 해결합니다.
  3. 코드가 버전 관리에 투입 될 때마다 들여 쓰기 및 기타 사항을 수정하는 자동 도구를 버전 관리에 추가
  4. 프로그래머마다 프로그래밍 스타일이 다르므로 나중에 변경하기가 어려울 수 있습니다. 이를 처리하는 가장 좋은 방법은 팀원간에 정보를 공유하여 모든 사람들이 사람들이 사용한 스타일을 알 수 있도록하는 것입니다. 다른 코드를 작성하는 팀원이있는 경우 기존 팀원이 새로운 스타일을 배울 수 있습니다.
  5. 한 가지 좋은 트릭은 기존 코드를 수정 하지 않는 것입니다 . 코드를 수정하는 대신 빈 줄을 새 코드로 바꾸어 새 코드를 작성하십시오. 코드가 준비되면 기존 시스템을 조금만 수정하여 새 코드를 사용하십시오. 이것은 기존 코드의 조정을 피하여 이미 잘 작동하고있는 것을 깨뜨릴 수 있습니다.

피해야 할 사항은 다음과 같습니다.

  1. 다른 사람보다 다른 사람의 코드가 더 나은지 또는 더 나쁜지 결정 그것은 그렇게 작동하지 않습니다. 모든 사람들은 언어의 특정 하위 집합을 코드에서 사용하기에 충분히 알고 있습니다. 모든 프로그래머는 배우기 위해 다른 하위 집합을 선택했으며, 함께 배우지 않으면 다르게 보일 것입니다.
  2. 누군가 코드 작성 방법 변경 사람들에게 익숙하지 않은 스타일을 쓰도록 강요하면 코드에 많은 버그가 생깁니다. 사람들은 처음 사용하는 것에 대한 충분한 세부 사항을 알지 못합니다. 프로그래머는 항상 언어의 하위 집합을 선택하고 그 언어 만 사용합니다. 프로그래머가 gotos로 가득 찬 수천 줄의 코드를 작성한 경우 gotos는 버그가 가장 적은 코드를 제공합니다.
  3. 또한 기존 코드베이스가 훌륭하고 깨끗하며 유지 관리가 용이하다고 생각해서는 안됩니다. 항상 개선해야 할 것이 있습니다. 그러나 모든 변경 사항은 작성된 원래의 디자인 아이디어를 흐리게합니다. 완벽한 코드를 처음으로 작성하여 나중에 변경이 필요하지 않도록하십시오. (새로운 사람이 처음으로 올바르게 수행했다면 완벽한 코드를 "깨뜨릴"필요가 없습니다.)

OP의 원래 맥락에서 답을 사용하려면 ... 해킹을 삽입하고 매크로를 사용하며 다른 나쁜 코딩 습관이있는 프로그래머가 있으므로 제품의 일부를 조각하고 그에게주는 대신 전화를 걸기를 제안합니다 "나쁜"코드를 "다른"이라고합니다. 나는 이것에 더 이상 동의하지 않았다. 팀으로 일할 때 끊임없는 커뮤니케이션, 디자인 / 코딩 토론 및 검토가 중요한 부분이며 팀이 성숙함에 따라 팀원은 지적한대로 기술이 향상 될 것입니다. 서로 이야기함으로써, 우리는 ...
DXM

... 서로 가르치면 팀 전체의 기술과 역량이 향상됩니다. 그렇지 않으면, 당신은 좋은 제품의 일부를 가지게 될 것입니다, 그러나 당신은 유지하기 어려운 엉망이 된 더 많은 부품을 갖게 될 것입니다. 그리고 그러한 엉망의 "소유자"는 그 버그가 들어 오면 계속 해킹을 계속합니다. , 사람들이 제대로 수행하지 못한 동일한 구성 요소를 작업하는 데 몇 년이 걸리는 것을 보았습니다.
DXM

1
아니요, 여기서 문제는 누군가가 나쁜 코딩 습관을 사용한다는 것이 아닙니다. 실제 문제는 이미 한 사람이 코드를 작성하는 방식을 변경해야한다고 결정하고 나머지 팀은 자신의 코드가 완벽하다고 생각한다는 것입니다. 사람들은 당신이 기회를 주면 코딩 스타일을 향상시킬 것입니다. 그러나이 사람들은 다른 사람이 그렇게하지 않으면서도 빨리 개선하도록 강요하기로했습니다.
tp1

@DXM 이전에는 보지 못했거나 사용하지 않은 사람들이 많은 훌륭한 언어 기능을 '못생긴 해킹 및 바로 가기'라고합니다. 가장 좋은 것은 새로운 사람이 해커라고 결정하기보다는 표준에 대해 이야기하는 것입니다.
커크 브로드 허스트

우리는 여기서 다른 경험을 바탕으로 답을 얻을 수 있습니다. 무엇보다도 OP는 "모든 곳에서 정의를 사용하는 것"이라고 말했다. 그것이 상수를 입력하는 것이 아니라면 나쁘지는 않지만 개선 될 수 있습니다. 그러나 나는 사람들이 클래스를 올바르게 리팩토링하고 디버깅 할 수있는 함수에 공통 코드를 넣기가 너무 게 으르거나 기술이 없기 때문에 코드 덩어리를 정의하는 것을 보았습니다. 절대로 그런 식으로, 나는 그 "다른 스타일"을 고려하고 그들이 계속 그렇게 할 수있게 해줄 것입니다. 또한 다른 모든 답변은 팀을 일반적인 스타일 / 컨벤션으로 통합하는 데 중점을 둡니다. 이 답변은 ...
DXM

1

기존 코드베이스에는 대부분 읽기 쉽고 깨끗하며 유지 관리 가능한 코드가 포함되어 있습니다

몇 년 동안 배운 한 가지는 가독성이 보는 사람의 눈에 있다는 것입니다. 나는 누군가의 치킨 스크래치 코딩 스타일이 "읽기 쉬운"것으로 정당화되는 많은 경우를 보았고, 어떤 코딩 스타일이 가장 "읽기 쉬운"지에 대해 완벽하게 합리적인 사람들이 논쟁하는 것을 보았습니다. 이 남자는 당신의 스타일을 읽을 수있는 것으로 보지 않습니까?

즉, 새로운 직원은 다른 방식이 아니라 표준을 준수해야합니다.


0

새 코드에 대한 풀 요청을 저장소에 사용하십시오. 이것은 코드 검토를 수행하기에 편리한 장소를 제공합니다. 코드 검토에 실패한 코드는 형태가 정해질 때까지 리포지토리에 병합되지 않습니다.

풀 요청을 너무 크게하지 않도록주의하십시오. 내 경험상 그들은 반나절에서 최대 이틀까지 크지 않아야합니다. 그렇지 않으면 병합 충돌이 너무 많습니다.

bitbucket 또는 github와 같은 온라인 vcs 시스템은이 기능을 지원합니다. 온 프레미스 접근 방식을 선호하는 경우 숨김은 현재 가장 좋은 방법으로 보입니다.


0

수행 할 수있는 간단한 규칙이 있습니다. 코드를 사용하여 파일을 수정하는 경우 해당 파일에 사용 된 코딩 표준을 사용합니다. 새 파일을 만들면 좋은 코딩 표준을 사용합니다. (플러스 : 컴파일러에서 경고를 표시 할 수있는 경우 모든 합리적인 경고를 활성화하고 가능한 경우 경고 = 오류를 켜고 경고가 포함 된 코드를 허용하지 마십시오. 공백 등의 탭은 사용하지 마십시오).

코딩 표준에 대한 큰 논증이있는 이유는 한 표준이 다른 표준 (보통)보다 나쁘지 않고 다르기 때문입니다. 유일한 나쁜 점은 코딩 스타일을 혼합하는 것입니다.

분명히 나는 ​​괜찮은 프로그래머가 특정 표준을 선호하는지 여부에 관계없이 모든 코딩 표준에 따라 코드를 작성할 수 있다고 기대합니다.

반면에 품질 표준이 있습니다. 품질 기준에 맞지 않는 코드는 절대로 받아들이지 마십시오.

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