なんか仕事場で規約に悪態つきまくってる気が
いい子ぶるつもりはないけど、いい加減に悪態つくのはやめないと信頼関係崩しかねないよな(;^_^A
とにかく規約がむかつくのです。ﾌﾟﾗｲﾍﾞｰﾄｸﾗｽがダメならダメってはっきり書いてよ！「クラス定義はファイルに一つだけとする」じゃ見落とすってばよ！VOにsetter/getterしか作っちゃダメなら作らないで済むようなテーブル構造にしてよ！内部クラス持たせてその中で管理したほうが楽なくらいでかくて冗長なテーブル作るのがいけないんだと思う。全部VOのsetter/getterにしたら、メソッド名は長ったらしい、メソッドの数は異常に多い、しかも似たり寄ったりな名前、という見通しの悪い極悪なコードができあがるっつーの！せめてテーブルの正規化くらいして欲しい。
JSPに業務ロジックを書いちゃダメ。ごもっともです。で、どこまでが業務ロジックですか？VO以外はJSPで一切使っちゃダメですか？明確な基準を提示してよ！
本来、ソースレビューとはロジックに誤りはないか、ソースは読みやすいか、無駄なコードはないか、規約は守られているか、などをチェックするもの。前にも述べたけど規約は処理方式を統一して管理しやすくすることでソースを読みやすくする、というのが本来の目的。なんか今のプロジェクトは規約を守らせるためにソースレビューがあって、ソースの読み易さとか二の次なんじゃないのかって気がしてくる。
厳しすぎる規約なんざ百害あって一利なし。開発効率は落ちる、開発メンバーのモチベーションは落ちる、そのため生産性の低下を招き、スケジュールはタイトになり、さらなるモチベーションの低下と品質の低下となりプロジェクトは火を吹きはじめる。うん、まさにデフレスパイラル。
モチベーションの低下とスケジュールのタイト化は、開発メンバーの体調不良の引き金にもなりかねず、ていうかみんな体調崩し始めてるし(;^_^A
チームの管理体制に大きな不備は見えないし、なんでこのプロジェクト火を吹いているのだろうって考えると、厳しすぎる規約、使いづらい共通部品、複雑怪奇なデータベース構造の三つに集約されると思うのだ。テーブルが複雑だから業務ロジックも複雑になり、（*1）共通部品が使いづらい（*2）せいで、環境に慣れていない者は四苦八苦するため人員を増強しても環境に慣れるまでに時間がかかり、また規約が厳しすぎるせいで、これまた人員の増強の即戦力化を阻んでいるという…。
そもそも読みやすいコード書くのは、誰でも容易に理解が可能とすることで、人員の即戦力化、開発効率（特に保守効率）のアップを図るためなのだから、やはりこのプロジェクトは本末転倒になっているという…。
そもそもJavaの常識が通用しないJavaプログラミング規約とは一体？
