↓の続き。
あると嬉しい：ビジネスロジック
一覧表示をする際「XXのパラメータ順に並び替えて表示する。デフォルト表示は◯件」などの業務的な仕様はフロントエンド領域でもある。バックエンドでソートしてやれよ！と思ったりするが、クラウドのストレージから直接データを抜いてくる…みたいなときもある。 1
業務的な仕様を満たすため、取得したデータをコネコネするのはいい。いいんだけど、業務ロジックがコードでしか残ってないと保守対応にすごく時間がかかる。特に仕様バグが見つかったので直したい！という場面で業務ロジックが分からないとクサクサした気分になってくる。
これこそ単体テストでは！！！と思う。でも業務背景とかはテストから読み取れないので、作業issueやチケットに記録してもらいたい。体感だけど、解読に時間がかかるものに限って単体テストも仕様記録も残ってないことが多いのでうーーーーーーんってなる。質を捨てると開発時間は増えていきますよ、を身をもって体験できる。嬉しくない。
ないと困る：アプリケーションの設計思想
- UIフレームワークの選定理由
- ディレクトリ構成の理由
- コンポーネントの粒度
これらの情報が何も残っていない かつ 開発者が複数人いる場合、アプリケーション全体の統一性が崩れやすい。 2
実装や設計思想に統一感がないアプリケーションを保守するのはとてもクサクサした気分になる。解読する際にとても疲れるし、「修正漏れはないだろうか」と心配しながらコード変更するのも疲れる。開発初期の設計段階で思想はドキュメント化して、思想に反するコードがきたらレビューで弾いて欲しい。
あと途中で設計を変更したら、コード全体も直して〜と思う。とにかく複数の考えがコード内に散らばってる状態を保守するのはしんどいと言いたい。
ないと困る：アプリケーション全体で共通化している処理とその拡張方法
エラーハンドリングやAPI通信処理など、アプリケーション全体で使うので共通化している処理があったりする。3
共通化ふんぬんの是非は横においても、どこをなぜ共通化してるのか・拡張したい場合はどうするか記録がないと困る。仕様追加したら例外的な処理ができた！特殊な画面なので処理を拡張しないと、となったときに詰みが発生する。
「実装の仕様が分からなくて拡張できないですね〜。調べるのに1週間ほど欲しいんですけど」と言う場面が何回もあった。アプリ全体の処理を共通化するなら設計ドキュメントとIN/OUT（やコンポーネント仕様）の単体テストはセット！必須！ないと保守無理！なお気持ちになった。
誰かが作ったアプリケーションを保守してると、保守しやすい状態 = ちゃんと正しい仕様がわかるしデグレチェックが自動でできる、かな〜と思う。質とスピードのスライドにある通り、保守性が低いアプリケーションのお守りはめっちゃ時間かかるな…作ったものは自分で保守して欲しい…が最近のお気持ちです。
新機能開発マンは目立つので社内で評価されるがテストとかは割り切ってたりするのでお守りする側が😥てなるやつ。作った人がちゃんと運用して〜
— もふもふ (@froakie0021) 2021年3月2日
