コードの不吉な匂い（変な名前を付ける遊び）

コードを見てると不吉な匂いが色々あります。
色々面白い名前つけれないか個人的に勝手に考えてみた。

いや別に真面目な話をしてるのではなくて、以下の図書3章に変な名前つけて笑おうぜってだけの話。

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

WETコード（重複したコード）

DRY コードの対極。
要するにコピペか何かで重複したものがあるコード。
WETコードは別に造語ではなく存在する言葉。

ロングストジャーニー（長すぎるメソッド）

スクロールがまるっと埋まるくらい長大なメソッド。
処理終了の道のり（ジャーニー）が長すぎる（ロングスト）から。
やることがい敗詰まっててテストコードが書けない状態。

感動の超大作（巨大クラス）

クラスの役割が多すぎてテスト数が爆発するような状態。
きちんと役割ごとにオブジェクトを切り分けよう。

ちゃんぽん（引数過多）

パラメータリストがアホみたいに長い問題。
引数6個から一気にバグが出るらしい

Googleの2億行のソースコードを解析した結果、関数に渡す引数の順番を間違える系のバグは、引数の個数が6個以上になったときに著しく増えるので - TWILAB

片頭痛（変更の偏り）

変更があったときに、一部分に変更が偏る問題。
大体このケースだと、特定一部がなんでも屋みたいにいろんな処理をしてて、バグ直しが集中してる。

大抵この値が高い

循環的複雑度の指標 - Qiita

村落（変更の分散）

たった一つ直すだけで、関連個所があれよあれよと大量に変更される状況。
メソッドの役割をきちんと定義せずに、しかも密結合しているとこんな状況がまま発生する。
綱渡りみたいにギリギリの依存で繋がってるので、修正時のバグを食いやすい。

横つながりが無駄に強い感じ…村かなと思ったけど、もっといい名前ないもんか

不倫メソッド（特性の横恋慕）

他のクラスインスタンスのしかも中身の変数に依存して何か処理をしている状況。
そもそも論メソッドのあるべきクラスを間違えてる可能性がある。

魚群（データの群れ）

アカウント名、パスワード、表示名、メールアドレスのような、関連して一緒に動きそうな情報が、クラスにまとまらずに動き回ってる状態。
データに対して処理するメソッドが各所に散らばるので、論理的なバグが出た時何処で問題が発生したのかわからなくなる。

基本データへの執着

変な名前思い浮かびませんでした…

「こんなにパラメータ少ないのにオブジェクトにまとめるとか面倒なんですけどー」とか言ってバラバラのデータを使ってるケース。
もしくはオブジェクト配列に突っ込んで渡すとかいう、引数増やすより酷い状況。

パラレル継承

これもネタにしづらかった。
関係ある A クラス B クラスがあって、A' クラスを A クラス継承で作ろうとしたら、なぜか B' extends B しないといけないという設計。
具象クラスにベットリ依存しすぎてポリモーフィズムが効いてないクチ。

ペテルギウス・ロマネコンティ（怠け者クラス）

名前は Re:ゼロ から。
リファクタか何かの結果、使用しなくなった処理。

怠惰ですねぇ～

疑わしき一般化

茶化す名前が思い浮かびませんでした。
「多分どっかで欲しくなるはずさー」という希望的観測で追加され、息をしていない潜在能力。

YAGNI 原則違反

サーセン途中で力尽きます。
いずれにせよ、バッドノウハウも覚えておけば何かと役に立ちます。

TDD アンチパターンの「嘘つき（テストしてるように見せかけて実は何もしてない）」とか「ローカルヒーロー（特定環境でだけ動くテスト）」「検閲者（テストしたい気持ちが行き過ぎて、private とかアクセス制限をブッチするテスト）」とか名前があった方が覚えやすいからね…。