アーキテクトのためチュートリアル

概要

「アーキテクト」のためのチュートリアルです。

ここでいう「アーキテクト」とはロール(役割)を示します。 場合によってはマネージャー兼アーキテクトやディベロッパー兼アーキテクトもありえるでしょう。 複数人でやることもあるでしょう。

必要な知識

アーキテクトは、実装部分だけでなくDBFluteの環境周りや設定周りなど全体を把握する必要があります。 DBFluteを探っている人、これから使う人、問わずに必要な知識を得るためのエントリです。

DBFluteの概念・役割

開発の効率化のためにDBFlute利用を推進する、提案されてきたDBFlute利用の許可判断をする、 直接は利用(実装)しないにしてもある程度の「概念と役割」を理解しておく必要があります。

それらはまさしくDBFluteの紹介にて書かれておりますのでぜひお読み下さい。

DBFluteのインフラ情報

DBFluteを採用することが可能なのか？インフラ的な視点を事前に把握しておくことが大事です。 DBFluteを使う場合に最適な環境は？という視点からも把握しておくことは大事です。

DBFluteの環境情報にて書かれておりますのでぜひお読み下さい。

ツールとしてのDBFlute

DBFluteと触れ合う際に、一番最初に出会うのは「ツールとしてのDBFlute」です。 DBFluteはO/Rマッパでもあり、自動生成ツールそのものと言えます。

ツールとしてのDBFluteにてタスクの詳細が書かれておりますのでぜひお読み下さい。

O/RマッパとしてのDBFlute

「ディベロッパーが知るべきこと」を知ることが、そのままO/RマッパとしてのDBFluteを把握することになります。

ディベロッパーのためのチュートリアルをぜひお読み下さい。

開発時のやるべきこと

DBFluteの利用ポリシー決め

DBFluteをどう使うか？作業が発生したときに誰がどのように行うか？事前に決められるものは決めておきましょう。 この後の項目の内容を参考に開発がスムーズに進むようにポリシーを考えてみて下さい。

ReplaceSchemaの利用有無

大きな判断の一つとして「ReplaceSchemaを利用するかどうか」というのがあります。 ReplaceSchemaは自動生成とは無関係のDBFluteの付加機能ですが、DDLの管理・実行やテストデータの管理などの機能を しっかりと設定をして横展開することで、ディベロッパーのDB環境の構築・管理の負荷を軽減することができるとても便利なものです。 次の項目の「セットアップ(初回自動生成)」にて参照するDBFluteのセットアップの手順の中に登場します。

DBFluteのセットアップ(初回自動生成)

DBFluteのセットアップはプロジェクトに付き一回だけ行います。開発が始まる前のDB設計がおおよそ固まった時点で行い、 生成されたクラスをバージョン管理システム(SVNなど)に登録をしてディベロッパーが利用できるようにします。

手順はDBFluteのセットアップをご覧下さい。

全体最適化のための設定

DBFluteは全体最適を行う様々な機能があります。プロジェクト要件がそれら機能と一致するのであれば、 事前にしっかりと設定をしてディベロッパーに横展開することお奨めします。詳しくは全体最適化をご覧下さい。

設定した後、ディベロッパーの実装に影響のあるものはしっかりと周知します。例えば 「共通カラムの自動設定したのでInsertやUpdateのときに気にしなくていいよー」とか 「区分値を設定したのでこういうメソッド使ってねー」など。そういった情報はメールや口頭で伝えるだけでなく、 いつでも参照できるようにプロジェクト内の情報共有システム(Wikiなど)に掲載しておくと良いでしょう。

ディベロッパーへの横展開

DBFluteに限ったことではないですが、開発が本格化する前にディベロッパーに実装スキルを習得してもらう必要があります。 「各自勉強しておくように」というのも悪くはありませんが、勉強会などでディベロッパーたちがスキルを共有できるような形にしておくことで、 スキル習得の効率も上がりますし、開発が始まってからのディベロッパー同士の情報交換によるスキル向上も望めます。

ディベロッパーのためのチュートリアルというページを用意しています。 ディベロッパーに必ずこのページを読んでもらうようにして下さい。

DB変更時の自動生成

DB変更(テーブルの追加やカラム名変更など)が発生するたびに再自動生成を行い、 変更されたクラスをバージョン管理システム(SVNなど)に登録をしてディベロッパーが利用できるようにします。 再自動生成作業には、全てのタスクの実行が含まれます(ReplaceSchemaを利用していなければそれは除外)。

生成されたクラスをコミットする前に必ずやっておくべきことがあります。

ReplaceSchemaの正常終了確認
DB変更がテストデータに影響があるかもしれません。 データ修正作業をアーキテクト自身がやるか他の誰に任せるかはプロジェクトの組織次第ですが、 とにかくこの作業を忘れて変更をコミットしてはなりません。
OutsideSqlTestの正常終了確認
DB変更が外だしSQLに影響があるかもしれません。 簡単な修正であればアーキテクトが直してコミットしてしまえばよいのですが、 ディベロッパー(そのSQLの担当者)でないと修正が大変そうであれば、各ディベロッパーに直してもらいましょう。 あまりに影響範囲が広い場合は、エラーのままコミットして皆で一斉に直すというのもやむ得ないでしょう。 うまくディベロッパーの方々と連携を取るようにして下さい。
自動生成クラスのコンパイル確認
DB変更がプログラムに影響があるかもしれません。 GenerateとSql2Entityで生成されたクラスをローカル環境でコンパイルが通るか確認します。 簡単な修正であればアーキテクトが直してコミットしてしまえばよいのですが、 ディベロッパー(そのプログラムの担当者)でないと修正が大変そうであれば、各ディベロッパーに直してもらいましょう。 あまりに影響範囲が広い場合は、コンパイルエラーのままコミットして皆で一斉に直すというのもやむ得ないでしょう。 うまくディベロッパーの方々と連携を取るようにして下さい。

DBFluteのアップグレード

新しいDBFluteがリリースされたときに、DBFluteをアップグレードするか否かの決定と実行をする必要があります。 アップグレード方法についてはDBFluteのアップグレードをご覧下さい。

Document

Topics