2014/03/25にあったDevLOVE関西「レガシーコードと対峙する方法を考える」で、「"レガシーコード"再考」とか釣りっぽいタイトルで話してきました。DevLOVE関西は発表とダイアログって形式が多いので、その時のネタの一つにでもしてくれればいいかなーくらいを力点にしてます。だもんで、「レガシーコードってなんやねん」とか聞くだけ聞いて、結論付けたりとかはせずに終わったり。そんな毒にも薬にもならない話でした。
問い: 発表者の気持ちを答えよ(制限時間10分)
「レガシーコードの話をする」のは簡単なことだと思う。世の中にはレガシーコードが溢れてる事にはおおむね同意されるだろうし、見てきたものをそれなりに話すだけでも「あるある」とか「うへー」みたいな、参加者の多くである開発者の気持ちにアプローチするセッションはやりやすい。下手に記事や本に書かれてるような成功事例よりは話にも身が入るだろう。それはそれで意味はあると思うし、そこから考えられることも多い。私はそう言う話が好きだから、聞くならそう言うのを聞きたいと思う。
でも、よく話題になってる「レガシーコード」って、「レガシーコード改善ガイド」の定義通りの「テストのないコード」を指してることは少なくて、単に古くさいだけのをレガシーコードと呼んでみたり、単純にバグッてるダメなプログラムをレガシーコードと言ってみたり、そんなのを見て悶々としつつ。このあたりは本来の意味を無視してバズって点で「リファクタリング」とかにも通じるし、安易に使われるべきではないと言う点では「デスマーチ」に近い感覚があったりして。
そんなこともあって「レガシーコードで何が悪い?」と言ってみたかったから言ってみた。「レガシーコード」と言う言葉が出るだけで失笑を浮かべるような人たちでも、「レガシーでないコード」ってどう言うのを想定しているんだろう。本の通り「テストのないコードがレガシーコードだから、テストのあるコードならレガシーコードでない」と言うのもあるんだけど、それならまた「テストがあるってどう言うこと?」と被せちゃうわけで……我ながら面倒くさい。
質問を重ねるだけなら何も考えなくても出来るから、この行為自体は単に面倒なだけだと思ってる。考えを促すとか偉そうなことも聞きますけど、そんなのは思考の上下関係がある前提に立ってるように感じるし、そんな上下関係があるなんてただの思い込みじゃないのと。っと脱線した。
「レガシーコードで何が悪い?」とか「テストがあるってどう言う状態?」とか「レガシーコードでないって何?」とか「レガシーコードが問題になるのはいつ?」とか。この辺りは自分で自分にする質問で、その答えを人に教えてもらう気はあまり無くて。
レガシーコードを改善する*1となると、技術は勿論、戦略も要って。両輪なのでどっちも欠かせられないんだけど、「レガシーコード」って言葉が一人歩きして、ただの変更(寧ろ破壊)を「リファクタリング」と読んだりして、さもそれ自体が「素晴らしい行為」みたいな感じでやっちゃってるのを見ると、どこまで行っても「動いているものに触るな」を覆すことは出来ないと思っていたりして。
レガシーコードは変更時にこそ問題になると思ってる。なので変更しなければレガシーコードはそのままでも問題無いかなと。でも変更されないソフトウェアは無いから、レガシーコードは改善しなきゃいけない。とかなんとか。
若干暴論気味かもしれないけど、レガシーコードが問題になるのは、変更コストが開発者のスキルを上回ったときだと思ってる。スキルの高い技術者集団にとって、レガシーコードは問題にならない。なのでレガシーコードをなんとかできないのは、自分のスキルが足りないからだってのはただの事実。そこまでは受け入れた上で、コードの変更コストってのは対処しなければ青天井に上がり続けます。積み重ね塗固められていくから。そして「変更に必要なスキル」はあっさりと人類の限界を突破するします。だから変更コストが上がり続けないように抑えなきゃいけないし、いくら抑えようとしても上がっちゃうものだから、下げる取り組みも続けなきゃいけない。
そんな感じのことを思いながら話してました。
*1:根絶するでも退治するでもなく。出来るのはせいぜい「マシにする」程度だと思ってるので、改善はとてもいい表現だと思う。