どうすればいいの？ 結局のところ、単独では記述できないプロジェクトがあります。 この記事では、プログラマーのチームで働くことの心理的な側面を示します。 いくつかの理論的知識を提供します。これにより、プログラマーとその全体的な感情的背景の有効性を高めることができます。
ソフトウェアの有効性と品質が低下した理由は何ですか？
プログラマの有効性を低下させる要因は、客観的と主観的なものに分けることができます。
私はこれらの2つの用語を理解しているので
客観とは、知覚のポイントに依存しないものです...その値を変えない、一定の角度で、あなたがそれらを見ない角度で。 しかし、主観的な要因は、知覚のポイントに依存するものです。
効率に影響を及ぼす主観的要因
ありきたりの対人的敵意を捨てて、私たちの状況では、感情的な理解と尊敬の十分なレベルを持つ複数のプログラマーのチームがあると仮定します。 それにもかかわらず、そのようなチームでさえ問題があるかもしれません。
実際、プログラマーはコードの所有権を開発します。 結局のところ、コードは彼が作成したものであり、具体的なものです（モニター画面で見ることができます）。 プログラマーは、コードをオブジェクト（ このコード を書いた）およびスペース（ このコードがエディターで開いているとき、私は安心し ます ）として認識することができます。 したがって、コードは、椅子や部屋のように、「私のもの」、「私のものではない」にすることができます。 これは私の椅子であり、私はそれに座っています（このコードを書きました）。 これはVasyaの椅子であり、Vasyaはそれを使用しています。私は座るのが感情的に不快です（Vasyaはこのコードを書きました）。
私は今、彼が自分の画面に表示されるコードを使用してプログラマーの主観的な自己識別について話していることを強調したいと思います。
作業しているプログラマーは、このコードが「彼」または「彼ではない」と感じるかもしれません。 このコードでの自己識別は非常に重要です。 コードが「自分」であると信じている人は、次のことを行います。
- 拒否されたと感じることはありません（「あなたのたわごとはそれほど臭いことはありません」）
- プログラマーの一般的な感情的な感情が発生します。 彼は快適ゾーンにいると「自宅」にいると感じます（「エイリアン」コードで作業するとき、彼がどのように感じるか考えてみてください... 1日8時間...数ヶ月連続で）
- 彼にはマスターと所有者の感覚があります（さらに原始的：リーダーの感覚、結局のところ、ほとんどのプログラマーは男性です）。 これらの感情は、私たちの場合、コードに対するイニシアチブ、責任、および積極的な態度を示すように男を刺激します
- 私のコードでは、リファクタリングを行うのは怖くないです。 「これは私の財産であり、私はそれでやりたいことをします」のようなもの
- 「自分の」コードを完成させながら、プログラマは必要な調整を行い、コードのアーキテクチャを維持するために、必要なだけコードに変更を加えます。 しかし、コードが「エイリアン」である場合、プログラマーは必要最小限の変更を行おうとするでしょう。 機能を追加するが、アーキテクチャをサポートしない場合、彼はおそらく、新しい機能を既存の機能の側面に「固定」するでしょう。
- 人々は奇妙な/新しい場所に慎重になる傾向があります。プログラマが「外国の」コードに大幅な変更を加える必要がある場合、彼はコードに慣れるのに多くの時間を費やし（このコードを「彼」にしようとします）、感情的にもっと拘束されます必要な変更を行います。 最悪の場合、既存のコードにコードを単に「貼り付ける」だけです（前の段落を参照）
- 「エイリアン」コードを支配すると、感情的にその所有者に影響を与えます。 意識的または無意識のうちに、プログラマーはコードセクションで他のプログラマーの所有権を認識します。これは、食卓で家族が暗黙の場所を家族ごとに認識するのと同じ方法です。 テーブルの「外国人」の椅子に意識的に座ると、椅子の「所有者」への感情的な影響により不快感を覚えます。
また、コードの変更について話していることを別にお知らせします。 コードを読んで、特にそれを使用する（「エイリアン」関数を呼び出す）ことは、プログラマーの感情的な状態に影響しません。
客観的要因
客観的なコンポーネントもあります。プログラマーがこのコードを知っているか、このコードを知らない可能性があります。 「コードを知る」とは、関数の名前とその機能を思い出すことを意味します。 この知識が本当に客観的であることに気付くのは難しいことではありません-それはそこにあるかどうか、そして私たちの貧弱な実験的プログラマーがどのように感じるかは関係ありません。 コードに正しい変更を加えるために、人はそれを客観的に知る必要があります。
問題の特異性と説明
何がありますか？ プロジェクトの理論上の理想的な状態は次のとおりです。すべてのプログラマーは客観的にすべてのコードを知っており、すべてのプログラマーはすべてのコードを「自分自身」と見なします。 しかし、教えてください、1つの歯ブラシに2人の所有者がいることはできますか？ 残念ながら、ありません。 コードに変更を加えるプログラマーは、コードの作成者（「現在の」所有者）の目にはこのコードをより「異質」にします。
目的 ：各プログラマーは、自分が知っているコード、および「自分の」と見なすコードを使用して（最大時間）作業する必要があります。 この結果はすでに達成可能です。
問題解決
ソフトウェア開発の過程で、プロジェクトに関する客観的な知識と、プログラマーのコードに対する主観的な自己識別が変わります。 私たちのタスクは、最後の段落で設定した目標をサポートするために、所有権の知識と感情の分布に影響を与えることです。 プログラマーがプロジェクトについて知っているほど、または彼が「自分の」と考えるコードが多ければ多いほど良いです。 おridgeをバターで傷つけません。 これらを下げることはできませんが、上げることは常に役立ちます。
もう1つのことは、これらの要因を増やすことはプログラマにとって時間がかかるということです。 そして、ここで合理化の問題がすでに発生しています：プログラマーはプロジェクトを知るために1日2時間費やし、所有感を高めるために1日2時間を費やすことができます...
合理化に取りかかる前に、レバレッジを見てみましょう。 コードに関する客観的な知識を増やすには適切です。
- 最も実績のある方法は、コードの作成者になることです:)
- 書かれたコード文書
- プログラマー間の口頭および書面によるコミュニケーション
次のメソッドは、コードの所有権を強化するのに適しています。
- ここでも、メソッド番号1はコードの作成者です。
- コードの客観的な知識。 それでも、「自分の」ために少なくともあなたが理解していることを認識しやすい
- コードレビュー-コードの作成者がコードを表示し、他のプログラマーと相談すると、この他のプログラマーはコードに影響を及ぼします（彼のアドバイスの一部でさえコードに該当する可能性があります）。 独特の方法で、著者は2番目のプログラマーにコードを「知って」、ある種の「私たちの」特性が生じます。
- コード設計基準を順守することで、すべてのチームメンバーの「鉱山」の所有感が高まりますが、予約があります（以下について）
コード草案の標準に関する別の段落（所有権を増やす別の方法、長すぎる）
コード設計標準（それらが何であれ）は、主にコードの外観を統一することを目的としています。 このようにして、コードを読みやすくします。また、このコードを初めて目にした場合でも、プログラマーがこのコードを使用して自己識別できるようにします。
プログラマーはどう思う
または
ああ！ 書いたかのように書かれています
または
ああ！ ほら、彼はジグリビールも大好きで、ソファは家のように柔らかい！ ここで快適に感じます！
しかし、そこにありました。 コードは同じように実行できますが、コードが従うロジックは、実験的プログラマーが使用するロジックとは異なります（プログラマーはここで
while
ループを使用し、コードは
foreach
と言います）。 コードのロジックとこのコードを読む人のロジックとの間のこれらの違いは、所有権の感覚が最終的に作成されないという事実につながります。 そのため、コードの設計要件が完全に期待される結果をもたらさない一方で、プログラマの自由度をある程度制限し、官僚機構の別の層を追加します。
1つの解決策は、すべてのプログラマーに同じロジックを考えさせ、唯一の正しいロジックを課すことです（または、
foreach
を使用するタイミングと使用するタイミングまでコードの設計要件を詳述することです）。 しかし、これはユートピアです。 さらに、すべての人が異なっており、なぜカーボンコピーに10人のプログラマーを「クローン」するのか。
プログラマー間の理解を深め、彼らが仲間のプログラマーのロジックに精通するのを助けることはより良いです。 特に、コードのレビューにより、プログラマーはお互いのロジックを学ぶことができます。 コードレビューの魔法は、プログラマーVasyaがプログラマーPetyaによって記述されたコードを取得することですが、Vasyaはその中で何も編集する必要はありません。 彼はPetyaの仕事を勉強するだけで、その後Petyaに自分の考えを伝えます（VasyaはPeteにPetyaのダイニングチェアで何か変えるものを提供しますが、彼は椅子に触れません）。 VasyaとPetyaはコミュニケーションをとりながら、彼らがどういうふうに何を好むかを理解しています。 したがって、将来的には、VasyaはPetitのコードを見て、Petitのロジックを知っていることをより快適に感じるでしょう。
合理化の問題
プロジェクトの開発を続けながら、同時に「自分自身」と感じるコードに常に取り組んでいるプログラマ間のバランスを見つける方法は？ そのような質問に対する答えは、文脈に大きく依存します。 2つの最も急進的な方法のみを紹介しますが、これら2つの極端な方法が実際の状況での使用に適しているとは考えられません。むしろ、これら2つの正反対のバランスを見つける必要があります。
メソッド番号1。 責任の分離と「個室」
プロジェクトの仕様で許可されている場合：
- プロジェクトをいくつかのサブタスクに明確に分割し、互いにほとんど相互接続しない
- かけがえのないプログラマーがいる（プログラマーが去ると、プロジェクトは崩壊するか、非常に苦しむ）
その後、プログラマーが状況の唯一のマスターになる場所に小さな穴を開けます。 これらの「ミンク」が互いにどのように相互作用するかについて明確に同意する必要があるだけで、「所有者」（責任プログラマ）が各ミンクの内部実装を引き継ぎます。
これはかなり急進的なアプローチであるため、非常に重大な欠点があります。
- かけがえのないプログラマーがいるでしょう（ミンクの所有者が去ると、他の誰かがこのミンクに同行することは困難になります）
- 1つの「ミンク」以外のすべての準備ができている場合、すでに作業を完了しているプログラマーは、スケジュールより遅れているプログラマーを実際に助けることができません。 彼らは「ミンク」の詳細を知らず、おそらくプログラマを悩ますだけです。
長所：
- ミンク内プロセスの文書化なしで行うことができます。 なぜなら 1人のミンクが1人のプログラマーによってサポートされている場合、彼はこれをすべて頭の中で保持できます
- プログラマーは実質的にコミュニケーションに時間を費やさない
メソッド番号2。 フォーラム
フォーラムはマスコミュニケーションの分野です。 また、あなたのソフトウェアは、誰もがプロジェクトのすべての部分を知っており、互いに非常に密接に相互作用するとき、マスコミュニケーションのための領域に変えることができます。 この方法の長所と短所は、実際には、「パーソナルミンク」法の利点の反転です。
おわりに
プログラマーの正しい配布とプログラマー間のコミュニケーションに加えて、プロジェクトの管理と開発の方法を考慮することも重要です。 開発ベクトルを変更し、プロジェクトの現在のタスクを変更することが頻繁に予想されますか？ これは成熟したプロジェクトですか？ プログラマーの特殊性を考慮に入れてください。その中には天才がいるかもしれませんが、膨大な量の官僚制度の下では、加速して上空を飛ぶことはできませんか？ プログラマーの責任についてあなたはどれほど自信がありますか？ 考えて決定します。