リファクタリングについて

#

自分は設計が下手くそである。 設計が下手くそなんでたいてい最初の設計は残念極まりなく、密結合なものが出来あがる。

だが、時間を置いて見てみると、「あ、これは密結合だ」というセンサーが光ってくる。

密結合である場合というのは大体

• 関係ない(なにかしらの代入だとか演算だとかメソッド呼び出しの引数とかの関係が一切ない)変数が一緒にいる
• フラグ変数とかが奥深くまで引き回されている
• 共通コードのはずなのに、ある場合のときの例外みたいな処理が入っている
• 必要以上にコンテキスト変数?が引き回されている
• ひとつのクラスに色々情報詰め込みすぎ

これは主観だが最近リファクタリングしたコードはこんなかんじであった。

これらのことは大体時間を置いてみると客観視ができるようになるので 時間を置いてみるというのは非常に大事である。

またリファクタリングというのは処理の内容を変えずにコードを整理することである。 この処理の内容を変えないというのが肝であり、処理が変わってしまうとせっかくの修正も 思わぬ影響を与えかねない。そのために重要なのはテストである。 テストを書いていないのにリファクタリングをするというのは 命綱を付けないでやる綱渡りみたいなもんで危険極まりないと筆者は思っている。 ただ、一方で、これは密結合で作り始めたときは若干分が悪い。 密結合なものは往々にしてテストがし辛いためここにトレードオフがある。

他方でこのようなものを一切合切排除しているコードにもデメリットはあると思われる。

ひとつはコードリーディングの難しさという問題がある 初期の開発者はおそらく(想像でしかないが)この具体的で密結合だとかで分離しきれていないという状態を たどったうえで抽象化、構造化をしているためどこに何があるかがわかる状態である。 しかし、後から入ってきた初見の人やまったくの部外者には一体どこでその具体的な処理がなされているのか わからなくなってしまう。 たいてい OSS とかのコードはこのような抽象化が進んでいるため処理の詳細を追うのに苦労する。 こういう OSS にはドキュメンテーションなどはあれど大体表に出ている部分の説明であることが多い(そして大抵の人にはそれで事足りる)。 そのためとくに実装の参考にしたいなどといってに詳細部分を探すのは骨が折れる (まあ最近はエディターとか GitHub だとかの検索機能が優秀だったり生成 AI もあるのである程度は読めるであろう)

総じて思うのは最初はそれこそ密結合でプロトタイプくらいの気持ちで書いておいて、 一段落したらある程度分離の目処がつくのでそのときに分離をし、テストを書くようにすればよいのではと思うのである。最初から下手な設計でガッチガチに決めてしまうとあとから変えるのは難しい。 あとから想定していなかった状態が出てくるのは開発では日常茶飯事である。 そしてソフトウェアは生き物のようなものであると筆者は考える。 ホメオスタシスを保つかのごとく外からの状態は一定でありつつも内部はどんどんより良く変えていけるのが メンテナンスのしやすさの向上に繋がり、また外とのインターフェイスを変更したくなったときなどでも変更にも強くなると筆者は思うのである。

ただし、これはあくまでボッチで書く場合の話である。 大量の人が関わるプロダクトの場合、あとから引っ剥がすのは全箇所についてある程度 当たりをつけられないと難しいためまともに設計をしてから書いたほうがいいかもしれない。 と思ったが、筆者は万年ボッチ開発者なので実際のところはどうなのかは不明である。