インターフェイスの調整によって具体的に何が調整され、作業負荷はどこにあるのでしょうか?

テクノロジーのことを理解していない IT 実務者として、「今日はインターフェイスを調整しているのですが、複数のインターフェイスを調整するのに時間がかかり、膨大な作業量のように感じます」という声をよく聞きます。そこでお聞きしたいのですが、調整インターフェースでは具体的に何を調整しているのでしょうか？仕事量はどこにあるのでしょうか?技術専門家が一般的な科学を簡単な言葉で教えてくれることを願っています。どうもありがとう！ （簡単に説明できない場合は、もっと深く説明した方が良いです。ゆっくり百科事典を見てみます（笑）、またよろしくお願いします！）

返信内容:

調停とは、あなたと同僚の間での同じニーズに対する理解の違いに関するもので、誰が最初から緊密に連携しないようにしたのかは計り知れません。これが、私がサーバーとクライアントを 2 人で作成することに反対する理由です。 IT は何年も前から存在しており、人々を CPU スーパー パイプラインとして扱うほうがよいのではないでしょうか? 最初にサーバーを担当し、それが完了したらクライアントを担当します。一時的な理由でサーバーとクライアントを一緒に作成する必要がある場合でも、何か問題が発生した場合は、常に実際のサーバーとクライアントを同時に起動する必要があります。他の人がブロックされることを心配する必要はありません。一緒に解決しましょう。

初期段階では時間が無駄に見えるかもしれませんが、長期的に見ると全体の効率は数倍向上します。

理想的な状況。

サーバー: 大丈夫です、電話してください!

クライアント: テスト通話は正常です。テストの準備ができました。

実際の（国内）状況。

サーバー: 大丈夫です、電話してください!

クライアント: 500

サーバー: 見てみましょう、ある古いコードが異常なようです。 。

(30分後)

サーバー: 大丈夫です、電話してください!

クライアント: まだ 500

サーバー: 忘れてください、古いコードをリファクタリングします。

(2時間後)

サーバー: 大丈夫です、電話してください!

クライアント: まだ 500 です。 。パラメータを変更しましたか？

サーバー: リファクタリングされました。新しいパラメーターに従って調整します。

クライアント: このインターフェースは問題ありませんが、そのインターフェースは再びダウンしています

サーバー: パラメーターを変更しました。あなたも変更する必要があります

クライアント:ドキュメントバーを作成します

サーバー: オンライン障害が発生しました。緊急に対処する必要があります

クライアント: わかりました (その後、お茶を入れて Zhihu を閲覧します)

(1 時間後)

クライアント チーム リーダー:共同デバッグは大丈夫ですか？私たちのクライアントは、できるだけ早く新しいバージョンをリリースする必要があります。あなたはとても忙しいようです

クライアント: サーバーが新しいドキュメントを提供するのを待っています

クライアント チームのリーダー: p を待って、すぐに終了してください。そうでない場合は、あなたのパフォーマンスです。 -1sになります

client :サーバー、来てください、インターフェイスをすぐに修正します、これは誰かを殺します

server:くそー、障害はまだ解決していません、10分以内にお手伝いします

サーバーチームリーダー: 障害は修正されましたか?私たちはサービスの品質を確保する必要があります

サーバー: クライアントと共同デバッグした後、後で来ます

サーバーチームリーダー: 連絡してください。障害をすぐに修正してください。そうしないと、パフォーマンスが-1秒になります

クライアント&サーバー: 私は本当にひどい犬です

インターフェイス調整の本質は「待つ」ことにある 作業量は調整中です。ソフトウェアの製造を製造ではなく開発と呼ぶのは、絶え間ない試行錯誤が必要だからです。 関連システムとのインターフェースを共同でデバッグすることになり、
0 は共同デバッグの日に同意し、開発を開始したばかりで、共同デバッグまで 2 日間待つつもりだと言いました。
1 インターフェースドキュメントは 3 つのバージョンに変更でき、各バージョンのパラメータ名は異なります。
2 予定されていた 5 つの出力パラメータが突然 2 つになりました。不具合の通知を受けてから、ロールバックして修正するのに半日かかりました。オンラインになる 2 日前には、出力パラメータは 2 つだけになりました。
3 2つのインターフェースABの呼び出し順序は国慶節の延長中に通知されましたが、10日後も順序がまだ間違っていたことが判明しました
4 オンライン検証中に、Cインターフェースを呼び出すときにDが呼び出されたことがわかりました。昨日はよく眠れませんでした
IT業界で働いている皆さん、うーん╭(╯^╰)╮ 尋ねたのは私の上司ではないですか？ 標準的なプロジェクトプロセスは次のとおりです。

PMはプロジェクト要件文書とMRDを作成します -> PMはMRDレビューのために関係者に連絡します -> デザイナーはMRDに基づいて設計図面を作成します -> バックエンドエンジニアはプロジェクト要件、MRDおよび設計図面に基づいてサーバーインターフェース文書を作成します - > フロントエンド エンジニアがインターフェイスのドキュメント レビューを実施 -> フロントエンドとバックエンドのエンジニアが並行して開発し、独立したセルフテストを実施 -> フロントエンドとバックエンドの開発が完了した後、インターフェイスの共同デバッグが行われます。実行 -> テスターがテストを実施 -> テストが完了したら、リリースしてオンラインに移行 -> オンラインサービス機能に戻る

このプロセスに従って完全に開発し、すべてのステップがうまくいけば、当然問題ありません。ただし、バックエンド エンジニアは自分自身に自信があるため、十分なセルフテストを実施しないことがよくあります (あるいはまったくテストしないこともあります)。その結果、フロントエンドとバックエンドが共同でデバッグされると、フロントエンドがデバッグされなくなります。 -end はバックエンドが利用できないことを検出し、その後バックエンドが問題を修復します (フロントエンドに問題があり、バックエンドはそれを知りません)。それについて)、プロジェクトは遅れています。同様に、インターフェイスのドキュメントが明確に記述されていない場合、フロントエンドとバックエンドでパラメーターの理解が異なるため、回数が増えるとインターフェイスやフロントエンドの実装の変更にもつながります。プロジェクトは遅れます。

このようなことはよくあることなので、通常、共同デバッグ時間にはセルフテスト時間が含まれており、このテスト時間が追加されると、当然共同デバッグ時間は長くなります。

私は、ルン兄弟の方法が良い方法だとは思いません。芸術には専門分野があり、人々のエネルギーには限りがあります。フルスタックエンジニアであっても、その人が得意とすることが 1 つあります。さらに、異なる言語や開発が頻繁にローテーションされると、多くのエネルギーが無駄になります。 、言語開発を切り替えると、開発効率も削減されます。また、大きなプロジェクトは一人で開発することはできず、複数人で共同作業する以上、たとえ同じモジュールのコードを変更した場合でも、このような問題が発生する可能性が高くなります。共同デバッグ段階ではありません。開発段階で何か問題が発生した場合、効率が低下することはありませんか?プロセスの問題は、東の壁を取り壊して西の壁を埋めるのではなく、標準化されたプロセスを通じて解決されるべきです。 まず、キー (第 4 トーン) インターフェイスではなく、キー (第 2 トーン) インターフェイスについて話していると仮定します。後者には作業負荷の問題がないからです。

前の質問に対する答えは、期限切れのパスポートを再発行するときに発生する問題に関するもので、これはインターフェイスのデバッグの問題と一致しています。

Xiao Ming (こちら側) が今海外に行きたいと考えており、パスポートを申請する必要があるとします (ビジネス要件)。

Xiao Ming は公安局の Web サイト (インターフェイス プロバイダー) にアクセスして申請ガイド (インターフェイス文書) を確認しました。パスポートの申請には次のものが必要であると記載されています:

• 写真
  
• ID カード
  

これらの資料 (パラメーター）。 Xiao Ming はオンライン (インターフェイス 1) で予約を入れ、予約番号 (インターフェイス 1 の通話結果) を取得して、戸籍のある公安局に行って申請を行うことができます。または、公安局 (インターフェース 2) に直接行くこともできますが、当日の予約はできない場合があります。

Xiao Ming さんはオンラインで予約をしようとしましたが、Web サイトには「予約が成功しました」と表示されました (インターフェイスはドキュメントと一致しません)。そしてあなたは、「よし、うまくいった」と思います (これは私たちの見落としでした)。

シャオミンは写真と身分証明書を持って公安局に行きました。その結果、公安局の女の子は両手を広げて「番号はどこですか？」と言いました。

あなたの番号は何ですか?

予約番号?

いいえ？

いいえ、それはカウントされません。それ以外の場合は、オンラインで予約して予約番号を取得するか、その場で予約することもできます。 (結果は予想と異なります。もう一度試してください)

シャオミンはそう思い、その場で予約を入れます。予約を取ろうとしたとき、別のスタッフが娘に、最近システムがアップグレードされているので、予約をしたのに番号を受け取っていない人がたくさんいるかもしれないと話しているのを聞きました。リストラ）。少女は、シャオミンが休暇を要求したために上司に犯されそうになっているのがどれほど哀れかを見て、それを放っておいて、シャオミンに今日するように頼みました（双方が解決策を交渉します）。

Xiao Ming は満足し、写真と ID カードを取り出し、証明書を申請する準備をしました (インターフェイス 2 を呼び出します)。

小さな女の子はそれを見て言いました：何をしているのですか？

写真…あれ？

いいえ、パスポートの写真は標準化されている必要があります。写真を撮るためにフォトギャラリー A に行きます。データは私たちに直接送信されます。 ）。

シャオミンは言葉を失いました。なぜあなたのウェブサイトでそれを明確にしないのですか？

その女の子は、ウェブサイトを見てみると、私たちのウェブサイトは一昨年に作られたもので、ずっと前に方針が変わった（文書が整備されていない）と言いました。

シャオミンはギャラリーAに行くしかありませんでした。

A 写真館で聞いて、ああ、写真撮れるのね、と思いました。それから彼はそれを受け取り、「わかりました。私があなたのためにそれを彼らのシステムにアップロードしますので、あなたは直接行って大丈夫です」と言いました。

シャオミンは公安局に戻りました。

妹: 待って、今日はインターネットが少し遅くて、写真が送信されていません (プロバイダー間のインターフェース呼び出しの問題)。

仕事を終える時間近くになるまで待って待って、ようやくそれができました。

妹: はい、ついにダウンロードされて、始めることができます。

シャオミンは安堵のため息をつきました。

妹: 待って、いいえ、私たちのシステム送信チャンネルは閉じられています。

シャオミン:? ? ?

妹: そうです、私たちの上司は私たちをとても愛しているので、オフィスシステムを設計していたとき、テーブルを片付けるために、30分後に仕事を終えたらビジネスチャネルを閉じるように頼まれました。そして夜にどこで食べるかについて話します。

シャオミン:? ? ?

妹: ごめんなさい、明日は早めに行きます。

シャオミンは翌日、公安局に行くしかありませんでした。

妹: ごめんなさい、昨日の夜、ポンドが急落して、突然 2,000 人以上の人がイギリスにパスポートの申請や買い物に来ました。

シャオミン:? ? ?

妹: 私たちのシステムは少し古いので、キューに 255 人以上の人がいるとクラッシュします (予期せぬ状況)。

シャオミン:? ? ?

妹: 私たちのシステム担当者が今日二度目の結婚をして、明日戻ってくる予定です。

シャオミン:? ? ?

妹: いつ修理されるか分からない。明日か明後日に電話して聞いてみてください。

シャオミンは吐血しました。

============

インターフェースの調整はこのようなプロセスです。

仕事量とトラブルは次のとおりです:

• サプライヤーの事業内容の説明が不完全。理由は次のとおりです。1. 明確に考えていない、2. 怠惰またはやる気がない、3. アップグレードまたはビジネスの変更後に対応できない、4. 意図的にトラブルを引き起こす。したがって、結果が期待どおりであるかどうかを確認するには、常に通信したり、繰り返し確認したり、インターフェイスを呼び出したりする必要があります。
• 私たちとさまざまなサプライヤーの間、およびサプライヤーと他のサプライヤーの間で協力の問題が発生し、一歩の問題が全体の状況に影響を与えます。これはいつも起こることです。私は一方通行の道路を渡るときは両方の方向を確認します。自分でうまくやれたとしても、他の人が同じことをするかどうかは保証できないからです。ロジックは同じです。したがって、待つか、和解するか、他の解決方法を見つける必要があります。

これらに加えて、特定の予期せぬ状況 (高い同時実行性など) ではインターフェースに予期せぬ問題が発生する可能性があり、これもデバッグが必要です。

これを知れば、異なる規格やインターフェース間の通信を避けた秦始皇帝の度量衡を統一するという偉業に賛同するでしょう。全世界が同じインターフェースを使用し、通信コストが大幅に削減されます。

つまり、インターフェースの調整に関して言えば、あなたは兄であり、インターフェースを調整するのはあなたであり、あなたは弟であり、自分の精神を調整するのです。

上司はパン屋に行って、ハンバーガーはありますか?と尋ねました。上司は数分以内にハンバーガーを買いに通りの向かいのマクドナルドに駆け込み、中身を新鮮な肉に置き換えて笑顔で両手でハンバーガーを掲げた。仕事の負担がなく、相手も自分に合わせてくれます。

それどころか、一人でマクドナルドに行ってハンバーガーを買い、焼きたての肉まんを買って具材を取り出し、他人の視線に耐えて黙ってハンバーガーを食べることしかできません。

仕事量は当然膨大です。 銀行にカードを申し込みに行くときと同じように 幸いなことに、私たちのチームではフロントエンドとバックエンドで実行される js を使用して、要件を移行ファイルからフロントエンド エフェクトに書き込むことができます。デザイナーが提供するデザイン成果物は、グラフィックをクリックして関連する CSS 情報表示ページを取得することなので、ラングリングの可能性はありません。