くたばれカーゴ・カルト・プログラミング
何？
Wikipedia によると。
実際の目的には役に立たないコードやプログラム構造を儀式的に含めておくプログラミングのスタイルである。カーゴ・カルト・プログラミングは主に、プログラマが解決しようとしているバグか解決策のいずれかかまたは両方を理解していない場合に見受けられる。 他にも、スキルの低い、ないし新人プログラマ（または当面の問題を経験したことのないプログラマ）が、そのコードが何をしているか理解が足りないまま、またはもしかしたら新しい場所にも必要なのではないかと、別の場所から関係ない部分も含めてコードをコピーしてしまうことで発生する可能性がある。
ひいてはコピペ駆動開発
どうして
不要なコードは、ロジック的に余計な処理であるがゆえにバグを生み出す温床（しかも実装者がわかってない事が多く、余計にバグりやすい）であったり、本来行うべき処理を読み取る中でノイズ（雑音）となって、レビュー時間、もしくは保守時の工数を浪費してしまう。
性能（無駄な処理）、安全性（余計な処理によるバグ発生）、保守性（可読性の低下）全てに悪影響をもたらす忌むべきもの。
どうする？
大抵は書いてあることの意味を理解していない為に起こる。
これには大きく分けて二つのパターン、もしくは両方の場合がある。
- コピペ元がそもそも煩雑で、追いかけ切れない
- ボーイスカウトの原則を守られず、コードが秘伝のタレになっている
- 色々検証してて、動いたからいいやとリファクタをサボった
- 可読性に無頓着でともかく手続きを並べまくってそのまま
- 実装者が元のコードを読む気がない
- やる気が無い
- 読んでる時間的余裕がない
時間的余裕がない場合を除き、コミット前に書いた部分を最初から見直すのが一番。
また、修正の場合でも関連箇所はもっと共通化分けできないかとか考えるのが良い（DRY原則、ボーイスカウトの原則）。
「１行１行注視して読める」では足りない。
メソッド化と分離を繰り返すと、次第にメソッドの流れは単純な複数のメソッドコールになっていく。
結果として、「流し読みできる」レベルで抽象化しているのが望ましい。
蛇足
因みにレビュアーの観点でこれをやるプログラマのもっともあるある Top3 は
- 可読性に無頓着でともかく手続きを並べまくってそのまま
可読性の重要性を理解していない。
知らないだけのパターンが多く、丁寧に説明すれば大体わかってくれる。
それでダメなら、スパゲティなコードの保守プロジェクトに突っ込んで、次に原理主義的に綺麗なコード（オープンソース）のカスタムを経験させるに限る。 - コードが秘伝のタレ
特にプロマネがせっつくだけで品質に興味がない場合で発生しやすい。
この場合、現場が整理したいって言っても大抵工数を理由に拒否されるか、「動いてるのに手を加えるなんてありえない」と拒否される。
この場合は、バグ数を理由に、レビューの実施（にかこつけてリファクタしてしまう）。 - やる気が無い
このタイプは大体２タイプ。どっちも「こんなに戻って仕事進まないなら覚えた方がマシ」と思わせたら勝ち。- もらう金一緒なのに苦労とかしたくない派
→ 超絶レビューバックで矯正。 - そんなのしなくてもやってこれた派
→ 汚いコードに劣等感持つまで、リファクタのやり方を指摘。
- もらう金一緒なのに苦労とかしたくない派
