確かに、キャリアのさまざまな段階にいるすべての人がそのような問題に直面しています。タスクを見て、それは単純で要件が明確であるように見えますが、それを別の方法で実装する必要があることがわかりました。実装に時間が費やされ、締め切りはすでに迫っていて、タスクは実際には準備ができていません。おそらく締め切りに違反して、その場で書き直さなければなりません。人件費が失われ、費用がかかります。この問題が1人の開発者ではなく、会社全体にある場合、延滞タスクの塊が増え、開発コストが増え、ビジネスが戦略を実行できなくなり、会社は損失を被ります。
何が問題ですか？
この問題は、タスクへの没入が不十分なために発生します。多くの理由が考えられます、ここにそれらのいくつかがあります：
- 最新の文書の欠如;
- ビジネスプロセスの誤解。
- 要件の詳細は完全ではありません。
- 人的要因（知識の源とパフォーマーは同じことについて話しますが、彼らはそれを異なって理解します）;
- パフォーマーと顧客の個人的な不注意。
- およびその他（それぞれが独自の方法でレーキを踏んだ）。
タスクへの没頭が不十分な結果として、開発者は間違ったことを行うか、完全に行わないか、テスターは間違ったことを行い、開発者は間違ったことを行い、SREを間違ったパラメーターで監視します。
これはどのように修正できますか？
以前の職場では、次の作業アルゴリズムを見てきました。
- 情報の収集と要件の形成。
- チームは、共通の解決策を模索し、考えています。
- タスクを実行する実行者が任命されます。
- コードレビュー;
- 修正;
- テスト;
- その他の修正;
..。
- その他の修正;
- 待望のタスク完了。
, , ?
, , , , . 
テクニカルソリューションの説明は、開発開始前でも行われ、チーム全体でレビューされます。わかりやすく、知覚を向上させるために、テキストをグラフィックスキームで希釈することにしました。このアクションの目的は、落とし穴を特定し、適切なツールを選択し、他のシステムノードと正しく対話し、チーム全体をソリューションに没頭できるようにすることです。期待した結果は、人件費の削減とビジネスプロセスのエラーでした（将来的には、ビジネスロジックのエラーは実質的になくなり、多くの技術的なエラーが回避され、修正が短縮され、タスクを完了するための平均時間が大幅に短縮されました）。また、すでに記述されているコードよりも、テキストによる説明や図を編集する方がはるかに簡単で高速であることがわかりました。
その場合、作業アルゴリズムは次のようになります。
- 情報の収集と要件の形成。
- チームは解決策を模索し、考えています。
- 責任ある開発者が任命されます。
- 開発者は技術的な解決策を説明します;
- 次に、この技術的解決策は、主題分野に没頭しているチームや他の人々によってレビューされます。
- そして、決定が合意された後にのみ、開発者はコードを書きます。
- コードレビュー;
- テスト。
実装自体の前に技術的な解決策を説明することがなぜそれほど重要なのですか。
- ソリューションのロジックがレビューされ、エラーは設計段階で修正されます。
- 開発者は、実装前にドメインを深く掘り下げます。これにより、アーキテクチャについて事前に検討することができます。
- 隣接する部門は、APIがどうなるかをすぐに理解でき、並行開発を開始する準備ができています。
- 実装に応じて同僚のニーズを明確にします。
- ( , , ).
Exness?
Exnessに来て、私はすぐにチームに慣れ、インフラストラクチャを研究し、戦闘ミッションの解決を開始したいと思いました。最初の大規模なタスクでは、蓄積された経験を使用して、問題を誤って解決するリスクを最小限に抑えることにしました。サービスの相互作用を説明するために、シーケンス図、アルゴリズムの操作を説明するブロック図、およびデータベーススキーマを説明するER図を使用することにしました。
ダイアグラムを描く過程で、問題を解決するために必要なサービスを同僚から学び、彼らへのリクエストとデータベース内のデータを確認したので、それがどのように機能するかをすでに理解しました。ダイアグラムを作成するのにそれほど時間はかかりませんでした。ダイアグラムを確認しているときに、有益なフィードバックを受け取りました。
- フロントエンド開発者は、どのような場合に、バックエンドからどのようなデータとステータスを受け取るのかを知りたがっていました。
- QAは、可能な限り多くのケースをカバーするために、サービスのデータがどこから来ているのかを理解する必要があります。
この図では、例外と、それらがどのように「アウト」するか、および使用されるデータソースについて詳しく説明しています。これにより、機能がどのように機能し、何が期待できるかを同僚に視覚的に示すことができ、同僚は私の実装を待たずにパーツの実装を開始できました。フロントエンド開発者は、サービスがどのように応答し、統合の作成を開始できるかを知っていました。QAには、サービスがさまざまな状況にどのように応答するか、およびこれらの状況を再現する方法に関する情報がありました。その結果、タスクの開発と没頭は非常に高速であることが判明し、描画された図は開発中のサービスのドキュメントを補足しました。
例
以下に説明する例は、さまざまな状況を組み合わせたものです。
新しい開発者は、文言でタスクを受信した「 延滞アプリケーションを拒否するための新しいmicroserviceを書く。ステータスの変更について顧客に通知します。」
技術的な詳細を明確にすると、次のような問題を理解できます。
- マイクロサービスを構築し、その中に1つのPOSTを作成します-reject_old_requestsという名前のAPIメソッド。
- このAPIメソッドでは、データベースからデータを取得し、リクエストでユーザー、ステータス、日付でフィルターを指定する必要があります。
- リクエストごとに、リクエストを管理するサービスのステータスを変更します。
- 次に、通知サービスにリクエストを送信して、アプリケーションのステータスの変更についてユーザーに通知します。
このタスクのシーケンス図は次のようになります。
また、発生する可能性のある間違い：
- 新しいマイクロサービスでは、アナリストはリクエストを処理するためのマイクロサービスの通常のAPIメソッドを意味する可能性がありますが、そのようなシナリオを認識することは困難です（私の実際では、アナリストが正しい用語に適応しなかったことがわかっている限り、アナリストが通常のAPIメソッドをマイクロサービスとして理解した場合がありました）。
- アプリケーションにサブアプリケーションまたは関連アプリケーションがあり、その存在を新しい開発者が知らない可能性があり、アナリストは報告を忘れて、開発者が自分で情報を取得することを期待する可能性があります。
- おそらく多くのアプリケーションがあり、販売でのそれらの拒否には長い時間がかかります。この場合、横になってバックグラウンドで拒否できるようにする方がよいでしょう。
- — , . , .
全体として、そのようなエラーの存在は実装を実行不可能にする可能性があるため、そのようなソリューションは最初から書き直す必要があることがわかります。
開発前に技術的なソリューションを作成し、明確にするためにシーケンスダイアグラムを使用すると、そのレビュー中に、対象領域に没頭している同僚がエラーを確認して指摘できるようになります。そして、おそらく開発者自身がいくつかの問題を確認し、レビューの前にそれらを修正することができるでしょう。
確かに、問題の解決策を話すだけでは、問題を正しく解決することはできません。一方は正しく表現できず、もう一方は正しく理解できず、タスクは正しく実行されません。シーケンス図は特効薬ではありませんが、多くの場合、詳細を明確にするのに役立ちます。
修正後の図は次のようになります。
チャートの用途は何ですか？
すべての人が考えを紙にうまく伝えることができるわけではないので、グラフィックの説明でテキストを薄める方が良い場合があります。タスクのより明確な説明は、開発者だけでなく、開発者と同じ没入問題に直面するテスターにも役立ちます。テスターは、肯定的な結果をチェックするだけでなく、システムがどのような状況でも正しく予測どおりに応答することを確認する必要があります。そのような場合をエミュレートするには、システムで何が変更されたかをよく理解する必要があります。チーム全体としては、ドキュメントを図やさまざまなスキームの形式で保存する方が便利な場合があります。ドキュメントは簡潔であり、大きな変更を加えると、テキストによる説明よりも編集にかかる時間が短くなります。主要なリファクタリングでは、システム内の特定のノードを誰がどのように操作しているかをすばやく理解できるため、チャートは不可欠です。チームリーダーにとっては、時間と後輩の同僚の没頭時間を短縮し、それに応じてタスクをより正確に計画できるという点で便利です。ある開発者から別の開発者にケースを転送する場合、それぞれ時間コストが削減され、バスファクターの状況が改善されます。
どのような結論を導き出すことができますか？
シーケンス図は、あなたとあなたの同僚の時間を節約する非常に強力で便利なツールです。視覚的な説明により、理解が容易になり、技術的な実装に深く踏み込むことなく、ソリューション自体に集中できます。しかし、そのような視覚的な説明がすべての問題からの救済であるとは決して言えませんが、それはそれらの重要な部分を解決するのに役立ちます。
ダイアグラムは間違いなく役立ちます：
- プロジェクト/タスクへの没頭の質と速度。
- バスファクターで状況を改善します。
- 技術文書を維持するための人件費を削減します。
- 同僚間のケースの転送を簡素化します。
- 問題を解決するロジックは実装の開始前でもレビューされるため、実装、テスト、およびコードレビューの人件費を削減できます。多くのエラーを回避できます。
私の個人的な慣習では、図は不可欠なツールであり続けています。
また、作業を最適化するツールを見つけてください。最後までお読みいただきありがとうございます。
PSこのプラクティスを使用する場合は、コメントに書き込んでください。どのツールを使用しますか？