XHTML+CSS
XHTML+CSS or 力技の続き。例によって当たり前といえば当たり前の話。問題は当たり前のことを知らない人たちがプロジェクトの計画管理をしているという、例によって例のアレだ。
プログラミング技術としてのXHTML+CSS
- ちょっとでもプログラミングをかじったことがあれば、「コードの中にマジックナンバー（魔法の数字）を置くな」ってのは習ったはず。
- HTMLのスタイル属性もマジックナンバー。だからこそCSSとしてHTMLとは別に記述する。
意味がわからないおじさんは消費税が３％から５％になった時の苦労を思い出すのがよいだろう。1.03というマジックナンバーを埋め込まれたコードの対応とテストは大変だったはず。色とか大きさとか場所とかの情報をHTMLに埋め込むのも同じような問題を抱えているわけ。（まあ、1.03を1.05と書き換えて消費税率変更を逃げ切ったおじさんには一生かかってもわからないだろうなぁ...）
プロジェクト計画管理の観点
スタイル属性をHTMLに埋め込めば、保守性は確実に低下する。変更時のコストが高くつくようになる。このような場合、プロジェクトリーダが取る道は二つある。
- 画面の事前設計を徹底し、開発開始後は変更を認めない→徹底したウォーターフォールのアプローチ
- 画面スタイルとビジネスロジックとの結合を緩くし、ビジネスロジックの開発を先行できるようにする。画面についてはビジネスロジックの開発と並行して徐々に詰めていく。→Agileのアプローチ
ウォーターフォール的なアプローチで画面設計を詰めていくと、背後で動くビジネスロジックに関する議論がおざなりになる傾向があるのが問題であろう。業務に関しては下手なことを言えないので議論は本質的になるが、画面のデザインは（極論すれば）誰でも口出しできてしまう世界。本質的ではない、どうでもよい画面デザインのためにプロジェクト前半の貴重な時間が浪費されるのはもったいない。
Agileアプローチでは「画面スタイルはあとから（ほぼ）なんとでもなる」ということを顧客に納得してもらうことで、重要なビジネスロジックの議論と開発に専念できる。画面デザインは、本体ロジックの開発と並行して念入りにやっていけばよいのである。また、CSSを使えば案１・案２・案３・・・・と候補をいろいろ作ることも可能であろう。同じことをHTMLスタイル埋め込みでやるのは非常につらいものがある。
