はじめに
はじめまして、kaiba と申します。
ソフトウェアエンジニアはきっと誰もが穴があったら入りたくなるようなコードを書いた覚えがあるのではないでしょうか？ まれに最初から 100 点の設計ができる人もいますが、僕もたくさんいわゆる「クソコード」を書いてきましたし、見ても来ました。 良くないコードとわかっていても直すことができず、良くないコードを更に良くないコードにしたこともありました。
そもそもコードが汚いと以下のような問題があります。
- 読みづらい
- 変更がしづらい
- 新たなバグを誘発する
- コードからプログラムの挙動が予測できない
- バグを抱えたまま動き続ける
- パフォーマンスが落ちる
経験を積んでくると、よくあるパターンがいくつか見えてきました。 本書は僕が書いてきた・見てきた・聞いてきたプログラミングアンチパターンについて以下を紹介します。
- アンチパターンの紹介
- 何が問題なのか
- どうすればよいのか
僕自身まだまだアンチパターンを生み出す未熟者で、偉そうなことは言えません。
僕が大好きな本である「SQL アンチパターン」をリスペクトして、各章にアンチパターン名を付けながら、恐る恐る書いてみます。
対象読者
- プログラミング初学者で自分がクソコードを生み出したくない人
- 「こういうの俺も書いたわ〜」と懐かしみたい人
- 後輩の指導に困っている人
注意事項
- 「クソコード」は否定的な意味合いが強いです。自分の書いたコードに対してのみそういうべきと考え本書はそのようにしています。
- 本書のコードは僕が書いたり、見たりしたコードについて書かれていますが、特定の企業のコードであることは記載していません。僕の趣味のコードのことも書かれています。特定の企業と勝手に結びつけて非難中傷をしないでください。
- 「どうすればよいのか」を示してはいますが、どのケースにもマッチするとは限りません。参考にしつつ最適な設計を考えてください。
- 本書は Ruby 及び Ruby On Rails のコードをサンプルにしていますが、どのプログラミング言語でも応用が効くレベルの簡単なコードにしてあるつもりです。そのため、Ruby ならもっと短く書けるケースもあえて冗長に書いています(例: 後置 if、return の省略)。
- 後半に進むほど高難度になっています。難しいと思ったら読むのを一旦やめてみてください。
初学者が陥りやすいアンチパターン
マジックナンバー
マジックナンバーとは何かしらの意味がある数値です。 具体例を見てみます。
item.price = new_price * 1.1
item.status = 3商品の価格に税込みの新しい価格を設定し、ステータスを 3 にしています。
何が問題なのか
価格に 1.1 をかける。 これは消費税の計算だとわかりそうですが、果たして 10 年後もこの数字は変わらないでしょうか? ステータス 3 は grep したり、ドキュメントを読んだりしないとわかりませんね。
以下の 2 点が問題です。
- 数字の意味がコードから伝わらない
- 漏れなく数字を更新するのが困難
このコードを書いた当時は税金の計算をする箇所が一箇所で問題なかったのかもしれません。
しかし、税金の計算箇所は増えていくもので、税金が 15% になったときのことを考えてみます。
たくさんの場所で 1.1 もしくは 10 を使っていそうなので以下のように検索します。
不安なので tax も検索しますか…
grep -R "1\.1" ./
grep -R "10" ./
grep -Ri "tax" ./\n10 は他の場所でも使っていて、税金なのか人力でチェックする必要があります。 100%バグらずに直せるか問われると冷や汗が出てきます。