とりあえずnull

プログラミングの勉強日記

Rails:メンテナンスしやすいフロントエンド設計の重要性

フロントエンドのメンテナンスってすごく難しい。複数人で開発していると、特にバックエンド専門の人がCSSをいじろうとし、HTMLにstyle=""で直書きしたりと「なんでやねん!」ってつっこみながら無駄な苦労を体験することもしばしばあるのではないでしょうか。そんなアプリケーションを運用していく中で生じるメンテナンスのだるさについて書いてみます。

 

運用してみてわかってくるメンテナンスの重要性

とあるスタートアップで開発やら運用やら行なっているのですが、開発者が複数存在し、だんだんとコードが増えていき、機能が増えてくるとどうしてもぶち当たってしまいがちな問題がメンテナンスコスト。今回は特にフロントエンドに関して書こうと思います。どっかのタイミングでリファクタリングなど行なうべきなのでしょうが、なにせ、スタートアップ。リファクタリングより価値検証が大事だという信念もあるためなかなかリファクタリング作業に本腰になれません(まぁ言い訳なんですが汗)。

 

しかし、開発・運用していくとアクセスログを見ながら小さな改善を頻繁に行なうようになりました。そこでぶち当たった壁がメンテナンスのしにくさ。特にRuby on Railsを使っているのでScssを用いているのですが、@extendやら@mixinやらバンバン使いまくっているわけです。実際にそのコードを書いた人は問題ないでしょうが、別の開発者(バックエンド専門の人だった場合は特に)が同じようにビューのUIやデザインを変更をしたいってなったときにすごく探しづらかったり、変更すると別の場所まで適応させてしまったりなどなど、Scssが便利すぎる反面、ちょいとやっかいなことが増えてきました。結果的にそのやっかいなタネはぼくらの時間と精神を貪りつづけ、デスマへと導くのでした。

 

実際に生じている問題

・前例に挙げた複数人で開発する際、Scssの全体的な構造を全員が把握できてないのでメンテナンスをすればするほどさらなるメンテナンスが必要になってくる。(Scssを編集してみたら、編集する予定じゃなかったところまで変更が適応されてた!)

・大まかなルールはあるものの、各人のルールでScssファイル構造でファイルを追加・編集しているので、メンテナンス時に編集しにくい。それが積もり重なって小さなメンテですら億劫になり改修・開発がめんどくさくなる。

 

個人的なベストプラクティス

  1. ビューのフォルダ構造に合わせてScssファイルを用意する
  2. @extendや@mixin、変数などを管理するファイルを用意する
  3. 開発者全体でファイル構造や編集の仕方などをまとめた資料を共有する

 

アプリケーションによって、もう少し詳細に定義することができるはずですが、一般論の範疇で書くなら上記3項でしょうか。特に最後の共通認識を持っているかどうかが運用を快適にするためのコツだと感じます。

 

やっぱり定期的に確認を踏まえた社内勉強会をするのが一番有意義かもですね。