複数のプログラマーと連携するためのベストプラクティス

ほとんどのプログラマーは、それが実行不可能な場合でも、プロジェクトで一人で作業することを好むと思います。プログラミングプロジェクト以外でも、私は一人で作業することを好みます。他の開発者と作業するとき、私は通常それを見つけます

• 書式や規則（変数名やメソッド名など）が気に入らない
• 彼らが書いたコードがどのように機能するかについて私はよく理解していません。
• 彼らが書いたものを実装するためのより良いまたはより効率的な方法があると思います

4〜5人のプログラマーがいるプロジェクトで、これらの問題や他の同様のチームの問題を克服するための最良の方法は何ですか？

これらの問題を克服する方法は1つしかありません。つまり「コミュニケーション」です。あなたが説明する問題はあなたがプログラマーが互いに話し合わないことが原因です。タスクを解決するための最良または最も効率的な方法が何であるかについて話し合った場合、それはあなたが望む方法で実装されます。さらに、フォーマットと規則に同意することもできます。

彼らのコード部分を理解するには、みんなのコードについて話し合うコードレビューを毎週行う必要があります。次に、彼らが彼らの作品を発表している間に質問をすることができ、これはみんなのコードの品質を高めるのにも非常に役立ちます。

私はチームでの作業が大好きです。問題は、チームで効果的に作業するために、チームメンバー全員が同じプロジェクトで別々に作業するだけでなく、実際に一緒に作業する必要があることです。

なぜあるコーディング規約を他のコーディング規約よりも好むのか、などについて話し合う必要があります。そして、個人的なお気に入りかどうかにかかわらず、すべてが1つの規約に同意する必要があります。それらが何であれ、あなたはそれらに慣れ、一貫性を高く評価します。

あなたはお互いのコードを見直し、批評するべきです。実際には、ほとんどの場合、ペアでプログラミングする必要がありますが、私がそれを信じるとは思えないので、お互いのコードを確認してください。コードの一部は、別のプログラマがそれをレビューし、それを保守する必要がある次の人が理解できるようになるまで、「完了」と見なすべきではありません。

コーディングしているときに言い訳をお互いに話し合って質問してください。問題を攻撃するために2つ以上の方法を選択しようとしていることに気付いた場合は、おそらく最良の答えがわかっていると思っていても、他の開発者の1人から健全性チェックを受けてください。どちらも会話から何かを学び、コードがどのように組み立てられているかについての共通の概念をより多く得るでしょう。

毎日簡単なミーティングを行うことで、誰もが自分のやっていることとそれがどうなっているかを言うことができます。そうすることで、進行中のすべての作業の状態と、それがどのように処理されているかについて、誰もがよりよく理解できるようになります。

あなたはコードを所有していません-グループとしてコーディング規約を選択できます。あなたはいつもあなたの道を行くわけではなく、ただ適応することを学ぶだけです。

他の人のコードに慣れることは決してありません。XPでは、これがプッシュペアプログラミングの理由です。しかし、通常、他のすべてと同様に、最善の方法はそれを掘り下げて学ぶことです。

より効率的またはより優れたコードがある場合（Readableの方が効率的であるよりも重要です。前のポイントを参照してください）、コードについて話し合う必要があります。

これはキャリアであり、あなたは自分の仕事を所有していません。あなたは多くの人と仕事をするか、それに慣れるか、自分自身ですべてを行い、自分のプロジェクトに資金を提供できるほど優秀でなければなりません。

それは楽しい仕事ではありません-あなたの仕事が夏の真ん中に屋根を修理することであり、彼らがあなたが好きではない方法でそれをするようにあなたに言ったならばそれ。限目。

「なぜ」と尋ねますが、丁寧にお願いします。プログラマーは通常、その理由を説明するのに満足しています。答えが「私はいつもそうしてきた方法だ」でない限り、あなたは何か役に立つことを学ぶでしょう。たとえば、ハンガリー語の「良い」表記と「悪い」表記の違い、さまざまな命名規則の利点、選択したアルゴリズムが現在のタスクに十分対応できる理由などです。

私はいくつかの考えを持っています。他の回答のほとんどはこの問題のコミュニケーションの側面をかなりうまくカバーしているようですが、私はあなたが考えたまたは私自身の2つで作成した各箇条書きの点に対処したいと思います。

書式や規則（変数名やメソッド名など）が気に入らない

これは、実際には余裕がないという考えです。あなたのフォーマットや慣習が気に入らない人はおそらく20人いるでしょう。これらのことを決定するプロセスの一部ではなかった場合は、それを乗り越えて、適応する方法を学ぶ必要があります。プロセスに参加している（または将来参加する可能性がある）場合は、懸念事項を他の開発者に伝えてください。しかし、文句を言うだけではありません。ソリューション/代替案がすでに計画されており、準備が整っている。

彼らが書いたコードがどのように機能するかについて私はよく理解していません。

いいえ、必要ありません。あなたがこの主張をしているなら、あなたはペースの速い変化する環境であまり働いていません。6か月前に書いたコードは、一見しただけでは理解できません。それが私の個人的な癖のいくつかで書かれたという事実がなければ、私がそれが私のものであることを本当に知ることすらできませんでした。他の誰かの作業をリエンジニアリングするためにはより多くの労力が必要になるかもしれませんが、間違いなく、誰が書いたかに関わらず後でそれを理解するためにリエンジニアリングします。

彼らが書いたものを実装するためのより良いまたはより効率的な方法があると思います

驚くばかり。すべてのチームは、改善と効率を愛しています。仲間の開発者にそれをもたらします。あなたの上に任命された上級開発者または建築家がいる場合は、彼に知らせてください。オープンで自由にチームとアイデアを共有してください。他の人のアイデアも受け入れる準備をしてください。多くの人があなたがここで言っているのと同じことを言うのを見つけますが、彼らの本当の意味は「私のやり方はより良いです、そしてあなたはすべてそれを吸うことができます。あの人になってはいけない。あなたが他の人がそうであると期待しているのと同じくらい進んで変化してください。

私はこれらの質問についてしばらく考えてきました。私はチームリーダーであり、他の2人のプログラマと協力しています。プログラマーの1人は私と非常によく似たスタイルを持っています-同じではありませんが、十分に近いです。私はそれが彼の側で何らかの変更を正当化するとは思わない。さまざまなタブの規則または変数名のために何かを開始するポイントは何ですか。

他の開発者はacプログラマーです（私たちは.netプロジェクトに取り組んでいるvb.netプログラマーです）。彼はcbコードであるかのようにvbコードを記述します（ロールが逆転した場合、cコードをvbであるかのように記述します）。これに関していくつか問題がありました。でもしばらく考えてみたら。私が持っていた問題は、奇妙に見えるコードが私に与えた本当に不快な感じでした。彼のコードには何も問題はありませんでした。彼のコードはクリーンで非常によく機能します。さらに、コードはクラスインターフェースの背後で抽象化され、プログラムの残りの部分に公開されます。したがって、結局のところ、コーディングスタイルは実際には重要ではありません。プログラムが正しく、コメントが妥当である限り。私たちは皆、十分に賢く（少なくとも私は願っています）、デバッグがそれほど難しくないはずです。

彼がc＃でコーディングしていて、vb.netでコーディングしている場合は、別の話になります。まだ管理はできますが、もっと難しいでしょう。

個人的には、個々のチームメンバーが満足して快適なコーディング規約を使用することがはるかに重要だと思います。これは、関数をインデントするために必要なタブの数を伝えるいくつかのスタイルガイドを参照するのではなく、生産的にコーディングしていることを意味します。

これは、アプリケーションの使用例や要件を自由に設定できるという意味ではありません。これらは顧客が設定します。

ああください！コーディング基準は妊娠中絶の議論に似ています：誰もが妊娠中絶を持っています（私を除いて、妊娠中絶については本当の意見はありません。他のみんなの悪臭。

読みやすいとわかったため、さまざまな方法を使用しています。たとえば、PHPのテストブロックは次のように記述します。

if（条件）{
  ステートメント;
} [オプションのelseまたはelseif]

しかし、Pascalでブロックを書き込む場合は、次のようにします。

if（条件）
  開始

  終わり;

それは言語に依存します。私にとっては、この両方を読む方が簡単です。しかし、誰かがPHPのifの後に{を付けたい場合、私は本当に問題はありません。

「外部」コードを使用することに伴うフラストレーションは理解できますが、この「障害」を克服するための機会が2つあります。

1. すべての開発者は「中括弧戦争」を経験することを学ぶ必要があり、それによって私は共通のコーディング標準を取得する方法を見つけることを意味します。特定のテクニックを好む理由を明確に説明することを学ぶが、さらに重要なのは、他の誰かが異なる見方をする理由を聞くことを学ぶことです。次に、チーム/プロジェクトのためにあなたの一部を置くことを学びます。

2. ただし、長期的に見れば、他の人のコードを読むことの学習がはるかに大きな価値になります。これについては、あなたはそれを押し通す必要があり、それを避けてはいけません。たくさん学ぶことさえあるかもしれません。

チームが大きくなるほど、単体テストの重要性は増すと思います。

• 自分で作成したコードが単体テストの対象であることを確認してください。
• 他のチームメンバーにテストを書くよう説得してください。

コードをカバーするテストがあると、（自分のコードと他のコードの）共存が容易になります。これは、好きではないコードにも当てはまります。

の 最高のあなたが妥協する必要はありませんので、その答えは、その思考プロセス、独自に一致するチームを見つけることです。

現実的な答えは、あなたができる最善のようにそれに対処することです。異なるコードスタイル（たとえば、同じ行の中かっこ対次の行）の問題である場合、それは大した問題ではありませんが、ユーザーが使用している言語のガイドラインに従っていない場合、いらいらすることは理解しています。それがまったく意味をなさないまったく無意味なコーディング標準のようなものである場合（たとえば、必要のないハンガリー語の表記、SoMeWeIrDnAmInGsTyLe、すべての変数は8文字を超えてはならないなど）、それを変更してみてください。コードには手がかりがなく、コードを改善したいほどインテリジェントではなく、以前のコードでカーゴカルティングするだけです。

まず、私のコーディングスタイルre：white spaceを調整します。昔、一部のピエロは、ベストプラクティスに関するジョーク記事を書いて、可能な限りあらゆる場所に空白の12個の完全なタブのようなコード例を示しました。12フィート幅の画面がない場合、または.0001フォントサイズでは、コードを読み取ることができません。多くのプログラマーは、それが信頼できるものであると想定し、それを実行し始めました。それは私を狂わせます。みんな来て、私は言う、あなたはそれより賢いです。240列のページの50％以上の空白は意味がありません。最初の波括弧を関数またはクラスシグネチャと同じ行に配置します（間に1つまたは2つのスペースを入れ、間に1つまたは2つのスペースを入れません）。3つのスペースを使用してコードレベルをインデントします（部分的に盲目のチームメンバーがいる場合は5つ）。次に、コードのあちこちに空白行を使用して、より小さな論理ブロックに配置します。

ここに骨のあるものの別の例があります。まず、これは経験の浅いハーフウィットからではないことをお伝えします。それは、世界の他のほとんどの国々がまだそれについて頭を悩ませている間に、非常に高度な技術を機能させることができた人によるいくつかの非常に優れたコードにあります。これは私にとって苛立たしいことです。優れたプログラマーがコードのフォーマットについて骨の折れる理由

    for (Iterator<Byte> iterator = collection.iterator(); iterator
            .hasNext();) {
        byteArray[i++] = iterator.next();
    }

次に、for条件のフォーマットを見てください。実際に考えてみれば、改行を入れるのはまったく理不尽なところではないでしょうか。1つは、1行に... {全体を表示するのに十分なスペースがありました。（幸いなことに、この男はインデントに複数のタブを使用していません。）しかし、分解することなしに絶対に生きられないのなら、なぜ関数仕様の真ん中にあるのでしょうか。その直前に完全に適切な区切り文字-セミコロン-があります。これは、ブレークポイントとしてより理にかなっています。私の投票は、条件全体とオープニング{（forに伴う）を同じ行に置くことです。彼も終了します-閉じ中かっこを開いた「for」と一致させるのは簡単です。（一部の人々-とツール（それは冗長ですか？）-奇妙な場所にも配置したいです。）

第二に、各プログラマーの専門知識の焦点に注意し、大きな違いがある場合は、それが各プログラマーが作業するコードのどの部分に反映されているかを確認してください。ロボット工学の産業用制御の専門家、主に複雑な数学的ビットに取り組んでいるエンジニア、完全にあいまいなコード構成で自分を印象づけるCS学位の人（理解しにくいほど、洗練されているように見えます）が全員です。別の方法でコードを記述します。これらの大きな違いがある場合は、個々の強さが仕事に一致するように作業を分割します。

そのような違いがない場合は、コーディングスタイルに同意します。いずれにしても、コードレビュー、コードレビュー、コードレビューです。率直に言って、私は人生の多くのずさんなスパゲッティコードを経験してきました（メンテナンスグループによるデバッグと変更の12倍のラインダウン、または目を凝らした統合の結果）。最後に作業した人と2分間話し合った後、コードの専門家。（補足：実際には、適応を続けるよりもコードを書き直した方がよい点があります。）

個人的には、私も一人で家で仕事をすることを好みます。他の多くのプログラマー、ディスカッション、および中断に囲まれたキュービカルで好むか、またはうまく機能するプログラマーに会ったことはありません。しかし、チームでの作業に慣れる必要があります。つまり、時間をかけて集まり、自分のしていることについて話し合う（戦うのではない）ことを意味します。それは実際に仕事の一部です-それは本当にです。それを受け入れ、体系的、効率的、効果的に行う方がはるかに優れています。そして、私たちがそうしている間-知識や情報をドキュメントを書く人（あなたが自分で書く必要があるかもしれない人）に転送することに時間を費やすことも仕事の一部です。そして、あなたが責任のレベルを上げるのに十分な経験を積んでいると、マネージャーやマーケティング担当者などともっと頻繁にチャットすることさえあるかもしれません。

コーディングだけでも趣味です。プロフェッショナルソフトウェアエンジニアリングは、多面的な職業です。