プログラミングにおけるコミュニケーション-夢と現実の中で

子供の頃、私はバベルの塔についての聖書の物語を奇妙な物語だと考えていましたが、ソフトウェアプロジェクトでほぼ毎日人々による誤解の異常に遭遇し始めました。 簡単な言葉で言えば、砲塔に関するストーリーの本質はこれです。人々は大きくて恐ろしい、強力なシステムを「コーディング」し、さらにはアーキテクチャを複雑にし、混乱し始め、お互いの足、腕、頭を踏んで、構造全体が地獄の杭になった-チームは崩壊しましたそして、クラブを手にした「フリーランサー」、腕の下にある粘土板（ラップトップではなく）、地面に点在するsmoke製肉の在庫などを口論しました。







そして21世紀の科学、数学、論理の全盛期-歴史はまさにヒステリーを繰り返します。 なぜそれが起こったのか、シスの魔法が適用されたかどうかを見て、成功に導くいくつかの原則を開発してみてください-予算を指数関数的に超過することなく、わいせつな悪魔払いをせずに、チームメンバーが費やした時間のための積極的なドラフトなしで、ソフトウェアプロジェクトを時間通りに立ち上げてください。



しかし、最初に、「ビルダー」を見てみましょう。私たちは誰ですか？

なぜプログラマーはそんなに賢いのですか？

プログラミングとは、簡単な言葉で言えば、人間の欲望の多次元のカオスを、愚かではあるが非常に高速なプロセッサー用のコマンドセットに並べることです。 厳密な数学と途方もない速度で飽和した鉄の論理は、魔法を生み出します-ディスプレイ上の生命、多次元現実、ゲームなど。 毎日これを行い、多くの本を読んで、そして最も重要なことには、同僚のコードを閲覧して部分的に理解し、開発者は自分の脳を集中的に訓練し、負の湾曲のひもでニューロンに座って不本意に、不本意に...彼らはオフィスの周りの「マネージャー」を追いかけますただ見てください。



しかし、精神を発達させるには、シスに敬意を払わなければなりません。

心の報い

絶えず脳を発達させて、開発者は毎週変わります。 一方では、人が成長しています。 一方、2、3週間前に独自のコードを見て、さらに3、6か月のエージングを行うと、災害が発生します。非標準で禁止されたU​​TFシーケンスを呪いたいという抵抗できない欲求があり、...はい、はい、独自のコードに嫌悪感を伝えたいと思っています。 あなたは男を変え、あなたはずっとクールで経験豊かになりました-そしてあなたは常に、常に過去の自分の仕事から引き返されます。 しかし、幸いなことに、この症状はプロセスを理解することで治療されます-すべてが問題なく、あなたは異なった、より完璧になり、あなたは正しい軌道に乗っています！



しかし、まだ誰も効果的に治療することを学んでいない大きな問題がまだあります-これらはバグです。 原則として、だれも意図的にそれらを許可することはありませんが、自分の脳の制限を伴う複雑な問題を解決するとき（通常、タスクを切り替えるときに混雑するコンテキストのために十分な「RAM」はありません）-人は間違っています。 彼らは複雑さを軽減する方法でこの症状を治療しようとします：

-オブジェクトの関数やメソッドにコードを配置することにより、コードの一貫性を高めます。

-多くの場合、設計パターンまたは「正しい」プログラミング言語（正しいパターンを具現化する）のいずれかを使用して、システムコンポーネントの相互依存を減らします。

-すべての言語機能を軽率に使用しないでください（例外、多重継承、テンプレート）。



しかし、残念ながら、絶対的な薬はまだ発明されていません。 バグ：角があり、目があり、多くの脚と腕があり、すべての可能な色があります。



それにもかかわらず、自分が何をしていて、なぜそれを明確に明確に理解していれば、間違いをはるかに少なくすることができます。 ライブラリ、アルゴリズム、アイデア、アーキテクチャのさまざまな形式と予測で、正確かつ敬verな一貫した説明が表示される場合、独自の作業をシステムに追加します。 そして最も重要なこと-プロジェクトがプロジェクトで正しくオープンにコミュニケーションをとるとき、あなたはあなた自身の努力からますます喜びを受けるようになります！

APIと通信

開発者は、シンプルでよく考えられたAPIのレベルで、そしてそれほど集中的ではないがソースコードのレベルで、お互いにうまく通信できます。 残念ながら、優れた、産業的で、思慮深く、一貫したAPIが作成されることはめったにありません。 なぜ最初はすべてが非常に正しく、あまり賢くなかったのかというトピックについて、 経験豊富で有能な図書館開発者の告白で本が定期的に登場し、よりよく考えてより長くテストすることを約束することは何のためでもありません 誰もがSun / Oracleで動作しているわけではなく、ほとんどのAPIは、いわば控えめに言っても、一貫性がありません。



APIレベルで通信する機会は比較的少ないため、メソッドのソースコードにアクセスし、バリドールと懐中電灯を使用して同僚のロジックを1行ずつ理解しようとすることがよくあります。 ミディ - クロリアンのレベルが上昇したために、コードを書くための特別な才能を持っている人がいることは秘密ではありません。2〜5行のコードを理解するには数時間または数日も瞑想する必要があります。



厳しい締め切りと変化する要件の環境では、誰もそのようなrebusに対処することはほとんどなく、「思考のないコピー＆ペースト」が生まれます。 作成されると、「脳の倒錯」が増殖し広がり始め、システムにカオスが導入され、不透明度が増加します。



したがって、管理リスト「Kill​​ Bill」の最初のメモを作成します。システムのAPIコンポーネント/モジュールの作成と共同の議論と設計を確実にするようにしてください。 API内にあるものを制御するのははるかに困難ですが、人間の顔とコードのインターフェースを実現することは、かなり達成可能なタスクです。

コードコメント

これは両刃の剣です。 コードに有用なコメントを書く能力は素晴らしい芸術です。 それらを更新します-十分な時間がないかもしれません。 そして感情的で役に立たないコメントの束を与えるために...そしてそれらを後で更新しないために-たぶん小学生でさえ。 その結果、冗長なコメントは害を及ぼすだけです。



多くの場合、特にXPの世界では、コメントなしで理解できる明確なコードの原則が実践されています。 ここで推奨される最大値は、複雑なアルゴリズムとビジネスロジックを実装するときに手がかりを残すことです。 ヒントなしで、同僚を何時間も瞑想的なトランス状態に追い込み、 悟りを 90％獲得できるようにします。



したがって、マークを付けます：条件を作成する必要があります（たとえば、規則を作成し、全員と調整する）。生成されたコードには、コードが変更されたときに更新する必要がある短い、必要かつ有用なコメントが発生します。

プログラマー間のコミュニケーション

多くの場合、開発者は忙しい人であり、壁に中傷のオブジェクト、天井にデザイナー、脊髄の破壊者、例外を自由に飛び回るタスクのコンテキストに深く没頭しています。 彼の注意をそらす-コンテキストに飛び込むには、それ以上ではないにしても、約30分かかります。 したがって、大半-引っ張られるのが好きではありません 。



それが彼らが働いている 「天才」の「悪意のある社会嫌悪者」の社会的適応の様々な方法を思いついた理由です。 たとえば、スクラムでは、これらは毎日のスタンドアップであり、各開発者は同僚全員に次のことを伝えます。

-彼は昨日何をしましたか

-今日は何をしますか

-明日何をするつもりですか



はい、これは残酷で簡単です-しかし、どうやら非常に賢い人たちがコミュニケーションを取るための最良の方法はまだ発明されていません。



あなたは尋ねるかもしれません：なぜ人々は単にタスクに近づき、議論するだけでコミュニケーションを許すべきではないのですか？ 時にはそれは本当に機能します。 しかし、多くの場合、資格が異なるため、これは危険です。 さて、経験豊富なフルスタック開発者がオペレーティングシステムのプロセスを尋ねられたらどうなるでしょうか。 彼は正しい文献を参照し、彼は何ヶ月も座ってビールと女の子を否定し、質問者はうなずきます...彼はStackOverflowで考えずに解決策をコピーします。



したがって、私たちはメモします：非常に賢い人々は、強制的に通信する必要があります。 たとえば、毎日のスタンドアップを通じて。

タスク評価コミュニケーション

はい、10,000ページのアーカイブ詳細TKを記述し、その中のすべてを設計し、タスクに分割して10年間実行できます。 しかし、働く人はほとんどいません-それは高価で、長く、すでに時代遅れのものを手に入れます。 そうでない場合はどうすればよいですか-開発者にタスクを評価するよう依頼してください。 しかし、非常に賢い人であり、しばしば経験があり、明日は要件が魔法のように悪化する可能性があることを知っており、Pi * E回の余裕を持って時間がかかります！ そして彼は正しいでしょう。



タスクの評価で悪用を「戦う」ために、2つの古く実績のある方法がよく使用されます。

1）主要開発者/部門長/テクニカルディレクターによるタスクの評価。 しかし、覚えておいてください-これらの人々はコミュニケーションをとる必要があります-しかし、合理的な時間でこれは常に達成可能ではありません...それは「傾斜」用語で愚かな表面コミュニケーションを見つけるかもしれません。

2） Planning Pokerをプレイするだけです。



実際、Planning Pokerは非常に陰湿で強力なコミュニケーションツールであり、1つの目的で機能します。人々からの問題のかなり妥当な評価をノックアウトして修正することです。 2人があまりにも異なる評価を与えた場合、彼らはチームの他のメンバーによって聞かれる議論を公に与えることを余儀なくされ、合意に達するまでプロセスが続くことを思い出してください。 そして最後に-「チーム」によって採用された評価はタスクに設定されます。Pi* E時間をプッシュすることは困難です。



私たちは、信頼できる専門家と開発者をできるだけ「結び付ける」ことを目指しています。PlanningPokerでゲームセッションを行うことをお勧めします。 開発者は十分な評価を行い、発表された時間枠内でタスクを完了することができますが、残念ながら、実際には評価の精度は資格に強く関係し、「重砲」が必要です。

デザインコミュニケーション

開発者のさまざまな経験と資格により、人間の怠、なせいで、誰かがシステムにとって必要ではなく、自分にとってより便利なことをしたいと思うことがあります。 これは、高負荷時の時限爆弾、データ量の増加などの形で発生する可能性があります。 「そして、私はここでORMをプレイします！」-モニターの近くにオリビエがいるコンソールでの新年の祝日が提供されます！







開発者にアルゴリズムをO表記言語で記述し、そのアルゴリズムの値を推定するように依頼するだけで十分のように思えるかもしれません...しかし、誰もが知っているように、これはそうではありません。 使用するライブラリがどのように機能するかは、ソースを数時間見てもわからない場合があります。 さらに、データベースがどのようにリクエストを処理するのか、どのインデックスで取得するのかが常にわからない。 そして、アルゴリズムが「複雑でもつれのない* nocode」というフレーズで囲まれた長期退職同僚の多次元パズルの包含と重複する場合...そして、負荷テストのみがアルゴリズムの実際のパフォーマンスを示します。



コミュニケーションに関しては、XPに再び根ざした原則がここでは主に便利です-比phor。 簡単に言えば、提案されたソリューションをシンプルなメタファーの形式で説明する必要があります。「これは標準コンテナによって実装される双方向リンクリストです。これはすべて、入力値をフィルタリングするための平凡なコードでハングアップします。」 そのため、内部に存在し、ほとんどの人がリスクを目にすることはすでに明らかです。たとえば、リスト内の値を検索する線形時間などです。 単純化や、同僚と公に議論されている単純なメタファーの検索を行わないと、2次アルゴリズムを使用した重い構築がコードに陥り、システム管理者やクライアントのために眠れぬ夜や週末が配置されます。



Wikiで公開表示および議論するためのメタファーを公開すると便利です。 誰でもコメントを追加したり、「来たりして」というようなコメントを追加できます。 はい、残酷です-しかし、公然と公正。



開発者は、単純なメタファーの形で公に発言します。アルゴリズムの理論、エンコードされたソリューションのすべての用語に「単純で理解可能な」ものを使用します。 アルゴリズムのコストを評価する試みが行われます-または負荷テストが計画されています。 オリビエとシャンパンを装って、大someone日に顧客の資格情報を処理するコードに誰かが静かにORMをねじ込むことを許可しないでください。

マネージャーとの開発者コミュニケーション

誰もが推測するわけではありませんが、多くの場合、プロジェクトでのこれらの役割の目標は異なります！ リッジを持つマネージャーが目標を持っている場合-プロジェクトを時間通りに開始するために、開発者は「わずかに異なる」目標を持っている場合があります。

-ライブラリAの使用を試みます。これは絶対に必要なわけではありませんが、興味深いです

-履歴書の行に言語Bを入力してください

-1人だけが理解できるアルゴリズムを実装し、カルマを増やす



これらの実験は、コードの複雑さとエントリレベルの急激な増加によってプロジェクトに損害を与え、チーム内のコミュニケーションを悪化させ、システムサポートのコストを上昇させる可能性があります。 経験豊富なマネージャーは、プログラマーの魂の中でこの「科学的エロティックな脈」を感じ、人類の特に賢明な代表者のアイデアをきれいな水に持ち込み、チームでアイデアを公に話し合うことを学ばなければなりません。 確かに、それは時々逆に起こります-革新的なアイデアがプロジェクトを助け、新しいレベルに持って行くことができ、それはより簡単で、より安く、より速くなります。 しかし、リスクの理解と評価は厳しいリリースのコンテキストではかなり難しいため、一般的な方法はここにあります：アルゴリズムを簡素化し、実績のあるライブラリとソリューションを使用し、複雑さを軽減する-残念ながら...



歴史的に、開発者は多くの場合、マネージャーをプログラミングをマスターしていない人類のあまり発達していない代表者と見なしますが、もちろんそうではありません。 正しく通信し、効果的に管理し、必要なときにリーダーになり、困難なときに肩を立てる能力は、C ++のテンプレートよりも劣ります。



それにもかかわらず、経験の浅いマネージャーは、プログラマーのアルゴリズム化された頭脳の手に簡単なおもちゃになることができ、常に警戒する必要があります。 紳士の最小セットは次のとおりです。

-個人的な紛争を起こさず、チームが決定を下し、それに従う

-開発者に特定の分野で素人の知識を押し付けないでください

-タスクの個人的な評価を要求せず、共同でまたは専門家の支援を受けてタスクを評価する

-無駄な仕事から人々をそらさないでください。創造的なポジティブな雰囲気を作り、やる気と賞賛を得ることができます。



プログラマーによってゾンビ化されたマネージャー：





チームコミュニケーションの条件

結論として、コミュニケーションを容易にするためのいくつかの便利で効果的な方法を検討します。

1）異なるプロジェクトチームと機能ユニット間のパーティションと壁が少ない

2）自発的なコミュニケーションとブレーンストーミングのためのマーカーを備えたホワイトボードの追加

3）議論を促し、問題の原因を見つける

4）パブリックディスカッションとリンチを使用して、枠組と問題の外部への出現を奨励する

結論

コミュニケーションに関連するソフトウェアプロジェクトで最も重要なリスクについて簡単に説明し、期限内に目標を達成できないようにしました。 私たちは、心理学とコミュニケーションを妨げる典型的なケースを調べ、それらの影響を軽減する方法をマークしました。 彼らは、これらのタスクが柔軟な方法論によってどのように解決されるかを調べました。 適切なコミュニケーションチャンネルと透明なプロジェクトフレームワークを提供することなく、経験豊富で素晴らしいスターワーキング天才-思わずゾンビマネージャー、バベルの別の塔を建設し、シスの領主の怒りを引き起こし、 新しい洪水が来る ... :-)チーム内で効果的なコミュニケーションを達成するために私たち全員に幸運と成功を！