チームメンバーにWebフレームワークを使用するように説得するにはどうすればよいですか？
問題はこれであり、詳細は次のとおりです。プログラマとして、彼を私の側に連れていくために私が言える/育てることができるものはありますか？
私はこれについて双方の正当な議論を聞きたいですが、主に彼と話す方法についての提案です。
私の状況は次のとおりです。大学のプロトタイプとして中規模のWebサイトを構築し、学位課程のチームプロジェクトに取り組んでいます。グループ内のすべてが平等であると見なされ、指名されたリーダーがいないため、この問題の答えは「プルランク」にはなりません。
すべてが同等ですが、メンバー間の知識には大きなギャップがあります。問題のチームメンバーと私はどちらも有能な開発者ですが、業界での経験はありません。他の3人のメンバーは能力が低く、2人は完全に開発をオプトアウトしています。知識不足のため、3人ともコメントを控えている。
私たちはグループとして、ウェブサイトの実装に使用するテクノロジーを決定します。具体的には、PHPフレームワーク（Code Igniter）を使用するかどうか）。
私は賛成で主張して、引用します：
- 車輪を再発明しない
- 動作するように作成され、テストされたコードベース
- 始めましょう（締め切りは私たちが望むよりも近いです）
- 開発のスピード
- 健全で保守可能な設計パターンと良い習慣
彼は彼が慣れている方法で働くことを支持して主張しています：
- オーダーメイドの1回限りの関数を、必要なときに「ライブラリ」ファイルに書き込む
- データアクセスとそのデータのページへのレンダリング、セッションの取得と設定、データの取得と送信などの機能
- ページごとに1つのファイルがあること（結果として、制御、プレゼンテーション、およびデータの間で懸念が分離されない）
彼がフレームワークを使用する理由は、主に彼が要点を理解できないことに基づいています。彼はそれらすべてのことをすでに行うことができます。フレームワークはそれを変更しません、それは彼がフレームワークを学ばなければならないのでそれを単に難しくします。彼は自分で書いていないコードを使いたくありません。
また、「プロジェクトはプロトタイプにすぎず、維持されることはないため、コードベースの品質は問題ではない」とも述べています。私にとって、それはメンテナンス不可能なコードを書くための言い訳はありません。
なぜ彼がそうした議論をするのかはわかりますが、彼の「保守性に対する懸念の欠如」と「優れた設計の無視」、あるいは懸念の分離についてさえ、私は問題を抱えています。しかし、彼がデザインパターンを研究したことがないのではないかと思うので、彼の方法が維持不可能であると証明できる理由を示すのにどれほど効果的であるかはわかりません。
私はこのプロジェクトを始めたいと思っていますが、長年にわたって学んだすべてのことを考慮せずにそれをやりたくありません。前に言ったように、ここにランクを上げる可能性はなく、他のチームメンバーも積極的にピッチングすることはできません。彼は頑固すぎて経験が浅く、よく知ることができませんか？それとも私はここで頑固なのですか？
TL; DR経験の浅いチームメンバーが頑固ですが、どうすれば彼を倒すことができますか？
あなたは彼にそれに話すことができないでしょう。 Dunning-Kruger effect と呼ばれます。彼は自分が知らないことを知るにはあまりにも無知であり、彼がアドバンテージと呼ぶものを失うことを恐れすぎます。
コンセンサスに到達できない場合は、代わりに妥協する必要があります。多分あなたは仕事を分割することができるので、彼がフレームワークを学ぶ必要性は最小限です。たぶん、あなたはそれぞれが数週間あなたのやり方でそれを行い、チームがどちらが最良であるかを投票するある種の「デザインオフ」を持っているかもしれません。たぶん、あなたはあなたのスポンサーの教授や顧客がその関係を解決している誰にでも参加することができます。
あなたの支持の一つの議論は知識の再利用性です。よく知られ広く使用されているフレームワーク（CodeIgniterなど）を習得したすべてのチームメンバーは、その知識を次のプロジェクトで再利用できます。一方、無計画な知識のある「ライブラリ」は再利用できません。他のチームメンバーは、このプロジェクトに関する有用で再利用可能な知識を得ることを好むため、これは他のチームメンバーとよく共感できます。
別の議論は、開発/保守コストの具体的な測定かもしれません。 CodeIgniterに精通した開発者は、同僚が独自にこれらすべての独自機能を作成するよりも速く開発できると思います。これは、あなたと彼の両方が同一のWebページ（CodeIgniterを使用して、彼自身の方法で）を作成し、完了までの時間を測定することで実証できます。次に、ページに一連の変更/拡張を加え、完了までの時間を再度測定します。もちろん、仕様は中立的な立場で戦うために、両方から独立した誰かによって準備されるべきです。
別の-あなたが言ったように-コードの品質です。 Webページの準備ができたら、それぞれに対して同じ一連の受け入れテストを実行し、バグ密度を比較します。
もちろん、時間的なプレッシャーがかかっている場合、そのような測定を停止して実行する可能性はありません。したがって、おそらくこのジレンマを迅速に解決したいと思うでしょう。他のチームメンバーを説得してみてください（たとえば、投稿の今後の回答をここに読んでもらう:-)、グループプレッシャーをかけます。最後に、彼が本当に納得できない場合は、CodeIgniterを使用して、プロジェクトを2つの部分に分割することができます。自分の能力を最大限に発揮するために自分の部分を実行することに焦点を当て、彼が望むことは何でもできるようにします。結果はおそらく自分自身のために語ります。
他の3人のチームメイトを関与させる必要があると思います。あなたはどちらも彼らにあなたの議論を提示し、彼らが理解できるように彼らに物事を説明する必要があります。結局のところ、彼らはこのコードベースでも作業する必要があります。そして、すべてが等しい場合は、何を処理したいかについて意見を述べる必要があります。
それぞれのソリューションのメリットの概要を示し、他のチームメンバーにそれが最善の方法だと思う理由を示すことは、良いアプローチだと思います。その後、彼らに決定させてください。それらが3つあるので、タイブレーカーになります。
あなたが指摘したいことの1つは、これがあなたのシニアプロジェクトであり、他のチームメンバーが他の経験がない場合、このプロジェクトは潜在的な雇用主にできることを反映する必要があるということです。あなたがそれを正しく行うならば、それはインタビューで良い話し合いのポイントになることができます。新しい卒業生に彼らの上級プロジェクトの概要と、それがどのように設計および開発されたかを尋ねるのは知っています。
彼らが他の男のアプローチで行くなら、あなたはそれを吸い上げる必要があります。しかし、希望をあきらめないでください。彼が書いている混乱がすべてに影響を与えないように、良いデザインを考え出してください。時間があれば、コードをクリーンアップしてリファクタリングし、毎回ホイールを再発明する必要がないことを示します。
大学はサンドボックスのようなものだと思います。そこで行うことのほとんどは、デプロイメントでは使用されません。そのため、実験して快適ゾーンから抜け出す自由度が大幅に高まります。失敗しても影響はそれほど大きくないので、新しいものを試してください。また、あなたの状況では、チームメンバーは、事前に知識のある人に手伝ってもらうという特別な利点があります。
他の経験豊富なチームメンバーについては、新しいことを何も学びたくなければ、大学に行く必要はありませんでした。これは、何か新しいことを学び、それを彼のツールボックスに追加する良い機会です。
また、経験の浅いチームメンバーの場合、履歴書にCodeIgniterのようなフレームワークを追加することで（実際には履歴書でそれを正当化するための知識が得られるため）、雇用/雇用される可能性が高くなります。