良いチームプレーヤーになるには？[閉まっている]

私は12歳からプログラミングを続けています（アセンブリからC ++、Javascript、Haskell、Lisp、およびQiまで）。しかし、私のプロジェクトはすべて自分のものです。

CSやコンピューターエンジニアリングではなく化学工学の学位を取得しましたが、今年の秋に初めて大規模なプログラミングプロジェクトを他の人々と一緒に作業することになり、準備方法がわかりません。私はこれまでずっとWindowsを使ってきましたが、このプロジェクトは非常に統一されたものになるので、最近、環境に慣れるためにMacを購入しました。

昨年、CSメジャーの両方である友人たちとハッカソンに参加できたのは幸運でした。しかし、彼らと一緒に仕事をするうちに、彼らのワークフローは私のものとは非常に異なっていることに気づきました。彼らはバージョン管理にGitを使用しました。一度も使用したことはありませんでしたが、それ以来、できることをすべて学びました。また、多くのフレームワークとライブラリを使用しました。ハッカソンにとってRailsがほぼ一晩であったことを学ばなければなりませんでした（一方、レキシカルスコーピングやクロージャが何であるかを知りませんでした）。私たちのコードはすべてうまく機能しましたが、彼らは私のものを理解していませんでしたし、私は彼らのものを理解していませんでした。

実際のプログラマーが日常的に行うこと-単体テスト、コードレビュー-への参照を聞きますが、私はこれらが何であるかについて漠然とした感覚しか持っていません。通常、私の小さなプロジェクトには多くのバグはありません。そのため、バグ追跡システムやそれらのテストは必要ありませんでした。

そして最後のことは、他の人のコードを理解するのに長い時間がかかることです。変数の命名規則（新しい言語ごとに異なる）は難しく（__mzkwpSomRidicAbbrev）、疎結合は難しいと感じています。だからといって緩くつなげないわけではありません-私は自分の仕事でそれが得意だと思いますが、LinuxカーネルやChromiumソースコードのようなものをダウンロードして見てみると、これらの奇妙な名前のディレクトリとファイルのすべてがどのように接続するかを理解します。車輪を再発明することはプログラミングの罪ですが、多くの場合、ライブラリを解剖するのに何時間も費やすよりも、自分で機能を作成する方が簡単だと感じます。

明らかに、生活のためにこれを行う人々はこれらの問題を抱えておらず、私はその点に到達する必要があります。

質問：他の全員と「統合」を開始するために実行できる手順は何ですか？

ありがとう！

グループで働くことに不安と興奮の両方を感じていると思います。

グループやチームでの作業を本から学んだことも、赤ちゃんの手順や「チームで作業するためのダミーガイド」を与えられた人もいませんでした。

グループで作業することにより、グループで作業することを学びます。

プロのプログラマーについて聞いたことはすべて、チームで作業するにつれて徐々に適切になります。バージョン管理、単体テストなどのように、それらすべてを1つずつ学びます。

私にとって、一番下の行は

チームの一員になりましょう。

私はあなたの文章をいくつか選んで、いくつかの一般的なポイントを作ります

（一方、彼らは語彙の範囲やクロージャが何であるかを知りませんでした）。私たちのコードはすべてうまく機能しましたが、彼らは私のものを理解していませんでしたし、私は彼らのものを理解していませんでした。

...

実際のプログラマーが日常的に行うこと-単体テスト、コードレビュー-への参照を聞きますが、私はこれらが何であるかについて漠然とした感覚しか持っていません。通常、私の小さなプロジェクトには多くのバグはありません。そのため、バグ追跡システムやそれらのテストは必要ありませんでした。

...

私は、これらの奇妙な名前のディレクトリとファイルのすべてがどのように接続するかを理解しようと何時間も費やします。

あなたが学ぶ必要がある最大の単一の事柄はこれだと思います：

開発者の能力を与えられた標準のために、チームnの開発者が行います以下よりn開発者の一人が一人で行うことができると回仕事を-彼らはまだ行うことができます任意の1人以上行います。

理由は簡単です。他の人と仕事をするときは、時間をかけて他の人と情報を交換する必要があります。一方、単独で作業する場合、情報交換はすべてあなたの頭の中で行われます。これは当然のことながら高速です。

他の重要なことは：

同僚の中には、確かにいくつかのスキルにおいて、あなたよりも能力が低い人もいます。すべてのスキルにおいてあなたよりも能力が低い人もいます

これらの2つのアイデアを念頭に置いて、上で引用したすべてのことが理にかなっています。多くの人々は閉鎖を「取得」しません。テストとコードレビューは、能力の異なる人々のグループによってコードがもたらされたときに品質を保証し、リスクを減らすことです。バグ追跡は、十分に大きなシステムを作成する場合、バグは避けられないためです。また、規則のある無限のライブラリは、規則がないと、必要なたびに学習したり、書き直したりするコードが多すぎるためです。

本当に、私はチームで働く方法を学ぶ唯一の方法は実際にそれをすることだと思います。うまくいけば、上記は精神的に準備するのに役立つでしょう。がんばろう！

最も効率的な方法は、チームの一員になることです。

多くの学生や他の開発者と一緒に仕事をすることを仕事とする多くの人々のように、あなたはまだチームの一員ではないことを理解しているので、チームに参加するのは難しいように思えます。

非常に活発であり、最新のすべてのチャンネル（課題追跡システム、メーリングリスト、wikiなど）で頻繁に通信することを好むオープンソースプロジェクトに参加することをお勧めします。おそらく他の人がどのように相互作用するかを観察することから始めるので、オープンなコミュニケーションは重要です。そのため、コア開発者間でメールに依存するプロジェクトやアーカイブされていないIRCを避けてください。

すべてを行う1人のプロジェクトではなく、非常に頻繁に寄稿者がいる歓迎的なプロジェクトをお勧めします。また、より楽しく、コミュニケーションの機会が増えるため、誰もがすべてに触れることができるプロジェクトを優先します（各開発者が区切られた領域を持つのではなく）。

恥知らずなプラグイン：あなたはここで大歓迎です！

他の人がすでにの効果について言っていることを繰り返すことはしませんが"just do it"、言及されていない追加のポイントを追加します。優れたマネージャーは、チームに統合するのに本当に役立ちます。

あなたは仕事のプログラミングの部分についてあなたについてのすべての適切なものを持っているかもしれませんが、あなたはより個人間のおよびソフトウェア開発関連のもののいくつかを見逃しているかもしれません。優れたマネージャーは、チームプラクティス（ソフトスキルとハードスキルの両方）を導き、ゲル化を支援します。また、それらのプラクティスに反対することを行ったか、行ったかを伝えます。壊れていることがわからないものを修正できないためです。

もう1つお伝えしたいのは、2つのチームは同じではなく、既存のチームでさえ1人以上の人が参加すると変更されるということです。

チームは、お互いを知り、共通の方法を見つけるまで一緒に仕事をする方法を理解しようとする個人の相互作用から始まります（例えば、タックマンのグループ開発の段階を参照）。

したがって、私のアドバイスは、あなたの質問に対する答えを今すぐ見つけて見つけるのではなく、新しいチームで実際に働き始めたときに何が起こるかを見ることです。あなたの問題の一部は同僚によって非問題と見なされる場合があり、他の一部は関連性があると見なされ、それらを一緒に議論したり、トピックに関する独自の見解を促進する可能性があります。そして最後に、あなたはおそらくあなたが考えていなかった側面にも対処するでしょう。

私はElYusubovに同意します、あなたは多くの忍耐を必要とし、あなた自身と新しい同僚にあなたがチームになるまで一緒に働くことを学ぶためにいくつかのチームを与えます。チームスポーツを練習する場合は、すでにこれを経験している必要があります。

他の人のコードを理解するのに多くの時間を費やすことに関する最後のコメント。チームで働くということは、誰か他の人のコードに取り組み、他の開発者があなたのコードに取り組むことを意味します。コードが複雑すぎて、最初から書き直すことができない場合があります。典型的な解決策は、元の開発者に変更のレビューを依頼することです。そうすれば、コードの何も壊していないという確信がもう少し得られます。

これは私にとって、ソロプログラマーからチームプログラマーへの移行における大きな飛躍でした。あなたは部分的にしか理解していないコードに取り組み、それに慣れる必要があります。これには、同僚とのより多くのコミュニケーション、多くの尊敬（はい、変数の奇妙な命名規則があるので、何ですか？）と相互信頼（彼らは異なるコーディングスタイルを持っているにもかかわらず、彼らは動作するコードを提供することを知っています） 。

優れたチームメンバーになることは、恐れることなくコミュニケーションを取り、大学を信頼し、チームとしてのプロジェクトの障害を克服し、deliver project as a team.

それはかかる時間がかかり、患者をし、必要で学ぶためにプログラマーとして、快適で自信にするために。また、すべてのプログラマーが優秀なチームプレーヤーであるわけではなく、チームプレーヤーが成功を共有し、失敗から教訓を学ぶことも事実です。

良いチームメンバーの性格を強調することは役に立つでしょう。

a）優れたチームメンバーは、自己志向ではなく目標志向の人です。

b）資質：自己満足よりも全体像について考える。これが重要なポイントです。他のすべての品質（信頼性、建設的なコミュニケーションなど）は、この品質を継承します

c）改善方法： 日中にチームとどのようにやり取りしているのかを評価し、良い点と悪い点を定義し、次の会議でそれらに注意を払ってください。また、多くの角度からチームの決定を見てみてください。他者の役割に身を置き、他者の仕事にどのように影響を与えることができるかを考えてください。

まず、プログラミングを本当に楽しんでいるような人であることを祝福します。ただし、プログラミングは有用なシステムの提供の始まりでも終わりでもありません。あなたはあなたの前で挑戦するつもりです、そしてあなたが趣味のプログラムに戻るか、あなたが好きなことをしてお金を得ることができるキャリアに行くかどうかはあなた次第です。

ソフトウェアの構築に関する教育を受けていないという点で不利です。その教育では、CSの卒業生や経験豊富なソフトウェア開発者にとっては第二の性質となる（プログラミングの方法だけでなく）いくつかのことを教えています。職場で頻繁に出てくるわけではありませんが（一度はやったことがありますが）、NP-hardは彼らが理解するかもしれない用語の例であり、あなたはそうではないかもしれません。計算の背後にある正式な理論の背景はおそらくないでしょうが、それについて学ぼうとする限り、大丈夫です。たぶんあなたの将来のCSのマスターですか？あなたには明らかなように見えるプログラミングスタイルがあるが、他のコードにはないという意味で、コードの一部が慣用的であるように思えます。コードのレビューに注意を払い、批判を受け入れて学ぶことをいとわない。これには手間がかかりますが、イライラするかもしれません。

あなたが行っていることは貴重です。あなたは本当にプログラミングを楽しんでいるように見えます。設計、アーキテクチャ、テスト、最適化など、システム開発の他の側面もお楽しみいただけると思います。プログラミングはパズルの一部であり、ソフトウェア開発者になるためには他のスキルを習得する必要があります。ハッカソンは別として、多くのビジネスにはコミュニケーション、お互いからの学習、リスニング、計画が含まれます。私はCSの卒業生であり、車や絵画の家を売るよりもソフトウェア開発を好む多くの人々と仕事をしましたが、それに対する本当の愛はありませんでした。