定数化のポリシー

ははっきりして欲しいよな…。なんか良く分からないけど定数化したいですとか、そういうのは勘弁して欲しいな。極端な例を上げると、


public static final int CONST_1 = 1;


みたいな定数を作る人って稀に居るからね。そこまでの馬鹿には滅多に会わないけど。Java 1.5 からはリテラルの文字列は intern されて Heap 上には実体が 1 つしか存在しない、みたいな話があった筈なんだよね。それにクラスを Persistence にロードするにしても文字列の実体は保持していないだろうし…。つまりリテラルをバラバラに書いてもメモリの浪費にはならない筈なんだよ。だからパフォーマンス的な問題は起きない訳じゃないですか。
そうなると保守性や開発効率だけを考える事になると思うんだよね。定数を使うと Grep し易いというのはメリットではある。シンボル検索も出来るし。後々になって値を一括して変えたい、という場合も楽に出来るというメリットはある。修正箇所が少なくなれば差分も少なくなるし。定数を使って複数の開発者で開発をするとバラつきが少なくなるというメリットはある。一般的には値に意味を持たせたいってのがあるよな。同じ 1 という値でも、値が持っている意味が違うから名前を付けたいんだって目的な。それとかマジックナンバーとか見た目じゃ訳が分からない値もだな。単純にタイプミス防止ってのもあるな。でも定数化してもミスは起こり得るんだけどな。似た様な定数が一杯あるとミスる。同音異義語みたいなのとか。定数を使っているからミスり難い筈って思い込みが死角になってミスし易い、という意地悪な考え方もある。IDE で光るというメリットもあるな。それとか、今は意味をなさないけど定数化して置く事によって、その定数が大量になって来た時にビッグデータ的に何らかの活用法が出て来る可能性を見越して…というのもあるかもな。将来的に次のバージョンを作った時に定数ファイルを活かして辞書を作る…とかな。
だけど開発者の全てが必ず定数を使ってはくれないかも知れない、という問題は残る。定数を使うルールを知らない人が居たり、知ってても無視する人が居たり、ミスをする人は居る。だから定数は必ずしも万全ではない。検索性や統一性や一括置換性のメリットを出す為には、定数を使うという事を口が酸っぱくなるぐらいに強制する人物が必要になる。これは定数に限らないんだけどさ。コーディング規約とかを守らせる為にはレビューをしたり、何度も何度も口頭で注意したり、そういう骨の折れる事をしなきゃならなかったりするんですよ。寄せ集めの大所帯で開発してる時は特に。そういう口煩いプロパーが居なきゃ出来ないんですよ、居ないにしてもプロパーがそれを明示的にでも暗黙的にでも承認する人物が居ないと。そういう人物は嫌われ役でも良いし尊敬されてる人物でも良いしめっちゃしつこい人でも良いし金を握ってる人でも良いし、何らかの力で強制力を持つ人だったりすると思うんだけど。
後はリリースの時とかに置き換えるファイル数を少なくする事が出来る、というメリットはあるかもだけど。それにしてもそれによって影響を受けるファイル数は変わらないから、テスト工数が減る訳ではない気がするし。
それと一括して置換したいというメリットというのは、本当に一括して置換するという要件がありそうな場合に限るからね。個々の定数を利用する箇所がバラバラに値を修正するという要件が発生するのであれば、却って逆効果にもなりかねない。ここは良く考えて欲しい所なんだよなあ。逆に自動生成で何度も定数ファイルを置き換えるかも、みたいな事もあるかもだし。流石にそういった場合は DB のマスタテーブル化をするかもだけど…。
現状では値がどうなるか分からないけど、こういう意味の値が存在する、みたいな IF だけはっきりしてる時は定数を使うと良いかも、っていうメリットもあるな。
テストコードを書く時に定数があるとテストコードの保守にも便利ってメリットはありうる。それにしてもテストコードを書く場合でしか生まれないメリットだけど。テストコードを書かない職場ってのも少ないけどあるからね。逆にテストコードが納品対象な所もあるだろうし。テストコードだけじゃなくてテスト仕様書やテストデータも考えないとなあ…。
後は設計書との一致性を維持し易いか否か、これは難しい所なんだよな…。どんな書き方で設計書を書いたのかにもよるというか。納品対象としての設計書だったり、使い捨ての設計書だったり、納品してずっと大切に保守する積もりの設計書だったり、そういう違いも大きいだろうし。定数のソースだったら設計書から自動生成する、というルールは良くあるかもな。
定数の影響範囲とかも考慮しないとな。Java の定数を作ったとして、それが Java、JSP、JavaScript、XML、HTML、XHTML、プロパティ、SQL、ストアドプロシージャ、DB のビュー、…といった物からでも参照可能か否かとか。参照可能な範囲が中途半端だと困るんだよな…。複数の言語に対応するとなると、Java で日本語が使えるからと言って日本語定数を作ったりすると他の言語との整合性を取れなくなったりするし、そういうのも注意が必要だな。ソースの全文検索とかに対応する為に長い名前にするとかもあるのかなあ…。
定数に限らずプロパティファイルとか外部ファイルとか DB のマスタテーブルとかも同じ様な事が言える訳だけど。そういうレベルの違いがあるとホットデプロイ性とかにも違いが出て来るから、それはそれで色々と考えなきゃならなくなるよな。定数の場合は多言語対応は流石に考えないか…。
「作り」との整合性って問題もある。こういったパッケージ分けで、こういったクラス分けで、インプットとクラスとアウトプットの対応がこうなっていて…、みたいな幾つかの前提条件を満たすと、ここは定数化すべきだって思ったり、逆に定数化したら「何の為にこういう作りにしたの？」って言いたくなって来る場合もあると思う。そこも考えて欲しいなあ。何の為ってのも微妙な所なんだけどね…。次元の違う問題として「御金の為」って話も出て来るから。馬鹿な客を相手に工数を水増しして金を要求する為にこういう作りになってる…みたいな話もあるからねえ…。世の中は難しいよ…。
デバッガを使った時に名前付きシンボルがあると見易い、というのはあるのかも知れない。逆コンパイルが上手く行き易いとか。Java は良く分からんけど。VC++ で PDB ファイルを使ってデバッグしてる時はシンボルには気を使ってた気がする。
デメリットとしてはコードが見難くなるというのがある。これは「値その物が見えないから」というのもあるし「一般的に定数というのは文字数が非常に多く、横に異常に長いコードになってしまう」というのもある。これが非常に嫌な所で…。このデメリットは開発時も保守時も効いて来る。でもこの問題は将来的に Eclipse みたいな IDE が定数ビューみたいなエディタ表示モードを用意して解決される可能性はある。つーか早く用意しろ。後は定数ファイルに定数を追加したりしてから定数を利用しなきゃならなかったり、定数の数が異常に多くなって来ると既存か否かを検索しなくてはならなかったり、そういう問題が発生して工数が膨らむ、という問題も当然に起こる。複数の開発者が同時に開発をしてると、定数の命名規約が曖昧だったりして、同じ値が別の名前で定義されたりする事もある。定数ファイルに同時に更新を掛けて、コンフリクトの発生頻度が増して開発者が嫌なマージ作業を強制される、というのもある。それに半角英字大文字とアンダーバーの定数にする事によって、「氏名」と「名称」が同じ NAME という定数に割り当てられないという状況が発生したりして、段々と名前付けが混沌として来る、というのもある。名前を付ける手順や規約があったらあったで面倒臭いし、本当に守るのかって問題が残るし。ローマ字規約とか辞書とかあると凄い大変だからね。そういうのが得意な人も居るかもだけど俺は苦手だわ…。辞書に無かったりすると更に大変でさ。辞書に追加しなくちゃならなかったりするんだけど、その時に手順を踏まないと行けなかったりする所もある。申請が必要だったりね…。凄いコストだよな…。チーム開発では、値として "値1" を持つ定数「定数 A」を定義して、それを目的「目的 1」の場合に利用すべき、と誰かが定義して、それを別の誰かが勝手に目的「目的 2」の為に参照してしまう、という問題も起こり得る。それとか阿呆っぽい人がコーディングすると定数の部分にコメントで値その物を御丁寧に書いたりするじゃないですか。お前は何がしたいんだって言いたくなって来る。お前は定数に何のメリットを求めているのかって言いたくなる。もちろん値その物をコメントで書く事にメリットはあるし、そのコメントを書く事によって影響を受けない他の定数化メリットもある。だけど一括置換性や修正ファイルの最小化やリリースファイルの最小化といったメリットは影響を受けてしまう。そういう場合はコメントが邪魔になるんだよ…。コメントも一緒に置換しないと整合性が取れなくなる。だけどこの問題は設計書の修正にも派生するので、その辺りも一緒に考慮して考えた方が良いのかな。変更管理的な、何と言うか、変更した時は確実にこれだけの作業が必要で、これだけの工数は必須で掛かります、みたいなのがはっきりしてれば良いのかな。変更にこれだけの工数を掛けるのは国際競争力的にも問題がありませんし、保守性も低下せず万全です、って言えれば尚良しなんだけど。でも一括置換性とは言っても値だけを変えずに、そもそも定数名を変えなきゃ整合性が取れない、って事も多いんだよなあ…。実は定数名を変えても、それだけじゃ足りず、関係する変数とかゲッターとかセッターとか、色々と名前を変えなきゃ変になるって可能性もある。でもそういった事を考え出すとキリが無いっちゃ、そうなんだよなあ。
つまり将来に想定される変更を正しく予想して、それに見合ったポリシーがあれば良いんだよ。無いのは嫌だなあ…。難しい事を要求してるのかも知れないが…。正しく予想するのは難しいにしても、責任のある人物が大々的にポリシーを謳って欲しいんだよな。出来ないなら定数化したいとか言うなって言いたくもなって来る。だけど逆に自分がその立場になったら辛いなあってのは理解が出来るから、俺も表立って批判したりはあまりしないけどさ。でも下っ端の立場からすると嫌なんですよね、好い加減な感じに進むのは。まあ後々になって色々と直すにしても、その為の工数や御金がちゃんと出れば良いんだけどね。出ないとモメる原因になるよな…。だからアレですよ。俺は俺として責任は取れないので、軽くチクっと「俺は言ったぞ」って状況を作って行くぐらいしか無いんだよなあ…。そのレベルじゃダメなのは認識してるんですよ。それでは保身のレベルでしかない、そうじゃなくてプロジェクトを成功に導けるレベルにならなきゃプロフェッショナルとは言えない、そうは思っているんだけどね…。力が足りないんだよなあ…。
俺自身も 100 % 規約を守って書いてるかって言うと、そうじゃなかったりもするからね…。これは重要だって所は流石に守る様にしてるけどさあ。はっきり言えないのはそういう後ろめたさもあるからってのは言える。でも俺は規約をしっかりと守らせたいのなら、規約を学ぶ時間や教授する時間を設けるべきなんじゃないのか、って思ってるけどね。WBS に開発の線しかなくて、その線の中で規約を読みながら進めろ、ってのは外注の人達を馬鹿にしてると思うんだよなあ…。その職場の生え抜きみたいな人は、他の職場の事を知らないから「×××って言ったら○○○の事でしょ」って外部の人を馬鹿にする人もたまに居るけど、外部から来た人にすればそういう人は可哀想な頭の人に見える訳で「×××には○○○という解釈も□□□という解釈も△△△という解釈もあるのに…」って心の中で思いながら溜息をついて「すみません、そうでしたね…」みたいなバツの悪い返事をしたりする。要は外部から来た人には、その職場の独自のルールや文化を学ばせないとダメなんですよ。外部から来た人は共通語しか知らないんで…。
やる気がある人って言うのは外注でもプロパーでも変わらないのかも知れないけど、やる気がそんなでもない人の場合は外注とプロパーで差が出る気がするんだよな。そうでもないか。「金を出さないぞ」って言われた経験があるか無いかかなあ…。プロパーの場合は顧客から、外注の場合はプロパーから「金を出さない」って言われると「ああん？何を言ってんだ」って感じでモメる訳ですけど、この経験があると、やる気があっても無くても仕事への取り組みは変わる気がするんだよね…。でも金持ちのボンボンとか脛齧りの寄生虫みたいな人は別かもだけどさ…。モメる時に言った言わないとかの問題が起こったりする訳ですよ。そういう時に「ここはそちらから質問して来て当然なところでしょう」みたいな言い方もある訳ですよ。要は訊くべき所を訊かなかったって言われる訳だよ。何を言ってるんだ、お前から言って来るべきじゃなかったのかって言いたくなって来る所なんだけど。そういうのが起こり得るからチクって言って置くのは避けられないというかねえ…。一々そういう事を言って来るんじゃねえって思う人もいるんだろうけど、それならそれで後になって絶対に文句を言うなよって言いたくなって来る。我々は必要な事は全て伝えたので、そういう事は言って来なくて構いません、とでも言うのか…と。まあでも現実には全ての要求を一度に全て伝えられても、一気に飲み込むのは俺も無理だしなあ…。って事で程度の問題というか難しい所なんだよなあ。俺は若干の波風が立とうが言ってしまう人間というかねえ…。ちょっとずつ抑える様に大人になって来てる気もするんだけどねえ…。
でもこういう話というのは結局は企業の文化なんです、合わせて下さいって話でもあるのかなあ…。郷に入っては郷に従えってのは確かにそうなんだけどねえ…。外注ってのは何が求められているのか微妙だったりするからね。本当に扱き使いたいだけで言う事を訊いてれば良いんだ、そしてゴミみたいに最後は金を払わずに捨てられる奴が一番だって真っ黒な企業も居るだろうし、誠実にパートナーとして仕事をしたいから合わせる所は合わせて欲しいって企業もあるだろうし、内部からの変革は難しいから外部から来た人間の刺激を求めているんだって企業もあると思うんですよ。そういう話もあるんだよなあ…。定数の話でここまで話が発散するのもアレなんだけど。でもこういう所にまで話が繋がっているのは事実で。俺は 10 年超の業界経験で、そういうのが割と染み付いていて、頭では分かっていないけど上手くやって行けるような、様々な視点から見て破綻しないような行動パターンになってる筈なんですよね。それってのは業界経験だけでなくて、日本人として日本で生きて来た経験というのもある訳で。まあ難しいですよ。
何と言うか、徐々に追い詰められるのが嫌だ、みたいに思う人も居るのかもだね。徐々に言質を取られて取られて、後々になって状況が変わった時に「ああ言ったじゃないですか！」って言われるのが嫌だ、みたいな人ねえ…。まあそれは理解が出来なくも無いんだけど、そこは器量の問題というかね。俺は別に後になって「ああ言ったじゃないですか！」って責めたい訳じゃない。自分の身を守る為だよ。攻撃したい訳じゃない。だから何と言うか…。世の中には確かに「ああ言ったじゃないですか！」って、ここぞとばかりに攻撃をする奴はいるけどさ。水を得た魚の様に生き生きしながら叩き捲る奴は居るとは思うんだけさ。何て言うんだっけか、水を得た魚じゃなくて、何て言うんだっけ、そういうの…。尻尾を掴むじゃなくて…。えーと…。鬼の首を取ったかのように…だ。まあ兎に角、俺はそういう積もりで言ってるんじゃないんですよ。保険を掛けたいだけです。それと状況が変わった時に軽く不平を言うぐらいなら、それぐらいは許容してくれって思うけどね。程度の問題とは思うけど…。その辺りは信頼関係ってのに繋がる話なんですかねえ…。
久々に仕事の事で長文を書いたなあ…。