ドキュメントなし・Pull Requestやissueもあまり記載がない・自分は初期開発に関わっていないアプリケーション保守開発を2年ほどやった。ほぼヒントがない状態からアプリケーションの動作や仕様を解析できるようになってきたので、調査の進め方をざっくり洗い出してみる。
まず始めにやること
まずはドキュメントがあるかチェックする。ドキュメントがなければリリース前のテストケース一覧がないかも確認する。受け入れテスト的なものは絶対あるはず。1まずはどのように使われる想定なのか把握することから始める。ドキュメントやテストケースを見ながらアプリケーションを動かし、正常系の動作仕様を把握する。
フォームは正常系・異常系のどちらも調べると良い。異常系の洗い出しは次のポイントをチェックすることが多い。
- 1度入力後、フォームを空にしたときの挙動
- 入力可能な文字種別は何か
- 入力不可な書式はあるか(メールアドレスのみ、とか)
- 必須入力項目は何か
ある程度動作がわかった後にコードを見る。いきなりコードを見るとメチャメチャだったときにゲンナリしてしまう。まずは「これはわかる」量を増やす。
構成を把握する
この辺を把握する。ライブラリの利用有無は結構ヒントになる。デコレーターをたくさん使ってる場合、テストは期待しないほうが良い。デコレータを使いつつテストを通すことまで考えて開発する人は少ない。
package.json
を見て利用ライブラリを探る- Vuex
- Vue Router
- デコレータ利用の有無
- 個人開発のデコレーターを使ってたりするケースがある
- Unit Testの有無
- 動作するかも含む
コンポーネント
Vue.js Devtoolsを使い親子関係を把握する。Vue Router利用の場合、ルーティング定義である程度大まかな親子関係は把握できる。ネストされたルートが多い場合は構成が複雑なことが多い。
Props・Emit・Watchに注目し、親子間でどのようにデータをやりとりしているか把握する。最初は紙と鉛筆を用意して作図すると良い。 フォームのコンポーネントの場合、バリデーション実装はどこにあるかチェックする。
ロジックやInterfacesなど
ディレクトリ構成を把握し、どこにどのようなロジックがあるか把握する。似たようなロジックが乱立していないかよくチェックする。全く同じロジックがコピーペーストで使いまわされていたり、似たような実装が変数名や書式を少し変えて再登場していることがある。複数回出会う場合は覚悟を決めた方が良い。
Vuex周り
Storeをどこで、なんの用途で利用しているか確認する。Storeなしで実装できる部分もStoreに保持していないか?あと画面を抜けるときに初期化処理があるか、も確認する。ない場合は同じStoreを複数画面で使いまわしていないか見ておいた方が良い。大体そういうところからバグになる。
API呼び出し系
正常系の動作がわかっていれば、この段階でどのあたりを見れば良いかアタリをつけられる。それっぽい処理をコード検索で探す。ラップした関数を使っているかチェックしておくと良い。ラッパーは便利かもしれないが、作るならドキュメントなりテストなりは欲しい。
テスト(ある場合)
動くかどうか確認する。「やったーテストあるじゃん!」と言って蓋を開けたらタスクが落ちる = 動かない ≒ ないじゃん!となったことがある。期待した後の失望はダメージがでかい。あとは意味のあるテストになっているかも確認しておく。
最初から解析が不要なアプリケーションを作ってよ、と言いたいが、どんなに綺麗でも参加したばかりのときは何もわからない。なので解析できるに越したことはないと思う。一番大事なのはイライラしないことですね。開発時は最大限の努力をしてるはずなので、それを貶すのはよくないことである。
-
なかったら色々覚悟決めた方が良い。撤退できるならするのもアリだと思う。それか作り直すか。↩