読者です 読者をやめる 読者になる 読者になる

Develop and Design Note

フロントエンドなデザイナーの覚書

コードの破綻と設計・リファクタリングの関係

設計 リファクタリング

大規模サイトでは、運用していくうちに、テンプレートの「破綻」という現象が起きることがあります。

一方、「破綻」を防いだり、立て直す手段に「設計」や「リファクタリング」があります。今回は仕事でリファクタリングを実施する機会があったので、その備忘録になります。

コードの破綻とは

作業現場で良く使う言葉なのですが、「破綻」というのは、コードの理解が著しく困難になり、ちょっとした修正にも多くの時間と労力を割かなければいけなくなる状況です。

また、サイトの見た目は問題ないので、コードの状況を知らないクライアントやディレクターからは、普段の感覚で修正依頼が飛んで来ます。しかし、もはや普段の感覚で修正できないことを知っているコーダーにとっては大きなストレスになってしまいます。

コードの破綻は、単に運用が大変になるだけでなく、修正を依頼する側とされる側に摩擦を生み出し、チームワークにも悪い影響を与えてしまいます。

どうしたら破綻は防げる?

そもそも破綻する原因は何でしょう。個人的に思うところを列挙すると、

  • ディレクトリ構造が乱雑
  • ディレクトリ名やファイル名に命名規則がない
  • HTMLのclass名やid名に命名規則がない
  • CSSの上書きを多用している
  • CSSで要素セレクタを多用している
  • コメントアウトを多用している
  • 使われていないHTMLやCSS、ディレクトリやファイルがある

などなど。つまり「設計」に不備があることが、主たる原因なのではないかと思います。
ただ、初期開発で設計を完璧にやろうとするのは(時間がかかるのと手戻りが大きいので)逆に間違いで、大事なことは(理想の設計が10だとしたら)「初めから設計を10にする必要は無いけれど、最低限3,4くらいにはする必要はある」だと思います。

リファクタリングは大事な運用の一つ

とはいえ、HTMLやCSSの言語の特性上(スコープの概念がないなど)、破綻とまではいかなくても、不備は必ず出てくるものですよね。

なので、運用に入ったらリファクタリングの機会を定期的に設けて、1にした設計を、徐々に、2、3、4、、と上げていくことが大事になってきます。これをやらないと、設計は1から0になってしまいます。

最近は「アジャイル開発」が増えてきています。従来のウォーターフォールでは、初期開発の段階で、設計を7、8くらいまで完成させるが故に、仕様変更による手戻りの工数が大きかったのですが、アジャイル開発では、運用に入ってからサービスを成長させていくので、「リファクタリング」とも相性が良いわけです。

リファクタリングやってみた

実際にリファクタリングに取り組んだ手順としては以下になります。

  1. テンプレートの大まかな構成を把握する(サイトマップやディレクトリ構成を見える化する)
  2. 問題点と改善点を洗い出し、実施したい内容を小分けにする
  3. リファクタリングの重要性を啓蒙する
  4. UI改善と一緒に小分けしたリファクタリングを実施する

詳細は省きますが、リファクタリングを妄想で終わらせず、”実施する”ために重要なのが 、「実施したい内容を小分けにする」「重要性を啓蒙する」の2点です。

というのも、リファクタリングの実施は一人でやるわけじゃ なく、チームでやるからです。リファクタリングは、実施しても見た目に変化はないので、コードを見ていない関係者にとっては、効果のないものと受け取られてしまいがちです。

なので、「なぜリファクタリングをするのか?」を関係者に理解してもらう必要があります。

そのために効果的なのが、実施したいことを小分けにする、つまり、リファクタリングの規模を小さくして、ちょっとずつリリースしていけるようにすることで、他の作業の停滞を防ぎます。Gitでテンプレートを管理している場合は、小分けしたリファクタリングごとにブランチを切ると良いでしょう。

もう一つは、リファクタリングにより得られる効果や重要性を啓蒙すること。サイトの見た目は変わらなくても、リファクタリングをすることで、UI改善のリリース頻度が2倍になる、引継ぎに割く工数が減る、など、関係者に説明して、理解してもらいます。

ある程度経験値のあるコーダーやエンジニアなら、たいていはわかってくれるので、まずは彼らから味方につけましょう。


コードの破綻を防ぎ、サービスを効率的に運用していくために、設計とリファクタリングを計画的に実施していくこと。チームで大規模開発する際の参考にしてみてください。