思いやりが遺産を育む

2019年7月6日 01:02

レガシー

レガシー。遺産。
この単語を聞いて、ネガティブな感情を抱く一団がいる。
ソフトウェアエンジニアである。

ここでは「レガシーコード」という言葉を『何年も前に誰かが作り、内容が複雑で何をしているのかよく分からず、まともな仕様書もない』というコードを指すものとします。

当然のことながら、最初からメンテナンスしずらいコードを書こうと思って書くエンジニアはいない。
様々な積み重ねがレガシーをつくるのだ。
一般には厳しい納期や技術トレンドの移り変わりが下手人として上げられるが、私はそこに「思いやり」も連座させたい。いくつか、紹介しよう。

偉人崇拝

コードを眺めていると、なんだか設計がよくない。古い技術を使っている。よし、リファクタリングしてやろうかと意気込みメソッドのヘッダを見ると、社内の重鎮・尊敬を集めるエンジニアの名前がコメントされている。

「うーん、この方がこう書いているならなにか意図があるだろう」
「私が手直しするなんておこがましい」
かくして、「偉くなってしまったエンジニア・元エンジニア」のコードはいびつな形で時の洗礼を乗り越えてしまい次世代に致命傷をもたらす。

余談だが、私はリファクタリングをするときにまず個人名コメントを消すところから始める。
誰が書いたか見てしまうと意識にバイアスがかかるからだ。

助け合いアーキテクチャ

これは職能別組織でおきやすい。
ある案件を進めるにあたって、特定の領域の担当がなんらかの理由で手を動かせないとする。
機能横断組織であれば「他のチームメンバーが特定領域の業務にとりくむ」という形になる。あくまでドメインの設計は保つ。
それが、職能別組織でかつ気が利く人たちだと
「今忙しそうだからこっちで実装しちゃおうか」となってしまう。
ここでドメインの壁は決壊し、依存性の海がシステム全体を覆う。

忙しかろうがなんだろうが、依存性が拡散されないか、モデリングが破綻しないかといった点は確認が必要である。

中間管理職

これはリファクタリング時にも出現する厄介なものだ。
「拡張するかもしれないから、汎用的なIFにしよう」と切り出され、結局一種類の実装しかなされず無駄に階層が深くなる。
一見無害なのだが、放置しておくと何かしらこの層にスペシャルな仕事が入り複雑化してしまう。

モデルに立ち返り、うつくしくつくろう

思いやりをもつことは悪いことではない。
しかし思いやりがアーキテクチャを壊しては元も子もない。
違和感を持ちながらも、思いやりゆえにカイゼンできないときにはモデルに立ち返ろう。
その瞬間目の前にいる人のご機嫌をうかがうのではなく、将来にわたってこのシステムを使うであろう人たちに正しいモデルをプレゼントしよう。