July 24, 2007.

命名や設計の話

S!アプリのアニメ部分は結局Actionクラスによる実現を採用してみました。それぞれのAction内でタイムライン方式を用いるか、プログラムによる動的制御を用いるかを自由に決めればよいわけです。動的制御をやってみて思ったのは、直線的な動きでは動画として美しくないと言うこと。Flashなどだと、加速動作や減速動作の設定ができます。そういう動きをさせるためのAPI群を準備しておくと美しいかもしれません。

取り合えず、クラス化のお陰で目に優しいソースになりました。ざくざく作って、問題になったらリファクタリングフェイズで減量や高速化をやりましょう。今のところ3枚の画像を使った2パターンの動画を動的制御して、PC上で6KB。携帯上で10KBらしいです。うーん、この差は何だ？？取り合えず、メガアプリ時代ですから、理論上は300枚の画像を使った200パターンの動画が作成可能という事になりますね。実際にはもっといけると思いますけど、安全側で計算してこのぐらい。

バドのスコアアプリもオブジェクト化を進めてメンテナンス度を高めてから完成させたいところ。こちらの作業は中断中です。なぜかって、ある程度先が見えると、あの、その。アプリ★ゲットさんを借りられる条件は「一般公開」ですから、こまめに完成させないと。その思いがお互いに利益をもたらします。ユーザが喜んでくれたら三方一両得ですね。

今、実務ではVBやCモジュールのバグ修正をやってます。現在のプロジェクトにはアプリが完成後の状態から携わっており、他人が設計開発した上にまともに仕様を理解していない状態。そこから４行ぐらいのメールでバグを探して直すという悲惨な作業。仕様書とソースが乖離していて役に立たないし...。

こういう場合、ドキュメントが無くともソースコードの設計がよければ何とかなるものですが、これがまた酷い。まったくもって読めません。設計も酷いのですが命名がさらに酷い。例えば、getSalesTableData()というメソッドが「売上テーブルに実績テーブル中の得意先のデータが既存ならUPDATE、無ければInsert」という処理を実行していたりするのです。あとは「sqlDataInsert」って名前の「DataをInsertするためのSQL文字列を格納する変数」がいたり。それなら精々dataInsertSQLとでも名づけるべきだろう(baristaならinsertSQLでやめるけど。insertするものがdata以外の事があるのかと)。sqlDataInsertって名前からだと「SQLデータをどこかにINSERTするメソッド」ってのを想像してしまいます。

挙句の果てにそこに付与された日本語の１行コメントも酷い。「ProccessIDが0で更新します」ってもう論外。主語は何ぞや。まぁ中国のオフショアチームの書いたコメントだからしょうがないのか...と思いきや、そのソースは日本人が書いたもので２度びっくり。うーん、日常は良いけどビジネスの時はちゃんとやろうよ...。ってなわけで久し振りの終電ペースでした。残業代が8000円ぐらいついて儲かったなと思っておきましょう。

前のサイトの時代からずっと新規コンテンツが追加されていないjavaの格言に、「他人に読みやすいマナーのいいコード」とか追加しようかなぁ。命名法とかを守っていけば８割がた実現するから、重複を避けるために書かずにいたんだけれど....。

Copyright 2007 barista. All rights reserved.