アジャイルだとリファクタリングが必要な理由＆アジャイルする意味をなくす営業・ＰＭの態度

　アジャイルが使われる多くの理由は、「仕様が固められない」という部分が多いと思う。
　あ、あとは、できるのを見ないと怖いとか。。

　っていうことで、アジャイルではじめる場合、初めから「共通部分を抜き出して」ということをやれないケースもあるし、やると危険なケースがおおい。
　話が進んでいったら、「ぜんぜん共通じゃないじゃーん！！」っていうことになり、その部分を作り直しとなったりするから。

　オブジェクト指向な人は、「そーいう部分のために、派生があるんです」というとおもうけど、派生する意味ないくらい、共通じゃない（見た目は共通だけど、中身は共通じゃない）というケースがあるので、やっぱ、オブジェクト指向を採用しても、共通化すると、作り直しになってしまったりする。

---

　てなわけで、いったん全体を作ってしまったあとで、もう一度、チューニングとしてのリファクタリングが必要になってきたりするわけだ。でも、こういう開発手順を踏んでも、仕様確定前に、モノを見ながら、作成、仕様決めができるというメリットは大きい。

---

しかーっし！！
ここで重要なことは、できたところをお客さんに見せて。。
というところである。

客に見せると、仕様が変わってしまう。これはほんと。
でも、だから見せないで、仕様をきめてしまうんなら、アジャイルにするいみなーい！！
ウォーターフォールでやったほうがいいって。

なんで、

アジャイルでやる＝リファクタリングは入る＝できたところを客に見せるのが必要

これ、３点セットだと思う。
　これを理解しない営業、ＰＭで、客に見せなかったり、リファクタリングの機会を与えないならアジャイルでやる意味ないし、むしろ逆効果。
　この場合は、ウォーターフォールのほうが、進みはする（ただ、その場合は、今度、客に見せない危険性、仕様の大勘違いを生じる危険性はある）

メモリを確実に解放するためのきまり

　ふとおもった。

　今まで、カオル姫方式の話の中に出てきた、

　メモリを、ハッシュマップに入れるように、連想配列の中に入れ、

　つまり、

typedef struct _IKaoruMap
{
	char	key[50];	//	キー名は４９バイト以内
	int	kind;		// 	val の型
	void	*val;
}IKaoruMap;

という形で取って、
IKAORUMAP_Put(IKaoruMap *mp,char *key,int kind,void *val);
で、データを入れて、
IKAORUMAP_Get(IKaoruMap *mp,char *key);
で値をとってくるという考え方なんだけど、

この考え方だと、
・ある画面は　g画面番号_
・ある業務内では、g業務番号_
　（業務の中に画面が存在する。だから、受注業務は２、受注画面は２０１
　（業務２の中の０１番）みたいなかんじ）
・ファイルはFファイル番号
みたいなとりきめにすると、

業務を抜けたときは、フリー関数を呼び出し
　g抜ける業務番号_
のメモリをすべて解放する（IKaoruMapの要素からはずす）

画面を抜けたときは、フリー関数を呼び出し
　g抜ける画面番号_
のメモリをすべて解放する（IKaoruMapの要素からはずす）

プログラムを抜けたときは、フリー関数を呼び出し
　すべての
のメモリをすべて解放する（IKaoruMapの要素からはずす）

ってすると。。確実にメモリが解放できるかも？

って、思った。以上。