機能の半分を実装するための適切なアプローチを学ぶにはどうすればよいですか？
私は開発チームを主導しており、できるだけ頻繁に製品をリリースしたい（継続的デリバリー）。
多くの場合、リリース間の時間よりも実装に時間がかかる機能を実装する必要があります。私はまだ人々に彼らのコードを日常的にコミットして欲しい（継続的インテグレーション）。
多くの場合、新しい機能を実装するには、既存の機能を変更する必要があり、新しい機能がまだ完成していない場合でも、既存の機能はもちろん機能する必要があります。
開発者が正しいアプローチを使用する場合、既存の機能を注意深く調整でき、上記のすべてが問題になることはありません。
しかし、IS正しいアプローチは実際にありますか？プログラミングに同調している私の心は、個々のケースに対して何をすべきかを教えてくれますが、もっと学ぶ必要があり、私が読んだり、読んだりできる資料が必要ですチームメンバーに本を読んでもらうか、このアプローチを学ぶ正しい方法を学ぶ他の方法があります。
それが問題です。 機能の半分を実装するための正しいアプローチをチームメンバーが確実に学ぶにはどうすればよいですか？
私はこれに関して戦略を持っていると主張する人々を探しましたが、トピックについていくつかのランダムな考えを書いている人々を除いて、まだそれを見つけていません。おそらく、私は正しい検索語を使用していないか、おそらく誰もこれについて信頼できるガイドラインを作成していません。
私はここの他の答えとは異なる見方をしています。開発者からの変更をできるだけ早く統合し、組み合わせたコードの組み合わせをテストし続けることに同意します。
ただし、コードを出荷する権利が今朝開発されたことには同意しません。それは失望した顧客のためのレシピです。
解決策は、バージョン管理ツリーにブランチを用意し、検証済みのデルタを開発ブランチからリリースブランチに昇格させる別のプロセスを用意することです。
そうすることで、両方の長所を最大限に活用できます。継続的な統合を行う開発者がいて、それによってもたらされる利点、定期的に顧客に出荷される安定したコードがあり、開発者ブランチで完成した機能をテストする新しいプロセスがあり、テストに合格すると、リリースされた製品の一部になります。 。
この種のプロセスを適切にサポートする、私がよく知っている2つのツールがあります。開発構造が単純な場合、git-flowを使用したgitは、中小規模のチーム（おそらく20人の開発者）で適切に機能する適切な分岐構造を実装します。
大規模な開発チームの場合、または製品の複数の「スピン」をサポートするためにより複雑な分岐戦略が必要な場合は、accurrevが最適です。変更の管理に関与していない開発者は、サブバージョンなどよりも難しいと文句を言いますが、複雑な開発環境をサポートしています。
ここには2つの問題があります。1つは機能の半分を実装しています。もう1つは、継続的な開発中に出荷製品を機能させ続けることです。
機能の半分を実装
強力な包括的な設計がこれに役立ちます。これにより、境界が明確に定義された機能を実装できます。たとえば、コードの隣接ビットへのAPI、データ構造に関する期待、実装されたコードがいつどのように呼び出されるかを理解できます。
テストには、機能の他の部分のコードのモックアップバージョンを含めることができます。これにより、後半を実装する際の移行がスムーズになります。
出荷中の製品を機能させる
ここにはいくつかのオプションがあります：
- 出荷された製品で機能を「オフ」にします。コードが製品に含まれているからといって、コードを実行またはユーザーに提示する必要があるとは限りません。欠点は、ユーザーに付加価値を提供することができず、フィードバックが得られないことです。
- 機能のエッジをユーザーに明らかにします。あなたが持っているものを示し、これから何が起こるのかについていくつかの指標を提供してください。
- ユーザーが新機能と旧機能を切り替えられるようにします。これには、エンドユーザーが使用できる2つのコードパスを維持する必要がある場合があります。
最後に、これらのソリューションのいずれかに問題がある場合は、機能を正しい境界に沿って分割したかどうかを検討してください。別の方法でスライスした場合、バラバラにした方が簡単ですか？
ここであなたに役立つ最大のことは、コードのある領域が他の領域に干渉しないように、懸念事項を適切に分離することです。
これは、インターフェイスへの依存性注入とプログラミングの使用が本当に役立つ場所であり、サイトにISupportingFeatureの現在の実装を用意し、別の実装に依存するINewFeatureを作成する必要がある場合は、新しい実装を行い、十分にテストされて稼働する準備ができるまで、既存の実装を本番環境で維持します。 DIがなんらかの構成システムで機能していると仮定すると、システムで同じコードを並行して使用でき、常に安定したコードを使用できます。
実際、この構成アプローチは、Martin Fowlerによって Feature Toggle。 と説明されています。
もちろん、問題は、コードのallallをすべて展開する場合にのみ発生します。これはまさに機能ブランチが設計されたシナリオのタイプであり、ファウラー氏がそれらに眉をひそめていることは認めますが、それらがそれほど計画的で考えられたもので作成され、使用されている場合は特に、それがそれほど悪いことだとは知りません。途中で。
チームメンバーが機能の半分を実装するための適切なアプローチを確実に学習するにはどうすればよいですか？
それらを教えることによって。 （ええと）
学習には反復が含まれます。何かを試し、それがどのように機能するかを確認してから、より良い結果を達成するためにアプローチを変更します。この種のものについては、私はデザイン/コードのレビューを提唱します。ハーフ機能がどのように設計/実装されているかを確認し、フィードバックを提供する機会を得ます。 「これはCIを壊してしまうので機能しません。XYZはどうでしょうか？」、「こんにちは、とてもきれいです。」
チームでレビューを行うと、誰もがあなたがすでに直感的に知っていることを学ぶのに役立ちます。