ぐち

仕事で、「リファクタリング」みたいな、っつーリファクタリングそのものなんだけども、あのコード例を作ったんですよ。今日終わらせたんだけども。

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

120ページ分くらい、延々とひとつのプログラムを書いてはリファクタリングして機能追加してまたリファクタリングして、って続く実例をずーっと書いてて、ボロボロに疲れた。あの、削除部分は線を引いて表示して、追加を太字で出して、ってのがね、もうね、地獄なの。この本、あれだけよく作ってあるわ。すごいよ。あのコード例を作る労力は。
労力がかかるのは差分表示じゃないんです。あれをサブバアジョンの差分から生成できるよねとかは全くどうでもいいんです。大変なのは、作業の流れなんです。簡単なコードで、その差分生成もあるとしましょう。では始めます。こうやって、次はこうやって、こう直して、....と行って、途中でここのコメント行が話とずれてる気がするね、となったら、今までの履歴をまた最初からリプレイ。リポジトリ作ってようがなんだろうが全部一からリプレイ。そうしないと、その「こうやって」の流れが合わない。
更に、読者向けレビューっちゅうのがありますね。読者がここのリファクタリング例はもっと詳しくだの言い出したらさあ大変。またリプレイ。しかも前より細かく、違う流れを作る。でまたリファクタリングってのは名前からして重複部分をあえて多く書くからさ(上記のとおり、削除する部分も線を引いて残すので手間は2倍)、しんどいよ。更に今回は実はテスト駆動な話だったからタスクリストも同様にあってな。世にある本はその性格上、比較的リファクタリングしやすいコード例しか載せないんで、今回はガチ現場っぽいコードで例を作るっつー話だから、一行でもコーディングキヤク違反があるとまたやり直しでな。全ページを。
同じ作業を数年前、100行くらいのPythonコードで数回やってるんで大丈夫かなと思ったんだが、Cで本気でやってみたら割と泣けたので、もう二度とやらねえ。読む方はさらっと眺めるだけで済むから最高なんだけどねえ。無理。マジで無理。
よくわからん人は金子信雄が「そこ包丁が写ってません」だの「最初の湯通しがよくわかりません」だの言われながら、5時間かかる料理のレシピ手順(机の下から出す途中まで煮た野菜とか)を何回も何回も全部作り直している様を思い浮かべると、近いです。