ユーテリティのランニングコストの重さを知った
まえがき
当記事では、eslint、prettier、その他開発に関わるツール群が持つランニングコスト、特にメンテナンスコストについて論じます。
トピックはeslintに設定していますが、具体的にeslintについて述べる訳ではない点にご注意ください。
要約
イチから環境作るのはそこまで難しくないが、管理するのはとても大変。
フレームワークやcreate-(react/next/etc)-app等、纏めてあるものを使うのが無難。
目次
ランニングコストへの無理解
Reactを学び始めた当初、筆者はcreate-react-appを使うことにひどく抵抗がありました。よくわからないものがよくわからずに動作していることへ、強い忌諱感を抱いていたのです。
ダニング・クルーガー曲線で言うところの「完全に理解した」状態だったのもあり、またReactはフレームワークでなくライブラリである、という言説にシンパシーを抱いていたのもあって、自力で環境を構築することにこだわりを持っていたのです。
また、環境を構築さえしてしまえば、後から使いまわせるだろうからこれは、楽するために苦労しているだけなのだ、と考えていました。
この、後から使いまわせるだろうから、という予想が当たっていてもあり、外れてもいてもあることに、気づいていませんでした。
メンテナンスコストの認知
「完全に理解した」状態から一年ほど経ち、「なにもわからない」状態へと遷移した頃です。
私は大量のコンフィグファイルの管理に塗れていました。
ぱっとあげられるものでも以下があります。
- .eslintrc.json
- .prettierrc.json
- .editorconfig
- .lintstagedrc.json
- commitlint.config.ts
- tsconfig.json
- tsconfig.build.json
- tsconfig.test.json
- webpack.config.ts
- webpack.dev.config.ts
- jest.config.js
使用ツールとしては、以下になるでしょう。
- eslint
- prettier
- lint-staged
- commitlint
- tsc
- webpack
- jest
開発をより有意義に行おうと様々なユーテリティを導入していった結果、コンフィグは複雑怪奇の様相を呈するようになりました。
特にひどいのはeslint周りです。prettierとの連携、各種react、typescript用の追加ルールの適用等、様々な要素が絡み合ったコンフィグとなっていました。
ひとつ行を間違えただけで上書きする順番が変わり、動作不良に陥ってしまう。こんなじゃじゃ馬を管理するのは骨が折れます。
それでも、必要ならばすべきです。必要は絶対的なルールであり、至上命題でもあります。
ただ、筆者が行っていたイチからの開発環境の構築は、使いまわすこと前提に作ってしまっており、またその寿命はひどく短いものでした。
なぜなら上記の７つのライブラリ・ユーテリティの更新を追いかけ続ける必要があり、それだけでも大変なのに、その更新に合わせてコンフィグを調整し続ける必要があったからです。
これをして、ようやく出来上がるのはただのテンプレート。筆者はそこでようやく、自分が無駄なことをしているのに気づきました。
やはりIssue駆動か
事前にテンプレートを用意しようとして、そのメンテナンスコストに筆者は失敗しました。
対象のプロジェクトに応じて、それに最も適切な開発環境を立てるのがよいでしょう。
問題が発生したときにこそ、その場その場で必要なユーテリティを用意すればよいのです。
しかし、テスト環境、リント環境など、ほぼ全てのプロジェクトが要求する環境というものはあります。
それらを都度用意するのは骨が折れますが、かと言ってテンプレートを用意しようとして筆者は失敗しました。
Issueを生まないためのOOTB
OOTBとは、Out of the boxの略です。
テンプレートは欲しい、しかしテンプレートを用意する工数は捻出するのは難しい。そうであるならば、一つコマンドを叩く、ないし一つインストールするだけで動く、まさにOOTBなプリセット環境を利用すればよいのです。
プリセット環境は、初期時点で発生しやすいIssueを先んじて潰してくれる非常にありがたいものです。
それと同時に、Issueを生まないということは、テンプレートを作成する工数だけでなく、Issueをさばく工数をも減らしてくれます。
結果的に浮いたコストは間違いなく開発を推進してくれることでしょう。
それは初期コストだけでなく、テンプレートを自力で用意した際と比較すれば、テンプレートを調整するランニングコストをも浮かせることができます。
react環境において、最も有力なプリセット環境としてはnextが挙げられます。
無論nextはプリセット環境だけでなく、ロジックの最適化やプロジェクトの健全化にも役立ちますが、eslintのルール定義なども行ってくれるのでプリセット環境の側面から見ても魅力的です。
このように、各プロジェクトに応じたプリセット環境を探すことが、より健全なプロジェクトの推進に力を貸してくれます。なにがなんでも、全て目を通して自力で管理する必要はないのです。
まとめ
楽するために苦労する必要はありますが、本当に楽できるのかを見極めることが大切です。
当記事ではその掲示を、ランニングコストという観点から行いました。
自由度の高さは自由を行使できる工数があって初めて成り立つものですから、あえて触らない選択肢を考えられるとベターであると、筆者は考えています。
Discussion