機能の半分を実装するための正しいアプローチをどのように学ぶのですか？[閉まっている]

開発チームを率いて、できるだけ頻繁に製品をリリースしたい（継続的デリバリー）。

多くの場合、リリース間の時間よりも実装に時間がかかる機能を実装する必要があります。私はまだ人々に毎日コードをコミットしてもらいたい（継続的インテグレーション）。

多くの場合、新しい機能を実装するには、既存の機能を変更する必要があり、もちろん、新しい機能がまだ終了していない場合でも、既存の機能を動作させる必要があります。

開発者が適切なアプローチを使用する場合、既存の機能を慎重に調整でき、上記のすべては問題ではありません。

しかし、実際には正しいアプローチは何ですか？私のプログラミングに慣れた心は、個々のケースごとに何をすべきかを教えてくれますが、さらに学ぶ必要があり、読むことができ、チームメンバーに読んでもらうための読み物が必要です。または、このアプローチを学習する正しい方法を学習する他の方法でも実行できます。

それが問題です。機能の半分を実装するための適切なアプローチをチームメンバーに確実に学習させるにはどうすればよいですか？

これに関する戦略を持っていると主張する人々を検索しましたが、トピックについていくつかのランダムな考えを書いている人々を除いて、まだ見つけていません。おそらく、私は正しい検索語を使用していないか、おそらく誰もこれに関する権威あるガイドラインを作成していません。

私はすでに他の回答とは異なる見解を取っています。開発者からの変更をできるだけ早く統合し、組み合わされたコードの組み合わせをテストし続けることに同意します。

しかし、今日の午後にリリースするという理由だけで、コードを出荷する権利が今朝開発されたことには同意しません。それは失望した顧客のためのレシピです。

解決策は、バージョン管理ツリーにブランチを作成し、検証済みのデルタを開発ブランチからリリースブランチに昇格させるための別のプロセスを用意することです。

そうすれば、両方の長所を最大限に活用できます。継続的インテグレーションを行う開発者がおり、それがもたらす利点により、顧客に定期的に安定したコードを配布し、開発者ブランチで完成した機能をテストし、テストに合格した場合にリリース製品の一部にする新しいプロセスがあります。

この種のプロセスを適切にサポートする2つのツールがあります。開発構造が単純な場合、gitはgit-flowを使用して、中小規模のチーム（おそらく20人の開発者）で適切に機能する優れた分岐構造を実装します。

大規模な開発チームの場合、または製品の複数の「スピン」をサポートするためにより複雑な分岐戦略が必要な場合、accurrevが最適です。変更の管理に関与していない開発者は、サブバージョンなどよりも難しいと文句を言うでしょうが、複雑な開発環境をサポートしています。

ここには2つの問題があります。1つは機能の半分を実装することです。もう1つは、継続的な開発中に出荷製品を機能させ続けることです。

機能の半分を実装する

強力で包括的な設計がこれに役立ちます。これにより、境界を明確に定義して機能を実装できます。たとえば、隣接するコードのAPI、データ構造に関する期待、実装されたコードがいつどのように呼び出されるかの理解などです。

テストには、機能の他の部分のコードのモックアップバージョンを含めることができます。これは、後半を実装するときに移行をスムーズにするのに役立ちます。

出荷製品の動作を維持する

ここにはいくつかのオプションがあります。

1. 出荷された製品の機能を「オフ」にします。コードが製品に含まれているからといって、それを実行したりユーザーに提示したりする必要があるわけではありません。欠点は、ユーザーに付加価値を提供できず、フィードバックが得られないことです。
2. ユーザーに機能の端を明らかにします。あなたが持っているものを見せて、来るべきもののいくつかの指標を提供してください。
3. ユーザーが新機能と旧機能を切り替えられるようにします。これには、エンドユーザー対応の2つのコードパスを維持することが必要になる場合があります。

最後に、これらのソリューションのいずれかで問題がある場合は、適切な境界に沿って機能を分割したかどうかを検討してください。物事を別の方法でスライスした場合、バラバラになりやすいでしょうか？

機能の半分を実装するための適切なアプローチをチームメンバーに確実に学習させるにはどうすればよいですか？

それらを教えることによって。（だよ）

学習には反復が含まれます。何かを試して、それがどのように機能するかを見てから、より良い結果を得るためにアプローチを修正します。この種のことのために、私はデザイン/コードレビューを提唱します。半機能がどのように設計/実装されているかを確認し、フィードバックを提供する機会があります。「これはCIを壊してしまうので機能しません。XYZはどうですか？」、「ここでの仕事は本当にきれいです。」

チームとしてレビューを行うと、誰もがあなたがすでに直感的に知っていることを学ぶのに役立ちます。

ここであなたを助ける最大のことは、可能な限りコードのある領域が別の領域に干渉しないように、懸念を適切に分離することです。

これは、依存関係の注入とインターフェイスへのプログラミングを使用すると本当に役立つ場所です。そのため、サイトでISupportingFeatureの現在の実装を行うことができ、異なる実装に依存するINewFeatureを作成する必要がある場合は、十分にテストされ、稼働する準備ができるまで、実稼働環境で既存の実装を維持します。何らかの構成システムでDIを使用していると仮定すると、システム内で同じコードを並行して使用し、常に安定したコードを使用できます。

実際、この構成アプローチは、Martin FowlerによってFeature Toggleとして説明されています。

あなたが展開している場合はもちろん、問題が発生するすべてのコードのすべての時間のを。これはまさに機能ブランチが設計されたタイプのシナリオであり、ファウラー氏がそれらに眉をひそめることは認めますが、特に計画および思考で作成および使用される場合、それらがそれほど悪いことはわかりません。方法で。