上記のイベントに参加してきたので、感想を書いていこうと思います。
イベント概要
以下、イベントページからの抜粋です。
世の中の主流がインターネット上に移行してきた中で、「高速化」が一つキーワードになってきています。とりわけソフトウェアのサービスにおいては、技術の選定やソースコードを日々アップデートしていくことがダイレクトに”高速なサービス成長”に繋がります。本イベントでは、技術選定やリファクタリングといった観点から、高速なサービスの成長を実現する為のエッセンスをお届け致します。
参加したきっかけ
自身が開発しているシステムでは稼働歴が長くなるにつれて技術的負債が溜まっており、負債を解消するために様々な取り組みをしていきたいと考えています。
そのため、リファクタリングの話が経験豊富なCTOの方々から聴けるという本イベントに関心が湧き、参加しました。
イベントで印象的だった箇所
綺麗に書き換えるリファクタリングに注意
エンジニアとして綺麗に書き換えたい気持ちがあるのは当たり前ですが、綺麗に書き換えたいだけの理由でリファクタリングするのはリスクに見合ったリターンが得られないという話がありました。
綺麗に書き換えることで解決したい課題をできる限り定量的に表現する作業が重要で、そのためにソースコードをビジネス価値に変換する努力をエンジニアがしていく必要があるという意見が出て、深く共感しました。
ソースコードが汚いのでリファクタリングしよう、位の感覚でリファクタリングするのが理想形の一つだと思っていたのですが、考えを見直すきっかけになりました。
ビジネス的に成長しているソフトウェアのリファクタリング
成長しているビジネスのソフトウェアは仕様が複雑になりやすいため、コードが複雑になる前提を忘れがちだという話が印象的でした。
リファクタリングはソースコードに対して必ずしも行う必要はないので、アーキテクトやソースコードのリファクタリングのみではなく、仕様を減らす(or単純にする)リファクタリングも検討していく重要性を実感しました。
リファクタリングが嫌なメンバーの話
コードを書き換えるのを嫌がるエンジニアの話を聴けたのは、現場だとそんなに周りにいないので貴重でした。
単純にそのような価値観に触れ合えたのも有意義でしたし、どういう風に説得するかの話が聴けて良かったです。
その他
戦略的余白の重要性やリファクタリングのアンチパターン、リファクタリングや技術選定のリスク管理、リファクタリングとテストの関係性...の話が聴けました。
CTOの方々の頭の使い方や多数の経験談の話が聴けて、楽しかったです。
感想
技術選定やリファクタリングについて、CTOの方々の話が聴けたのは有意義でした。
また、リファクタリングというビッグワードに対して解像度を上げた後、「リファクタリングをなぜやるのか」「技術選定がなぜ大事なのか」みたいな所から話が始まってくれたのが好印象でした。
6年間かかって技術的にボトルネックになっていたソースコードをリファクタリングした話や、リファクタリングの成功談(ドメインモデルのリファクタリング)失敗談(誰もが問題意識を持っているモジュールに対してリファクタリングを試みるも頓挫した話)など、リアルな話が多く聞けたのも楽しかったです。
リファクタリングに関して、コメント欄でも多数の質問があり、皆さんの関心度の高さが伺えました。
印象的だった部分以外でも参考になる考え方が数多く聴けたので、参加できて良かったです。
