あなたもクソコードの世界に触れてみませんか?? - 逆リファクタリングバトルのイベント報告 -
「コードは綺麗に書くべき」
そんな呪いにかかっていませんか?
「可読性が正義」「保守性が命」
確かにその通り。
でも、そこに縛られすぎて“自由に書く楽しさ”を忘れていないでしょうか。
コードなんて、本来もっと遊んでいい。
ときには破壊的に、意味不明に、カオスな方向へ振り切ってみてもいい。
今日はその逆方向へ思いっきり振り切る遊び「逆リファクタリングバトル」というイベントをしたので、その内容を共有しようと思います。
Hello. クソコード!!
はじめに
こんにちは。初めまして。まるべいじ(malvageee)と申します!
先ほど、少し刺激的な言葉で始めましたが、この記事は「汚いコードを推奨する」わけではありません。
むしろその逆で、あえて汚く書くことで、普段どれだけ可読性や構造に助けられているのかを再発見するための試みです。
私たちは日常的に「綺麗に書く」「読みやすくする」といった正論の世界でコードを書いています。
それは正しく、大切なことですが、一方でいつの間にかそれが“当たり前すぎて意識しなくなる”こともあります。
そこで今回、あえて常識をひっくり返すイベント
「逆リファクタリングバトル」 を実施しました。
参加者全員が意図的にクソコードを書き散らすという、普段なら絶対に許されない遊びです。
結果として、想像以上に盛り上がり、同時に多くの気づきが得られました。
この記事では、そのイベントの雰囲気、どんなカオスなコードが生まれたのか、そして得られた学びをまとめていきます。
自分で書くコーディングはやっぱり楽しい!!!!
イベントについて
レンタルスペースに5人で集まり、オフラインの個人戦として開催しました。
まずはアイスブレイクとして1時間ほどボードゲームで肩慣らし。その後、ルール説明を挟んでから、2時間の実装をしました。
最後は参加者それぞれが「どこをどう意図して崩したのか」を発表する形式です。
集まってくれた皆さんありがとうございます。
課題は「正しく動く FizzBuzz」
目的は「綺麗に書く」ことではなく、あえて悪い設計・読みにくい構造を作ることです。
フォーマッタを通しても残る本質的な読みづらさで勝負します。
ルール
Ruby / TypeScriptで事前に実装されたFizzBuzzを利用して汚くしていきます。
▫️ 目指すもの
- 動作の正しさ(テストが通ることが前提)
- 逆リファクタリング度(構造・抽象化・制御フローのひどさ)
- 学び・説明性(何のアンチパターンを狙って書いたのか)
- 芸術点(アイデアの面白さや意外性)
▫️ 禁止行為
- 単なるミニファイ、テストコードの改変
- フォーマッタ設定の変更
- sleep乱用などテスト実行に支障のある行為
- AIでのコード生成(AIに質問はOK)
こちらはAIに作らせた回文判定処理のサンプルですが、こんな感じの無駄に処理を複雑化させて遊ぶイベントです。
作品紹介
こちらが私の作品です。こちらの3つの処理を抜粋して紹介します。
※ タイポやよくわからない変数名は標準装備なので割愛
① 標準出力してくれるconsole.logなんてものはありません
console.logを書き換えることで、Fizz, Buzz, FizzBuzzという文字列を返してくれる素晴らしい関数を生み出しました。
これのおかげでconsole.logの戻り値を利用するという奇妙なコードを見ることができます。
② debugLogという本来不要な処理
クソコードを書くときは可読性が下がるのでデバッグが一苦労です。
でも安心してください。console.logで出力してしまえば変数に何の値が入っているか見ることができます。
console.log(someVariable);
=> TypeScriptの引数エラー
あれ、引数エラー。
そうだった。console.logを上書きしたんでした。
console.logは使えないので、別の方法を探してログ出力できるようにしました。
非常に無駄な処理ですね。
③ 文字列のコードを実行したい
JavaScriptにはevalという便利な機能がありますね。
これはRubyのsendのような文字列のコードを実行できる関数です。
ですが、evalはセキュリティ上の理由からBiomeがエラーを出すため、使用できません。
しかし、なんとしても文字列を実行したい。
そんなあなたに朗報です。
new Function()を使うことで文字列で関数を作ることができます。
いかにも危なそうな雰囲気の機能ですね。
各参加者の作品紹介
参加者の作品を軽いコメントで紹介します。
詳しく知りたい方は、リポジトリを見てみてください(もしくは作者からZenn記事出るかも...??)
① 過度な抽象化・分割
設計する上で抽象化や分割は大事ですよね?
でも、やりすぎると違うんです。
継承の一貫性もないと発狂ものです。
② FizzBuzzを実装するためのリストを生成するためのFizzBuzz処理??
1〜100までの数値の場合はリストに設定された値を見て判定するという拡張性のない実装をしてます。
そのリストはどうやって作ったのかって?
それは、、、別でFizzBuzzを作って出力したらしいです。。。w
③ 動的にコードを作ろう
やろうとしていることが推測できなすぎて、謎質問を繰り返していた参加者です。
作者「ミニファイを禁止してますが、1行で作られているがテストを実行すると展開されるのはOKですか?」
他の人「???」
Rubyの柔軟性を再確認できたプログラムです。
④ クソコードはクソ環境から 〜 iPhoneから送信 〜
技術書3冊。キーボード。マウス。その他周辺機器を完璧に持ってきて本気で挑んでくれました。
そう。PCを除いて。
iPhoneにキーボードとマウスを繋いで、WebのVSCodeを使って書いています。
めっちゃ辛そうでしたが、負けじとbit演算を用いたクソコードを作っていました。
「エディタと戦ったで賞」を授与します。
さいごに
クソコードを書くというのは、想像してたよりも難しかったです。
業務ではあまり使わない引き出しの多さが求められます。
無意識で「綺麗に書かなければいけない」という思考が働くので抵抗するのに精神力が必要です。
書いたり見たりすることで、今まで持っていなかった引き出しを知ったり、自分でコードを書く楽しみも思い出せたので、またやってみたいです。
あなたもクソコードの世界に触れてみませんか??
Discussion