はじめに
こんにちは、りゅうです！先日、会社の先輩方と「逆リファクタリングバトル」というイベントに参加しました。これは、あえてよくない設計のコードを書くことで、きれいなコードを書くことの大切さを学ぶというもです。
イベント当日は、PCを持ってくるのを忘れるという大失態を犯し、劣悪な環境での開発を余儀なくされました。「クソコードはクソ開発環境から生まれる？」という言葉が、まさにぴったり当てはまる状況でしたね。この辺りの詳しい話は別の記事で！
他の参加者の作品はこちらから！主催の方がまとめてくれています！
僕がやった逆リファクタリング
ざっくり、自分がやった逆リファクタリングの内容は以下の通りです。
- 変数名を読みにくくする（これはデフォルト装備）
- ローマ字を使う
- ローマ字と英語を混在させる
- 一貫性のない命名方法を使う
- 無駄な例外を定義したり継承したりする
- 一貫性のない継承構造を作る
- 割り算をわざわざコンピュータが行う低級言語の演算方法に書き換える（残念ながら時間内にはできませんでした...）
変数名をわかりにくくする
やはり命名規則を守ること、そして一貫した命名方法を保つことはとても大事です。開発中は自分でさえ、何を書いているかわからなくなっていました。良くないですね！
また、クラスなのかメソッドなのかが一切わからなくなる点も、非常に読みにくくしています。
汚しポイント
- ローマ字で書いたり
- 例外をローマ字で
reigaiと書いたかと思えば、次は英語でexceptionと書いてみたり
意外な発見
- 僕たちエンジニアは、結構無意識に命名をわかりやすくしているらしい
- キャメルケースやスネークケースを混在させれば、さらにわかりにくくできたはずですが、実装しているときはそんな発想がありませんでした
無駄に例外クラスを定義し、継承する
次に、こちらをご覧ください。最終的にはすべて ArgumentError を発生させるにもかかわらず、わざわざカスタム例外クラスを作成し、個別に例外をキャッチしています。
さらに、カスタム例外を最適化するわけでもなく、あるものはベースの例外クラスを使い、あるものは派生後の例外クラスを使う。かなりの愚行ですし、無駄に読みにくいだけですね。
汚しポイント
- 無駄なカスタム例外クラス（上の画像参照）
- 一貫性のない継承クラス
- 「整数」という括りで
n_1ijouはn_seisuを継承していますが、この考えでいくと、上位クラスになるべきsuuti_no_exceptionとn_seisuに親子関係がないのです。命名が分かりにくいせいで説明が大変ですが、継承関係を持つのであれば、以下のようになるべきです（正直、継承自体が必要ないのですが...） -
"kihon_no_reigai" <- "suuti_no_exception" <- "n_seisu" <- "n_1ijou"
- 「整数」という括りで
- なぜ基本の例外クラスをそのまま使っている？
https://github.com/salvage0707/refactoring-reversal-battle/blob/e3e555619c4620ea51ede7df1f3c9c251cc35877/submissions/meteor-submission/ruby/src/fizz_buzz.rb#L15 - このメッセージ設定は本当に必要だった？
https://github.com/salvage0707/refactoring-reversal-battle/blob/e3e555619c4620ea51ede7df1f3c9c251cc35877/submissions/meteor-submission/ruby/src/fizz_buzz_exception/kihon_no_reigai.rb#L1-L2
割り算をビット演算でやってみる（時間内に完成しませんでした...）
自分の開発環境では、例外クラス関係の汚しだけで結構な時間を使ってしまい、残り時間で実装したい汚しとして、あえてコンピュータアーキテクチャレベルの算術演算をわざわざ使うというアプローチを試みました。
残念ながら時間内には完成しませんでした。劣悪な開発環境ではデバッグが難しく、期間内には直しきれませんでした。（後日完成させたので、別の機会に完成系は紹介します）
流石に、プログラミング言語が抽象化しているものを手動で実装するのは愚行だなと思いつつ、知的好奇心と挑戦心でやってみました！
ちなみに実装の参考にしたのは、世界で最も有名なコンピュータの教科書「パターソン＆ヘネシー『コンピュータの構成と設計』第5版 上巻」です。
この時点での作成結果
まとめ
今回、逆リファクタリングバトルに参加して気づいたのは、持っている知識や引き出しによって「汚し方」が変わるということです。ある程度の知識がないと、効果的に悪いコードさえ書けないというのが大きな発見でした！
アンチパターンの学習の重要性について、改めて認識できた会でした。
Discussion