新しいシステムのコードを書くとき、私は決して必要としないかもしれない不必要な複雑さを設計に導入したくありません。そこで、私はここで YAGNI に従っていますが、柔軟性を高める必要があるか、責任がより明確になるにつれてリファクタリングを行っています。これにより、私はより速く動くことができます。
しかし、若手の開発者には、いつリファクタリングを行うべきか、どこで設計を構築するべきかを認識できないという問題があります。既存の設計にコードを追加するだけです。
それで、これに取り組む最善の方法は何ですか？何も追加する必要がない場合でも、追加するときに彼らが従うべき良い例になるように、より将来性のある設計をより頻繁に構築する必要がありますか? それとも、コードのレビューや教育などをさらに進める必要がありますか? または両方？
この種の問題を経験したことのある人はいますか? どのように解決しましたか？
コードレビューやペアプログラミングをお勧めします。これにより、仲間の開発者を教育し、全体的な品質を向上させる機会が得られます。
おそらく、あなたの仕事の一部はジュニア開発者の育成を支援することであることを明確に認識することから始めます. あなたが上司でない場合、経営陣はこれを承認する必要があります。経営陣は、あなたの選択が今それらを開発するか、後でクリーンアップするかであることを認識する必要があり、これにかかる時間について経営陣の支援が必要です.
コード レビューとペア プログラミングは良いアイデアです。彼らは「ジュニア向け」ではないので特に優れています。私は親しい同僚の一人と両方を行っています。私たちは共に 100 歳近くになり、70 年以上のプログラミング経験があります :-)
しかし、ここにはもっと大きな問題があります。最も効果的なプログラミング手法 (YAGNI + リファクタリング) は、後輩のパートナーには効果的ではありません。 私の経験では、人々が YAGNI の利点を学ぶには何年もかかるので、彼らがあなたのやり方を学ぶだけだと期待するなら、あなたはがっかりすることになります.
後輩のパートナーに役立つと思われる方法論を特定することをお勧めします. 特定の方法論はおそらく問題ではありません (異端!)。私は、複合/構造化設計、オブジェクトベースの設計、代数仕様 (!)、および極端なプログラミングで成功を収めてきました。しかし
後輩が誇りを持って学ぶことができ、将来のプロジェクトに引き継ぐことができるスキルとなる、名前とそれに特化したいくつかの文献があるものを選んでください.
おいしいことを示すために、ドッグフードを自分で食べる必要があるかもしれません。一緒に暮らし、生産的になれるものを選んでください。
後輩を注意深く観察し、いつ指導を求めるべきかを判断するための決定手順を教えてください。
幸運を！
彼らが後輩で、あなたが先輩であるのには理由があります。
設計の変更が必要になったときに気付く能力もその 1 つです。
私はあなたのように続けますが、物事が困難になったときに彼らがあなたのところに来るように勧めます. その後、必要に応じて設計を変更するために彼らと協力することができます。これは、リファクタリングよりも簡単であり、後輩の開発者に知識を伝えるのに役立ちます.
設計をどこまで構築するかを示す非常に良い方法は、構築したときに設計が何を行うかを指定してから、新しい機能をカバーするテストを作成することです。テストに合格すると、開発が完了します。
途中で、何かをテストするのを忘れたことに気付くかもしれません。それは問題ありません。次回より適切に指定するのに役立つ有用なフィードバックです。不足しているテストを記述し、合格するのに十分なコードのみを記述します。
次にリファクタリングします。リファクタリング時に何を探すべきかを知るには、少し練習が必要です。皮切りに
これを数十回繰り返すと楽になります。
YAGNI のもう 1 つの見方は、コードの変更は正当化される必要があるということです。
関連する単体テスト (または BDD ユーザー ストーリー、ポイズンを選択) が必要なコミットを要求することは役立つでしょうか? 意図を伝えるのに役立ち (なぜこの機能を追加するのかを人々に考えてもらいたい)、回帰テストを無料で入手できます。
また、初心者がモジュール性 (通常はコードをテスト可能にするために必要) について考え始めるようになり、後でリファクタリングが必要になった場合に大いに役立ちます。
彼らがどのような仕事をするかを計画し、それを検証して、あなたが本当に求めている判断力を構築するのに役立つかもしれません. ペアリングは 1 つのオプションですが、それほど時間を割くことができない場合は、一種の「チェックポイント」を用意して、彼らがどのように行動しているかを確認し、間違った道を進むのを防ぎます.
私はコードのレビューと教育に大賛成ですが、将来を見据えた設計も重要だと考えています。API を設計するあなたと、API を使用する若手開発者の観点から考えることができるかもしれません。このように、あなたは彼らが台無しにする大変な作業 (重複したコードを特定してそれを排除する) を行う一方、彼らはあなたの時間を生産的に使用しないすべての単調な作業を行います。
もちろん、これはジュニア開発者のスキルを開発する必要性とバランスを取る必要があります。方程式のどちらの側も無視できません。