何も知らないまま雑にNuxtで開発したら死んだ話

はじめに

本投稿は TECOTEC Advent Calendar 2019 の16日目の記事です。
以前、手探りでやった結果大惨事になったプロジェクトの状況を、主犯の一人として反省を込めてメモがてら書き記していきたいと思います。

使ってた技術

• Nuxtjs
• vuex
• Pug
• Firebase(Authentication/Functions/Firestore/Hosting)

状況

俺たちは雰囲気でこのプロジェクトをやっている。

新規のサービス開発。チームとしては10名くらい。Nuxt触ったことある人なし。JSのスキルレベルもそこそこという感じでした。(ヤバ1) まあNuxtならそんなに難易度高くない（らしい）しへーきへーき！！みたいな楽観もあった気がしないでもない。(ヤバ2）
なお、Firebaseも同様にほぼ触ったことないメンバーでした。collection定義なにもわからない。（ヤバ3）
一体何がダメだったんでしょうかねぇ

何が起きたか。

• 無秩序に乱立した用途のよくわからないComponent
• 各Componentで似たようなオレオレObjectの大量発生
• テスト書いてない
• 途中で主要なFirestore collectionの定義し直し
• 一部導入したフレームワークの影響もありSCSSの肥大化/制御不能

特に検索系のComponentがヤバく、ほぼ同じPlateが18種類のComponentで爆誕しました。Slotでええやないか。
また、途中でもともと権限で出し分けていた管理系機能を別アプリとして切り出すような事態も起きてて、もはや何がなんだかという感じでした。使ってないComponentいっぱいあった気がする……。

いわゆるStore系の扱いもよくわからず、こちらも同様にスパゲッティ化しました。基本collection単位で切ってたんですけどね……。オレオレObjectを扱う謎Actionが乱立したのが悪かったかな………。
タスクはbacklogでチケット切ってチケット駆動開発のような感じで行っていて、これ自体が悪いわけじゃないんですが、いわゆる画面単位でタスクを切った結果、各々が作ったVueファイルのなかにBusinessLogicが押し込まれるという事態になりました。どうして？
collection定義し直しは雑に作った結果検索がクソ遅くて速度改善のために実施しました。なお、結果別のところ直したらぼちぼち改善したのであれが何だったのかは忘れることにしました。

どうすればよかったのか

Component作成のルールを決める

Nuxtで指定されているもの以外、フォルダの切り方が不明。ぱっと見でどのComponentが何なのかわからない。そんな状況を打破するにはやはりルールを整備する必要があります。なんで気づかなかったんですかね？
そこで、このPJの反省を活かし以降のプロジェクトではAtomicDesignを導入。最低限のフォルダ分けと作成ルールを整備しました。これによってSCSS側もScopedで書きやすくなり、圧倒的にマシになりました。
なんで気づかなかったんですかね？

Typescriptの導入

オレオレObjectが無限に発生するならそうならないように型で縛ればいい。型は偉大である。共通の型を使えば処理の共通化もしやすい。素晴らしい。書く手間は増えるが些細なことだ。型のルールをちゃんと決めてなくてこっちも乱立しかけたりしたけどそれも些細なことだ。
もともとこのPJでも導入の検討はしてたんですけど何もかも新規だしハードル上がりそうだからやめたんですよね確か。結果としてはどうせ何もわからないしあったほうがマシだった説は濃厚なんですが。

ElasticSearchの導入

検索を自前でやるなんて自殺行為でございますわ！！なんで入れてなかったのかは忘れました。

テスト書く

いや最初から書けよ。テスト書いてないとかお前それ（ｒｙとライオンのスタンドが現れて怒られてしまいます。

振り返ってみて

こうして振り返るとだめなことするとだめになるというお手本のような感じでございますね。当時は何もわからなかったんですよ。多分。実はそんなに昔じゃないとかそういうのは置いといて。

VueやReactにTypescript入れちゃったらそれはもうAngularじゃんみたいなのは一昔前には言われてましたけど最近はもうTypescriptは導入必須みたいな空気感ありますよね。個人的にはJavaが長かったのもあって型がある方が落ち着くんですが、JSで雑に書いてもいい感じに動いてくれるのも嫌いじゃないんですよね。だからと言って調子に乗ると大変なことになるというのも多大な犠牲ともにわかりました。
それと、導入してイキってますがAtomicDesignは未だによくわかっていません。そんなに知見が転がってないのと、あくまで考え方でしかないのでPJごとにいい感じに調整するしかないような感じですし。どこかの勉強会で聞いたまずAtomsから始めよ的なやつはまあそのとおりだなあと思いました（てきとう）。

総括

人間は愚かなのでルールを整備しましょう。ルールを整備したら強制する仕組みも導入しましょう。

4/10追記

その後のAtomicDesign
https://tec.tecotec.co.jp/entry/2020/03/27/090000