친구와 작은 프로젝트를 포기할시기를 결정하는 데 어떤 요소가 영향을 미칩니 까? [닫은]


30

나는 늦게 힘든 곳에서 자신을 발견했다. 거의 8 개월 동안 프로그래밍 친구와 게임을하고 있습니다. 우리는 작년 8 월경에 프로그래밍을 시작한 신입생으로 시작했습니다. 그는 2 학년 CS 학생이며, 저는 무역 분야의 IT 지원 기술이며, 수많은 서적과 온라인 구독을 갖춘 독학 프로그래머입니다.

내가 끊임없이보고있는 문제는 우리가 코드 덩어리를 작성할 때 종종 약간의 해킹이 발생하고 많은 실패가 있으며, 그것이 우리 중 하나에 대한 새로운 개념이라면 순진한 솔루션으로 가득 차 있다는 것입니다. 이것은 괜찮습니다. 우리는 배우고 있습니다. 두 코드 모두 전나무 또는 두 번째 패스에서 약간 해킹 될 것으로 기대합니다. 문제는 해킹 된 행동을 실제로 고치고 리팩토링 할 때 발생합니다.

내 파트너는 새로 고집 된 동행을 유지하면서 작동하기 시작하는 순간 오류를 보지 않기를 맹렬히 거부합니다. 한 조각의 구조에서 거의 완벽 함을 주장하면서 주석과 적절하게 명명 된 방법 및 필드가 있어도 사용할 수 없습니다. 아무리 노력해도 나는 그 행동을 완전히 깨지 않고 행동의 더 이상의 변화 나 확장을 막을 수있는 눈에 띄는 명백한 결함을 볼 수 없으며, 그와 너무 밀접하게 결합 된 모든 것들이 같은 클래스에있을 수 있습니다. 해킹 된 솔루션은 끊임없이 해킹 된 상태를 유지하며, 제대로 설계되지 않은 디자인은 처음 고안하고 테스트 할 때의 위치를 ​​유지합니다.

새로운 코드를 직접 작성하는 것만 큼 많은 시간을 보냈는데,해야 할 일을 잃었습니다. 내 파트너는 오늘 밤 그것을 잃어 버렸고 벤치 마크, 일반적인 관행, 반박 할 수없는 증거에 관계없이 자신의 코드가 처음 작성된 방식을 유지한다는 것을 분명히했습니다. 왜 당신이 무언가를하지 않기를 원하는지에 대한 책 전체가 쓰여졌더라도, 그것은 단지 누군가의 의견이라고 주장하는 타당성을 인정하지 않을 것입니다.

프로젝트에 관심이 있지만 파트너와 계속 협력 할 수 있을지 잘 모르겠습니다. 세 가지 옵션이 열려있는 것 같습니다.

  • 컴파일 시점을 지나는 코드베이스 기능에 대해 신경 쓰지 말고 간신히 절뚝 거리는 동작을 유지하고 구문 분석하려고 시도하십시오. 일단 상황이 심각하게 깨지기 시작하면 그는 근본적으로 결함이있는 디자인에 반창고를 치는 것보다 더 많은 것을하려고 노력할 것입니다.
  • 더 많은 유능한 개인이 10 년 전에 파악한 문제에 대한 끝없는 논쟁을 계속하십시오.
  • 이 프로젝트에서 프로그래밍을 중단하고 거의 10,000 줄의 코드를 작성하고 디자인에 대해 수많은 시간을 허비하고 새로운 프로젝트를 직접 찾아보십시오.

이 사람과이 프로젝트를 계속할 가치가 있는지 판단하기 위해 어떤 접근법을 취할 수 있습니까? 아니면 내 결정에 어떤 요소가 영향을 미칩니 까? 우리는 많은 코드를 작성했으며 필요한 경우가 아니라면 이것을 포기하고 싶지 않습니다.


3
합의 된 코딩 스타일 가이드 라인과 코드 검토 프로세스는 무엇입니까? 논쟁의 여지가있는 문제는 피하고 표준에 충분히 합의하면됩니다.
Brandin

25
네 번째 옵션 (허가 라이센스하에있는 경우) : 코드를 포크하고 직접 작업하십시오.
Robert Harvey

4
코드는 어떻게 라이센스됩니까? 당신은 그것을 포크하고 다른 사람과 계속할 수 있습니까?
Jaydee

14
@enderland는 그의 대답에 언급, 당신이 쓴에서 절대적으로 거대한 붉은 깃발이 : "내 파트너는 오늘 밤을 잃었하고, 아니 벤치 마크 문제가 무엇인지 상관없이, 더 일반적인 관행을 문제가 있음을 지우 만든, 아니오 상관 없다 반박 할 수없는 증거, 그의 코드는 그가 처음 만든 방식대로 유지 될 것입니다. " 이로부터 벗어날 있다면 그렇게하십시오. 진정으로 일할 가치가있는 사람이라면 누구나 때때로 잘못 될 것이라는 점을 받아들이는 겸손을 가질 것입니다.
Richard J Foster

3
무엇을 결정하든 10k 줄의 코드는 손실되지 않습니다. 코드를 작성하여 배운 것을 생각하십시오. 코딩하는 동안의 즐거움을 생각하십시오. 그리고 (강제) 3 / 4 / n + 1 번째 반복에서 배운 내용을 적용하면 현재 버전보다 더 나을 수도 있습니다. 10k 라인의 코드 를 작성하는 것을 알고 있다면 비교적 짧은 시간에 10k 라인을 작성할 수 있습니다. 종종 일을하기 위해 무엇을 써야하는지 아는 것이 가장 많은 시간이 걸립니다.
Kasper van den Berg

답변:


26

배송되지 않은 코드는 화이트 보드의 완벽한 코드보다 배송되지 않습니다.

그 말은 ...

더 많은 경험이 있거나 비슷한 상황에 처한 사람들. 뭐 했어? 내가 뭘 추천 해?

나는 다음을 고려할 것이다.

  • 이 프로젝트의 목적은 무엇입니까? 장난? 돈? 배우다?
    • 실제로이 목적을 달성하고 있습니까?
  • 이 사람이 실제로 목표를 더 잘 달성 할 수 있습니까?
  • 실제로 배송에 얼마나 가깝습니까?
  • 이러한 문제로 인해 시작이되지 않습니까? 아니면 그들은 개인적인 자부심의 문제입니까?
  • 답답할 때 자발적으로 누군가와 협력하면 어떤 이점이 있습니까?

이 프로젝트에서 프로그래밍을 중단하고 거의 10,000 줄의 코드와 디자인에 노골적인 시간을 버리고 스스로 새로운 프로젝트를 찾아보십시오.

위의 사항을 고려하여 필요한 추가 작업을 통해 생각하십시오.

우선 순위를 파악하고이 사람과의 작업과 관련된 문제가 그만한 가치가 있는지 결정해야합니다. 우리는 당신을 위해 이것을 알아낼 수 없습니다.

내 파트너는 오늘 밤 그것을 잃어 버렸고 벤치 마크, 일반적인 관행, 반박 할 수없는 증거에 관계없이 자신의 코드가 처음 작성된 방식을 유지한다는 것을 분명히했습니다.

이 유형의 사람과 일하고 싶지 않다는 것을 알고 있습니다.

공예 자체에서 프로그래밍을 배우고 우아함을 원하기 때문에 아마도 이와 같은 프로젝트를 수행하고 있습니다.


1
당신의 답변에 감사드립니다. 나는 즐겁고 (파이팅하지 않을 때) 배우는 목적을 달성하고 있습니다. 돈을 버는 날씨는 완전히 다른 이야기입니다. 그는 내 목표를 달성하는 데 도움을 주지만 여전히 스스로 달성 할 수 있다고 생각하며 동기 부여를 도와줍니다. 이 게임은 기능 크립의 훌륭한 예입니다. 솔직히 언제 배송 할 수 있을지 모르겠습니다. 파트너가 몇 달 동안 2D에서 3D 로의 변경을 추진하려고했지만 이미 범위를 넘어 섰기 때문에 거부합니다.
Douglas Gaskell

1
프로젝트를 기꺼이 포기할 의향이 있었는데, 내 프로젝트 인 경우 몇 달 전에 떨어졌을 것입니다. 내 동기 부여 요인은 다른 사람과 함께 일하는 것입니다. 그것을 포기하는 것을 막아주는 유일한 것은 코딩 외부에서 그를 연결시키는 것과 같은 우정입니다. 물론 이것은 논리에 근거한 설명이 아닙니다. 개인적 감정이 관련되어 있기 때문에 의사 결정 능력이 실제로 향상됩니다.
Douglas Gaskell

1
친구를 잃는 가장 빠른 방법은 친구들과 함께 일하는 것입니다!

58

이것은 문화적인 것일 수 있습니다. 어떤 문화권에서는 실수를했다는 사실을 들어 본 적이 없으며, 누군가에게 실수를 인정하도록 요구하는 것은 당신이 할 수있는 가장 무례한 일입니다. 그런 상황이라면 도망 치십시오.

매우 똑똑한 사람들과의 경험에서, 그들이하고있는 일이 완벽하지 않다고 말하면, 그들은 (1) 그들이하고있는 일이 실제로 옳은 이유를 정확하고 이해하기 쉽게 해줄 것입니다. 그들이 잘못되었다는 것을 알고 있지만 우선 순위로 인해 고칠 시간이 없습니다. 또는 (3) 지적하고 고마워 주셔서 감사합니다.

배우기를 거부하는 것은 소프트웨어 개발자가 가질 수있는 최악의 속성에 관한 것입니다. 그에게 맡기십시오. 인생은 너무 짧고 소중한 시간을 낭비하기에 귀중합니다.


Gnasher에게 감사합니다. 실제 일정이 없지만 정기적으로 # 2가 표시되므로 응답의 유효성이 확실하지 않습니다. 나는 이것에 대해 잠을 자고 AM에서 내가 무엇을 생각하는지 알 것이다. 이것은 결정을 내리기 전에 많은 숙고가 필요하다.
Douglas Gaskell

1
"그런 상황이라면 도망 치십시오." -그리고 일반적으로, 목표가 무엇인지에 대한 합의에 도달 할 수 없다면 누군가와 협력 할 수 없습니다. 이유와 상관없이 "자신의"코드 변경에 동의하지 않는 것 같습니다.
Steve Jessop

글쎄, 시간 압력은 변화를 거부하는 이유가 아닌 것 같습니다.
gnasher729

1
이것은 좋은 대답입니다. 누군가 자신의 길을 바꾸도록 강요 할 수는 없습니다! 그러나 프로젝트와 프로젝트에 많은 시간과 노력을 들인 것처럼 들립니다. 내 생각은 코드를 변경하고 싶지 않을 수도 있다고 생각할 수 있습니다. 그것은 또는 그의 머리에 달려 있지만, 그것을 이해하지 못한다면 좌절하고 있다는 것을 명심하십시오. 비록 당신이 아주 잘 의미한다고해도 당신이 그에게 "말을 걸고있다"고 생각하십시오. 내 충고는 당신이 둘에게 달려있을 때 그와 대화를 시도하는 것입니다.
zfrisch

^ + 당신이 같은 레벨에서 시작할 때 누군가에게 당신의 기분을 상하게하기 쉽고 그들은 당신을 능숙하게 능가합니다. 나는 그것이 확실한 경우라고 말하지는 않지만 분명히 그것과 관련이있는 것처럼 들립니다.
zfrisch

12

아마도 가장 쉬운 방법은 다른 사람을 프로젝트에 참여시키는 것입니다-당신이 틀렸고 그의 코드베이스가 당신에게 너무 영리하거나 모든 사람에게 옳고 영리합니다. 당신은 곧 알게 될 것이고, 쓰레기, 복잡한, 주니어 프로그래머 레벨 코드로 판명되면 백업을받을 것입니다.

다른 한편으로, 작동하는 제품은 수년간 세밀하게 조정되고 우아하고 명확한 코드의 가치가 있습니다. 게임을 만들고, 발송하고, 걷다가-유지하고 v2에서 작동하지 않도록하십시오.


2
답장을 보내 주셔서 감사합니다. 첫 번째 요점을 언급 한 것이 재밌습니다. 그는 프로젝트를 도와 줄 수있는 초보 프로그래머를 찾아 데려 오려고 노력하고있다. 두 사람이 같은 스타일의 해킹을 따라 잊어 버린 경우에만이 결과가 끔찍할 것으로 기대할 수있었습니다. 나는 두 번째 옵션이 마음에 들어서 만들어 배송 한 다음 그대로 두십시오. 내가 겪을 수있는 문제는 우리가 게임을 출시 할 이름을 갖도록 LLC를 만들면서 부분적으로 있다는 것입니다. 두 가지 용도 모두 물론 50 %의 점유율을 갖습니다. 그러나 나는 그것을 끝내고 나아갈 수있었습니다. 프로젝트가 크므로 시간이 오래 걸릴 수 있습니다.
Douglas Gaskell

20
당신은 할 수 없습니다 어떤 경우는 그런 사람과 법적 구속력 비즈니스 관계를 입력합니다 아래.
gnasher729

3
@ douglasg14b는 주니어를 데려 온다. 가난한 아이. 경험이 많은 사람을 데려 오라고 제안하십시오. 결승선에 당신의 시야를 설정하십시오-아니면 둘 다이 취미에서 영원히 그리고 영원히 노력하고 싶습니까? (이 취소됩니다 때까지 일어날 것을 알)
gbjbaanb

나는 확실히 마무리 할 계획입니다. 비록 그것이 처음으로 다루기에는 너무 큰 프로젝트라고 생각합니다. 그것은 단순한 디자인으로 시작되었지만 현재의 규모와 가까운 곳은 아닙니다. 우리 범위의 범위는 파트너에 의해 기능 크리프로 끊임없이 밀려났습니다. 나는 그것이 일어날 수 있고 일부 기능에 동의하기 때문에 부분적으로 비난해야합니다. 그 범위는 홀로 남겨두면 아마도 1 년 안에 완성을보고있을 것입니다. 고맙게도 프로그래밍 방식에 따라 부품을 쉽게 꺼내어 나중에 다른 프로젝트에 넣을 수 있습니다.
Douglas Gaskell

4
코드가 자신이 아닌 프로젝트에 속하는 것으로 생각하십시오. 제품의 공동 소유권이있는 경우 다음 프로젝트에 모든 코드를 재사용 할 수 있습니다. 누가 무엇을 소유하는지 모르는 경우 지금 토론하십시오. 행운을 빕니다.
gbjbaanb

9

그들 중 일부가 상호 배타적 인 경우에도 몇 가지 아이디어가 있습니다.

  • 별도의 소스 책임. 모듈 A에서 작업하고 모듈 B에서 작업하는 경우 다른 스타일과 경쟁 할 수 있습니다. 그는 작업 기능을 자주 발표합니까? 코드를 처음부터 다시 작성해야하는 시점에 도달합니까? 모듈에서 코드를 리팩터링하고 코드를 건드리지 마십시오.

  • 최악의 코드를 유지하도록하자. 그가 그것을 성공적으로 수행하면 끔찍한 작업을 피할 수 있습니다. 그가 능력이 없다면 고통을 느낄 것입니다.

  • 사용자 또는 비즈니스 관점에서 고려하십시오. 경우에 따라 Google 또는 Microsoft에서 구입할 수있는 실행 가능한 제품 만 필요합니다. 다른 한편으로, 당신은 시장에 제품을 출시하고 버그가 있거나 해킹 된 코드로 수천 명의 고객을 지원하는 것이 지옥이 될 것입니다. 코드가 핵 미사일을 가진 드론을 제어하거나 십대들을위한 행복한 비디오를 만드는 경우 동일하지 않습니다.

  • 그는 수업을하고 테스트를합니다. 테스트로 코드를 리팩토링하는 것이 더 쉽고 안전합니다. 이렇게하면 Junit 막대 만 코드 내부를 볼 필요가 없습니다. 이것은 A) 프로그래밍 테스트이고 B) 동료 코드를 테스트 할 수 있다고 가정합니다. 코딩 단계에서 테스트를 빌드하기 어려운 경우 후자가 더 나빠질 수 있습니다.

  • 훈련이나 행사에 함께갑니다. 당신이 올바른 방법을 모른다면 당신이 아는 유일한 방법은 자연스럽게 사용하는 것입니다. 다른 사람의 코드를 보는 것이 모든 것을 해결할 수는 없지만 해치지 않을 것입니다.

  • 보완적인 강점을 찾으십시오. 리팩토링은 때때로 재미있을 수 있습니다. 그가 적어도 일하는 것을 쓰면 리팩토링을 할 수 있습니다. 그는 프로덕션 코드로 끝나지 않는 솔루션을 탐색하기 위해 스파이크 를 수행 할 수 있습니다 .

  • 코드를 다시 작성하고 싶지 않지만 새 코드를 더 잘 작성하는 데 동의 할 수 있습니다. 나는 다시 쓰기가 힘들고 지루하며 일을 망칠 수 있음을 이해합니다. 양질의 섬을 키우십시오. 이런 식으로 그는 일을하는 방법에 대한 좋은 예를 갖게 될 것입니다.

  • 보이 스카우트 규칙을 사용하십시오 . 작업 할 필요가 없으면 손대지 마십시오. 모듈이 잘못 작성되었지만 작동하고 변경할 필요가 없으면 그대로 두십시오. 버그를 수정하거나 기능을 완료해야하는 경우 조금 개선하십시오. 시간이 지나면 80 %의 수업을 변경 한 20 %의 수업이 향상됩니다. 더 많은 품질의 섬.

두 사람 모두 모르면 최고의 솔루션이 무엇인지 제안 할 수 없습니다. 행운을 빕니다.


4

좋아, 여기에 아마 당신이 좋아하지 않을 답변이 있습니다.

기능을 구현하지 못하면 코드를 '수정'하지 마십시오.

여기 내 추론이 있습니다. 당신은 아마 돈을 벌기 위해 노력하고 있습니다. 돈을 벌기 위해서는 완성 된 기능을 빨리 배송해야합니다. '잘 코딩 된'컴퓨터 게임에 대해 더 많은 돈을 지불하지는 않을 것입니다.

대부분의 회사는 같은 문제가 있습니다. 기존 코드를 리팩토링은 때로는 객관적으로 더 나은 속도 나 안정성의 측면에서, '더 나은'그것을 만들기 위해 또는 새로운 기능을 작성합니다.

간단한 비용 편익 분석 결과 새로운 기능을 작성하기로 선택한 시간의 99 %


15
그러나 이것은 "기술 부채"전체 논쟁에 해당된다. 새로운 기능을 작성할 때 (또는 기존 기능을 수정하는 경우) 리팩토링을 유지 한 경우보다 3 배나 오래 걸리고 10 배나 많은 버그가 발생합니까? 그렇다면 리팩토링을 건너 뛰는 것은 잘못된 경제였습니다.
Ben Aaronson

1
당신은 그렇게 생각할 것이지만, 나는 많은 성공적인 회사에서 일해 왔으며 나는 (거의) 리팩토링을 절대 우선 순위로 보지 않습니다. 내 결론은 단순히 돈을 지불하지 않는다는 것입니다.
Ewan

그것은 충분히 공평하며 이것에 대한 다양한 의견이있을 것이라고 확신합니다. 한 가지 방법으로 해결하지 않는 것이 대답에서 중요한 누락이라고 생각합니다. 또한 내가 잘못 될 수 있지만 문제의 행간 읽기, 나는 영업 이익은 걱정되는 나쁜 코드가 될 수있다 생각하는 방법 코드 당신에 대해있는 거 사고의 종류보다 더.
Ben Aaronson

yu! 또한 변경 비용이 매우 높은 것처럼 들립니다. 내 대답에서 나는 '당신이 돈을 위해 이에 있습니까?'라는 목표를 제시하려고합니다. 답과 확률의 균형이 어디에 있는지에 대한 나의 주관적인 견해
Ewan

1
이것은 어떤 경우에는 합리적이지만, 누군가의 "작업 코드"로 인해 다른 사람이 자신의 코드 나 시스템 통합 또는 향후 작업에 2 배 많은 시간을 소비하게되면 더 이상 단순한 "선박 대 선박"결정이 아닙니다. 다수의 대규모 프로젝트 는 빠른 것이 아니라 올바른 결정을 내리지 않기 때문에 죽 습니다.
enderland

3

나는 지금까지 모든 대답을 좋아합니다. 엔더 랜드의 답변 에서 요점 중 하나를 취하는 :

답답할 때 자발적으로 누군가와 협력하면 어떤 이점이 있습니까?

이번에는 코드 검토 스택 교환 을 위해 플러그를 꽂고 싶습니다 . 전문가가 코드를 비평 할 수있는 훌륭한 장소입니다. 솔직히 말해서, 많은 코드 검토가 관련자, 즉 질문자, 응답자 및 비틀 거리며 읽고 읽는 사람들에게 큰 도움이됩니다. 전문적인 환경에서 그러한 유용한 리뷰를 거의 얻지 못합니다 (어떤 이유로 든 내가 일한 곳에서 그럴 수 있습니다).

내 조언은 검토를 위해 코드 중 일부를 게시하는 것입니다. 나는이 사람을 잘못 증명하기 위해 탄약으로 사용하는 것을 제안하지 않을 것입니다-나는 그가 그것을 마음에 걸릴 것이라고 의심하지만-당신은 작성한 코드와 그가 작성한 코드에 대해 매우 유용한 정보를 얻을 수 있습니다. 두 사람이 가장 많이 싸우는 코드를 제출하는 것이 좋습니다. 어쨌든 어느 정도 틀 렸으며 리뷰를 객관적인 제 3자가 개입시킬 수있는 방법으로 사용할 수 있습니다. 이렇게하면 몇 가지 사항이 달성됩니다.

  • 상황의 정서적 긴장에서 벗어날 수 있습니다.

  • 실시간 전문가의 조언을받습니다. 배우고있는 내용을 크게 향상시킵니다.

  • 누군가 당신이 틀렸다고 말할 것입니다. 어떤 시간 동안 프로그래밍을하는 사람이라면 누구나 이것을들을 수 있기 때문에 좋습니다. 당신은 당신이 일하고있는이 사람처럼 제대로 처리하지 못하거나 그것을 다루는 법을 배울 수 있습니다.

코드 리뷰를 올바르게 사용하면 매우 실망스러운 사람을 만날 수 있습니다. "이것은 대부분의 경우에 올바른 방법이기 때문에"라고 말하는 책이나 웹 사이트보다 훨씬 대화식입니다.

마찬가지로 게임 개발자 스택 교환도 있습니다. 검토를 위해 코드를 게시 할 곳은 아니지만, 어려움을 겪고있는 개념 / 아이디어에 대해 문의하십시오. 다시, 그 장소는 모든 관련자들에게 큰 도움이됩니다.

이전에이 두 사이트를 모두 보았을 것입니다. 나는 그들이 당신의 도구 세트의 일부인지 확인하고 싶었습니다.


2

절망적으로 들립니다. 당신이 생각하는 것처럼 나는 아마 포기하고 나아갈 것입니다. 분명히 걸어 갈 시간이 있고 당신은 거기에 있을지도 모른다.

아직 멀어 질 준비가되지 않았다면 프로세스에 대해 더 나은 동의를 얻을 수있는 방법을 찾아야합니다. 코딩 표준은 있지만 동의 한 표준은 아닌 것 같습니다. 다음에 교차로에 올 때, 다음에 약간의 코드로 원숭이를 원하고 친구가 혼자두고 싶어하면 다음 줄을 따라 대화를하십시오.

더글러스 : 가이드 라인에있는 X 때문에 변경하고 싶습니다.

친구 : 잘 지내요.

더글러스 : 가이드 라인을 변경해야한다고 말씀하십니까?

친구 : 아뇨, 그냥 괜찮아요.

더글러스 : 그렇다면 지침은 무엇입니까?

친구 : 몰라요 – 당신은 그것들을 썼습니다.

더글러스 : 어떤 지침을 작성 하시겠습니까?

친구 : 나는 지침을 쓰지 않을 것입니다. 시간 낭비 야.

더글러스 : 가이드 라인을 버리고 우리가 생각하고있는 쓰레기는 무엇입니까?

친구 : 이것은 쓰레기가 아닙니다.

더글러스 : 완벽합니까? 이상적입니까?

친구 : 작업이 완료됩니다. 다음 기능으로 넘어 갑시다.

더글러스 : 우리가 동의 할 수있는 것이 있습니까? X는 좋은 코드이고 Y는 나쁜 코드입니까?

친구 : 날 내버려둬; 난 그냥 코딩하고 싶다!

글쎄, 잘 안되나요? 내가 가진 느낌은 당신과 버디가 다른 것을 원한다는 것입니다. 당신이 동의 할 수있는 것이 있다면 좋습니다. 거기에서 시작하여 구축하십시오. 그러나 당신이 원하는 것을 원한다고 동의 할 수는 없습니다. 그 공통된 욕망을 찾을 수 있고 거기서 공통의 합의에 이르면 함께 ​​일할 수 있습니다.

더글러스 : 무엇을 원하세요?

친구 : 그냥 코딩하고 싶습니다.

더글러스 : 나도 코딩하고 싶지만 내 코드를 자랑스럽게 생각하고 싶다.

친구 : 내 코드를 자랑스럽게 생각합니다.

더글러스 : 여기에 내가 자랑스럽게 여기는 기능이 있습니다. 어떻게 생각하십니까?

친구 : 글쎄, 괜찮지 만 루프 내부에서 X를 다시 계산해서는 안됩니다. 비효율적입니다.

더글러스 : 루프 외부의 상수 값을 항상 계산해야한다고 말씀하십니까?

친구 : 글쎄, 어이!

더글러스 : 우리의 지침에 따라야한다고 생각하십니까?

친구 : 물론입니다.

더글러스 : 알겠습니다. 가이드 라인에 추가하고 코드를 업데이트하겠습니다.

더글러스 : 지금 어때요?

친구 : 좋아.

이제 Buddy는 가이드 라인에 (간접적으로) 기여하고 있으므로 약간의 소유권 감각이 있습니다. 어쩌면-어쩌면-더 진지하게 시작할 것입니다. 나는 슬레이트를 닦고 가이드 라인부터 시작하여 대부분 또는 전부가 버디에서 나올 수있게하는 경향이 있다고 생각합니다. 계속해서 똥 코드를 작성하여 지침에 추가해야 할 필요성을 느끼십시오. 그들이 그에게서 나오게하십시오. 아마도 그는 그 이유를 이해하기 시작할 것입니다.

그러나 포기하고 계속 나아가고 싶다면 그렇게 나쁜 옵션이 아닐 수도 있습니다.


2

프로젝트를 포기하기로 결정한 경우 :

  • '전 / 후'포트폴리오 항목으로 사용하여 코드를 포크하고 리팩토링
  • 프로그래밍을 배우는 것이 목표 (주로 또는 부분적으로) 였고 이미 알고있는 것을 수행하는 것보다 2-4 배가 걸리기 때문에 그 작업은 실제로 낭비되지 않습니다.
  • 'Sunk cost attachment'(나쁜 아이디어를 배우기 전에 이미 벤처에 투자 한 투자)는 의사 결정에서 가장 일반적인 인적 오류 중 하나입니다.
  • 우정을 유지하려면 코딩보다 우정을 우선으로 결정하십시오.

1

tl; dr 당신은 틀림없이 프로젝트를 포기해야합니다.

이것에 대해 더 이상 알지 못하면 당신이 우리에게 말한 것처럼, 나는 당신이 겪는 마찰이 경험과 관련이 있다고 추측합니다.

IT 전문가로서 직업적으로 프로그래머가 아니더라도 처음으로 제대로 수행하는 데 어려움을 겪었을 것입니다. 미래의 자기 자신에 대한 언급은 과거에 그를 망치고 배웠 음을 나타냅니다. 하지 않습니다.

2 학년 CS 학생은 비록 재능이 있어도 그렇게했을 것이라는 관점이 부족할 것입니다 (나와 같은 경우 반복적으로 :).

그 / 그녀는 그렇게하지 않으면 상처를 입거나 특별한 공학 분야 또는 둘 다를 가진 문화에서 멘토링 될 때까지 물건을 고치는 것의 가치를 실제로 믿지 않을 것입니다.

이 사람 프로그래밍 동료 일 수도 있지만 프로젝트 동료 가 아니기 때문에이 게임을 동료 프로젝트로 수행하는 것은 손실 된 원인 일 수 있습니다. 미래의 비용을 먹을 준비가되어 있지 않다면. 어쩌면 관계는 당신에게 충분히 가치가 있습니다. 이 경우, 그 / 그녀가 자신을 걸기에 충분한 로프를주고 그 사람이 문제를 인정해야 할 때 엉망을 청소할 수 있도록 돕습니다.

그렇지 않으면 동료와 함께 프로젝트를 구제하고 수행하거나 처음부터 역동적 인 멘토 / 멘티 프로젝트를 수행하십시오.


1

모든 위대한 답변에 추가 포인트를 추가하려면 :

  • 프로젝트를 완료하는 데 얼마나 많은 노력이 필요합니까? "마지막 10 %"를 마무리하는 것은 사람들이 예상하는 것보다 훨씬 오래 걸립니다. 플레이 테스트 / 튜닝, 사용성 수정, 다양한 대상 플랫폼에 대처, 릴리스 등이 여기에 포함됩니다. iOS 게임 인 경우 코드 서명이 있으며 Apple의 검토를 거쳐야합니다. 정직하게, 마무리는 첫 번째 "90 %"만큼 오래 걸릴 수 있습니다. 그리고 코드가 제안한대로 나쁜 경우에는 더욱 어려울 것입니다. (지금 테스트를 시작할 수 있습니까?)
  • 현실적으로 사람들이 당신의 게임을 즐길 가능성은 얼마나됩니까?
  • " 침몰 비용 휴리스틱 "에 주의하십시오 . 큰 그림에 비추어 10,000 번의 코드 라인 투자를 평가하고 완제품을 되돌아 보며 과도한 낙관주의없이 평가하십시오.
  • 3 년이 더 걸리면 계속 갈 수 있습니까? 두 팀은 서로 다른 개발 스타일을 가지고 있습니다 (팀이 잘 맞지 않음). 인내심이 거의 끝나가는 것처럼 들리며 계속 진행하면 친구를 유지하기가 어려울 수 있습니다.

3
코드의 90 %가 쓰레기 인 경우 "마지막 10 %"는 훨씬 오래 걸린다 :-(
gnasher729

0

주석과 같은 방식으로 코드를 올바르게 작성하고 코드를 변경하는 경우 코드의 사본을 작성해야합니다.

싸우지 말고 화 내지 말고 그의 나쁜 결정을 볼 때 웃어 라.

작동하는 경우에만 사용자로 불평하지 마십시오.

포기하지 마십시오. 실제 직장에서 일어날 당신과 다른 사람들에게 익숙해지는 것이 중요합니다.

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