大きく作り替えるより、少しずつ変えるほうが速かった

• 一度に作り替えると、問題の切り分けができない
• 少しずつ変えると、壊れてもすぐ戻せる
• 結果として、全体の時間も短い

テーマを大きく作り替えようとして、動かなくなった。段階を踏む形に変えてから、確実に進むようになった。

一度に作り替えた失敗

やったことを書く。

• 複数のファイルを、まとめて書き換えた
• 表示が崩れた
• どの変更が原因か分からない

3つ目が致命的だった。10か所変えて壊れると、切り分けに時間がかかる。

段階に分ける

いまは、こう進めている。

• 変更を、意味のある単位に分ける
• 1単位ずつ入れて、確認する
• 問題なければ、次に進む

2つ目が要点だ。確認を挟まないと、分ける意味が無い。

単位の決め方

どう分けるかには、慣れが要る。

• 1つの機能、1つの画面要素
• それ単体で、動作を確認できる大きさ
• 大きすぎず、小さすぎず

2つ目が基準だ。確認できない単位に分けても、意味が無い。

確認の内容

1単位入れるごとに、こう確認している。

• 変えた箇所が、意図どおりか
• 他の箇所が、崩れていないか
• 画面幅を変えて見る

2つ目を省くと、後でまとめて崩れに気づくことになる。

控えを取る頻度

段階ごとに、控えを取り直している。

• 1単位終わったら、その時点を控える
• 次で壊れても、直前に戻れる
• 戻る範囲が小さい

3つ目が効く。最初から全部やり直す必要がない。

頼むときの分け方

頼むときも、分けて依頼している。

• 1回につき、1つの変更だけ頼む
• まとめて頼むと、まとめて返ってくる
• 返ってきたものを分けるのは、手間がかかる

2つ目が実際に起きた。5つ頼んで、5つ混ざったコードが返ってきた。

戻す判断

進めている途中で、戻すこともある。

• 想定より影響が大きいと分かったとき
• 2回直しても、意図どおりにならないとき
• 別の方法のほうが良いと気づいたとき

2つ目を基準にしている。同じ箇所を3回目に触るときは、やり方そのものが合っていない。段階的に進めていれば、戻すのは1単位分で済む。一度に作り替えていると、戻す決断自体が難しくなる。

記録を残す

各段階で、何をしたか記録している。

• 何を変えたか
• 確認した結果
• 次に何をするか

3つ目を書くと、翌日に再開できる。段階が多いと、途中で中断することがある。

途中でやめられる

段階に分けると、途中で止められる。

• 各段階で、動く状態が保たれる
• 時間が無くなったら、そこで止める
• 公開中のサイトでも、安全に進められる

3つ目が最大の利点だった。一度に作り替えると、途中は壊れた状態になる。

どこまで分けるか

細かく分けすぎても、効率が落ちる。

• 1行の変更ごとに確認すると、時間がかかりすぎる
• 確認に意味がある単位で区切る
• 関連する変更は、まとめて1単位にする

3つ目の判断が要る。色と余白を同時に変える場合、別々に確認しても意味が薄い。見た目として1つの変更に見える範囲を、1単位にするのが現実的だった。目安として、5〜10分で確認できる量に収めている。

順番を考える

どの順で進めるかでも、進めやすさが変わった。

• 影響が小さいものから始める
• 土台になる部分を先に固める
• 見た目の調整は、最後に回す

2つ目が重要だった。土台が変わると、その上で調整したものが無駄になる。構造を先に決め、見た目は後から合わせるという順番にしてから、やり直しが減った。

時間の比較

遠回りに見えるが、比べると速かった。

• 一度に作り替え — 作業は速いが、切り分けで時間を失う
• 段階的に — 作業は遅いが、やり直しが無い
• 結果として、段階的なほうが短かった

3つ目が実測だ。やり直しの時間が、分ける手間を上回る。

まとめ

• 一度に作り替えると、問題の切り分けができない
• 単体で動作を確認できる単位に分ける
• 1単位ごとに確認し、控えを取り直す
• 頼むときも、1回に1つの変更だけにする
• 各段階で動く状態が保たれるので、途中で止められる