アプリケーションをゼロから設計する際に、ジュニア開発者をどのように関与させるのが最善ですか？
私たちは3人の開発者（2人の経験豊富な開発者と1人のジュニア）のチームです。
私たちは真新しいプロジェクトを始めました。アプリケーションを設計し、適切なアーキテクチャを選択することに集中して取り組み、コードの最初の行を配置します。その中核、つまりアプリケーション全体の基盤となるものを書いています。
これも簡単なアプリケーションではありません。厳しいパフォーマンス要件、大規模に分散された複雑なエンティティモデルなど。
私たちは皆、特にジュニアの快適ゾーンの外にいます。彼は優れたデザインを事前に作成する経験がありません。私と他の開発者が助けを求めており、私たちは両方ともメンタリングとチームの構築を信じているので、それは問題ではありませんが、私たちはそれを行うための最良の方法が何であるかを正確に知りません。楽しい経験とスキルの最大量を学びます。
新しいプロジェクトには後輩がいないことに気づき、既存のプロジェクトでは後輩が学習し、刺激するための完全なコードベースを持っていたので、後輩にとっては簡単でした。しかし、このアプリにはほとんどコードがありません。始めたばかりです。
私たちはいくつかのアプローチを考えていました：
- 彼に数日間自分で試してもらい、コードを介入させて一緒にリファクタリングし、正しい方向に導いてから繰り返します=>すべてのリファクタリングで彼の間違いを指摘するので、彼にとって楽しい経験ではないかもしれません;
- プログラミングを私たちの1人とペアにする=>彼は単なる「傍観者」になり、実際に多くの情報を学習したり、多くの情報を要約したりせずに、私たちのすべてに同意するかもしれません。
- 各モジュールのスケルトンを構築し、しっかりとしたデザインで、不足している部分を追加するようにモジュールを彼に与えます=>私たちの後にピックアップするのは面白くなく、ギャップを埋めることにのみ注意を払うというリスクがありますデザイン全体ではありません。
彼をどうにかして設計に関与させて、彼がどういうわけかそれの外に残されたと感じないようにして、彼が経験から多くを学び、自分で試してみるのに十分な自信を得ることはできますか？
次のガイドラインをお勧めします。
- デザインミーティングにジュニア開発者を参加させ、彼の意見を求めます。これにより、高レベルのデザインを自分で行う準備ができていなくても、全体像を考えることができます。
- ジュニア開発者に割り当てるアプリケーションのモジュールを分離して明確に定義するようにしてください。モジュールの入力/出力およびその他の要件を書面で説明します。簡単にテストできないモジュール、または他のまだ作成されていないモジュールと統合したときにのみテストできるモジュールを彼に割り当てないでください。
- おそらく、ジュニア開発者は、コアアプリケーションのコーディング以外の方法で支援することができます。たとえば、テストコードを作成できます。単純な作業ではなく、優れたテストスクリプトを作成することは、プロジェクトに貴重な貢献をし、また、ジュニア開発者にプロジェクトをしっかりと理解させます。
それは、ジュニア開発者にどの領域を改善してほしいかによると思います。私が（非常に）ジュニアだったとき、彼らは私に次のような特定の制限されたものを構築するために必要なAPIを与えていました：
- この関数は、PersonnelテーブルからN人の要員を提供します
- この関数は、個人のIDを指定して、個人統計を提供します
->
タスク：人事レコードがクリックされたときに彼/彼女の統計を表示する人事のリストを含むページを作成します。これは、プロジェクトで以前に作成した簡単なサンプルページです。
与えられたタスクの最も重要な側面は、与えられたリソースによってのみ解決可能であり、それらを変更する必要がないことです。
3つの方法すべてが私によく見えます。実際に10種類のアジャイル方法を同時に試してみると、すぐに良い結果が得られるはずです。少なくとも、どちらが機能し、どれが機能しないかがわかります（どちらが最も効果的かは、プレイヤーの性格に大きく依存します）。
ケントベックによって最初に記述されたプロセスに従って、タイピング/シンキングハットが10分（またはそれ程度）ごとに切り替わるプロセスに固執する場合、ペアプログラミングの問題は発生しません（私はどこか覚えていません）
設計に他の人を巻き込むことに関しては-設計段階でいくつかの設計文書（UMLモデルを含む）が作成されると役立つことがわかりました。他の人々（あなたの後輩）は、それらを校正して読み、レビューし、悪魔の擁護者を演じることができます。独立した手付かずのサードパーティのこの役割は、実際には非常に有益です。探索的テスト用- http://www.softwaretestinghelp.com/exploratory-testing-beyond-traditional-testing-boundaries