1つのif文に、大量の条件がandやorで結合されているソースをたまに見ます。
確かに、1つにまとめることで処理の重複を防ぐことができ、また、プログラムの行数も削減できます。
しかし、あえて複数のif文に分けた方が可読性や保守性が向上するケースが多々あります。
ロジックについて
その条件、同時に比較する必要ある？
レビューについて
コードレビューは後回しにしない
コードレビューは、ケアレスミスによるバグの防止や実装方法の統一性の維持など、うまく運用できれば高い効果が得られます。
とは言っても、きちんとレビューしようとすると時間がかかるので、レビューを依頼されても忙しいとつい優先度を下げてしまいがちです。
しかし、コードレビューは後回しにすべきではありません。むしろ、自身のタスクよりも優先して取り組むべきです。
クラスについて
バックエンドの役割って何だっけ？
Webシステムの場合、画面表示を扱うフロントエンドとデータを扱うバックエンドを分けているケースが大半だと思います。
サーバーやネットワークまで分けているかはシステムの規模やセキュリティ要件によって異なるでしょうが、少なくともクラスは分けているのではないかと思います。
しかし、フロントエンドとバックエンドの境目が曖昧なため、本来フロントエンドにあるべき処理がバックエンドに入っているケースが散見されます。
雑談
コーディング規約は美しいコードを生み出すか？
完璧なコーディング規約を定めて、メンバー全員がその規約に忠実に従っていれば、プロジェクトのコードは無駄の無い美しいものになるでしょうか？
必ずしもそうとは言えません。むしろ、厳しすぎるコーディング規約は逆効果になってしまう場合もあります。
そもそも、コーディング規約は美しいコードを書くためのものではありません。
クラスについて
メソッドはブラックボックスな部品であるべき
中の実装を読まないと、使い方や用途が分からないメソッドにしばしば遭遇します。
本来は、中身を読まなくても使い方や用途が分かるのがメソッドのあるべき姿です。
例えるなら、リモコンのボタンやキーボードのキーだと考えてください。
中の仕組みを知らなくても、どのキーやボタンを押せば何が起こるか分かるはずです。