TLDR は私が 5 人であるかのようにコードを説明します

TLDR は、一般的な Jetbrains IDE のプラグインで、コードの一部が何をするかを自然な英語で説明します。 これは、開発者にとって大きな生産性の恩恵です。

TLDR は、OpenAI の Codex に基づいていますが、これは GitHub の副操縦士を強化するモデルでもありますが、コードの作成や何かの自動化を支援する意図はありません。 代わりに、自然な英語で物語を生成することにより、コードの一部が何をするかを解読しようとするため、それを読んで理解しようとする時間を節約できます。

プログラマーとしてマスターしなければならないスキルの 1 つは、コードを読むことです。 これはさまざまな形で現れます。

  • 課題を理解しようとしている学生
  • 新しい言語を学ぼうとしている初心者または上級者
  • コードを理解してリファクタリングする
  • 自分で使用するためのコードの理解
  • コードレビューまたは QA の一環として
  • 未知またはレガシーのコードベースを継承する場合
  • ソフトウェアハウスが外部委託の成果物であるコードベースを第三者に引き渡す場合

コード生成は、プログラマーの世界にとって目新しいものではありません。 Windows Forms や Macromedia Dreamweaver が登場する前から存在していました。 GUI 要素をビジュアル プレーンにドラッグ アンド ドロップし、コードを生成して、本番環境にデプロイする準備を整えます。

逆に、コードから仕様を生成することもすでに問題になっています。 たとえば、既存の (Java) API コードから OpenAPI 定義を生成する Swagger を確認してください。

AI の最近の成果によって資金提供された進化のはしごの次のステップは、コーディング支援です。 インテリジェントなコード補完、複数のソースにわたるドキュメントとコード検索、不完全なコードの自動補完、および進行中の構文エラーの明らかに。

そして、Github Copilot があります。 OpenAI の Codex に基づいて、GPT-3 の子孫である AI システムは、自然言語と、公開されているソースからの数十億行のソース コードの両方を含む大量のデータでトレーニングされました。

Copilot は、単純ではありますが自然な言語を解釈して、ユーザーに代わって完全に機能するコードを作成できるため、大変革をもたらします。 これは、ワンライナーを提案する他のコード補完ツールとは異なり、Copilot は関数全体を生成します。 副操縦士は次のことができます。

  • コード コメントと関数の名前に基づいてコード スニペットを生成します。
  • 英語以外の言語を理解する
  • 単体テストの作成、視覚的な回帰テスト、モック データの生成
  • 正規表現を書くときに提案を与える
  • Copilot Labs 拡張機能の助けを借りて、開発者はコードをあるプログラミング言語から別のプログラミング言語に翻訳できます。
    内部の仕組みを平易な言葉で説明するだけでなく、

この最後の機能はまだ実験段階にあり、当面は VS Code 拡張機能としてのみ利用できます。

あなたが Jetbrains のファンなら、Copilot と同じモデルと同じ説明コード機能に基づいた、Jetbrains のさまざまな IDE と互換性のあるプラグインである TLDR があります。 そうは言っても、誰かがこれらの両方のツールを並べて比較し、同じコードに適用したときにどちらが最良の結果をもたらすかを確認することは非常に興味深いでしょう.

私が TLDR で実行したテストの 1 つは、Intellij Community エディションと Java を使用したものでした。 (PHP の) デモを見て、いくつかの Core Java スニペットで自分で試してみた結果、かなり良い結果が得られたと言えます。 次に、そのより広い可能性を探ることにしました。 サードパーティのライブラリのインポートまたはフレームワークに依存するコードにも適用できますか?

そこで、開発中の Vaadin/Spring Boot ベースのアプリに適用しました。 最初に、ログイン ビューを作成する Vaadin の短いスニペットを分析しました。

public LoginView(){
  addClassName("login-view");
  setSizeFull();
  setAlignItems(Alignment.CENTER);
  setJustifyContentMode(JustifyContentMode.CENTER);
  login.setAction("login");
  add(new H1("Hello"), login);
}

これが私に返ってきたものです:

これでは読めないので、以下に転載します。

  1. ビューにクラス名を追加します。 これはスタイリング目的で使用されます。
  2. ビューのサイズをフルに設定します。これは、親コンポーネント (この場合は UI) で使用可能なすべてのスペースを占有することを意味します。
  3. このビューの項目を水平方向と垂直方向の両方で中央揃えにします。
  4. ログインボタンには「ログイン」というアクションがあります。 これは、ユーザーがクリックしたときに何が起こるべきかを知るために Vaadin Flow によって使用されます (詳細は後述)。
  5. 最後に、2 つのコンポーネントを追加します。テキスト「Hello」を含む H1 要素と、以前のログイン ボタン コンポーネント (TextField と PasswordField を含む) です。

次に、Spring のセキュリティ構成で試してみることは興味深いことだと思いました。Spring のセキュリティ構成は正しく理解し、その意味を解読するのが難しいことで知られています。

http.csrf().disable().authorizeRequests().
antMatchers("/timologio/**").authenticated().and()
.requestCache().requestCache(new CustomRequestCache())
.and().authorizeRequests()
.requestMatchers(SecurityUtils::isFrameworkInternalRequest).
   permitAll()
.and().formLogin().loginPage(LOGIN_URL)
 .permitAll()
.loginProcessingUrl(LOGIN_PROCESSING_URL)
.failureUrl(LOGIN_FAILURE_URL)
.defaultSuccessUrl("/homepage", true)
.and().logout().logoutSuccessUrl(LOGOUT_SUCCESS_URL)
.clearAuthentication(true)

(興味深いことに、Vaadin が内部で処理するため、Spring Security の csrf 保護を無効にします。)

これは結果の転写です。

  1. CSRF 保護を無効にします。
  2. Vaadin アプリケーションが提供される URL へのすべてのリクエストを許可します。
  3. 不正なアクセス試行を保存し、ログイン後にユーザーを最初に要求されたページ (またはデフォルトのページ) にリダイレクトするカスタム要求キャッシュを構成します。
  4. すべての内部フレームワーク リクエスト (静的リソースなど) を許可します。
  5. ログインページの URL と Vaadin サーブレットの URL (それぞれ /login と /vaadinServIet) に一致するものを除いて、他のすべての要求を認証する必要があります。
  6. ログイン フォームは /login から提供され、HTTP POST メソッドを使用し、ユーザー名とパスワードのパラメーターを名前とともに送信する必要があります。 失敗した URL は「/login?error」で、LoginView クラスのエラー ビューにマップされます (以下を参照)。 認証が成功した後、認証されていないリクエストのためにこのフィルター チェーンにリダイレクトされる前に、「/homepage」またはユーザーが最初にリクエストしたものにリダイレクトします (/homepage は MainView クラスにマップされます – 以下を参照)。

ただし、1つの観察事項…「(詳細は後で)」または「-以下を参照」が何を指しているのかわかりません。

それは的を射ていたと言えます! 本当に非常に印象的です…次回、そのようなセキュリティ構成のワンライナーに出くわしたとき、どこに頼ればよいかがわかります。 ただし、無料版は制限があり、1 日に 2 回しか試行できないため、これ以上のスニペットで試すことはできませんでした。 明日までに別の 2 つのコードを実行する必要があります。おそらく、より精巧なコードの一部でしょうか、それとも複雑な正規表現についてはどうでしょうか?

ここでの取引は、コードを読むことはそれを書くことよりもはるかに難しいということであり、このようなアシスタントは、理解するのに必要な時間を短縮する上で価値があることが証明されるでしょう.

Copilot と TLDR の両方に関する懸念の 1 つは、プライバシーの問題です。どちらも、コードでペイロードとして呼び出される API を公開しているためです。 結局、コードを解釈する AI はサーバー上に存在します。 私は彼らのプライバシーポリシーを読んでおらず、悪意のあるスパイ条項がないことはかなり確信していますが、製品を本番環境で使用したい人は最初に確認する必要があります.

結局のところ、問題は、プログラマーの将来はどうなるかということです。 私たちは職業として運命づけられていますか? AIも私たちの仕事を奪うでしょうか?

OpenAI の長期的な野望は、Copilot や TLDR にとどまりません。 ユーザーが自然言語を使用して API を制御することを望んでいます。 これは、たとえば、Google などの検索エンジンで行うのと同じ方法でデータベースにクエリを実行する場合に非常に役立ちます。SQL を記述する代わりに、母国語で文を入力してデータベースにクエリを実行します。 これにより、データの専門家がレポートやダッシュボードをより迅速に作成できるようになるだけでなく、技術者以外のユーザーがソース データにアクセスできるようになります。

コーダーの仕事が消滅するという話は、今に始まったことではありません。 AIが登場する前から、何度も言われてきました。 悪役はローコード ツールとノーコード ツールで、コーダーを冗長にします。

しかし、違いは、コーダーとソフトウェア エンジニアという用語の間にあります。 コーディングは脅かされるかもしれませんが、エンジニアリング ソフトウェアはそうではありません。 エンジニアリング ソフトウェアとは、要件の理解と改良、ビジネス ロジックの翻訳、アーキテクチャの考え方、
設計図に戻り、点を結び、テストし、デバッグし、展開し、最適化します。

代わりに、Windows フォーム GUI ジェネレーターが行ったように、生産性を向上させるツールとしてこれらを検討することをお勧めします。
確かに、ボタンやチェックボックスをコードで作成することもできましたが、GUI ツールを使用するとより速く作成できるのであれば、そうではありませんか?.
そのため、生産性が向上しただけでなく、仕事の退屈な部分から解放され、ビジネス要件の翻訳や検証などの最も重要な側面に集中できるようになりました。

Python や Java などの高水準言語により、C のみを使用していたときよりもプログラミングがより簡単になり、より多くの開発者がアクセスしやすくなります。これらのツールは同じことを目指しています。 高水準言語は仕事を減らしたのではなく、増やしました。

結論として、ここで認識すべき重要な点は、AI はエンジニアリング ソフトウェアに必要な推論と幅広いスキルに対処できないということです。 しかし、それは間違いなく有用な支援になる可能性があります。

とりあえずTLDR楽しみ。

詳しくは

Jetbrains マーケットプレイスの TLDR

関連記事

GitHub Copilot による生産性の向上

GitHub Copilot – あなたのプログラミング仲間

開発者の日を台無しにするもの

バナー

.

Leave a Comment

Your email address will not be published. Required fields are marked *