BREWで複数画面を（分割して開発可能な）開発する場合の方法論（その９：分散開発の問題と解決策）。

　シリーズ「BREWで複数画面を（分割して開発可能な）開発する場合の方法論」のつづきです。
　前回で、一通りできました。。めでたしめでたし。。。

　ではなくって、分散開発上（構成管理の上で）、致命的な問題があります。
　今回は、その問題と解決法を書き、とりあえず、ここのまとめをしたあとで、さらに解決策の発展としたカオル姫方式の予告をしたいと思っています。

---

■分散開発の際の、構成管理上の致命的問題点

　今回は、画面ことに開発するということでした。ということは、gamen2のテストとgamen10のテストは、別会社で、連絡も無いところがやっているかもしれません。それも同時に。

　この場合、
・gamen2作成会社は、デバック_DEBUG_GAMEN2のところしかいれていません。
・gamen10作成会社は、デバック_DEBUG_GAMEN10のところしかいれていません。
・さらに、全体アプリはfukusu1を、画面が増えるたびに（HandleEvent追加で）修正します。

　この状況で、
（１）gamen2の会社は、_DEBUG_GAMEN2を、gamen10作成会社は、デバック_DEBUG_GAMEN10を
　　　いれてテストします
（２）このときデバッグオプションのはいったfukusu1は、サーバーにアップしないとすると
　　　→毎回、画面が増えてfukusu1が追加されるたびに、デバッグするときに、デバッグ
　　　　箇所を追加しないといけません（古いfukusu1を使うと、新しい画面が起動しない）

かといって
（２）’このときデバッグオプションのはいったfukusu1を、サーバーにアップしてしまうと
（３）gamen2の人がまず、アップし
（４）そのあと、gamen10の人が、単純にアップしてしまうと、
　　　gamen2のデバッグ情報が消えてしまいます。
　　　なので、このfukusu1に画面が増えて追加されたものを、デバッグしようとしたら
　　　結局、デバッグ箇所を追加しないといけません。。
（４）’じゃあ、gamen10の人は、まずサーバーからダウンロードし、そのあとで、
　　　gamen10の人が、そのソースにgamen10のデバッグ情報を追加すれば。。。
　　　といったら、その追加する分手間っていうこともあるけど、このとき、
　　　gamen1の人も同時に追加作業をやっていたりすると、そのあと、どっちがコミット
　　　するかにより、gamen1かgamen10のどちらかの情報が消えます。
　　　だから、だめ

となってしまい、どっちにしろ、デバックするたびに、その部分のソースをいれないといけなくなります。作業増えます。だめだめです（＞＿＜！）

　っていうか、これだと、１ファイル１担当者の原則に反します。

---

■解決策の前に、どうすればいいのか？

１ファイル１担当者なので、

・全体アプリの担当者がHandleEventと共通部分を追加して、アップしたら、あとは、
　このソースはだれもいじらない。

・スタートの関数と、デバッグ用の関数の設定は、ローカルテスト用と、全体リリース用で
　切り替えられるようにする（全体リリースにローカルの関数が入らない）

とする必要があります。

---

■解決策　関数名をバージョンのヘッダに書き、マクロを使う

　これは、こうすると、解決します。
　なお、以前、ここで、「画面数がふえると、たまったもんでないのですが、じつは、こうならない方法があります。」と書いた方法です。

●fukusu1.cの、デバッグのところ、スタートを呼ぶ関数のところを、マクロにします。
　fukusu1.cのデバッグを呼ぶところは、以下のように、DEBUG_FUNCにしています。

boolean fukusu1_InitAppData(fukusu1* pMe)
{
    // Get the device information for this handset.
    // Reference all the data by looking at the pMe-＞DeviceInfo structure
    // Check the API reference guide for all the handy device info you can get
    pMe-＞DeviceInfo.wStructSize = sizeof(pMe-＞DeviceInfo);
    ISHELL_GetDeviceInfo(pMe-＞a.m_pIShell,&pMe-＞DeviceInfo);

    // The display and shell interfaces are always created by
    // default, so we'll asign them so that you can access
    // them via the standard "pMe-＞" without the "a."
    pMe-＞pIDisplay = pMe-＞a.m_pIDisplay;
    pMe-＞pIShell   = pMe-＞a.m_pIShell;

    // Insert your code here for initializing or allocating resources...
	pMe-＞gno	=	0;
	pMe-＞garea	=	NULL;
	MEMSET(pMe-＞sei_ritu,0,20);
	MEMSET(pMe-＞byo,0,20);
	MEMSET(pMe-＞username,0,21);

	//	デバッグ用設定
	DEBUG_FUNC;

    // if there have been no failures up to this point then return success
    return TRUE;
}

（上記＜　＞　￥は、本当は半角です）

そして、HandleEventのところも、マクロにします。

static boolean fukusu1_HandleEvent(fukusu1* pMe,
　　　AEEEvent eCode, uint16 wParam, uint32 dwParam)
{  
	boolean	ret;

	ret	=	FALSE;	//	処理していない

		//	スタート時に、はじめの画面を呼ぶ
	if ( eCode	==	EVT_APP_START)
	{
		return	START_FUNC;
	}
	else if ( pMe	==	NULL )
	{
		return	FALSE;
	}

（上記＜　＞　￥は、本当は半角です）

●画面２のデバッグの場合、version.hで、以下のように、宣言します。

#define	_DEBUG_GAMEN2
#define	START_FUNC	gamen2_InitAppData(pMe)
#define	DEBUG_FUNC	gamen2_debug(pMe)

●gamen2.hで、あたらしくつくった、デバッグ用関数gamen2_debug(pMe)を

#ifdef _DEBUG_GAMEN2
void gamen2_debug(fukusu1 *pMe);
#endif

のように宣言します（externのほうも、追加します）

●gamen2.cで、デバッグ用関数gamen2_debug(pMe)を記述します

#ifdef _DEBUG_GAMEN2
void gamen2_debug(fukusu1 *pMe)
{
	STRCPY(pMe-＞sei_ritu,"100");
	STRCPY(pMe-＞byo,"20");
	STRCPY(pMe-＞username,"ウィリアムのいたずら");
}
#endif

（上記＜　＞　￥は、本当は半角です）

　gamen2の場合の修正は、これでＯＫです。こうすると、fukusu1のマクロが展開されて、実際には、version.hで宣言されている、それぞれの関数を見ます。

---

　gamen10の場合の修正は、gamen2をgamen10に変えて、同様のことをしてください。
　で、本番の場合は、version.hを、以下のように

#define	START_FUNC	gamen10_InitAppData(pMe)
#define	DEBUG_FUNC

としてしまえば、gamen10からはじまり、デバッグ処理はなにもしないで、できます。

---

　こうすると、デバックとスタートの部分は、マクロになっていて、文字ずらは変わらないので（実際の中身は、コンパイル時にマクロ展開されて変わるけど）fukusu1をgamen2の人もgamen10のひとも皆共有できます。そしてfukusu1の人は、関数がふえたり、共通部分が増えたりしたら、それを追加し、配布すればいいだけになります。

---

■まとめ
　ということで、このまとめとして、ソースは、以下のようになります。
　　　version.h
　　　fukusu1.c
　　　fukusu1.h
　　　gamen1.c
　　　gamen1.h
　　　gamen1.htm
　　　gamen2.c
　　　gamen2.h
　　　gamen2.htm
　　　gamen10.c
　　　gamen10.h
　　　IHtmlCtl.c
　　　IHtmlCtl.h

なお、fukusu1.mif,fukusu1.bidは、ＭＩＦエディタで作成したものを使います。

---

■解決策の発展
　しかし、もう一歩すすめて考えると、
　新規画面のとき、fukusu1を直してもらう、これはまあ、いいとして。。
　共通部分の変数って言うのは、画面間の打ち合わせで急に出てきたりします。
　それをすべて、管理してfukusu1に反映するっていうのは、大変です（＠＿＠！）

　なので、ここでは、カオル姫方式、つまり、
・画面間にまたがるデータをハッシュマップにいれてしまう
・そのハッシュマップを全体、各画面で共有するようにする
・中身はテキトーに入れてね。。。
ってすれば、
・fukusu1では、そのハッシュマップを生成して、そのポインタを持っているだけでいい。
・あとは、各画面において、データを入れてくれたり、使ってくれたりすればいい。
・構造体にハッシュマップを持ってるだけだから、共通変数が追加されても、
　fukusu1のソースは変わらない

　ということが実現できます。。

　え、よくわかんない。。

　それを、このシリーズの次回から説明していきます。