重複したコード (Duplicate Code) 同じようなコードの並びが、複数の場所で見られる。 長すぎるメソッド (Long Method) メソッドが長くて理解しづらい。 巨大なクラス (Large Class) インスタンス変数を持ちすぎている。コード量が多すぎる。 多すぎる引数 (Long Parameter List) 引数が多くて、それらの意味がわかりにくくなっている。 変更の発散 (Divergent Change) 1つのクラスがさまざまな変更要求の影響を被る。 変更の分散 (Shotgun Surgery) 1つの変更がさまざまなクラスの変更を引き起こす。 属性・操作の横恋慕 (Feature Envy) 他のクラスの属性やメソッドを使いすぎる。 (これは他のクラスに強く関連していることを意味します) データの群れ (Data Clumps) いつも一緒に使われるデータ

かれこれ一年ほど前に実施した実サービスでの apache のチューニングネタを思い出したように書いています。 以前いた部署では少ないサーバ台数で大量のリクエストを如何に処理しきるかってことに燃えていたので、静的コンテンツなどをブラウザに支障のない範囲で最大限にキャッシュさせ、サーバとネットワークの負荷を最小化させていました。 当時参考にした情報源は以下の３つでした。 どのようなレスポンスヘッダを返しておけばブラウザキャッシュを最大化できるかのテクニックがまとめられています。 ブラウザキャッシュとレスポンスヘッダ - murankの日記 Kazuho@Cybozu Labs: キャッシュの上手な使い方 [Studying HTTP] HTTP Status Code チューニングにおいて重要なのは自分自身での検証。というわけで自前で検証した結果と検証するために用意したプログラムを公開します。