seri::diary

日常

組織の中で新しいことをする勇気

長いこと多くのエンジニアに保守され続け、機能拡張を続けたシステムにありがちな話。初期の設計思想が無視され、付け焼き刃の設計と実装でどんどんコードが汚くなっていく。

適当なパッケージに適当な名前のクラスが量産され、似たような処理のメソッドや、やたらと多くのことをやり過ぎるメソッドが増えまくる。当然コメントなんて一言も書いてない。

急ぎで作ったから仕方がない、なんて場合もあるのだが、大抵は一つの理由に行き着く。「安易に似た実装をコピペするから」。

他の実装をパクるのはラクだ。すでに動いているのだから間違いがないし、何より自分の頭を使わなくていい。メソッドが新たに増える分には副作用が無いケースが多い。だからバグを埋め込む可能性も低い。良いことづくしだ。

その結果どうなるか。後から触る人が泣くことになる。

コピペした本人はコピペ元がなにをやってて何の為にコピペしたのが分かっているから迷うことはないが、後からコピペした辺りを触る人はそんな経緯は知らない。だからなんでほぼ同じで少しだけ違う処理をコピペして持ってきたのかわからない。このメソッドがなぜこのクラスにいるのか分からない。そもそもこの処理、このパッケージに書いていいんだっけ???等々。ソースを読みながらそんなことを悩んでいるうちに日が暮れる。無駄に工数を消化する。スケジュールが遅れてマネージャーに怒られる。。良いことなし。

どうするか。「根拠のあるコード」を常に書くようにする。レビューで問い詰めてコードの根拠をはっきりさせる。経験上、大体これぐらいしかない。

根拠がはっきりしていれば、他とは違うクラスの設計をしても良い。そのクラスの責務はそのシステムで初めて発生したものかも知れない。だから無理やり他の実装と合わせる必要はない。

オブジェクト指向の原点に立ち返って、「このクラスの責務は何だろうか?このメソッドはこのクラスの責務を超えてはいないか?」と自問して、「この処理はこのクラスがするのはおかしい。別の名前のクラスがやるべきだ」と感じたら、堂々と新しいクラスを作ればいい。

こういうパターンの名前は今いじっているシステムには無い?でも散々考えた挙句、あなたはその名前がふさわしいと思ったんでしょ?根拠があるんでしょ?だったら堂々とレビューに出せばいい。何でもかんでもHogeLogic , FooServiceでピッタリハマる訳じゃない。

新しいことをやるとレビュアーに突っ込まれる?根拠を堂々と述べればいい。それが出来ないならきちんと設計ができていない。自信が無ければ作業中でも他の人にクラス設計をレビューしてもらえばいい。

実装に手一杯で設計まで手が回らない、なんて言うケースもたまに見かけるけど、それでも設計には時間をかけるべきだし、設計に時間がかかるんならチケットを切る段階でそれを見越して見積もりを立ててスケジュールを切ればいい。それくらい設計フェーズは大事だ。ここを疎かにすると後の人が泣く事になり、いずれ自分も泣く羽目になる。

必要ならば新しいことをする勇気を出して欲しい、といつも思う。確かに新しいことは怖い。リスクも大きい。でも、他と同じような感じで何となくコードを書いて飯を食ってたらいつまでもスキルは上がらない。

仮にそれをやって他から突っ込まれても、きちんと根拠を説明して議論することもエンジニアにとっては重要なスキルだと思う。自分が知る限り、説明が下手なエンジニアに良いエンジニアはいない。優秀になればなるほど完結な言葉で端的に説明できる人が多い。議論好きである必要はないけど、きちんと自分の頭で考えて、「これがベストだ!」と思える設計・実装をして、それを周囲に認めてもらいながらものを作り続けられるようにしたい。