Habré（および実際のITライフ）には、次の形式の多くの質問があります。

• すべてがそのように機能する場合、システム（またはアプリケーションの依存関係）を更新する必要がありますか？
• アプリケーションでテスト（自動テスト）が必要ですか（時間と顧客のお金をテストに費やしていますか）。
• パターンと強調表示の抽象化に意味はありますか（結局、この種のコードはコードを広め、パフォーマンスの低下につながります）。

以下のすべての例で重要な質問は、何を開発しているのかということです。製品またはサービスですか。 奇妙なことですが、商品やサービスに関するこの質問に答えるとすぐに、テストや抽象化などの必要性についてのすべての疑問が生じます。 自分で落ちます。

規約

それらには根本的な違いがあります。製品は完成し、販売することができ、その存在を忘れます。 サービスの場合、買い手と売り手は長い間通信します（サブスクリプションと同様に、これがまさにサービスです）。

製品の例：

• 橋の建設。 実際、橋は建設され、委託された（これは基本的に重要なステップです）が、建設会社はそれを忘れていました。 現実には、まだ建設の保証がありますが、実験の球形性のために、それは存在しない（または非常に短い）ふりをする方が良いです。 建設中に、プロセスの計画を変更することは絶対に非論理的です（たとえば、インポートされたフェンスを返却し、別のより効率的なフェンスを購入するなど）。
• 販売スツール。 すべてが橋に似ていますが、最も重要なことはこの非常にスツールを販売することです。 その後、売り手は非常に長い時間（少なくともほとんどの場合）買い手を忘れます。
• アパートの販売（特に流通市場）。 ここでも、最も重要なことは、最初の数ヶ月でアパートがバラバラにならないようにアパートを売ることです。 そして次に何が起こるか-売り手は絶対に問題ではありません。

サービスの例：

• 銀行サービス。 クライアントは月に一度サービスの代金を支払い、銀行は今月中サービスを提供します。 クライアントと銀行は、少なくとも1か月間、そして多くの場合数年間、お互いを覚えています。 クライアントはすぐにサービスを拒否するため、非流動資産を販売することは意味がありません。
• タクシーサービス（Yandex Taxes、Gettなど）。 旅行が完了したという事実にもかかわらず、企業は、戻ってきた顧客に対して、通常の顧客に対して大部分のお金を稼ぎます。 したがって、ここでの関係は長いため、最初の購入（爆撃のスタイル）で購入者を欺くのは意味がありません。
• スーパーマーケット。 繰り返しますが、売り手と買い手の間の通信時間は、一時的な利益よりもはるかに重要です。 そして、これは、甘やかされて育ったパンを売る代わりに、店がバッチを利用するほうがより有益であることを意味します。 そうしないと、バイヤーは最後にパンを購入し、店にはまったく来ません。 さらに、ブリッジを使用した例とは異なり、スーパーマーケットが「リファクタリング」を実行することは絶対に普通です-棚がどれくらい効率的に立つかなどの分析

製品とサービスの違いを知る必要があるのはなぜですか？

アイデアは単純です：プログラムを製品と見なす（つまり、最初のリリース後にプログラムとの接続が中断される）場合、 テスト、リファクタリング、またはコーディングスタイルへの準拠のいずれでも余分な時間を無駄にすることはありません 。 結局のところ、時間をかけて「完全に」それを行うと、製品の価格が上昇するだけです。 そして将来、これらの抽象化は単にあなたにとって必要ではなくなるでしょう（結局のところ、あなたはプログラムでの作業をやめるべきです）。

ただし、ユーザーにサービスを提供する場合（たとえば、Facebookに似たものを作成する場合）、依存関係を更新するためのタスクがあり、関数を追加/削除するためのタスクがあります。したがって、長期的なリスクを軽減するため、テストが行​​われます。 さらに、少なくとも将来新しいロジックを組み込むためには、抽象化を強調する必要があります。 全体として、開発をサービスと見なす場合、依存関係を更新し、テストを記述し、抽象化を強調表示し、その他の多くの作業を行ってレガシーを回避し、将来のエラーのリスクを最小限に抑える必要があります。

マニュアル：自分の手でレガシープログラムを作成する方法

この記事の文脈では、開発中のほぼすべてのソフトウェアから非常に簡単にレガシーを作成する方法の式を導き出すのは非常に簡単です。この式に従って、このプログラムの開発者自身は何の助けもなしに成功します。 公式は単純です。 レガシーソフトウェアを入手するには、サービスソフトウェアの開発を製品を作成しているかのように参照する必要があります 。

または言い換えると、サービスの開発に参加していることがわかった場合（つまり、このプロジェクトに長期間参加する場合は、プロジェクトに新しい機能を数年間追加し、新しい現実に適応させます）、プロジェクトを本当にレガシーにしたいという要望があります新しいOS /ハードウェアなどで動作できない変更を加えるのが非常に難しいプログラムがあります）、プロジェクトを製品として扱い始めるだけです。 各リリースを最後のものと考えてください。 「よく売れたバージョン」という言葉をより頻繁に使用します。 コードを処理する代わりに、小さな松葉杖とハッキングを可能な限りアクティブにします。 そして最後に：より多くの手作業（TeamCity / Jenkinsを忘れてください）、およびコードでドキュメント、仕様、またはさまざまなコメントを書くことはありません。

ソフトウェアに対する態度を文字通りわずかに変更すると、それ自体がひどい遺産になり、さらに自分で作られてしまうのは非常に興味深いことです。

利点：プログラムをレガシーにしない方法

しかし、奇妙なことに、ひどいソフトウェアを手に入れないためには、月に1回、四半期に1回質問する必要があります。 私が作っている製品は製品またはサービスですか。 そして、少なくともしばらくの間、この答えを覚えておいてください。 将来的には、テスト、リファクタリング、ドキュメントなどに関する質問は、それ自体ではなくなります。

例：

• すべての依存関係の更新とすべてのリリースで絶えずクラッシュするテストで何をすべきでしょうか？ そして、彼らはビジネスに落ちません。
  
  
  • 製品プログラムの場合：これらの問題のテストを単純に削除することをお勧めします。 それと同じように、彼らからはすでに利益よりも多くの問題があります。 そして将来、誰もそれらを必要としないでしょう。
  • サービスプログラムの場合：テストの修復/修正を行って、偽陽性の応答を減らします。 テストの各修復は私たちの時間ですが、これらのテストの存在は、将来エラーを見逃すリスクを減らします。
• Spring Boot 2にアップグレードする必要がありますか、それとも1.5にとどまることは理にかなっていますか？
  
  
  • 製品プログラムの場合：厳密にはそうではありません。 プロジェクトは間もなく終了し、このお客様には二度と戻りません。 このプログラムをサポートしたり、新しい機能を追加したり、セキュリティを修正した新しいJavaにアップデートしたりする作業はありません。
  • サービスプログラムの場合：厳密にはい。 結局のところ、このバージョンは1年でサポートされなくなります 。 さらに、無料のJavaで実行するには、すぐにJava 11にアップグレードする必要がありますが、Spring Boot 1のいくつかのモジュール（少なくともASM）はJava 9+バイトコードをサポートしていません。
• 製品の技術文書を更新する必要がありますか？
  
  
  • 製品プログラムの場合：支払われますか？ そうでない場合は、「保証期間内」に修正する必要があるエラーが含まれている可能性があるため、完全に削除することをお勧めします。 ドキュメントがなければ、エラーはありません。
  • サービスプログラムの場合：もちろんはい。 数年後、このドキュメントは、新しい開発者がすべてがそのように機能する方法と理由を説明する必要があるときに非常に役立ちます。

製品またはサービスがITアウトソーサーを販売している

アウトソーシング業者は技術的にはIT会社であるという事実（さらに、実績の主な部分はIT関係者です）にもかかわらず、プロジェクトの最も重要なステップは次のとおりです。

• 顧客と署名した契約
• 顧客は「受け入れ証明書」に署名しました（または別の方法で-完成品が販売されます）

つまり、会社の従業員の他のすべてのアクションは、これらのポイントのみを中心に展開します。 そして、アウトソーシング業者が開発しているものに直接影響を与えるのは、まさにこれら2つのこと、つまり製品またはサービスです。

たとえば、商品はしばしば政府の注文のために開発されます。 決してサービスを提供しません（ただし、これも起こります）。 したがって、そのようなプロジェクトでは、ドキュメントを作成し、プログラムを高速化する（つまり、顧客を満足させる）理由はありません。 したがって、ルールを取得します。アウトソーシング会社でソフトウェアを開発、テスト、または構成する場合、契約に署名した後に契約を忘れると、テスト、ドキュメント、抽象化の強調などについて考えることすらありません さらに、ミドルマネージャーに「ソフトウェアを改善する」ようにアドバイスすると、彼はなぜこのことを原則的に考えているのかを完全に理解しません。 結局のところ、企業はリファクタリングから利益を得られないだけでなく、開発者が時間を費やし、何を理解していないかという事実から非常に大きな損失を被ることがよくあります。

さらに、アウトソーシング会社がそのようなソフトウェアを注文する場合、プログラムを安全にするインセンティブを持たないことがよくあります（将来、90年代に行ったように、いつでもブロガーに行くことができますか？そして、顧客はとにかく損失を被ります） ）

なぜレガシーなのか？

記事を読んだ後、意図せずにアイデアが生まれます。結局のところ、これらのアイデアはすべて非常に単純です。 なぜレガシーソフトウェアを入手するのですか？ ある会社/チームがサポートしやすい製品を持っているのに、他の会社/チームがスローダウンするプログラムを持っているのに、開発者がサポートに多くの時間を費やすのはなぜですか？

（多くの）答えの1つは、製品またはサービスとしてのプログラムに対するチームの人々の態度です。 さらに、このコンテキストでは、チームはソフトウェア開発に関与したすべての人々、つまりテスター、開発者、アナリスト、および管理者であるということを理解することが重要です。 すべての人々の合計位置は、チームの位置を示します。 そして、それは「商品を売る」または「サービスをする」ようなものです。

チームがサービスを開発するが、それを製品のように扱う場合の競合の例：

• プロジェクト参加者がこのプロジェクトでの長い仕事に興味がない場合。 たとえば、ある人が近い将来に会社を辞めることを計画している場合があります。 または、会社の離職率が高い（人々がチームからチームに頻繁に切り替える場合を含む）ため、プロジェクトの参加者がこのプロジェクトに自分自身を関連付けない場合があります。 つまり 6か月後に他の人や他のタスクで機能することがわかっている場合、現在のプログラムに投資するポイントは何ですか？ ドキュメントを書く理由、自動テストを行う理由など ただ速くして、加速された5年間のプランにボーナスを獲得し、他の場所で仕事をする方が良いでしょう。
• チーム/会社のニンジンとスティックの方法は、新しい製品の作成と古い製品の交換についてより頻繁に報告する方がはるかに有益であるように構築されています。 これは、会社のすべてのボーナスが「製品Aが作成された」または「製品Bがやり直された」という事実に対して授与され、「製品Cが絶えず進化して収益を上げている」ためではない場合に発生します。 この場合、すべての合理的な人々は長い期間を避けます（このため、彼らはニンジンを与えません）。 主な違いは、プレゼンテーションでは、動詞の完成形がプロジェクトに関連して事前評価されることです（つまり、プログラムが完了し 、プロジェクトが完了しました ）。長いものではなく（サービスはお金を稼ぐことができ、チームはインフラストラクチャを提供します）。
• そして、標準的な妨害行為（または仕事のセキュリティ ）を忘れないでください-よく知っている製品のドキュメントを作成する理由は何ですか？ 結局のところ、そうでない場合、マネージャーは簡単にあなたの代わりを見つけるでしょう。 ソフトウェアサポートで生活を楽にするのはなぜですか？ 結局のところ、ソフトウェアサポートが非常に簡単な場合、他の人に置き換えることができます。 この点は、売上高の大きい会社を説明する最初の点と非常に交差しています。 ただし、条件付きの「ジョブセキュリティ」は商品やサービスの概念とほとんど共通していないことを理解する価値があります。これは多くのプロセスの良い説明であることが多いため、言及するしかありません。

チームが実際に製品を作成するが、それをサービスとして扱う逆競合の例：

• ビジネスの誤解。 非常に正直なアウトソーサーでさえ、顧客がプロジェクトに支払う金額と、最小限の実行でどれだけの費用がかかるかの差が、顧客が受け入れる準備ができていることを認めることはめったにありません。 つまり、主な収入は、長期的に貯蓄するのが不合理な場所を貯める機会です。 ここで競合が発生します。中間管理者が「世界で最高のソフトウェアを開発している」と顧客に伝えた場合、開発者はこれらすべてを額面どおりに取り始めることができます。
• 彼らはいつもそうしました。 エンタープライズJava開発者（その後10年にわたって改善および補完されるサービスを作成する）のチームに「ポイントAからポイントBにファイルをコピーするための一時的なサービスを作成する」タスクが与えられると、この最も単純なサービスが複雑になりすぎる可能性が高くなります。 はい、ファイルをコピーしますが、コピー自体は10層の抽象化の背後に隠されます（ 数か月後-11日間 ）。

言語と技術に対する商品とサービスの影響

多くの場合、どのプログラミング言語が優れているかについて多くの議論があります。 またはどのテクノロジーが優れています。 奇妙なことに、それらの多くは、当事者がプログラムが何であるか-製品またはサービス-について異なる理解を持っているという事実のために発生します。

1回限りのタスク（たとえば、いくつかの条件と最小限の変換を使用してポイントAからポイントBにファイルをコピーする）がある場合、長いサポート用に設計されたテクノロジを選択するのはかなり愚かなことであり、長い下位互換性を提供します。 このようなタスクには、Go / Pythonが最適なソリューションです。

逆もまたしかりです-タスクが（頻繁なセキュリティ更新などで）長いサービスを提供することである場合、後方互換性、更新の容易さ、パッチ適用の容易さなどのプラットフォームの利点が最初に現れます。 Hello Worldを選択した言語で書くのが簡単か難しいかは、このようなプログラムは数年に1回作成されるため、すでにまったく重要ではありません。

そして、それを使用する方法は？

結論として、プログラムが製品とサービスの両方になりうるという事実の使い方。

1. 月に一度、あなたがしていることを覚えておいてください：製品またはサービス。
2. 製品を開発しようとしないでください。 彼らは一度それを売って、それを忘れます。 このアプローチは、ビジネスにとって非常に理解しやすいものです。 「メイド-忘れられた」システムで作業します。
3. サービスプロジェクトを商品として扱わないでください。 ユーザーと長い間コミュニケーションを取ります。この場合、一時的なメリットよりも、長期的な協力がユーザーにとってより重要です。