$shibayu36->blog;

クラスター株式会社のソフトウェアエンジニアです。エンジニアリングや読書などについて書いています。

TypeScriptでCLIツール作りをするためのプロジェクトサンプルを作ってみた

tech

最近TypeScriptの学習をしようと思い、何でもTypeScriptで作ってみている。今回はCLIツールを作ろうと思ったのだが、ビルド環境やeslint環境など考えることが結構あった。そこでTypeScriptでのCLIツールのプロジェクトサンプルを作りながら勉強してみた。

作成したのは https://github.com/shibayu36/typescript-cli-project 。 npm install -g shibayu36/typescript-cli-project でtypescript-cli-projectというコマンドがインストールされ実行できるようになった。

このプロジェクトサンプル作成を通して学んだことをメモしておく。

参考文献

以下2つの文献が入門として非常に参考になった。この2つの文献を参考にしつつ、公式ドキュメントを追いかけながら作成していった。

ビルドの環境を整える

TypeScriptを使うのでビルドの環境を整える必要がある。tscだけでも出来ると思うが、今回はwebpackも使ってビルド環境を作ってみた。

インストールした時にコマンドを使えるようにする

package.jsonのbinで指定されたkeyがコマンド名、valueが実行ファイルとなる。指定するファイルはshebangを設定してないといけなそう。そのためbinディレクトリ以下には、shebangとビルドしたファイルをrequireするだけのファイルを作る。

eslintとprettierとvscode

コードを書く時に何も考えたくないので、lintもかけてフォーマットも自動で行われるようにする。

  • .eslintrc.js
    • overridesを使ってTypeScriptのファイルだけ @typescript-eslint/parser を使うようにしている
    • このようにすることで、jsのファイルなどがあってもうまくeslintが動く
  • .eslintignore
  • .prettierrc.js
  • .vscode/settings.json
    • VSCodeでのフォーマットではデフォルトのフォーマットではなく、eslintのfixが働くようにしている

まとめ

今回はTypeScriptでCLIツール作りをするためのプロジェクトサンプルを作ってみた。今度作るCLIツールはこのプロジェクト構成を使って作ってみたい。

SCRUM BOOT CAMP THE BOOK【増補改訂版】を読んだ

tech book

スクラムを基本から学びなおしたいので、スクラムガイド(2017)読んだ - $shibayu36->blog;に続いて、SCRUM BOOT CAMP THE BOOK【増補改訂版】を読んだ。

SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発

SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発

Amazon

個人的に印象に残ったのは

  • インセプションデッキは単なる話し合いの機会を提供しているにすぎない。みんなで一緒にスライドを作り、認識合わせをすることが一番
  • プロダクトバックログの順序をつけるときは、直近の数スプリント分くらいに注力する。早く実現したいものが漏れていなければ問題ない
    • 今の自分のチームの優先度付をどうするかについて悩んでいたので参考になった

読書ログ

* スプリントプラニングを開始する前にプロダクトバックログリファインメントと呼ぶ事前準備が必要。プロダクトバックログの上位項目について準備する 338
    * 項目の中身を具体的にする、項目の疑問点を解決する、受け入れ基準を明らかにする、項目を自分たちが扱えるサイズに分割する、項目を見積もる、など
* デイリースクラムは問題解決の場ではない。問題が報告されたらデイリースクラム終了後に改めて必要な人を集めた別の会議を設定する。デイリースクラムはタイムボックスを守る 386
* スプリントレトロスペクティブで出たアクションアイテムのうち最低1つは次のスプリントのスプリントバックログに含める 426
* スクラムの流れの図 474 ※
* プロダクトオーナーとスクラムマスターを兼任するのは絶対にだめ 615
    * POは作るものをより良くすることに注力する必要があるので、開発チームにもっとたくさん作って欲しいなどのプレッシャーを無意識のうちにかけてしまうかもしれない
* インセプションデッキは単なる話し合いの機会を提供しているにすぎない 711
    * 自分たちの向かう先についてみんなで知るためのツール
    * 1時間半くらいでみんなでスライド一枚を作り上げるくらいの気持ちで
    * 出来る限り一緒にスライドを作る時間を確保する
* 優先順位は分類ごとに一列に並べる 808
    * 超重要、重要、ふつう、あればうれしいとか
    * 感想) 分類ごとで良い、というのは面白い
* エレベーターピッチを作る時は、メンバーごとに書く時間を取り、全員がかけたら共有しあう 1028
    * 認識のずれなどが見える化される
* プロダクトバックログの順序をつけるときは、直近の数スプリント分くらいに注力する。早く実現したいものが漏れていなければ問題ない 1614 ※
* 9人以上の人数で開発する場合、複数の開発チームで協力しながら開発を進めるアプローチを取る 2665
    * プロダクトオーナーは一人、プロダクトバックログも1つ
    * それぞれの開発チームにスクラムマスターがいる
    * プロダクトバックログが大きくなるとプロダクトオーナーの負担が大きくなる。プロダクトオーナーを支えたり横断的に問題解決したりするために、スクラムオブスクラムを行う
        * デイリースクラムの後にリーダーだけが集まって検査を行う