大きなコードベースの真ん中あたりをさわっていると、仕事の大半はリファクタリングに費やされる。機能を足そうと書くコードも 8 割リファクタリングで新緑は 2 割。失敗して捨てるものも多いから、かける時間は 9 対 1 くらいかもしれない。
それどころかリファクタリング自体がプロジェクトにもなりうる。「今四半期はこの腐ったコードどもをなんとかするのが目標」というように。私もいま大きなリファクタリング、あるいはリアーキテクティング、の手伝いをしている。仕事時間のほぼすべてがリファクタリングに費やされる。今の勤務先で通用する唯一の特技がリファクタリングな私にとってこれはたぶん適職だ。
リファクタリングにコーディングの大半を捧げる人は他にもいる。
プログラマ相手の管理職をエンジニアリング・マネージャと呼ぶ。ほぼ全員プログラマ出身。現場に近いマネージャは多くがコードも書く。ただ血気盛んな人を除くと新機能には手を出さない。管理業務がたてこむ時期にプロジェクトが滞っては本末転倒。だからボトルネックは触らない。かわりに地味なバグをなおす。そしてなにより後始末としてのリファクタリングをする。
彼(女)らがコードを書く理由の一つは、プログラマの仕事をよく理解するためだろう。エンジニアリング・マネージャの多くはコードレビューをする。さわったことのないコードはレビューできない。
昼行灯の噂
ある友人が「最近ひとり大企業から転職してきた同僚がいるんだけど、書類仕事ばっかり得意でぜんぜん現場の役にたたないんだよねえ」とぼやくのを聞いた。大企業づとめの私はふと不安になる。仮にいまレイオフされたとする。そのとき自分が友人の会社、に限らず零細やスタートアップに職場を移し、役に立てるか。
コードは書けるから大丈夫。そう言いたいけれど、正直心もとない。スタートアップがだめなら中規模以上でどうだろう。できればしばらく潰れない景気のいいところ。おもむろに羽振りのよさそうな会社たちの求人要項を眺める。これも雇われる気がしない。
頼りなさの多くは化石すぎる手持ちの要素技術から来ている。仕方ない。Android でも勉強しよう。でもそれだけでなく、自分の中から何かが失われた不安がある。物事を前にすすめる力のようなもの。リファクタリングばかりするうちに、その熱量が・・・元々少なかった所に輪をかけて・・・なくなってしまった気がする。書類仕事ばかりが得意な昼行灯に自分を重ねる。
リファクタリングと書類仕事
リファクタリングと書類仕事には似たところがある: リファクタリングはコードベースが大きいほど必要性を増す。書類仕事は組織が大きいほど増える。
ソフトウェア開発では、古き良き大きな事前設計も書類仕事に近い。大きな事前設計とリファクタリングは似ていない。思想的には水と油と言ってもいい。けれど一歩下がってみると、その目的は似通っている。どちらもソフトウェアの複雑さを克服するためにある。言ってみれば複雑さの対価を一括で前払いするのが大きな事前設計、ちまちま後払いするのがリファクタリングだ。
プロジェクトを小さくはじめ、余分な複雑さを買い込まずに済ませる。その身軽さは、けれど永遠には続かない。ソフトウェアが大きくなるにつれ Brooks のいう <本質的な複雑さ> が膨らみはじめる。密度を低く抑えてきたはずの <偶発的な複雑さ> すら積分すると結構な量。その昔、複雑さはそびえ立つ事前設計の塔として陽光を遮った。その質量が、今は終わらないリファクタリングの塵として静かに空を覆う。これがインクリメンタルな大規模開発の姿なのかもしれない。
リファクタリングと書類仕事にはもう一つ似たところがある: その技能は、特定のコードベースや組織に深く埋め込まれている。リファクタリングが得意なことと、手を加えるコードベースに詳しいこと。この２つを区別するのは難しい。一般的なリファクタリング技法は存在するし、経験から導きだされる法則もある。それでも相手にするコードへの深い理解ほどリファクタリングを助けるものは無い。リファクタリングは対象を理解する学びのプロセスでもあるから、これは自然なことだ。
書類仕事にも同じ事が言える。法的な文書のように広く使われる書類もある。けれど組織のワークフローや歴史的背景の理解、そこに隠されたノウハウこそが、達人ペーパーワーカーを達人たらしめる。
けれどそうした知見の多くは外に持ち出す事ができない。下手に使うと薬が毒になる。けれどそれに気づく難しさがあり、つい文脈にそぐわない歪な複雑さをまき散らしてしまう。かつてデザインパターン学派やプロセス大好き上司が嫌われたのと似た理由で、リファクタリング教徒も煙たがられる。これは化石化の症状でもある。達人たることに慣れすぎると、不慣れのぎこちなさや無知な自分と向かい合うのが辛くなる。慣れた道具に頼りたくなる。
リファクタリングと書類仕事の三つ目の類似は、どちらも管理職の守備範囲に含まれているところ。これは前二つの相似から読み解ける。組織やプロジェクトへの一段深いコミットを求められる管理職にとって尻拭いは日常だし、コミット対象を深く理解しようとするのもわかる。そして管理職の本業はコード書きの外にある。
切り開く、切り離す、切り刻む。
リファクタリングがプログラミングにおける書類仕事なのだとしたら、たしかに私は書類仕事ばかりが得意な大企業の人だと言える。書類仕事ではない、製品のユーザにとって直接意味のある何かを手がけないと昼行灯が板についてしまう。複雑さの支払いという先の比喩を頼るなら、リファクタリングばかりするのは借金(技術的負債)の返済に明け暮れるようなもの。負債を返し自由を手に入れたら何か意味のあることに使いたい。ついでに少しは新しい事がしたい。
大きなコードベースで働くプログラマたちは、様々にこのバランスをとろうとする。
中心部で活躍するプログラマは、借金返済レートと支出の両方が大きい。すごい勢いでリファクタリングをしつつ、すごい勢いで物事を成し遂げて行く。そして前線は新しい問題に事欠かない。
そんなハードワークに疲れ、しばらく姿を消し山奥のプロジェクトで気分転換をするベテランもいる。（たまにそのまま帰ってこない。）山奥まで行かないまでも少し距離を置き、まだ複雑さの届かない郊外や新興地区を好むプログラマも多い。割り切って塵降る都会に暮らしながら余暇コードに精を出す人もいる。
プログラマ個人からプロジェクト全体に視線を移すると少し眺めが変わる。新しいテクノロジが必要なのは人もプロジェクトも同じ。規模との戦いでは、コードベースやソフトウェアそのものを小さく絞り込む流れがある。
たとえば Microservices はまさにそうした試みだし、クライアントサイドならアプリの Unbundling が近いかもしれない。静的な依存関係の整理に留まらない分厚い出刃包丁で大きなコードを切り分ける。プロセスやバイナリ、コードレポジトリやデプロイ頻度、プログラミング言語、あるいはチームやプロジェクトそれ自体。素朴なインクリメンタリズムを超え、けれど振り出しには戻らず、トップダウンに一括返済を目指す姿は壮観だ。勝ち取った独立と自由に歓声が上がる。
ブラウザには様々な面倒があるせいでよくある方法は使いにくい。でも同じ目的意識で粗結合をめざす試みはある。形になる日が来たら紹介します。
複雑さの影
複雑さとの戦いがソフトウェア開発の全てだと、ずっと昔は思っていた。間違いは今や明らかだけれど、未だその価値観に縛られた自分がいる。
古いソフトウェア工学の言葉に「内部品質」と「外部品質」なんてのがある。内部品質は借金を返す仕事、外部品質はユーザにわかる成果だと思えば大体あっている。教科書がこれを隣り合わせたとき、二つは似通ったものに映った。その関係が並列でないことも同じく今や明らかだけれど、未だその違いを内面化できていない。
そして気がつくと複雑さの影を追いかけている。目を凝らすと、それは日に背を向けた人のかたちに切り抜かれている。
