JavaScript

フロントエンドの n年耐性 再考

ポエムです。自分は直近まで、中長期運用でも破綻しないために、どの様なコードにすべきか?というテーマに取り組んでいました。

クリーンアーキテクチャもそこを目指しますが、いかんせん学習コストが安くありません。誰でも今すぐ実践出来ること・脳内整理としてメモを残します。

経年劣化と戦うために

アーキテクチャ、ライブラリの流行に逆らうことは出来ないです。なぜなら、ひと昔前のコードベースは、保守メンバーのモチベーションを劣化させ、人員がプロダクトから離れていってしまうからです。プロダクトの本質とは無関係なこの負債要因を、誰しも感じているのではないでしょうか。

このコードベース置換は甚大な影響範囲のため、気軽に置き換えることは出来ません。この変化を受け入れる仕組みがあれば、誰しも幸せになれる、と設計者は夢を見ます。

将来頼れるコード

もし今、あなたが React を使っていて、Vue に移行するという決断が下された場合。何割のコードがどの様な形で残るでしょうか? 恐らく汎化モジュールとして切り出された純関数と、少しの DOM構造くらいの、ポータブルなものだけが残ります。

筆者も過去、CoffeeScript から babel へ移行した際、この知識が切り出されていたおかげで、工数が削減出来た場面がありました。

「ポータブルな純関数に重きを置くこと。ただし現コードで汎用的コンテキストに置く必要は無い」これが自分の n年耐性の答えです。どんなに堅牢な設計でも、時代に合わないレールなら見直し、その時保守するメンバーのモチベーションを最大化させる、そんなコードであるべきだと思います。

未来の実装者も最新のアーキテクチャの中で、資産として残された純関数を頼りに、伸び伸びと新しいコードを書くことが出来るのではと思います。