いいね!数

0

閲覧数
60

今後のバージョンアップや検証を簡便にするためにも、Notes DB 開発におけるルール・規約は何か定めているものでしょうか?

テンプレート化しているとか、サブフォームなどでパーツ化していていてそれ以外は使えないようにしている等の工夫、実例がありましたら

お聞かせいただけると助かります。よろしくお願い申し上げます。

サーバー情報: | クライアント情報: | 
カテゴリ:アプリ開発 - Notes アプリ | タグ:
  | 質問日時:Aug 11, 2017 6:44:43 AM

回答・コメント

いいね!数

0

ykamoshi さんこんにちは。

なかなか答えづらい(笑)ご質問ですが、このまま放置しておくのは心苦しいので私なりの見解を書きます。

Notes DB 開発における、ルールや規約はある程度どの会社でも暗黙の了解から明文化したものまであると思います。これまでたくさんの開発の現場に携わる方々のお話を総合すると具体的に、「これが正解」というものはありません。

データベースの数、規模、開発環境と本番環境の分離など企業の事情によって変わってくると思いますが、テンプレート化は必須で、常識の範疇と言って良いと思います。

フィールドや設計の命名規則、スクリプトのコーディング規約(必ず、ヘッダーに開発者名と変更履歴を明記、変数の命名規則などなど)から始まってというのが実情のようです。

特に、ルールにしやすいデータベース設計の中にはスクリプトライブラリーがあります。USE 句を使って、それぞれのデータベース内のスクリプトで再利用できることはご存知だと思いますが、このような再利用可能なコードをコードレポジトリーとしてどれだけ持てるかが管理のポイントになります。データベース全体のテンプレート化はもちろん、このようなコードレポジトリー(ここではスクリプトライブラリー設計)をひとつのテンプレートとして作成し、これをそれぞれのデータベース設計に設計の引き継ぎを持たせて配置するなどがあります。

弊社の場合では、どのデータベースでも使用する(使用する可能性がある)共通のスクリプトライブラリーがありました。

  • Common
  • Utility
  • Names
  • FlowControl

名前から察していただけると思いますが、共通して何かの値を計算する、日付の計算、Notesユーザーの取得、セット、ワークフロー制御など、よく開発者が使用するであろうものをまとめて関数化しています。こうすることで、querysave などにベタベタ書いているコードをヘラ空くことができるうえ、アップグレード時のコードレビューも少なくて済みます。コードレポジトリーを変更して設計更新すれば全てのデータベースに一度に反映できます。

サブフォームも同じ考えが適用しやすい設計ですね。

現実問題、これからこういうルールを導入していくのには協力してくれる人、推進力(ある程度上からの意向)に加え、かなりの忍耐力とモチベーションが必要です。今から、10年ほど前、私がしきりに「今からでも遅くない、こう言った標準化を目指しましょう」と声高に言っても、今更もう遅いよという声がほとんどでした。

ご参考になれば。

回答日時:Aug 21, 2017 4:51:50 PM