Steel Threads は強力ですが、あいまいなソフトウェア設計アプローチです。 Steel Threads について学ぶことで、より優れたエンジニアになります。それらを使用して、統合の問題などの一般的な問題を回避できます。また、それらを使用してシステム設計の複雑さを解消できます。 あまり知られていないため、2013 年にウィキペディアから削除されました スチールスレッドはどれほど知られていないのですか?この概念は 2013 年に た。その理由は、「このアイデアはソフトウェア エンジニアリング内で注目に値するものではなく、著名な情報源からの重要な報道を受けていない」ためです。カバレッジを追加し、なぜそれが非常に便利なアプローチなのかについても説明しましょう. ウィキペディアから削除されまし スチールスレッドとは? スチール スレッドは、ソフトウェア システムを通過する機能の非常に薄いスライスです。これらは、ソフトウェア システムのさまざまな部分を織り込み、重要なユース ケースを実装するため、「スレッド」と呼ばれます。 糸が後の改良のための強固な土台となるため、それらは「鋼」と呼ばれます。 Steel Thread アプローチを使用すると、システムの境界を越えて重要なユース ケースをカバーする、可能な限り薄いバージョンを構築できます。 従来の問題のあるアプローチの例 モノリシックなコードベースの一部を置き換える新しいサービスを構築しているとしましょう。これを行う最も一般的な方法は次のとおりです。 古いコードを見て、新しいシステムのニーズを把握してください。 必要な機能を提供する API を設計して構築します。 古いコードに移動し、参照を更新して新しい API を使用します。機能フラグの後ろでそれを行います。 機能フラグを使用してカットオーバーします。 機能するまで発生する問題を修正し、必要に応じて機能フラグをオフにして、古いコード パスに戻します。 安定したら、古いコード パスを削除します。 合理的に聞こえますよね？これは、ソフトウェア エンジニアが行う最も一般的な方法ですが、このアプローチには多くの地雷があります。 このプロジェクトではどのような問題が予想されますか? 古いシステムから切り離された方法で新しいサービスを構築することは魅力的かもしれません。結局のところ、デザインはより純粋に感じるかもしれません.しかし、大幅に多くの構造変更も導入しており、古いシステムへの統合を行わずにこれらの変更を行っています。これにより、統合の問題が大幅に増加します。プロジェクトの見積もりはすべて非現実的であると私は予想しています。また、結果として得られるサービスの設計が概して優れていたとしても、プロジェクトが完了した後は失敗と見なされることを期待しています。 新しいシステムへの切り替えには問題があると思います。切り替えると一連の問題が明らかになり、古いコード パスに戻すか、プロジェクトの最終段階で問題を修正するために熱心に作業する必要があります。 これらはどちらも、大幅なカットオーバーを行わないことで回避できます。機能フラグを使用して新しいサービスへのトラフィックを 1% 以上カットすることも、カットオーバー アプローチであることに注意してください。なぜ？トラフィックの 1% をすべての変更に対して同時にカットオーバーしているのです。 それでもうまくいくとは思っていませんでした。大きすぎる手順を実行しています。 スチールねじの使用例 そのアプローチをスチール スレッドの方法と比較してください。 あなたが構築している新しいシステムについて考えてみてください。システムの Steel Threads を表すいくつかの狭いユース ケースを考え出します。それらはシステムの有用な機能をカバーしますが、すべてのユース ケースを処理しないか、何らかの方法で制約されます。 ある程度の価値を提供する、できるだけ狭い開始ユース ケースを選択します。たとえば、新しいサービスの一部になると思われる API を 1 つ選択できます。 新しいサービスで新しい API を構築します。 その狭いユースケースだけで機能するようにします。その他のユース ケースでは、古いコード パスを使用します。本番環境に移行し、完全に使用できるようにします。 (ヒント: 新しいコードパスと古いコードパスの両方を実行して比較することもできます!) 次に、必要なすべての機能を新しいサービスに移動するまで、追加のユース ケースを徐々に追加します。各ユースケースは実稼働中です。 完了したら、古いコードと機能フラグを取り除きます。すでに新しいシステムで実行しているため、これはまったく危険ではありません。 これも「絞め殺し」パターンではないでしょうか。はい。ただし、これは新しいプロジェクトにも使用できます。グリーンフィールドの例を読んでください。 スチール スレッドは統合の手間を省き、信頼性を高めます 統合の問題は、プロジェクトの土壇場での問題の大きな原因の 1 つです。新しいシステムに切り替えると、予期しない問題が 発生します。カットオーバーを伴うものはすべて疑う必要があります。物事を少しずつ行う。 常に Steel Threads は最初から統合されるため、統合に苦労することはありません。代わりに、途中で小さな統合の痛みがあります。 また、途中で段階的にテストしたため、サービスを公開する前にテストする必要はありません。生産負荷を処理できることがわかります。すでにネットワーク遅延が追加されているため、その影響は理解できます。 サービスを段階的にロールアウトする方法の一部として、すべての驚きが前進し、段階的に処理されます。 重要なことは、機能する統合されたシステムがあり、それに取り組んでいるときは、それを機能させ続けることです。そして、あなたは時間をかけてそれを具体化します。 スチール スレッドは複雑さを解消するのに役立ちます システムを設計しているときは、非常に複雑です。新しいシステムの一連の要件を構築することは、困難な作業になる可能性があります。 Steel Thread アプローチを使用する場合、コア要件のいくつかを選択し、システムのレイヤーを切り抜けて設計を実行する方法でそれらを表現します。システム全体の一種の骨格構造を提供します。 その Steel Thread の実装は、さらなる要件を構築できる骨になります。 したがって、スチール スレッドはシステムの です。 要件のサブセット スチールスレッドはグリーンフィールド作業にも使用できます Slack のクローンを実装しているとしましょう。最初の Steel Thread は次のようになります。 「認証されていない人は誰でも、ハードコードされたアカウントのハードコードされた #General Room にメッセージを投稿できます。ページを更新してもメッセージは保持されます。」 この最初のスチール スレッドがいかに限定的であるかに注意してください。認証、ユーザー、またはアカウントは処理しません。メッセージの書き込みと永続化を処理します。 2 番目の Steel Thread は、システムをより便利なものにすることができます。たとえば、メッセージの投稿者が投稿する名前を選択できるスチール スレッドを作成できます。 この 2 番目の Steel Thread は、実際にはあまり効果がありません。認証、アカウント、またはユーザーの概念さえまだありません。しかし、使用を開始できるほど十分に機能するチャット ルームを作成しました。 また、システムのすべての部分にスチール スレッドを通しているわけではないことに注意してください。しかし、ユーザーとアカウントの概念をスタブ化してしまいました。 スチール スレッドによる早期フィードバック この Slack クローンの例では、まだそれほど構築していなくても、構築中のシステムに関する早期のフィードバックを得ることができることに注意してください。これは、スチール スレッドを使用するもう 1 つの強力な理由です。 この 2 つの Steel Threads だけで、チームはチャット ルームをフルタイムで使用できるようになります。システムを使用することで、チームがどれだけのことを学べるかを考えてください。それは働くシステムです。 これを、ユーザー システムとアカウント システムを構築し、すべてを接続し、最後にチャット ルームを構築することで学んだことと比較してください。 スチールスレッドから始める 多くの場合、スチール スレッドは、プロジェクトを設計する際の出発点として適しています。彼らは、今後の作業の骨組みを作成します。彼らは、肉付けする自然な場所があるように、システムのコア部分を突き止めます. Steel Threaded アプローチを試すことをお勧めします。プロジェクトを変革できることがわかると思います。あなたの経験を教えてください！ 鋼の糸は垂直スライスに密接に関連しています 「垂直スライス」という言葉を聞いたことがあるかもしれません。このコンセプトについては、 に関する投稿で説明しています。 マイルストーン Steel Threads は、ソフトウェアを垂直スライスで提供するソフトウェア設計手法です。この用語は、システムの最初の垂直スライスを説明するために使用される傾向があります。 これらは密接に関連する概念ですが、完全に同じではありません。 スチールスレッドが「トレーサー弾」と呼ばれていることも聞いた. による からの画像 Steen Jepsen Pixabay このストーリーはもともと次の場所に掲載されていました: https://www.rubick.com/steel-threads/

このオーディオは、ストーリーの元の言語で制作されています。

長すぎる; 読むには

Making security fun one episode at a time

より良いエンジニアになる方法: 鋼の糸

長すぎる; 読むには

Jade Rubick

About Author

ラベル

Languages

この記事は...

より良いエンジニアになる方法: 鋼の糸

長すぎる; 読むには

Jade Rubick

About Author

ラベル

Languages

この記事は...

関連ストーリー