Java オブジェクト XML変換
金曜の帰りの電車でがーっと作った。
最初 serialize で通信してたのを、バージョンの意識がうっとおしいのと他言語でも処理できるようにしようということで急遽。あり物でいいのあるんだろうか…？
任意のオブジェクトを XML 表現にできるけどたくさんの制限あり。ほぼ通信向けに特化したので実用上ほとんど問題ないけど applet で setAccessible(true) が効かないことだけは痛かった…。仕方なくやり取りするクラスのフィールドは public に。
まぁこれでフィールドの追加/削除に寛容なオブジェクト通信の手段は確立された。
いつ公開するかは不明…。あと、効率はまだ調べて無い-_-。
Java は primitive と array を特化処理にしないといけないのでうざかったなぁ…。
あと、実直にフィールドを書きだすと Collection クラスとかで冗長な出力になるのでその辺も特化処理で簡潔な出力にした。しかしそうすると、それらのクラスのサブクラスをテキスト化するときにサブクラスのフィールドが書きだされないという問題があり、そういうクラスはサブクラスでフィールドの追加をするなという制限にしたり^^;。
やり取りするオブジェクトへの融通性より言語非依存性を優先して、serialize の仕組みは一切使わない、その代わりやり取りするクラスの構造をシンプルにせよ、と利用者側に責を課すことにした。
transient をどうしようかと思ったけど、書きださないことにした。アプリケーションオブジェクトなど、シリアル化が明らかに困るという目的で transient 化しているケースを想定して書きださない。フォーマットの効率化目的で transient を用いているようなクラスは XMLSerializer の対象としない。たとえば HashMap とかはそういう類。Map は特化対応したけど。
final フィールドは書きだすが、復元できない。
と、いったところ。いまのところ。
■
最近こっち書くこと無いよ-_-。
技術ネタになるようなことあんましして無いしなぁ…。
そうだ。NSUG 行く人、いるかなぁ？
何が目的か
かざきり羽というキーワードが大人気らしい。
なぜ大人気かというと、言及していたサイトがどんどん消滅しているから、だそうで、ネタで隠している人も多数。
この問題自体は以前数回ちら見していたのですが、「検証サイト」の側が、それを本来見せたいと考えられる対象よりも興味本位の人ばかり呼び込むような形で話題を広め、風評被害を与えた、という印象。ほんと普通なら気にもとめないだろうと思うようなことを一所懸命あげつらってたケースも多数ありましたし。もちろん「検証サイト」で書かれていた指摘で正しいこともあり、件の人が謝罪すべきだった点も大いにあるんですが。そして、謝罪するべき点について考えず、批判を丸ごと荒らしとして対応したことが結局問題ではあるのですが。でも本質以外の部分についての叩きは名誉毀損だから、どっちもどっち。特に叩いていた側の反応が叩かれていた側と同じ様相になって来ていて、人に誠実を説くにはあまりにも浅はかな人間が多いという感想。
で、そんなこととは関係なしに、「お知らせ」と書かれたページにあった「荒らしとは」という文章を見て、すごくよくできていると思った…のですが、今見たらトップページからの辿り方がわかんないや-_-。
そこには「計画的荒らしは一見正当そうな主張をしていても、事態の改善を望むのではなく他人をあげつらうことが目的化している」といった節が。第三者の目に入るところで批判することって、常にそういう結果を招く恐れがあって、そうなってしまった場合の責任について意識しないといけないのですが、現在、人はメールよりも掲示板(今なら自分の blog)などでコメントすることを望む傾向がある。この傾向はいろいろな要因があると思っていて、分析したいなぁと思ってたりもしますが、分析してもあんまり自分の役に立ちそうな気がしないので、してない^^;。あぁ、でもフィードバック UI を考える上では重要なんだよな…。
鍵は、自己顕示欲/プライバシー/手間/相手へのプレッシャー/相手の手間といったあたりか。
あと、同ページには、「一時的な感情的発言が延々とさらされ続けた」とも書かれていましたが、そこについてはちゃんと撤回なり謝罪なりすれば引いてもらえたんじゃないかなぁとか思うけど、そっち方面についてはこれ以上は触れないでおこう。
再度「人に誠実を説くにはあまりにも浅はかな人間が多い」
もちろん、コンテキストを跨って誠実さを保つのは難しいけれど、せめて他人の誠実さについて触れる場合だけでも誠実さを保ちたいものです。
メイン日記に書くようなネタだったけど、まぁそっちに妙な危害が及んでもなので、こっちに^^;。
インターフェイス指向
何だろね。もっと前面に出てきてもいいはずなんだけど。
普通のプログラマには馴染まないのかな？インターフェイス指向。
オブジェクト指向とかアスペクト指向とかいろいろと違った見方が開発されてきてますが、普遍的に重要なのが「モジュール化」であることは各技法に共通なわけです。
で、モジュール化の肝はモジュール≒クラスの「インターフェイス」にあって、あらゆるモジュールは何らかの外部とのインターフェイスを持っているわけです。
で、モジュールをどうやって実現するかとか言うより先にこんなインターフェイスを持ったモジュールがあればこのプログラムは完成するなぁ、と考えるわけです。
インターフェイスが明確に決められる状況なら、そのモジュールの意味(役割＝Role)も明確。明確にならないならそれは一つの interface(Java的表現)であることが不自然だったというだけで。
インターフェイスは、外部から与えられる得る情報と、想定する実装が必要とする情報を照らし合わせれば比較的早く決めることができます。
もちろんインターフェイス早期決定に向かないモジュールも存在しますが。そういう時は受け渡す情報自体をとりあえず抽象化しておけばいいわけで。
こうやって、実現に必要なインターフェイスは何か？という観点と、低レイヤ側で提供できる機能とそのために必要な情報は何か？という観点によってトップダウン/ボトムアップの両面から詰めていく方式をインターフェイス指向と呼ぶ、と認識しています。
今できることからやるという方式な訳です。問題が発生した時に adapter をかますのが楽なので、良いと思ってるわけですが…。
そういえば最近はこういう設計作業自体をあまりしてないから、確信を持っては薦められないか…しょうがない次のプロジェクトで実践しよう^^;。
プロジェクト失敗原因となる典型的症例
とある(中規模以上くらい、200人くらいの体制)プロジェクトを見てきて、それを分析してみる。
- VSS (VisualSourceSafe) を使っているせいで名前変更などのつまらない変更に全員が同期していっせいに対応しなければコンパイルエラーの嵐
余計な TODO の増加。
ちなみに名称変更は全体を一日近く停止させるイベントだった。
また、ファイル削除がローカルに反映されないので、誰かがファイルを削除するとローカルに残ったソースでコンパイルエラーというケースが頻発。
CVS なら(以下略)。 - 内部ライブラリの API がタコ
呼び出し側に負担を強いる仕様。変更のたびに全員が(以下同文)。
ライブラリは直感的に利用した時に通常の動作をするように、特別な操作をしたい時にオプションを指定できるように。
そして利用手順は最高でも３ステップまでにしよう。
個人的にはあるクラスAへのオプショナルパラメタのためにクラスPを用意すべきでないと思う。相当オプションが多い場合はわからなくもないけれど、典型的な利用者のためにクラスAのメソッドとして提供されるべき。
一言で言うなら、API は利用者のこと、特に利用の手間を最優先に考えようってこと - wrapper の氾濫
ライブラリが使いにくいということで、wrapper を作りまくる。自分の担当範囲でしか用いないならそれはそれでいいが、同じ機能を実現する wrapper が複数作られ、「全員それを使って」アナウンスが頻発。どれを使えばよいのやら＆アナウンスのたびに全員が(以下同文)。 - 開発環境/実行環境の構築ノウハウの多さと、それが口コミでしか伝わっていないこと
ビルドは全開発者が実行すること、それに注意事項がたくさんあることはミスを誘発。
その上、その手順/ノウハウに日々変更が入り、全員がそれに従うようにとのアナウンス。アナウンスが無いことも多々。
動かないという話の半分以上が VSS の使い方によるバージョン不整合及びビルド手順のミス。
チェックアウト→実行までの手順は最初から最小化されているべき。
あるいは、せめて一貫したドキュメントをワンステップで辿れる所に配置してメンテナンスすべき。 - 各種アナウンスのダメさ
「全員が」これこれに注意せよという類のアナウンスが多すぎ。
全員がと書かれていない場合は「関係者は」と書かれていたり。
見るべきアナウンスなのか否かの判別が苦痛。
ただ、これに関してはベストな改善方法はまだ思いついていない。
おいらなら、そもそもそういったアナウンスをできるだけしなくてよいように環境を整備するけど。 - ドキュメントの検索性/追跡可能性の悪さ
Excelのドキュメントが数百。
さらに新たなドキュメントが数100KB の zip 形式で ML に添付されてくる。読む人はごく少数。
grep できない。ドキュメント置き場はカテゴライズしているがカテゴリの意味が理解できないことと階層を辿らないといけないので辿れない/辿らない。さらに同じ文書の版違いがたくさん。
(ここはあくまで個人的にではあるけど)プレーンテキストがいい…せめて grep しやすいものが…。 - 仕様書主義の癖に仕様変更ばかり
仕様が変わるのは当たり前なので仕様書主義が間違っている。
これは顧客説得まで絡む話なので、やはり該当プロジェクトで改善できるかというと難しいだろうけれど。
おいらなら、そういうのを強要される仕事は受けない。少なくとも今後は。 - 誰が何をやっていて、自分が何をすべきで、このシステムのアーキテクチャが何なのか理解しているのが極少数
元の要求や業務背景に基づく各種概念のややこしさがあるのは仕方がないし、ある程度の規模だとこれが難しいのはよくわかる。
ただ、問題は、用語/概念の定義がいいかげんでまぎらわしい部分を用語レベルで正さず、顧客用語をそのまま用いている所にあると思った。使っている当人も似た異なる意味として定義されている用語と誤用していたり。それを全員に理解しろと言いますか？ - 規約のタコさ
工業生産的規約とそれに縛りを入れるためのプリプロセスツールに縛られて、設計の自由度が減少し、歪みだらけ。
オブジェクト属性定義書のようなものからクラスを自動生成することになっているが、相互依存関係にあるフィールド群、例えば数量/単価/金額とか、金額/税額/税込金額とか、計算で求まるものにまでフィールドを与える結果になっていて、これじゃ内容の整合性を保つのが大変だろう…。データの重複/コードの重複あたり前。
多段になったプリプロセスツールのおかげで、ビルド手順の複雑化の後押しに加え、変更が掻き消される(自動生成されたソースを修正してたりとか)事件も。これは自動生成されるファイルまでチェックインしているから、という問題でもあるが。
どんなプロジェクトでも、スキルの下限はかなり低い所を想定しなければならないので同情するけど…。というか、あの状況で挫けずに仕事できる人って別の意味でスキルがすごく高いわけで、尊敬に値するわけですが^^;。 - 設計のタコさ
クラスの分割単位が変。データ構造的に問題。フィールドが30以上くらいあるクラスがざら。その状況でフィールド間の相互依存が何通りもあるわけだから…。
えーっと、クラスってのはモジュール化の結果でもあるわけで、例えば先に示した「数量/単価/金額」なんかならそれを pack したクラスとして定義すべきでは？と。プログラマの意識しなければならない範囲を狭めることにこそ意義があるってのに…。
それを後押ししていたのが前述のプリプロセスツール。細かい意味の単位でモジュール化を行うことを億劫にさせるという効果もあるのでしょう。そのフェーズには参加してませんが。 - コンテキストベースの UI 設計
部品単位の独立性/モジュール化ではなく、あらゆる場面をリストアップして、場面ごとに各部品がどう振る舞うかを決めていっている。
これでは、特定部品がどのように振る舞うべきかが読み取りにくい。ただし、この方針は、これをそのままテスト仕様書として使えることを想定しているらしい。その気分は分かる。
しかしその仕様書をベースにプログラムに落とし込むのはすさまじく苦痛な作業だ。すべてのコンテキストを判定して分岐し、分岐先で全部品のパラメタ設定を行うという檄コード重複な作り方が推奨されるらしい。やだよそれ…。
基本は部品単位で例外的状況への対応を行い、複数の部品に影響を与える特定コンテキストだけきり分けるのがよいと思うけどなぁ…。State を使えばよかったか…とも今さらながら思うけれど、他の人達はずらずらと書いていたようだ…。
この問題はまだ完全な解答を持っているわけではないけれど、State パターンを使うことを周知するのであればそれはそれでいいのかもしれない。しかしそれによって重複は減らせても、やはりむやみにコード量が増大する策だ、と思う。大体特定部品が特定の状況でだけ disable になる、みたいなのを一つの State とみなしちゃうようだと、いったいいくつの State になるのやら。
そんな感じで、ある程度規模が大きい開発プロジェクトが難しいのはよくわかるし、自分はそういうプロジェクトのリーダにはあまりなりたくないし、それをやっている方達はすごい、と素直に思うわけですが、上記の中には、やるべきことをやっていてもなるべくしてなるバタバタというより分析レベルからおかしく、それに引きずられる形でデータ構造設計、プログラムの設計にも曖昧さといいかげんさを引きずってるケースが多いわけですね。
ヘルプ的に導入される方は、みな対処療法に専念するわけです。自分だったら本気モードの場合は設計フェーズが終りぎみだったとしても再整理をやるだろうけれど、今回はお手伝いに徹しました。が、担当部分のインターフェイスだけに着目しててももともとの用語の紛らわしさと、事あるごとに一日無駄になる環境の変更には正直耐えられなかったなぁ。
