シェア:
){kind=small}
Alex Lakatos は Nexmo の JavaScript デベロッパーアドボケイトです。余暇には Mozilla で Tech Speaker や Reps Mentor としてボランティアをしている。オープンウェブでJavaScriptを開発する彼は、日々その限界を押し広げている。ロンドンでプログラミングをしていないときは、世界中を旅するのが好きなので、空港のラウンジでばったり会うこともある。
次のCLIの構築
CLIについてよく知らないという人のために、少し復習しておこう。CLIとはCommand-Line Interfaceの略で、テキストベースのインターフェイスを使うツールのことで、通常はTerminalのようなアプリケーションやシェルのような環境からアクセスできる。
常連の読者ならご存知だろう。 すでにCLIの代替として使用している ダッシュボード.このCLIで Vonageアカウントを管理し、コマンドラインからVonage製品を使用することができます。私たちはこのツールを4年ほど前から持っており、次のように書かれています。 で書かれています。.このツールは commander.jsフレームワークを使用しており、時間をかけて機能を追加していくうちにかなり大きくなってきた。
ツールがかなり大きくなったため、使用しているフレームワークの限界にぶつかりました。コマンダーには、エイリアス・コマンドを扱う特別な方法があり、1つのコマンドが持つことのできるエイリアスの数には厳しい制限がある。例えば nexmo app:list, nexmo apps:list, nexmo appsと nexmo alなどはすべてVonageアプリケーションをリストアップするものだ。しかし、Commanderでそれを実現するには、いくつかのコードを複製する必要があった。私たちは2つのコマンドを作成し、それぞれにエイリアスを設定しました。これは、人々が貢献するための障壁を増やしました。また、誰かが（主に私が）リリース前に両方のヘルプメニューを更新するのを忘れる可能性も高くなります。
Commanderは小規模なCLIを構築するには最適ですが、CLIの範囲や機能が大きくなるにつれて、私たちの要求のいくつかに対応できなくなりました。私たちが Applications APIを更新し、同じアプリケーションで複数の機能をサポートするようにしたとき、私たちは、コマンドのために9つのフラグを覚えておく必要はないと考えました。そこで、アプリケーションの作成プロセスをガイドする対話型のプロンプトを追加することで、CLIの開発者体験を改善しました。なぜなら Commanderは対話型モードをサポートしていないため、私たちはさらに Inquirer.jsを依存関係として取り込んだ。
私が何を言いたいか、お分かりいただけただろうか。フレームワークの制限を補うために使ってきた回避策は、CLIのメンテナンスとアップデートを難しくした。CLIは私たち全員が毎日使うものなので、かなり重要であり、私たちはそれを書き直すために時間を投資している。私たちが次のCLIアプリケーションに取り組むために使っているプロセスを共有しようと思いました。
新しいコード・プロジェクトに飛び込む前に、私たちは時間をかけて明確な構造を確認した。まず、現在のCLIを振り返ることから始めた。現在のCLIについて、いくつかのことをリストアップした。うまくいっていること", "もっと良くすべきこと「そしてやめるべきこと".以下は、私たちがこれらのコラムのために思いついたいくつかの例である。
私たちがうまくやっていること：
当社のCLIは、当社のサーバーSDKに匹敵する一流の製品です。 サーバーSDK.
CLIは、（先に述べたアプリケーション・リストのように）いくつかのことを行うための複数の方法を提供している。
もっとうまくやるべきだ：
ほとんどのコマンドでインタラクティブモード。
CSV、JSON、標準出力用のフォーマッタ。
コマンドのオートコンプリートをサポート。
サポートプラグイン。
依存関係を減らす。
私たちがやめるべきこと
その古いコードベースに鞭打つのはやめてくれ。😅
もっとうまくやるべきだ』というカテゴリーには、もっと多くのことが挙げられていたのがわかるだろう。このレトロスペクティブは、要求事項のリストを特定するのにとても役に立った。
次に、CLIに持たせたいユースケースのリストを作成した。CLIが現在サポートしているユースケースをもとに、私たちはそれらを考え出した。そして、私たちが実装したいと考えた機能要求。その中には、既存のフレームワークではコストがかかりすぎるものもありました（プラグインのサポートなど）。私たちはそれらを"ユーザーは自分のアプリケーションをリストアップできなければならない。".そして、"複数の出力フォーマット（ASCIIテーブル、CSV、JSON）が提供される。".
ご想像の通り、私たちは使用例の長いリストを持つことになった。私たちはこれらすべてを実装したいと考えていますが、一度に実装するのは逆効果で時間がかかると考えました。そこで、私たちはそれらをコア機能とプラグインを作るべきものに分類しました。さらに管理しやすくするために、すべてのプラグインに目標バージョンを設定しました。例えば、認証のユースケースのほとんどはV1で実装され、いくつかはV2に移行する予定です。 "SMSの送信"は、私たちが実装する最初のプラグインのひとつになる予定です。
要件を管理可能なリリースに分解した後、CLIのための標準をまとめました。私たちは、新しいツールで非常に一貫した開発者エクスペリエンスを構築するために、例を使用しています。これが、私たちが決めた標準のリストです：
コマンドのネーミングは、API名ではなく、ユーザーのアクションに関するものであるべきだ。
nexmo number format --number=012345678 --country=GBではなくnexmo insight basic --format --number=12345678 --country=GB.コマンド名は単数名詞である。
nexmo appまたはnexmo number.コマンドの2番目の部分は、能動態動詞でなければならない。
nexmo app createまたはnexmo number list.フラグは位置引数よりも優先される。
nexmo app update --name MyBetterNamedApp.フラグには省略形がある。
nexmo app update -n MyBetterNamedApp.ユニバーサル・フラグ
--help,--silent,--verbose,--debug,--format,--non-interactiveそして--color.ページ分割されたコマンドは
--limitと--offsetを使用する。
新しいCLIの構築は、古いCLIがあればそれを振り返り、要件を収集し、ユーザーエクスペリエンスにとって最も重要なものを見つけ出すことから始まります。CLIの次のイテレーションに何を求めるかをよりよく理解した上で、CLI構築フレームワークを特定し、要件と比較し始めた。このプロセスについては、次のブログ記事で詳しく説明する。
それまでは、CLIの改善に取り組んでいます。 https://github.com/nexmo/nexmo-cli.もし何か提案や問題があれば、GitHubやコミュニティの コミュニティ・スラック.