多くの人々が使用する大規模で複雑な製品を開発する会社のプログラマーであると想像してください。 この製品は長年市場に出回っており、会社にとっては大金を稼いでいます。 あなたはすでにそのようなプログラマーである可能性があります。 新しい開発サイクルごとに、製品の新しいバージョンをリリースし、以前のバージョンよりも優れていることを望みます。 さらに、新しいコミットごとに、作業中の製品がどんどん良くなることを願っています。



新しいバージョンが良くなったか悪くなったかをどのように評価できますか？ または、編集内容がまったく影響しなかったのでしょうか？ 結局のところ、会社にとって最も重要なことは、新バージョンの製品がどれだけお金をもたらすかということです。



同じ「より良い」または「より悪い」を測定するために使用できる、多かれ少なかれ明確なメトリックがいくつかあります。

1. コードの行数 。
2. 修正されたバグの数。
3. ユーザーが必要とする新しい機能がいくつ追加されたか。
4. 製品の生産性がどの程度向上したか。
5. 製品がどれほど便利になったか 。
6. 製品の品質指標（分類の精度、ランキングなど）がまったくある場合、製品の結果はどの程度改善されますか
7. その他の様々な指標 。

しかし、上記の質問に答える人はいません。



いつか人類が各コミットの金銭的貢献を測定できるメトリックを発明すると想像してください。 そして、たとえば、各リビジョンの反対側のリポジトリログで、ルーブルまたは別の通貨での数値を見ることができます。これは、このリビジョンがどれだけ会社のお金をもたらしたかを意味します。 まあ、または会社がどれくらいお金を失ったか。



この日は、すべてのプログラマにとってブラックデイです。 結局のところ、このようなメトリックは、ロボットプログラマーをトレーニングするための理想的な目的関数です。

しかし、どのように？

あなたの会社が改訂の金銭的貢献を評価する自然な方法を持っているなら、あなたは不運です。 これは、たとえば、違反を記録して罰金を記録するシステムで車の番号を分類する精度です。 この場合、車の数とさまざまな違反の確率の分布を知っていれば、未払いの罰金の形で何ルーブルが分類エラーの各割合を与えるかを推定できます。 誤って書かれた罰金からどれだけのお金を失うかを見積もるのは少し難しくなります。 そして今、あなたはそのようなシステムの開発者です。 分類器の精度を評価するために、多数の画像の選択肢があります。 そして、編集を行い、100％の精度で分類の完全性を80％から90％に上げました。 いくつかの数字を掛けて、ルーブルであなたの修正の費用を得てください 。



ただし、ウェブサイトやモバイルアプリケーションを開発している会社で働くことができ、主な収入は広告のインプレッション/クリックから得られます。 この場合、特定の改訂の貢献度を評価することはより困難です。 ただし、製品の全バージョンをすぐに評価してみてください。 たとえば、 A / Bテストを使用すると、新しいバージョンで得られる広告クリック数を評価し、新しいバージョンのコストをルーブルで取得できます。



各バージョンのライフサイクルが長い非常に重いデスクトップ製品をリリースする場合、このような評価を行うのはさらに困難です。 しかし、純粋に理論的には、A / Bテストに似た手法を考え出し、どのバージョンが最も売れているかを確認できます。

より多くの遺伝学が必要です

上記の最後の2つのケースでは、製品のバージョン全体の見積もりを取得しました。 しかし、特定のコミットを評価するにはどうすればよいでしょうか？ 一度にいくつかの方法を考えることができます。

1. 各コミット後にビルドし、「before」と「after」の2つのバージョンを互いに比較します。 この場合、編集のコストをバージョンのコストの差として決定できます。
2. 安定したバージョンを取得し、開発バージョンからのランダムコミットでビルドを試みます。 アセンブリが成功した場合、前の段落と同様に、編集のコストを同様に決定できます。 別のオプションは、開発バージョンを使用して、ランダムな編集を破棄することです。
3. 通常、編集のランダムなサブセットを取得し、それらを使用してビルドをビルドし、相互に比較するか、いくつかの修正バージョンと比較することができます。 この場合、特定の編集のコストを決定するには、バージョンコストの差を取り、「勝った」バージョンにあった編集にボーナスを追加し、「負けた」バージョンにあった編集にペナルティを追加します。
4. 最後に、編集のさまざまなサブセットを横断して突然変異させる遺伝的アルゴリズムを定義できます。 そして、どの編集が最も「勝利」につながるかを決定します。

すべてのケースで、多くの失敗したビルドがあります。 この場合、たとえば、未ビルドのビルドの一部である場合、編集に追加のペナルティを追加できます。



そして、さらに進んで、1つのコミットの評価から特定のコード行の評価に移行することを妨げるものは何もありません。 たとえば、コミットのコストをそれに含まれるすべての行に分割します。

Kpi

これで、リポジトリ内の各コミットにコストを追加する自動システムを構成できます。 おそらくすぐではなく、テストに何らかの遅延が必要です。







マネージャーの夢​​が叶いました！ リポジトリログを開き、開発者のどれが会社のお金をどれだけ持ってきたか、またはどれだけのお金が損害を与えたかを確認します。 ボーナスを書くことができ、敗者を解雇することができます。 しかし、さらにクールなのは、各従業員がすべての編集および部下の編集のコストの一部を受け取る会社でピラミッドを構築することです。 長いライブネットワークマーケティング！



コミットとタスクの間に接続を追加しましょう。 この場合、これらのタスクの経済的効果を評価することが可能になります。 そして、開発者だけでなく、アナリストや他のマネージャーもピラミッドに追加できます。 そしてそのように、コードの最も価値のある場所で見つかったバグの数によってテスターを追加することを妨げるものは何もありません。

ロボットプログラマー

誰かが本当にコードをルーブルで評価するための適切な関数を思いついたとしましょう。 ソースコードとターゲット変数のサンプル（各行のコスト）に機械学習法を適用し始めるとどうなるか想像してみてください。



編集が経済的にプラスであるかどうか、およびその程度を予測できる分類子またはリグレッサーをトレーニングできます。 お気に入りのIDE用のプラグインを作成できます。これにより、先ほど書いた行が赤い波線で強調表示され、「この編集で98.7％の確率で42ドルの罰金が科せられる」という警告が表示されます。 または、コミットする前に同様の警告を出すバージョン管理システムのプラグイン。



しかし、最悪なことに、 ニューラルネットワークは、ソースを見るだけでコードを生成する方法をすでに知っています 。 そして、そのような非ネットワークを追加する場合、目標は最も価値のあるコードを生成することですが、なぜプログラマーが必要なのでしょうか？ もちろん、彼らはすでに遺伝子プログラミングの助けを借りて同様のことを行おうとしており、問題はホラーストーリーよりも進んでいないと主張することができます。 しかし、機械学習の分野における現在の開発のペースでは、ロボットプログラマーがあなたの人生の間に現れないことを確信することはできません。

あとがき

「最初の波」では、最初のロボットプログラマーが登場するとき、彼らはまだそれらを書く人を置き換えることができないことが望まれます。 いずれにせよ、初めて。 それでは、機械学習の学習を開始します。 幸いなことに、インターネットには無料の資料がたくさんあり、ロシア語には少しでもあります。