개발시 동료와의 거래, 조언이 필요함 [폐쇄]

나는 우리의 현재 프로젝트의 아키텍처를 개발하고 내 자신에 개발을 시작 (같은 도달 revision 40) .

우리는 간단한 지하철 라우팅 프레임 워크를 개발하고 있으며 제 디자인은 매우 잘 수행 된 것 같습니다. 몇 가지 주요 모델, 해당 뷰, 주요 로직 및 데이터 구조가 "있는 그대로"모델링되고 렌더링과 완전히 분리되었으며 알고리즘 부분도 구현되었습니다. 주요 모델을 제외하고 소수의 교점이있었습니다.

나는 그 디자인을 확장 가능하고, 커스터마이즈 할 수 있고, 구현하기 쉽고, "블랙 박스 상호 작용"에 기초하여 상호 작용하며, 아주 훌륭하다고 생각합니다.

이제 무엇을 했습니까?

• 해당 인터페이스의 구현을 시작하고 편리한 라이브러리를 이식했으며 일부 응용 프로그램 부분에 대한 구현 스텁을 작성했습니다.
• 코딩 스타일과 해당 코딩 스타일 사용법 (내가 작성한 코드)의 예를 설명하는 문서가 있습니다.
• 코드 (스마트 포인터를 통해 래핑 됨) C++등을 포함하여 다소 현대적인 개발 기술을 사용하도록 강요했습니다 no-delete.
• 구체적인 인터페이스 구현의 목적과 사용 방법을 문서화했습니다.
• 단위 테스트 (주로, "실제"코드가 많지 않았기 때문에 통합 테스트) 와 모든 핵심 추상화에 대한 일련의 모형.

나는 12 일 동안 결석했다 .

우리가 지금 무엇을해야합니까 (프로젝트는 다른 4 명의 팀원이 개발했습니다) :

• 모든 프로젝트를 통해 3 개 가지 코딩 스타일 (내 생각, 그들 중 두 사람은 같은 스타일 :)를 사용하기로 합의 , 같은 우리의 추상화의 이름에 적용 (예를 들어 CommonPathData.h, SubwaySchemeStructures.h) 기본적으로 일부 데이터 구조를 선언 헤더입니다.
• 최근 구현 된 부품에 대한 문서가 전혀 없습니다.
• 내가 최근에 호출 할 수있는 것은 single-purpose-abstraction적어도 2 가지 유형의 이벤트를 처리하고 다른 부품과 긴밀하게 연결되어 있습니다.
• 사용 된 인터페이스의 절반은 이제 멤버 변수를 포함합니다 (sic!).
• 거의 모든 곳에서 원시 포인터 사용법.
• " (Rev.57) They are unnecessary for this project" 때문에 단위 테스트가 비활성화되었습니다 .
• ... (아마도 모든 것이 아님) .

커밋 역사는 내 디자인이 과잉으로 해석되어 사람들이 개인 자전거 및 바퀴를 다시 구현하기 시작한 후 코드 덩어리를 통합하는 데 문제가 있음을 보여줍니다 .

이제 프로젝트는 여전히 작은 양의 일을하고 심각한 통합 문제가 있으며 메모리 누수가 있다고 가정합니다.

이 경우 할 수있는 일이 있습니까?

나는 모든 노력에 아무런 이점이 없었지만 마감 기한이 곧 다가오고 무언가를해야한다는 것을 알고 있습니다. 누군가 비슷한 상황이 있었습니까?

기본적으로 나는 프로젝트를 위해 좋은 (잘, 내가 할 수있는 모든 것을했다) 아마도 좋은 무언가로 이어질 것이라고 생각했지만, 나는 내가 틀렸다는 것을 이해한다.

혼란에서 벗어나기 위해 무자비하게 리팩터링하십시오!

사용 가능한 스타일의 대부분을 설명하는 코딩 스타일을 사용하여이 프로젝트에 사용하십시오.

최악의 점은 개정판 40으로 롤백해야하며 프로그래머는 12 일 간의 교육 세션을 통해 주제를 더 잘 이해할 수 있다는 것입니다.

프로그래머가 깨끗한 코딩에 대해 배울 점이 많으면 12 일이 가장 지연됩니다.

귀하의 질문에 대한 역설- "나는 몇 주 동안 떠났고, 내가 떠났을 때 팀이 한 일에 동의하지 않습니다. 내가 없을 때 원하는 일을 어떻게하게합니까?"

나는 이것이 기술적 인 문제가 아니라 경영상의 문제라는 것을 당신에게 두었습니다. 나의 취임 (내가 틀렸다면 나를 용서해주세요)은 당신이 어떤 이유로 든 당신의 해결책에 동의하지 않거나 이해할 수없는 군대에 대한 기술적 해결책을 지시하는 것입니다.

12 일이 지나서 디자인에 많은 피해를 주었으면 이유가있을 것입니다. 디자인이 연약합니까? 엔지니어링 이상입니까? 또는 팀이 방치 한 상태에서 방금 했습니까? 마감일과 배송 물은 어떻습니까? 단단한? 그들은 단지 하나를 만나려고 했습니까?

제가이 사례를 보았을 때 기술 리더가 게임보다 훨씬 앞서서 일반 개발자 (나)가 유지할 수 없었습니다. 기술 담당자는 상업적으로 실행 가능한 코드를 설계하지 못했습니다. 코드를 유지할 수있는 유일한 사람이었습니다. 대학원 개발자가 유지 관리 할 수없는 경우 상업 세계에는 너무 복잡합니다. 다른 모든 경우에, 그것은 관리 측면에서 사람들 관리 기술의 명백한 부족이었습니다.

팀 역학이 깨졌습니다. (다른 사람들이 제안한대로) 엉망으로 리팩토링하는 데 시간을 할애 할 수 있으며 다음에 휴가를 갈 때 다시해야합니다. 팀원을 숙련시켜야 할 수도 있지만, 팀의 역 동성을 먼저 해결해야한다고 생각합니다. 팀 역학은 아무리 추악하다고 믿더라도 업무를 수행하기에 충분한 기술을 갖추고있는 것으로 보입니다.

쌍.

당신이 묘사하는 것은 기술적으로 솔로 로 많은 일을하는 것 입니다. 그렇습니다. 문서화를 시도하고 표준을 적용하려고했지만 의사 소통에 실패했습니다.

글쎄, 당신의 팀은 방금 당신에게 말을 걸었습니다. 그들은 "이피, 당신은 의사 소통을하지 않습니다!"라고 말했습니다. 내가 아는 가장 강력한 의사 소통 방식은 ​​페어링입니다. 쌍. 그들이 그것을 얻을 때까지, 또는 그들이 당신이 그것을 다르게하도록 설득 할 때까지.

Brooks가 지난 30여 년 동안 우리에게 말했듯이 개념적 무결성은 모든 프로젝트에서 가장 중요한 부분입니다. 사소하고 완전한 서브 시스템의 경우, 설계를 담당하고 구현을 지시 할 권한을 가진 사람은 정확히 한 명이어야합니다. 프로젝트에서이 부분에 문제가 있습니다. 그것이 무엇이든간에 유일한 해결책은 그 전에 존재했던 저장소의 코드로 롤백하는 것입니다. 12 일의 손실은 파손 된 설계 유지 비용과 비교할 수 없습니다. 또한이 작업에 참여한 사람들이 무능한 것으로 판명되어 프로젝트에 대한 추가 작업에서 제거하는 방법에 대해서도 생각하고 있습니다.

초보자를 위해 한 가지 좋은 방법은 좋은 코드 검토 도구를 사용하여 잘못된 코드를 표시하고 왜 나쁜지, 그리고 개념적으로 어떻게 수행해야 하는지를 문서화하는 것입니다. 이제 내가 이해 한 바에 따르면 많은 나쁜 일이 있었으므로 검토해야 할 일이 많았습니다. 코드에 문제가있는 유일한 사람이라고 가정하면 모든 것을 직접 검토하는 것이 불가능할 수 있습니다. 그러나 최악의 위반을 표시하고 해당 코드를 작성한 사람에게 할당 된 문제 추적 시스템의 항목으로 전환 할 수 있습니다.

양질의 코드를 작성하는 데 가장 좋은 동기는 그렇지 않다면 미래에 당신을 괴롭힐 것이라는 것을 아는 것입니다. 동료들은 그것에 대해 신경 쓰지 않는 것 같습니다. 따라서 최고의 약은 그들이 잘못된 부분을 스스로 리팩토링하고 배우는 것입니다.

주어진 시간에 문제가있는 코드의 다른 부분을 다시 방문하여 원래 (나쁜) 작성자에게 다시 할당 할 수 있습니다. 잠시 후 그들은 처음으로 좋은 일을하는 것의 이점을 알게 될 것입니다.

나는 당신이 원래 버전으로의 롤백을 옵션으로 고려하지 않는다고 가정합니다. 즉, 동료가 작성한 나쁜 코드에도 불구하고 동료가 일부 기능을 추가했으며 현재 버전의 순 가치가 원래 버전보다 높았습니다. 또한 그렇지 않은 경우에도 롤백을 수행 할 정치적 자본이 없으며 코드를 다시 작성해야한다고 가정합니다 (지구의 소수의 사람들이 그러한 자본을 가지고 있음). 이것들과 그 이상은 내가 경험하지 않은 상황을 판단하는 복잡성이지만, 2 센트가 도움이되기를 바랍니다.

내가 언급하지 않았지만 최근에 내가 일하는 곳에서 나온 것은 "개발자 사일로"와 "구입"의 문제입니다.

현재 프로젝트를 시작할 때 기본적으로 핵심 라이브러리를 스스로 디자인했습니다. (개정판 40 번까지했던 것처럼). 그런 다음 팀의 다른 팀원들에게 발표를하고 사용을 시작할 수 있다고 말했습니다. 그 후 몇 달 동안 사람들은이 라이브러리에 이미있는 것과 같은 것을 다른 곳에서 계속 구현하고있었습니다. CTO (능동적으로 코딩하는)는 라이브러리의 아키텍처 / 디자인 / 공용 인터페이스에 대해 다른 팀의 인수가 없었 음을 지적합니다.

글쎄, 우리는 방금 우리가 현재하고있는 것에 더 잘 맞도록 전반적인 디자인을 개선 한 라이브러리의 주요 재 작성을 마쳤습니다. 그러나 개발자는 라이브러리를 유일한 프로젝트로 가져 와서 몇 주 동안 작업했습니다. 그런 다음 방금 제시했습니다. "Voila! 여기 있어요! 예쁘지 않나요?"

이제 새 버전을 사용해야하고 동일한 문제가 있습니다. 그가 한 방식이 싫습니다. 그리고 그는 작업하는 동안 다른 사람과 협력하지 못했기 때문에 필요한 것을 제외했습니다. 다시 말하지만, 나는 다른 곳에서 동일한 것들을 구현하기 시작했고 내가해야 할 일을 수행하는 방법을 시작했습니다.

간단히 말해-코드 품질을 높이고 일관성을 유지하려면 전체 팀을 모아 표준, 스타일 등을 설정하는 것이 좋습니다. 또한 누구나 기본 또는 핵심 요소를 만들려고 할 때 응용 프로그램, 나는 책임이있는 사람이 수업 등을 디자인하는 데 전체 팀을 이끌도록 제안하여 하루가 끝날 때 전체 팀이 전체 응용 프로그램 아키텍처를 구입해야한다고 제안합니다. 또한 다른 팀원의 코드 작동 방식을 알고 있으면 자신에게 적합한 방식으로 코드를 다시 구현할 가능성이 줄어 듭니다.

이 팀의 선임 개발자 (또는 선임 개발자 중 하나)입니까? 그렇다면 모범 사례에 대한 교육 세미나를 개최해야 할 것 같습니다. 수행 한 많은 작업을 되돌리고 팀과 회의를하고 기존 디자인을 유지하는 방식으로 필요한 기능을 구현하는 올바른 방법을 설명해야합니다.

마감 기한이 촉박 한 경우 코드를 그대로 배송하고 릴리스 후 리팩터링 (재 작성?)해야 할 수 있습니다.

또한 일반적인 코드 관행을 정의하고 시행해야하는 것처럼 들립니다. 직장에서 코드 검토 프로세스가 있습니까? 그렇지 않다면 지금 같은 소리를 구현할 때입니다. 코드 검토는 새로운 개발자에게 모범 사례를 가르치는 좋은 방법입니다.

편집하다:

최근에 비슷한 상황이 발생했습니다. 회사 경영진은 계약 개발자를 사용하여 많은 응용 프로그램을 작성해야한다고 주장했습니다. 그들이 만든 코드는 끔찍했지만 (친절하게 말하면) 사용하도록 강요되었습니다. 오늘 현재, 계약자가 우리를 위해 작성한 코드의 80 %를 다시 작성했습니다. 버그로 가득 차서 새로운 기능으로 확장 할 수 없습니다. 몇 달 후에 우리 팀은 모든 것을 다시 작성하여 계약 개발에 투자 한 돈을 낭비로 만들었습니다.

나쁜 코드는 실제로 비용이 많이 들며, 이는 코딩 표준을 구현하고 시행하는 데 도움이 필요할 수 있기 때문에 관리자와 이야기하고 싶을 수도 있습니다.

당신은 노력했지만 사실은 아무도 책임 이 없습니다 . "그러나 나는 코딩 스타일을 선호한다", 똥. 나는 하루 종일 내 개인 프로젝트를 수행하고 여전히 돈을 받고 싶습니다.

바라건대, 당신은 이것을 강대국들에게 제시 하고 2 주간 진행된 Wild West Show 와는 반대로 행해졌을 수있는 것을 보여줄 수 있기를 바랍니다 . 문 밖으로 무언가를 가져와야하지만 제어력과 일관성이 부족한 문제에 대해서는 계속 후속 조치를 취하는 것처럼 보입니다.

계획과 함께 제공된 몇 가지에 초점을 맞추고이 혼란을 해결하고 향후 프로젝트에서 팀에 전달할 수 있도록 최선을 다하십시오. 그들이 함께 할 수없는 경우 나머지를 거부해야 할 수도 있습니다.