좋은 팀 선수가되는 방법? [닫은]


19

저는 12 살 때부터 (강박 적으로) 프로그래밍을 해왔습니다. 어셈블리, C ++, Javascript, Haskell, Lisp 및 Qi에 이르기까지 다양한 언어에 대해 상당히 잘 알고 있습니다. 그러나 내 모든 프로젝트는 저 혼자였습니다.

CS 또는 컴퓨터 공학이 아닌 화학 공학 학위를 받았지만 이번 가을에 처음으로 다른 사람들과 함께 대규모 프로그래밍 프로젝트를 진행할 것이며 준비 방법에 대한 실마리는 없습니다. 나는 평생 동안 Windows를 사용했지만이 프로젝트는 매우 유닉스 일 것이므로 최근 환경에 익숙해지기 위해 Mac을 구입했습니다.

나는 지난해 CS 친구들과 함께 친구들과 함께 해커 톤에 참여하게되어 매우 기뻤습니다. 그러나 나는 그들과 함께 일하면서 그들의 작업 흐름이 나의 것과는 매우 다르다는 것을 깨달았습니다. 그들은 버전 관리를 위해 Git을 사용했습니다. 나는 당시에 그것을 사용한 적이 없었지만, 그 이후로 내가 할 수있는 모든 것을 배웠습니다. 또한 많은 프레임 워크와 라이브러리를 사용했습니다. 나는 Rails가 해커 톤을 위해 밤새도록 무엇을 배웠는지 알아야했다 (반면, 어휘 범위 또는 클로저가 무엇인지 몰랐다). 우리의 모든 코드는 잘 작동했지만 그들은 내 것을 이해하지 못했고 나는 그들의 코드를 이해하지 못했습니다.

실제 프로그래머가 매일 단위 테스트, 코드 검토를 수행하는 것에 대한 언급을 들었지만 이것이 무엇인지 모호합니다. 나는 보통 내 작은 프로젝트에 많은 버그가 없으므로 버그 추적 시스템이나 테스트가 필요하지 않았습니다.

마지막으로 다른 사람들의 코드를 이해하는 데 시간이 오래 걸린다는 것입니다. 변수 이름 지정 규칙 (새 언어마다 다름)이 어렵고 (__mzkwpSomRidicAbbrev) 느슨한 결합이 어렵다는 것을 알았습니다. 그것은 내가 느슨하게 커플 링하지 않는다는 것을 말하는 것은 아닙니다. 저는 제 자신의 작업에 상당히 능숙하다고 생각하지만 Linux 커널이나 Chromium 소스 코드와 같은 것을 다운로드하여 볼 때 몇 시간을 소비합니다. 이 이상한 이름의 디렉토리와 파일이 모두 어떻게 연결되는지 알아 내기 바퀴를 재발 명하는 것은 프로그래밍 죄이지만, 종종 라이브러리를 해부하는 데 시간을 소비하는 것보다 기능을 직접 작성하는 것이 더 빠릅니다.

분명히, 생계를 위해 이것을하는 사람들에게는 이러한 문제가 없으며, 나는 그 시점에 스스로 도달해야합니다.

질문 : 다른 사람과 "통합"하기 위해 취할 수있는 몇 가지 단계는 무엇입니까?

감사!


첫 번째 단계는 프로그래밍을 공부하여 적어도 같은 언어를 말할 수 있다고 말하는 것입니다.
Rig

예전보다 더 큰 코드베이스로 프로젝트에 통합하는 방법에 대한 질문이 아닌가?
Louis Kottmann

3
"...이 프로젝트는 매우 유닉스가 될 것입니다. 그래서 저는 Mac을 구입했습니다 ..."내가 잘못 이해 했습니까, 아니면 오타입니까?
Stu Pegg

4
@StuartPegg : Mac OS X은 * nix이며, 쉘 터미널이 내장되어 있습니다. * nix 쪽을 많이 사용하려면 MacPorts를 설치하는 것이 좋습니다.
Dave Sherohman

1
나는 아메리칸 파이 영화에서 "당신이 득점 할 때까지 득점하지 않는다"고 한 번 기억합니다. tGilani가 말했듯이 팀의 일원이 되십시오. :)
asakura89

답변:


13

나는 당신이 그룹을 위해 일하는 것에 약간 불안하고 흥분하고 있다고 생각합니다.

우리 중 어느 누구도 책을 통해 그룹이나 팀에서 일하는 법을 배우지 않았거나 아기 발걸음이나 "팀 작업에 대한 안내"를받지 못했습니다.

우리는 IN 그룹을 통해 그룹과 함께 일하는 법을 배웁니다.

전문 프로그래머에 대해 들었던 모든 내용은 팀에서 일할 때 점차적으로 적용됩니다. 버전 제어, 단위 테스트 등과 같이 모든 내용을 하나씩 배우게됩니다.

나에게 결론은

팀의 일원이 되십시오.


8

나는 당신의 문장 중 일부를 고르고 몇 가지 일반적인 요점을 만들 것입니다.

(반면에, 그들은 어휘 범위 또는 클로저가 무엇인지 몰랐습니다). 우리의 모든 코드는 잘 작동했지만 내 것을 이해하지 못했고 나는 그들의 코드를 이해하지 못했습니다.

...

실제 프로그래머가 매일 단위 테스트, 코드 검토를 수행하는 것에 대한 언급을 들었지만 이것이 무엇인지 모호합니다. 나는 보통 내 작은 프로젝트에 많은 버그가 없으므로 버그 추적 시스템이나 테스트가 필요하지 않았습니다.

...

이상한 이름의 디렉토리와 파일이 모두 어떻게 연결되는지 알아내는 데 몇 시간을 소비합니다 ... 일부 라이브러리를 해체하는 데 시간을 보내는 것보다 기능을 직접 작성하는 것이 더 빠릅니다.

나는 당신이 알아야 할 가장 큰 단 하나는 이것이라고 생각합니다.

주어진 개발자 능력의 표준에 대해, 개발자 팀은 n개발자 중 한 사람이 단독으로 할 수있는 일 보다 적은n 시간을 수행하지만 여전히 한 사람이 할 수있는 것보다 더 많은 일을 합니다.

그 이유는 간단합니다. 다른 사람들과 함께 일할 때는 다른 사람들 과 정보교환하는 데 시간을 할애해야합니다 . 반면에 혼자 일할 때 정보 교환은 모두 머리에서 이루어집니다. 자연스럽게 더 빠릅니다.

다른 중요한 것은 :

당신의 동료 중 일부는 당신보다 능력이 떨어질 것입니다. 일부는 모든 기술 에서 당신보다 능력이 떨어질 것입니다

이 두 가지 아이디어를 염두에두고 위에서 인용 한 모든 것이 의미가 있습니다. 많은 사람들이 클로저를 얻지 못합니다. 테스트와 코드 검토는 코드가 혼합 된 능력 을 가진 사람들 그룹 에 의해 생성 될 때 품질을 보장하고 위험을 감소 시키는 것입니다. 버그 추적은 충분히 큰 시스템을 생산할 때 버그가 불가피하기 때문입니다. 규칙 이 없는 끝없는 라이브러리는 규칙 이 없으면 필요할 때마다 새로 배우거나 작성할 수있는 코드너무 많기 때문입니다.

실제로 팀에서 일하는 방법을 배우는 유일한 방법은 실제로하는 것입니다. 그러나 위의 내용이 정신적으로 준비하는 데 도움이되기를 바랍니다. 행운을 빕니다!


4

가장 효율적인 방법은 팀의 일원이되는 것입니다.

당신이 아직 많은 학생들과 같은 팀의 일원이 아니며 다른 개발자들과 함께 일하지 않는 많은 사람들처럼 팀에 합류하는 것은 어려워 보일 수 있습니다.

저는 매우 활발하고 현대적인 개방형 채널 (문제 추적기, 메일 목록, Wiki 등) 에서 자주 의사 소통을하는 오픈 소스 프로젝트에 참여하는 것이 좋습니다 . 공개 커뮤니케이션은 다른 사람들의 상호 작용 방식을 관찰하여 시작하므로 핵심 개발자 또는 보관되지 않은 IRC 간의 전자 메일을 사용하는 프로젝트는 피해야하기 때문에 중요합니다.

모든 일을하는 한 사람과 함께하는 프로젝트보다는 자주 참여 하는 여러 사람들 과 함께 환영하는 것처럼 보이는 프로젝트를 선호하십시오 . 또한 더 재미 있고 더 많은 의사 소통 기회를 제공하기 때문에 모든 개발자가 구분 된 영역을 가진 각 개발자가 아닌 모든 것에 접촉 할 수있는 프로젝트를 선호하십시오.

뻔뻔한 플러그 : 당신은 매우 환영 합니다 !


1

나는 다른 사람들이 이미 그 효과에 대해 말한 것을 반복 "just do it"하지는 않지만 언급하지 않은 추가 포인트를 추가 할 것입니다. 좋은 관리자는 실제로 팀에 통합하는 데 도움이 될 것입니다.

작업의 프로그래밍 부분에 대해 자신에 대한 모든 올바른 자료를 가지고있을 수 있지만보다 개인 간 및 소프트웨어 개발 관련 자료가 누락 될 수 있습니다. 훌륭한 관리자는 팀 연습 (부드러운 기술과 어려운 기술 모두)을 안내하여 도움을 줄 수 있으며, 그러한 관행에 반하는 일을했는지, 아니면 할 것인지도 희망적으로 알려줄 것입니다. 모르는 것을 고칠 수 없기 때문에 깨졌습니다.


0

또 다른 팁은 두 팀이 같지 않으며 한 명 이상의 사람들이 참여할 때 기존 팀도 변경된다는 것입니다.

팀은 서로를 알게되고 공통된 방법을 찾을 때까지 함께 일하는 방법을 이해하려고 노력하는 개인의 상호 작용에서 비롯됩니다 (예 : Tuckman의 그룹 개발 단계 참조 ).

따라서 제 조언은 지금 귀하의 질문에 대한 답을 찾지 않고 새로운 팀에서 실제로 일을 시작할 때 어떤 일이 일어나는지 보는 것입니다. 일부 문제는 동료에 의해 비 문제로 간주 될 수 있으며, 다른 일부는 관련성이있는 것으로 간주되며 함께 논의하거나 주제에 대한 자신의 견해를 홍보 할 수 있습니다. 그리고 마지막으로, 당신은 아마 당신이 생각하지 않은 측면을 다룰 것입니다.

ElYusubov에 많은 인내심이 필요하고 자신과 새로운 동료에게 팀이 될 때까지 함께 일하는 법을 배울 수 있다는 데 동의합니다. 팀 스포츠를 연습한다면 이미 이것을 경험했을 것입니다.

다른 사람의 코드를 이해하는 데 많은 시간을 할애하는 마지막 의견. 팀에서 일한다는 것은 다른 사람의 코드로 작업하고 다른 개발자가 귀하의 코드에서 작업한다는 것을 의미합니다. 때로는 코드가 너무 복잡하여 처음부터 다시 작성할 수 없습니다. 일반적인 해결책은 원래 개발자에게 변경 사항을 검토하도록 요청하여 코드의 내용을 위반하지 않는다는 확신을 조금 더 얻는 것입니다.

이것은 나에게 솔로 프로그래머에서 팀 프로그래머로의 전환에서 큰 도약이었습니다. 부분적으로 만 이해하고 익숙해 져야하는 코드로 작업합니다. 여기에는 동료와의 많은 의사 소통, 많은 존경 (예, 변수에 대한 이상한 명명 규칙이 있으므로 무엇입니까?) 및 상호 신뢰 (다른 코딩 스타일이 있지만 작업 코드를 제공한다는 것을 알고 있습니다) .


0

좋은 팀원 이된다는 것은 두려움없이 의사 소통하고 대학을 신뢰하며 팀으로서의 프로젝트에서 장애물을 극복하고deliver project as a team.

그것은 소요 시간 , 소요 환자 및 필요 배우고 프로그래머로 편안하고 자신감을하기 위해. 또한 모든 프로그래머가 훌륭한 팀 플레이어 는 아니며 팀 플레이어가 성공을 공유하고 실패로부터 교훈을 배우는 것도 사실입니다 .

좋은 팀원의 일부 캐릭터강조하는 것이 도움이 될 것 입니다.

a) 좋은 팀원 은 자기 지향적이 아닌 목표 지향적 인 사람입니다 .

b) 자질 : 자기 만족보다는 큰 그림에 대해 더 많이 생각한다. 이것이 핵심입니다. 다른 모든 특성 (신뢰성, 건설적인 의사 소통 등)은이 특성을 상속합니다.

c) 개선 방법 : 낮 동안 팀과 교류하는 방법을 확인하고, 좋은 점과 나쁜 점을 정의하고, 다음 회의에서주의를 기울이십시오. 또한 여러 각도 에서 팀의 결정살펴 보십시오 . 상대방의 역할을 맡고 다른 사람의 업무에 어떤 영향을 줄 수 있는지 생각해보십시오.


0

첫째, 진정으로 프로그래밍을 즐기는 것처럼 보이는 사람이 된 것을 축하합니다. 그러나 프로그래밍은 유용한 시스템 제공의 시작과 끝이 아닙니다. 당신은 당신 앞에서 도전을 할 것입니다 그리고 당신이 취미 프로그램으로 돌아가거나 당신이 사랑하는 일을하고 돈을받을 수있는 직업을 가지 든 그것은 당신에게 달려있을 것입니다.

소프트웨어 구축에 대한 교육이 없다는 단점이 있습니다. 그 교육에는 CS 대학원생들과 숙련 된 소프트웨어 개발자들에게 제 2의 본질이 될 수있는 몇 가지 것들 (프로그래밍 방법이 아니라)이 있습니다. 그것은 종종 직장에서 나올 수는 없지만 (한 번만 해봤지만) NP-hard는 그들이 이해할 수있는 용어의 예이며 그렇지 않을 수도 있습니다. 계산에 대한 공식적인 이론에 대한 배경 지식이 부족할 수도 있지만, 배우고 자하는 한 괜찮습니다. 어쩌면 미래에 CS에서 석사를했을까요? 그것은 당신에게 명확하게 보이지만 다른 사람들에게는 보이지 않는 프로그래밍 스타일을 가지고 있다는 의미에서 일부 코드가 관용적 인 것처럼 들립니다. 코드 검토에주의를 기울이고 비판을 받아들이고 배우십시오. 이것은 일을하게 될 것이며 좌절 할 수도 있습니다.

당신이 원하는 것은 귀중합니다. 당신은 진정으로 프로그래밍을 즐기는 것처럼 보입니다. 디자인, 아키텍처, 테스트, 최적화 등과 같은 시스템 개발의 다른 측면도 즐기게 될 것입니다. 프로그래밍은 퍼즐의 한 부분이므로 소프트웨어 개발자가되기 위해서는 다른 기술을 배워야합니다. 해커 톤을 제외하고, 많은 비즈니스에는 커뮤니케이션, 서로 배우기, 듣기 및 계획이 포함됩니다. 저는 CS 졸업생들과 많은 사람들과 함께 일했으며 자동차 나 그림 집을 파는 것보다 소프트웨어 개발을 좋아했지만 그에 대한 진정한 사랑은 없었습니다.

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