“レガシーコードからの脱却”を読んで

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス 新品価格 ￥3,190から (2019/10/21 20:52時点)

いつもと違いつらつらと読んだ感想を書いていこうと思います。少し読みにくいかもしれませんが、感じたことを書き留めておきたいなと思い、まとめておきます。

僕も普段はこの本でいうレガシーコードと向き合い、ソフトウェアの運用と開発をしています。その中で、どうリファクタリングをするか、そもそもリファクタリングをするべきか、というのはよく考えることです。それは、そのソフトウェアをもっと長く使われるようにしたいな、という気持ちがあってのことです。そしてもちろん、事業が長続きするように、というのもあります。(ちなみにレガシーコードとはバグを多く含み、壊れやすく拡張が難しいコードを指しています。)

リリースしてから新しい機能を開発し、修正し、不具合も直し、というのを続け、なんとか事業も続いていくとソフトウェアも徐々に負債が積み上がっていきます。誰も負債を貯めようとはしていないと思いますが、リファクタリングをするにもソフトウェアの経験や知識、スキルに依存してその負債をうまく返済できていくかも変わってくると思います。それくらいリファクタリングをして負債を返していくのは難しいと思っています。他にももともと開発時にいたソフトウェアエンジニアが異動したり転職していなくなったりするとその設計意図やアーキテクチャの意図が失われていくこともあるでしょう。僕もそういう状況と向き合っており、知っている人がいればすぐ済むのにな、ということはよくあります。書籍にもありましたが、まるで考古学のように以前のドキュメントを掘り起こしてやっと設計意図をしる、ということはよくあります。理解できればいいのですが、わからない時はコードを読み込んで把握するしかありません。これもなかなか大変です。(愚痴のようになってますが、これはこれでソフトウェアエンジニアの仕事らしく僕は面白い行程で好きなのですが、多くのケースで時間は限られており難しいなと感じています。)

よく議論になりがちなのは、”今リファクタリングをするべきなのか”、ということ。チームのメンバーからリファクタリングしたい、というのはよく話に上がるのですが、本当に今すべきなのか、それともリファクタリングせずに別作業に時間を当てるべきか、そうではなく逆にしっかり時間を確保してリファクタリングをするべきか、選択肢はこれくらいだと思いますが、これを随時判断していきます。他のソフトウェアエンジニアの方々がどうしているのか気になるところですが、僕自身は今までの経験からなんとなく今リファクタリングをすべきかどうかを随時判断していました。僕は立場的にもそういった最終判断をすることも多いのですが正直なんとなく判断しており時折本当にそれでいいのか不安になることがあります。もちろん、全く的外れということはないと思っていますが、もう少し論理的に、というか判断軸を持って判断していきたいなとよく思っていました。

そこについて、この”レガシーコードからの脱却”を読んでいて参考になることがありました。以下は書籍から引用します。

13.9.2 いつリファクタリングを行うかについての7つの戦略

• 重要なコードがうまく保守されていないとき
• コードを理解している人がいなくなったとき
• 新しい情報によって、より良い設計が見つかったとき
• バグを修正するとき
• 新機能を追加するとき
• レガシーコードのドキュメントを書くとき
• 作り直すより安い場合

出典：レガシーコードからの脱却

どうでしょうか。僕はこの章を読んでいたとき、とても腹落ちする戦略だ、と思いました。そして自分がなんとなく判断していた方向性が合っていたように感じられ、ホッとしました。

僕のソフトウェアエンジニアとしての力が十分であればソフトウェアの寿命を伸ばすことも、そして逆に縮めることもあるわけです。だから、リファクタリングという方法を適切なタイミングに、適切な方法でうまく実践していければソフトウェアの寿命、そして事業の継続に貢献できることになります。もちろん、いつリファクタリングをするべきか、の判断軸がこれでわかったとしても、そのときに具体的に実践できる力が僕に、またはチームにあるかは別の課題としてあります。これについては僕は一ついいアプローチの手法について心当たりがあります(書籍にもあったかもですがw)。それはペアプロやモブプロです。つい先日、こんなことが自然とチームメンバーとの会話でありました。

「ここの処理、複雑で難しいのでこの機能追加するのをみんなでモブプロしながらやりませんか」

「そうですね、その方がいいと思います、そうしましょう」

モブプロの提案をしてくれたのはベテランのソフトウェアエンジニアの方です、僕よりもコーディングについては素晴らしい経験とスキルを持っています。一方で、その方よりも僕ともう一人のメンバーの方がその機能追加する際に関係するコードの箇所について理解がありました。そのため、一緒に協力して改修をしよう、という話は自然にまとまりました。そして、実際にモブプロをして1時間ほどでその機能追加は完了しました。

「モブプロしたおかげで一人でやるより早く終わりましたね」

これはそのベテランの方がモブプロが完了してから言ったことなんですが、僕も同感でした。3人でモブプロをしたので1時間 x 3人の時間を使っていますが、改修もでき、そして僕ともう一人のメンバーはそのベテランのソフトウェアエンジニアが普段どうやってIDE(iOSアプリ改修をしているので具体的にはXcode)を利用しているか見て学ぶことができました。モブプロでよくある学べることですね。リファクタリングまではできなかったですがこのチームの状態はリファクタリングを継続的に行い、ソフトウェアの寿命を伸ばし、事業の継続に繋がるように思いました。

僕がソフトウェアエンジニアとして仕事をして今年でだいたい10年くらいです。まだまだ学ぶことも多く、この”レガシーコードからの脱却”を読んでもこれから身に付けたい力が多くあるなと強く感じました。この”レガシーコードからの脱却”は僕が今担当しているサービス、事業を継続させていくときにソフトウェアエンジニアとして必要になる力とその具体的なプラクティスについて記載があります。突っ込んだ内容はもちろん別の書籍の方がいいものが多いですが、ソフトウェアの開発運用に携わっているソフトウェアエンジニアにとってどういうい姿勢で、どちらの方向に向かって学んでいくといいのか、といったことを示してくれていると思います。ソフトウェア開発は難しいけど面白いな、と改めて感じました。いい本でした、おすすめです。