こんにちは、大井です。

今回はリファクタリングのススメということで紹介していきます。
皆さん、リファクタリングはしていますか？

組織やチームの中でプロダクトの品質や属人化に課題感がある方向けの記事となります。
色々な場面で役立つと思いますので一部分でも参考になれば嬉しいです。

 

リファクタリング (refactoring) とは何か

さて、検索するとリファクタリングにまつわる情報はたくさん出てきますね。

コンピュータプログラミングにおいて、プログラムの外部から見た動作を変えずに
ソースコードの内部構造を整理することである。…中略…ただし、十分に確立された技術とはいえず、
また「リファクタリング」という言葉に厳密な定義があるわけではない。
～Wikipediaから引用～

要は中身を整理・掃除しましょう！ということですね。テーマが年末っぽい！

関連する手法については色々なサイトで情報が得られるのでここでは割愛します。
お伝えしたいこととしては仕様を見直したり、シェアする仕組みがある程度あるだけで
属人化の軽減や標準化に近い効果が見込める。ということです。

ポイントとしては自分たちの環境や組織の中でできる範囲でフィットする形を探り、
完璧な制度や精度を目指さないことです。
多少色々なやり方があっても他の人が見てわかりやすい事が正義。

ちなみにですが私はリファクタリングよりも
動くモノを素早くアウトプットできる事の方が重要であり、
パッと一発作って終わりのタスクであればリファクタリングは不要とも思っています。
ですが一発作って終わりって、実は少なかったりしますよね。

 

メリットとデメリット

リファクタリングにおいて私が考えるメリットは上でも書いた通りですが、
ある程度の仕組みや習慣があるだけで品質や後続タスクのコストはだいぶ変わります。

デメリットとしてはやり方にもよりますが、
時間はかかりますし人によっては億劫に感じる方もいると思います。

なので始めは簡易な形で行いメリットを享受したうえでやり方を洗練し
そもそもの計画にリファクタリングを組み込めるようになっていく
必要な工程である共通理解を持てるようになるのが理想です。

 

テストはするのが当たり前

さて、少し話が変わりますが例えばプロダクトを開発する上で
「テスト」が必要な工程であるのは疑いませんね。
なぜでしょうか？ここから考えてみます。

超ザックリ言うと、テストをしないと恐ろしい事が起きる。
恐ろしい事＝やりたい事が出来ない。あるいは間違ったモノが出て行ってしまう。
後はご想像通り。なのでやりたい事が出来ている保証する為にテストを行います。
これは優先度も重要度も高いのでわかりやすいですね。

では、リファクタリングはどうでしょうか？
ここでの考え方としてはやる理由を探すのではなく、
いったんはやらなかった場合を想像してみます。

大前提として動くモノができているものとします。
作ったモノが評価されて拡張や別の機能開発を繰り返したとします。

ロジックの転用等でだんだんと中身が汚くなっていき、メンバーも入れ替わっています。
ちょっとした改修でも時間がかかるようになり、不明点を聞いてもわからない。
それでもなんとか作りますが不具合が後を絶たない。
気づけば当初のパフォーマンスは失われています。。。

リファクタリングをしない先に待ち受ける未来は恐ろしいのですが、
ゆっくりとやってきます。なので優先度が下がってしまいます。
ですが重要度は高いと思います。
少しの手間をかけるだけで少し先の未来でかかるコストを削減できます。

考えるほどリファクタリングをしない理由が無い。そんな気がしてきませんか？

でもどうやる？いつやる？既に恐ろしい状態になってます…
そんな状態の方も多いと思います。
そこで最初に挙げたポイントの通りできる範囲でフィットする形を探してみませんか？

ここからは簡単にですがやり方を紹介してみます。
まだ実践したことが無ければぜひやってみてください。

 

1人で行うリファクタリング

セルフチェックに近い感覚です。プログラムであれば
まずは他の誰かに説明するつもりでコメントをつけます。
複雑な所程丁寧に、処理の概要を書くよりもなぜそうしているのかを残すと効果的です。

後で見返すとなぜそんな処理にしたんだろう…みたいな処理って意外と多く、
スピード重視で作っている時ほどその場のキメでいったん仕様化されることがあります。

実際問題で書いてある処理はそこそこスキルがあれば読めばわかりますが
なぜそうなったのかは当事者達にしかわからないですよね。

Alteryxでいくとこちらの記事がとても参考になります

チームで行うリファクタリング

最近web会議等が増えてきた方もいらっしゃると思うので今回お勧めしたいのはこちらです。
私も最近Alteryxのデータ加工処理のリファクタリングを以下のルールでやってみたところ、
面白いですしメリットが盛りだくさんで恒例行事化されました。

・進行係を一人設定する
・時間を決める（30分～1時間くらい）
・発表者は自分の作った処理を目的から発表
・参加者は初歩的な内容でも遠慮なく質問する（チャット欄に投げておき発表後に回答）
・初心者もベテランもポジティブな気持ちで参加する
・出てきた改善ポイントは担当者が可能な範囲で最適化する（すべてをやりきらなくてもいい）

チーム内で行うことによって自分のロジックが晒される事になるのですが
自分でも見落としていた「なぜそうしたのか」が発見できたり、
もっと良いやり方を教えてもらえたり、あとはナゾの「流派」の話とかも出てきます。

結局どうする？という話になったところでどっちでもいいことってあると思います。
そこで登場するのが「他の人が見てわかりやすい事が正義」です。
「そのやり方でもxxxみたいにしてくれたらわかるわ」みたいな議論ができたら
やり方を変えたくない人がいたとしても変えずに済むなら…と頭の中の情報をアウトプットしてくれますし、
平行線の議論を終わらせることができます。

メリットだらけですね！

 

さいごに

ガチガチのルールやフォーマットで統制を取るよりも
色々な人がいることをある程度許容しあうことができれば
結果的に属人化を軽減したり（無くすことはできないと思う）、標準化の土台が見えたり
新規参画者が妙な流派に染められてしまうのを防いだりできるのではないかと考えています。

何かを完全に解決できるわけではありませんが
状況を悪い方へ向かわせない為の一手としてできる範囲で
リファクタリングをしてみるのはいかがでしょうか。

 

P.S
この記事を書いていて社会人になりたての時代、
書いたスクリプトを紙で印刷して先輩にレビューして頂いたのを思い出しました。
これもリファクタリングの一種なのだろうけど、知らずに流派に染まり、
後に別の先輩に流派について指摘されて色んな人がいるんだなぁと感じた（実際しょぼんとした）記憶がよみがえりました。

 

【メンバー募集中】