#前置き
今年はいろいろと地獄だったので、「将来のエンジニアを助けたい」がテーマになりつつあります。
新規の機会があったら運用保守をしっかり考えて構築しようと強く誓いました(震え
#経緯
去年の記事ではCSSもいけるようになったよ！くらいのノリでしたが
今年は改修案件多く、その中でも自力で既存の諸々をレスポンシブに記述しなければならない事があり、
・marginとpaddingの使い方おかしくね？
・これはインラインに書くなよ…
・この安易absoluteが！！！
・階層構造変更によるstyle崩れ乙
などなど問題が大発生＼(^o^)／
だいぶ鍛えられました…
今では、これをこんな感じにレスポンシブで表示したい！というは自力でモーマンタイな感じです。
(SEOに強い記述とかはいまいちまだ分かってないですけどネ)
#本題
そんな中で苦労した事といえば、フロントサイドの制御との絡みで、元のHTMLを修正する必要にせまられるケースが多かった事です。
ざっくりと下記2ケースが大半だったように感じます。
・階層構造がフロント側の制御に適したものになっていない
→だいたい安易absoluteが絡んでマス
・idとclassがフロント側から見た際に適切に設定されてなくて上手く制御できない
→このclassはon・offで使いたいから別けてぇぇぇええええええ
→直接セレクタ指定出来ねぇぇぇえええええ
そして思ったのが
「ここ動くから」とか「ここ繰り返すから」みたいな事を念頭においたうえでのコーディングってエンジニアの方が得意なのでは…？
という事です。
もちろん全てをエンジニアがやってしまうのではなく、制御に必要な最低限の枠だけを最初に作ってしまう的なイメージです。
工程のイメージとしては
ラフデザイン
↓
HTMLコーディング(場合によってはデザインとここが一緒になっている)
↓
組み込み
という流れが多いのではと思いますが、
ラフデザイン
↓
HTMLコーディング(エンジニアで動きを加味して大枠の記述)
↓
HTMLコーディング(詳細)
↓
組み込み
こうした方が手戻り少ないのではと思いました。
またエンジニアだったら、将来的にここはこうしておいた方がいいかも…みたいな事も分かったりしますしね。
#終わりに
HTMLコーディングも修正が発生した際の手戻りが半端ないので(特に改修で元がすごい事になっていた場合とか…)、あらかじめ動きを想定した階層であったりセレクタの指定が出来ていると、世界はとても平和になるのではと思います。