私は、現在のプロジェクトで新しい開発者の家庭教師を務めることになっています。
技術的、ドメイン固有の項目、および社会的観点から、プロジェクトにすばやく参加するための最良の方法は何ですか
私はかなりの数の TDD 支持者がペア プログラミングについて話しているのを読みました。経験豊富なチーム メンバーがテストを書き、新しい人が実際のコードを実装し、その後交代します。
あなたに最適なのは何ですか？
2220 次
9 に答える
5
ビール！
社会的な観点から、新しい人が来たときはチーム全員でビールを飲みに行くのが好きです。ビールが苦手ならボウリングかロックバンドか何か。
あなたが少しリラックスした後、彼らは質問をしたり、慣れたりするのがずっと快適になるでしょう.
于 2009-02-27T11:43:03.087 に答える
5
テクニックの組み合わせがあります：
まず、アプリケーションの機能を理解する必要があります。陳腐に聞こえるかもしれませんが、私はトレーディング アプリケーションで働いてきました。たとえば、マーケット メーカーは、金融市場がどのように機能し、何が行われるかについての多くの知識に基づいて構築されているため、マーケット メーカーが何をしているのか理解するのに長い時間がかかることがあります。彼らはそうします。「スプレッド」のような用語には、あらゆる種類の想定された知識が組み込まれています。
これは、誰かにチュートリアルやユーザー マニュアルを渡すのではなく、インタラクティブに行う必要があります。また、これは非常に重要ですが、ユーザー ユーザーは を運転する必要があります。見るのではなく、マウスとキーボードを使用すると、筋肉の記憶と根深い反応が構築されます。そうすれば、定着率が大幅に向上します。また、「ここをクリックしてこれを実行してください」と言うのではなく、その場で「ここで何をしますか」と尋ねてください。
新しい人は、あなたとあなたの既存のチームが持っているすべての履歴に汚染されていないため、この方法でアプリケーションの使いやすさについて有益な洞察を得ることができます。
誰かにすべてを教えることはできませんが、アプリケーションをナビゲートして簡単なタスクを実行できるように十分に説明してください。
次に、アーキテクチャの概要を説明します。これに 1 時間か 2 時間以上かかる場合は、詳細が多すぎます。彼らはただそれを忘れるでしょう。建築設計書を渡すよりも、実際に顔を合わせて話し合う方が良いと思います (通常、人々の目を眩ませるだけです)。
最後に、時間的に重要ではない小さな比較的簡単に修正できるバグを提供します。これにより、コードのチェックアウト、ビルド、デプロイ、実行などの基本に慣れることができます。新しいコードでは常に問題が発生するため、単純であることが重要です。コードなどを適切にビルドするには、適切な環境変数を設定する必要がある場合があります。彼らに複雑な問題を与え、何か問題が発生した場合、彼らはその環境が何か間違ったことをしているなどの理由であるかどうかを理解するのに迷います.
言うまでもなく、これを理解するために彼らを隅に置いておくことはできません. 彼らが行き詰まらないように、誰かが彼らを監視する必要があります。これは、彼らの性格についての良い洞察も与えてくれます。彼らはフリーズしますか？彼らは助けを求めますか？彼らはそれを試してみますか？彼らはあまりにも簡単にあきらめますか？
同時に、彼らはコードについて学んでいます。
于 2009-02-27T11:48:05.537 に答える
4
初心者にコードのバグを修正してもらいます。
それは双方にとって好都合です。コーナーに置いて、自分のペースで作業できます。彼らには目的があります。5分でタスクを設定できます。
于 2009-02-27T11:36:39.387 に答える
4
自然な傾向は、広く始めてドリルダウンすることであり、その結果、多くの長い導入の話になります。新しい人はそれをほとんど覚えていません。プロジェクトの歴史、高レベルのアーキテクチャなどに時間を無駄にしないでください。
それらを経験豊富な人とペアにして、1 つの問題に取り組みます。作業内容のコンテキストについてジャスト イン タイムの説明を提供します。その際、歴史的/文脈的な情報がどこにあるかを示して、釣り方を教えます。カーネルから理解を構築するときに、人々は最もよく学びます。人々は、事前の「足場」情報をあまり保持していません。
于 2009-02-27T11:52:18.897 に答える
2
12月に新しい仕事を始めたばかりなので、このプロセスはまだ頭に浮かんでいます:)。
私が遭遇した質問は次のとおりです。
これは何をし ますか？
- 私が取り組んでいるアプリケーションの目的は何ですか?
- そのターゲット ユーザーは誰で、どのような問題を解決しますか?
- どうやって使うの？
仕事はどうすればいいですか？
- ソース管理には何を使用しますか?
- バグ追跡には何を使用しますか?
- 日常的に誰とやり取りするのですか？(他の開発者、QA、ドキュメントなど)
- 他に知っておく必要のあるツールやプロセスはありますか?
どうすればそれを構築できますか?
- ソース管理で必要なソース コードはどこにありますか?
- これを構築するには、どのような手順を踏む必要がありますか? (理想的には、それは 1 つのステップであるべきですが、ほとんどありません!)
このすべてのものは何ですか？
- システム アーキテクチャの概要を教えてください。（あまり詳細ではなく、主要なプレーヤーの非常に基本的な説明です）
- ソースコードのディレクトリ構造はどのように設定されていますか? 何がどこに行くの？
これらすべての質問に回答したら、作業を開始する準備が整いました。
新しいコード ベースに慣れるための最善の方法は、より多くのコンポーネントに徐々に触れられるように構造化された、明確に定義された分離されたタスクに取り組むことです。また、行き詰まったり、さらに情報が必要になった場合に備えて、いつでも質問に答えてくれる人がいることが重要です。
ここでの私の経験はこれまで素晴らしいものでした。私が取り組んだことの順序は次のとおりです。
- いくつかのマイナーなバグを修正
- 恐ろしく設計された 2 つの異なるダイアログ ボックスを再設計します。
- 製品の COM API と対話するサンプル コードを記述します。
- まったく新しいモジュールをゼロから作成し、それを製品に統合する
于 2009-02-27T15:04:44.503 に答える
2
私は次のことをするのが好きです：
- システムのデモを行う
- 添付のフローチャート/設計を使用して、高レベルの概要を説明します
- ある特定の領域について、開発者に詳細な説明を提供します。
- その分野で彼らに仕事（簡単な仕事）を与えてください。
いくつかのバグを修正することは、これを行うための優れた方法です。
彼らがその分野に慣れてきたら、あなたはそれを拡大し、小さな機能などを提供し始めます.
これらすべての主なポイントは、彼らが製品と環境に慣れることです。
于 2009-02-27T11:42:02.743 に答える
0
- 必要な KT を 1 日か 2 日与えます。
- 逆プレゼンテーションを取得する
数日間、バグを修正するよう依頼してください。
また
新しい参加者をバックアップ リソースとしてモジュールに配置します。彼が示す自信に応じて、徐々に主要なコアワークを開始するように依頼してください。
于 2009-02-27T11:46:53.530 に答える
0
メイン プロジェクトと同じプラットフォームを使用して作成された社内ツールはありますか? もしそうなら、プラットフォームへの良い紹介は、新しい人に、あなたがしばらくの間望んでいたツールにいくつかの改善を加えてもらうことです.
于 2009-02-27T11:35:28.377 に答える
0
既存のプロジェクトに参加するとき、次の場合に参加しやすいと思います。
誰かがアプリケーションの動作を見せてくれ、何をすべきか、何が行われるかを説明し、私の最初の質問に答えてくれます。
優れたドキュメントを入手できるので、プロジェクトの基本を自分で見つけることができます。
私の質問に答えてくれる人がいます。
于 2009-02-27T11:35:33.883 に答える