팀에서 서로 다른 개발 스타일 (위에서 아래로)을 처리하는 방법은 무엇입니까?

아주 작은 팀에서 {현재 비교적 작지만 나중에 더 큰 프로젝트} 프로젝트를 시작했다고 가정 해 보겠습니다. 이것은 학기 말에 폐기 될 학업 프로젝트가 아닌 실제 세계의 다른 개발자들이 사용하기위한 실제 프로젝트입니다.
그러나이 코드는 아직 다른 사람에게 공개되지 않았으므로 아직 결정이 내려지지 않았습니다.

방법론

여러분 중 한 명이 코딩을 시작하고 모든 구성 요소가 정확히 상호 작용하는 방식 (아래쪽 디자인)에 대한 명확한 아이디어를 갖기 전에 조각을 맞추는 것을 좋아합니다. 다른 하나는 전체 디자인을 먼저하고 솔루션을 코딩하기 전에 모든 구성 요소와 통신의 세부 사항을 세분화하는 것을 좋아합니다.

기존 시스템을 모방하지 않고 새로운 시스템을 개발하고 있다고 가정 하여 올바른 최종 설계가 어떻게 보이는지 항상 분명하지는 않습니다. 따라서 팀에서 팀 구성원마다 때로는 최종 제품에 필요한 요구 사항에 대한 아이디어가 다른 경우가 있습니다.

상향식 개발자가 일부 코드를 작성하면 하향식 개발자는 코드가 당면한 문제를 해결할 수 있다는 사실에도 불구하고 설계에서 예상되는 잠재적 인 문제로 인해 코드를 거부하고 설계를 올바르게하는 것이 더 중요하다고 생각 솔루션을 문제점에 코딩하기 전에.

하향식 개발자가 코드 작성을 시작하기 전에 전체 설계 및 계획된 문제를 해결하려고하면 상향식 개발자는 실제로 일부 문제가 실제로 발생한다고 생각하지 않기 때문에 상향식 개발자는이를 거부합니다. 요구 사항과 제약 조건이 명확 해지면 향후 디자인을 변경해야 할 수도 있다고 생각합니다.

문제

결과적으로 문제는 상향식 개발자가 설계 결함으로 인해 상향식 개발자가 작성한 솔루션을 폐기해야한다고 결정하기 때문에 상향식 개발자가 시간을 낭비한다는 것입니다. -코드를 작성하십시오.

하향식 개발자는 작업을 병렬화하는 대신 이제 하향식 개발자와 함께 올바른 설계를 해결하기 위해 자주 앉고 둘을 더 빠를 수있는 지점으로 직렬화하므로 시간이 낭비됩니다. 한 사람이 2보다 일을 할 수 있습니다.

두 개발자 모두 계속 협력하기를 원하지만 실제로 조합이 실제로 도움을주고있는 것 같지는 않습니다.

목표

일반적인 목표는 코딩 효율성을 극대화하고 (예 : 시간 낭비 최소화) 유용한 소프트웨어를 작성하는 것입니다.

질문

간단히 말해서이 문제를 어떻게 해결하고이 상황에 대처합니까?

내가 생각할 수있는 유일한 효율적인 솔루션은 각 개발자가 디자인에 대한 자신의 스타일을 따르도록하는 것입니다. 그러나 이것은 코드를 검토하고 실제로 서로의 변경 사항을 승인해야 할 때와 다른 사람이 사용할 수있는 일관된 프레임 워크를 설계하려고 할 때 들리는 것보다 어렵습니다.

더 좋은 방법이 있습니까?

분명히 그들은 둘 다 틀렸다.

상향식 녀석은 코드를 해킹하고 있으며 예상대로 수행하는 작업을 수행하지 않습니다. 알 수없는 요구 사항이 결정되면 계속 흔들릴 수 있습니다.

하향식 녀석은 건축 비전에 오래 걸리고 생산적인 작업도 수행 할 수 없습니다.

그러나 중간 단계가 이상적입니다. (넓은 디자인 작업에서 얻은) 목표를 알고 자세한 계획없이 코드를 작성하면 시스템의 보상을 얻을 수 있습니다. 조직적이고 효율적으로 개발되었습니다.

그건 그렇고 애자일 (Agile)이라고 불린다 (일부 소프트웨어보다 절차가 더 중요한 곳에서 어떤 사람들이 절차를 연습하는 민첩의 BS 버전이 아니라).

여기서 문제를 해결하려면 하향식 녀석이 어떤 일을하도록 강요하고 상향식 녀석이 달성하려는 일을 계획하도록 강제하는 민첩한 접근 방법을 시도하십시오.

두 개발자는 서로 에 대한 상호 존중 을 유지해야합니다 .

하향식 사람은 상향식 사람이 실제로 작동하는 것을 생각해 낼 수 있다는 사실을 존중해야합니다. 저의 "수량"교수 중 한 분이 말했듯이 "작동 모델은 1000 번 추측 할 가치가 있습니다." 이 경우 하향식 사람은 상향식 사람의 작업을 수용하기 위해 "디자인"을 다시 수행하는 것을 고려해야합니다.

상향식 사람은 또한 하향식 사람의 "프레임 워크"를 존중해야하며, 노력 낭비를 피하고, 잘못된 문제를 해결하고, 주제를 벗어나는 등의 일에 도움이 될 수 있음을 인식해야합니다. 상향식 코더는 적어도 무엇을 명심해야합니다. 하향식 사람이 시도 하고 프레임 워크에 표시된대로 최소한 하향식 사람 의 우려 사항을 해결하려고합니다. 하단 상단이 프레임 워크 자체의 일부에 동의하지 않더라도 마찬가지입니다.

큰 작업을 여러 개의 작고 집중된 작업으로 분리하면 각 개발자가 소비하는 시간의 손실을 최소화 할 수 있습니다. 그들 중 한 사람이 다른 사람보다 너무 앞서 가지 않도록 긴밀히 협력하게하십시오. 짧은 스프린트와 작은 결과물은 먼 길을갑니다. 큰 실수보다 작은 실수를 고치는 것이 더 쉽습니다.

목표에 맞지 않는 것처럼 보일 수도 있지만 페어 프로그래밍이 작동합니다. 때로는 몇 시간 또는 며칠 동안 바로 잡을 수없는 것들이 있습니다. 함께 작업을 직접 수행하는 것이 문제가 아닌 경우 일주일 내내 코드 검토 / 스탠드 업을 더 자주 시도하십시오.

모두에게 알리십시오!

개발자가 자신의 세계에서 벗어 났기 때문에 코드를 버리는 것을 보게되면 가능한 한 빠르고 효율적으로 충돌을 포착하고 조정해야합니다. 당신의 상사는 그것을 인정할 것이고, 팀은 다른 사람이 무엇을하는지 알지 못했기 때문에 일주일의 일을 포기하지 않아도 될 것입니다.

또한 그들이 함께 축복으로 작용하는 것을보아야합니다. 그들이 함께 일하면서 실수를 해결한다는 사실은 좋은 신호입니다. 나는 "이 두 사람은 서로를 미워할 것"이라는 당신의 생각을 반쯤 내렸고 놀랍게도 당신은 그들이 계속 협력하고 싶다고 말했습니다.

귀하의 시나리오에 따라이 인용문이 적절하다고 생각합니다.

"두 사람이 모든 것에 동의하면 그 중 하나는 불필요합니다." ~ 일부 노인

이것은 실제로 이상적인 시나리오처럼 들립니다. 그럼 다시, 나는 오전 같은 시간에 그 개발자 모두를. 나는 이슈 트래커로가는 길을 찾는 노트 형식으로 "큰 그림"을 작성하고 싶다. 그런 다음 아래에서 구현 세부 사항에 대해 생각하기 시작합니다. 조각들이 어떻게 어울리는 지에 대한 이해를 높이면 큰 그림이 진화하고 요구 사항이 변함에 따라 조각들이 진화하고 새로운 아이디어를 얻습니다.

아마도 그것은 여러 두뇌에 좋은 모델 일 것입니다.

내 의견으로는, 그것들은 상호 보완적인 프로파일이며 결과가 매우 좋을 수도 있습니다. 코딩과 디자인은 프로그래밍에서 필요한 단계이며 X를 원하지 않는 팀에서 끝나기를 원하지 않습니다. 약간의 조직 만 있으면됩니다 (굵은 단어도 사용할 수 있습니다!).

이것은 다른 사람들이 지적한 바와 같이 감독을 통해 수행 할 수 있지만 디자인 시점과 코딩 시점의 반복 일정에 대한 상호 합의에 의해 더 잘 수행되며 일반적으로 현재 설계중인 것을 코딩하지 않습니다.

보너스 포인트는 프로젝트가 더 작은 모듈로 시작 되 자마자 하향식 프로그래머는 현재 상향식 프로그래머가 작업하지 않는 것을 디자인하여 둘 다 원하는대로 단계를 만들 수 있다는 것입니다. 그러나 이것은 모든 것이 하나로 모일 때 필요한 조정을 할 수있는 능력을 의미합니다.

참고 사항 : 당신은 말했다

기존 시스템을 모방하지 않고 새로운 시스템을 개발하고 있다고 가정하여 올바른 최종 설계가 어떻게 보이는지 항상 분명하지는 않습니다.

이것은 문제의 일부입니다. 이미 해결 된 문제를 해결하기 위해 작은 프로젝트를 진행 하지 않는 한 실제로 올바른 최종 설계는 없습니다 . 가능한 많은 디자인이 있습니다. 코드의 아름다움으로 인해 자아를 높이기 위해이 작업을 수행하지 않는 한 최종 목표는 작동하는 앱입니다. 그게 다야. 당신이 거기에 도착하는 방법은 무의미하며,이 두 가지를 빠르게 진행시키는 가장 좋은 방법은 상호 보완적인 방식으로 협력하는 것입니다.

다른 사람들이 말했듯이 두 가지 견해는 특정 방식으로 정확할 수 있습니다. 두 명의 개발자가 특히 설계 및 개발 프로세스와 같은 주관적인 것에 대해 관례에 동의하지 않는 것은 드문 일이 아닙니다. 여기에 그들이하는 일에 열정을 가지고 있고 그것을하는 방법에 대해 잘 알고있는 두 사람이 있습니다.

여기에서 두 사람이 각자의 방식으로 작업 할 수 있고 작업을 계속해서 응용 프로그램을 얻을 수있는 큰 잠재력이 있습니다.

1. 나는 두 사람이 앉아서 토론하면서 상대방의 입장에서 볼 것을 권장했다.

2. 그 토론 후에 계획에 관해 이야기 할 수 있습니다. 이것은 팀으로서 이루어져야하며, 상대방에게 '인식'할 필요는 없지만 타협이 이루어져야한다는 것을 이해해야합니다. 수많은 추가 코드를 도입하지 않고도 나중에 쉽게 확장 할 수있는 코드베이스 아키텍처를 계획하는 방법에는 여러 가지가 있습니다.

3. 일단 그들이 휴전을 할 수있게되면, 그들은 야생으로 달려 가게하십시오! 'top down guy'가 높은 수준의 아키텍처, 인터페이스, 계층 등을 계획하도록합니다. 몇 개의 모듈이 계획되면 'bottom up guy'로 들어가 코드 작성을 시작하십시오. 전체 프로젝트에 다른 사람의 방법을 받아들이겠다고 공식적으로 동의하도록하십시오. 미래의 쉬운 변경을위한 계획은 좋지만 즉시 그렇게 코딩 할 필요는 없습니다. 코드의 구조를 얻기 위해 인터페이스와 스텁 아웃 메소드를 작성하고, 미래를위한 좋은 코드가 실제로 필요할 때까지 작성되지 않을 것이라는 점을 인정하십시오.

4. 디자인과 코드를 함께 자주 검토하게하십시오. 아키텍처의 일부 세그먼트를 자세히 살펴보고 세부 사항을 계획하고 해당 부분을 작성하는주기를 반복합니다.

5. 이것은 아마도 가장 중요한 점일 것입니다. 수행중인 작업이 아니라 프로세스에 대해서만 이야기하는주기를 촉진하십시오. 건설중인 역 동성을 반영하십시오. 질문해야 할 네 가지 질문이 있습니다. 우리가 계속해야 할 일은 무엇입니까? 우리가 멈춰야했던 것은 무엇입니까? 우리는 무엇을 놓치고 있습니까? 우리가 잃어버린 것에 대해 무엇을 할 수 있습니까?

이것은 약간의 작업이 필요할 것입니다 : 당신은 그들 자신의 방식으로 함께 일하도록 동의해야합니다. 어떤 사람들은 일을하는 올바른 방법이 하나도 없다는 것을 인정하기가 쉽지 않습니다. 중요한 것은 당신이 일하는 방식이 아니거나 결국 코드의 모양이 아닙니다. 중요한 것은 숙련 된 지식을 갖춘이 두 사람이 가장 잘 협력하는 방법을 배우는 것입니다. 그것은 당신이 그들에게 말할 수있는 것이 아닙니다. 스스로 할 수있는 방법을 배우는 과정을 안내해 주기만하면됩니다. 올바른 디자인이없는 것처럼 사람들이 일할 수있는 올바른 방법은 없습니다.

일반적으로 경력을 쌓은 경험에서, 초기에 디자인 이 충분하지 않습니다 . 그리고 앞선 디자인은 품질 이 낮습니다 . 이것은 나쁘다. 대부분의 결과는 (더 크거나 더 적은) 벽에 진흙을 던지고 무엇이 붙어 있는지 볼 수 있기 때문입니다. 기술 부채는 시작부터 사라집니다.

하향식은 일반적으로 상향식 보다 우수 합니다. 비록 상향식을 배제하지는 않지만. 그 이유는 하향식으로 문제에 대해 더 광범위하게 생각하고 더 나은 질문을 하도록 하기 때문 입니다. 이것은 위의 첫 번째 요점을 강화합니다 ... 더 높은 품질의 디자인으로 이어지고 일반적으로 더 낮은 수준의 작업에 많은 영향을 미칩니다. 이는 하위 레벨 구성 요소를 먼저 빌드 할 경우 종종 필요한 재 작업을 줄입니다.

상향식 구성 요소를 먼저 구축하는 경우 개발 압력으로 인해 엔지니어링 된 구성 요소에 대한 비즈니스 요구 사항이 반영 될 위험이 없습니다. 이것은 또한 나쁘다. 비즈니스 요구 사항은 디자인을 주도하고 구현을 주도해야합니다. 다른 방법으로 진행하면 결과가 떨어집니다.

두 방법 모두 충분하지 않습니다. 그들 각각은 다른 접근법의 단점 (화상을 입었을 수 있습니까?)을 깨닫기에 충분히 영리하거나 경험이있는 것처럼 보이지만 자신이 선택한 접근법의 단점을 보지 못합니다 ...

진실은 혼합 접근법이 필요하다는 것입니다.

• "올바른"디자인을 미리 만드는 것은 거의 불가능합니다. 고통 지점, 병목 현상, ...을 식별하기 위해서는 어느 정도의 실험이 필요합니다. (힌트 : 그들이 생각하는 곳에는 없습니다.)
• "가는"방법으로 어디든 갈 수는 거의 없습니다. 원치 않는 곳에서 또는 서클에서 달리는 것보다 더 가능성이 높습니다

그러나 두 가지를 혼합하면 다음을 수행 할 수 있습니다.

• 방향과 인프라 구조를 대략적으로 보여주는 스케치
• 이 비전에 맞는 구성 요소 개발

이 목적을 달성하는 기존 시스템이 존재하지 않기 때문에 다음 사항을 미리 알고 있어야합니다.

• 실험 / 시제품 제작이 필요합니다
• 따라서 반복이 필요합니다

따라서 코너 케이스 등을 무시하는 경우에도 가능한 빨리 "작동"시스템에 중점을 두어야합니다. 이것은 "가로 세로 슬라이스"의 개념입니다. 집의 기초를 세우는 대신 다음, 벽, 다음 지붕 구조, ... 만 맨 끝에 뭔가 사용할 수를 취득 (또는 결코 그것을 얻을 수없는, 또는이도 정말 사용할 수있는) ... 대신 완전 복 구축에 더 나은 방을 첫째, 화장실처럼. 즉시 사용할 수 있으며 피드백을 수집하는 데 사용할 수 있습니다.

그러나 피드백이 가치가 있으려면 먼저 핵심 부분을 다루는 것이 가장 좋습니다.

그렇다면 동료와는 어떤 관계가 있습니까?

가장 먼저해야 할 일은 둘 다 협력의 필요성과 앞으로 나아가는 길에 동의 할 필요성을 이해해야한다는 것입니다. 끊임없이 꾸준히 책망하는 것은 자신의 신경을 자극하고 자신의 동기에 영향을 줄 수밖에 없습니다. 여러 프로젝트에서 실제로 잘 작동하는 것으로 나타났습니다. 제안으로 사용할 수 있습니다.

그런 다음 누가 무엇을하는지에 동의해야합니다. 위에 밑줄이 그어진 중간 접근 방식에서는 두 가지 모두 좋은 작업을 수행해야합니다.

스켈레톤 및 브릭 구축은 점진적으로 접근하는 것이 가장 좋습니다.

1. 둘 다 스켈레톤의 대략적인 스케치를 얻은 다음 먼저 어떤 "얇은 조각"에 초점을 맞출 지 결정해야합니다.
2. 상향식 사람은 가장 잘 이해 된 "얇은 조각"에 대한 작업을 시작해야합니다.
3. 하향식 녀석은 조각 을 완성 하기 위해 가장 많은 블로킹 조각을 다루는 것이 이상적입니다.

슬라이스가 작동 할 때까지 헹구고 반복하십시오. 필요에 따라 조정하는 방법에 따라 피드백을 축적하십시오.

주의 : 이것은 프로토 타입이므로 완전히 버리고 완전히 다른 디자인에서 처음부터 시작해야합니다.

소프트웨어 개발을 이해하고 프로젝트에서 어떤 접근 방식을 사용해야하는지 결정하는 리더 (또는 감독자)가 필요합니다. 필요한 경우 리더 는 개발자가 개인 취향에 관계없이 특정 방식으로 작업 하도록 지시 합니다.

내가 생각할 수있는 유일한 효율적인 솔루션은 각 개발자가 디자인에 대한 자신의 스타일을 따르도록하는 것입니다.

실제로, 그것은 매우 비효율적 일 수 있다. 왜냐하면 많은 갈등과 재 작업이있을 가능성이 있기 때문이다. 더 나쁜 것은 여전히 ​​전체 프로젝트 실패로 이어질 수 있습니다.