1週間だけ読む取り組み

一冊の本を一週間で読めるだけ読むというのをやってみる。 買った本は積まれる一方だし、買いたい本のURLもPocketに溜まるばかり。そしていざ本を読み始めると、最初から頑張って全部読みがちである。そういった習慣を変えるために、1週間で読むのをやめて強制的に次の本に行くという方法を試してみる。

一週間やってみて、全然読みきれないと感じた。ゾーンに入ってバーンと読んでしまえば今回の本などは読み切れるのかもしれないが、そうやって気合いを入れるのではなくて、趣味のプログラミングや雑誌の原稿や仕事のキャッチアップなどをする日々に馴染む範囲で日常的にどんどん読んでいきたいので、この取り組みをやり始めるわけである。

書籍に載るような文章を書く手間を考えると、本の作者には適当な読み方をして申し訳ない面もある。しかし世の中には読みきれないほどの本があるし、読まないより読む方がいいだろう。

レガシーコード改善ガイドを少し読んだ感想

今回は一冊目、レガシーコード改善ガイド。本に示されたトピックをいくつか紹介しながら感想を述べる。

https://www.shoeisha.co.jp/book/detail/9784798116839

変更の基本的な流れ

レガシーコードの変更には一連の手順がある。それは次のような手順であると紹介されている。

  1. 変更点を洗い出す
  2. テストを書く場所を見つける
  3. 依存関係を排除する
  4. テストを書く
  5. 変更とリファクタリングを行う

(p21)

既存の振る舞いをテストコードにより保護し、デグレしていないことを保証しつつリファクタリングや変更を加える手順である。 普段やっていること/やろうとしていることではある1が、改めて言語化されて本の前半で整理されていて再確認になった。

検出と分離、接合部と許容点

書籍の中では、「検出」「分離」「接合部」「許容点」という語が定義されている。普段なんとなく「この変数の値を検証したい」「この部分を切り出せば良いのではないか」「ここで分割できるな」「ここでモックすればいいな」などと考えているが、これらに言葉が与えられることの意義は大きい。言葉が与えられることで考えがよりわかりやすく整理されて表現され、脳を占有する思考のメモリ領域が圧縮できる。

検出と分離

コードの計算した値にアクセスできない時に、それを検出するために依存関係を排除する(p25)

コードをテストハーネスに入れて実行することすらできない時、分離するために依存関係を排除する (pp25-26)

例えば長いトランザクションスクリプトでは、一つのメソッドの中のある変数の挙動をテストしたいことがある。そういったもののコード実行時の挙動を"検出"するためにテストコードを書く。テストコードを書くために依存関係を排除しなければならないこともあるだろう。

例えば実装が特定のソフトウェア外部との接続に依存している場合もあるだろう(ネットワーク通信やファイルシステム、ハードウェアなど)。そういった時には、テストのために、偽装オブジェクト/モックオブジェクトを作ってそれらを利用できるようにすることで"分離"する必要がある。

接合部と許容点

接合部(seam)とは、その場所を直接編集しなくても、プログラムの振る舞いを変えることのできる場所である。 (p41)

どの接合部も許容点(enabling point)を持つ。許容点では、どの振る舞いを使うかを決定できる。(p41)

オブジェクト指向2の考えを取り入れた言語では、メソッドをオーバーライドしたり、インタフェースに異なる実装を与えると、コードの字面を一切変えずに挙動を変えることができる。例として、次にPHPのコードを示す。

class Renderer
{
  function render(PrintableDevice $device) {
    $device->print();
  }
}

ここでprint()メソッドがどのように振る舞うかは、$deviceインスタンスが何かによって変わる。ここでprint()メソッドの呼び出しを接合部、renderメソッドの引数による$deviceの引き渡しを許容点とと呼べる。

たとえば外部通信をするような依存を持つコードをテストの中だけで実行しないようにできれば、そのコードをテストできる。依存関係を整理するときは、どこかを接合部や許容点とし、本番環境との振る舞いを変えてロジックをテストするコードを書くことになる。

もうウンザリです。何も改善できません

「もうウンザリです。何も改善できません」は第24章のタイトル。この章は@UVB_76さんにおすすめいただいた箇所で、とてもポエミーで勇気づけられる内容が書かれている。 2ページくらいですぐに読めるし、本の中の文章をそのまま読むからこそ感じられることがあると思うのでぜひ原文を読んでいただきたい。

この章では、プログラムを書くことは本来楽しいことや、レガシーコードを抱えていることに落胆せず、毎日挑戦的に仕事を楽しむ方法を思い出させてくれる。やりがいを見つけ、テストによる保護でひどい状況を制御することで前進できると語ってくれている。現時点で私は落胆しているわけではない3のだけど、それでも勇気づけられたし、落胆しそうになった時にまた読みたい。

次に読みたいところ

テストがかけてしまえば、それにより保護されることで安全に変更を加えることができるだろうが、今の自分には既存のコードを切り分けてテストを書くまでのプラクティスや知識が足りていないところがあると思うので、そういった実践的な部分や内容をより深掘りして読みたい。

終わりに

「次に読みたいところ」に書いたとおり、次の本に行く前にまだまだ読みたいところだけれど、そうやるとダラダラ読んでしまうだろうから、次の本に行こうと思う。 最初なのでブログを書くのにも気合が入ってしまった。次からはもう少し肩の力を抜いて、なるべく負荷にならない範囲で記録を残していきたい。

Footnotes

  1. といいつつ、横着して、この本が横にある時に「編集して祈る」をやりそうになり、同僚とそのことを笑っていました。結局テストを書きました。肝に銘じます。(「編集して祈る」は書籍の中でテストを書いてリファクタリングや変更を繰り返す方法と対比され、よくない方法として紹介されている言葉です。) ↩

  2. オブジェクト指向とはなんぞやというのは脇に置いておきます。許してください。 ↩

  3. レガシーという言葉は結構気を使う単語で、私の仕事がレガシーにまみれているような誤解を与えそうなので一応補足を書いておきます。もちろん大きかったり歴史の長いソフトウェアやサービスでは相対的に手が届きづらくなるコンポーネントや巨大化したコンポーネントも扱うけれども、それらが一定コントロールされた/したうえで最新の手法を取り入れつつチャレンジングな仕事ができる環境にいると思っています。 ↩