メドピア開発者ブログ

集合知により医療を再発明しようと邁進しているヘルステックカンパニーのエンジニアブログです。読者に有用な情報発信ができるよう心がけたいので応援のほどよろしくお願いします。

問題を問題として認識するためにしたこと

こんにちわ、エンジニアの井原です。

どの会社も同じだとは思いますが、自社サービスをフルスクラッチしていた最初のころというのは突貫で作っている部分が少なからずあると思います。 弊社もそういった部分が多々あり、特にフロントエンドは手付かずな状態でした。

この混沌としたフロントエンドに漠然とした不安はあるものの、ルールが全くないため全員が同じ思いになってなく、何をもって悪いと言えるのかといった状態になっていました。 そのため、何が悪いのか、どうしたらいいのかという方針作りからはじめました。

本稿では、方針を作るプロセスとできた方針をいかにまもってもらうかという流れを記載します。

現状を確認する

  • インデント..?
  • styleプロパティ
  • 重複したid
  • 大量のcssファイル
  • ロード目的以外のscriptタグとstyleタグ
  • HTML4のころのタグ
  • invalidなcss
  • etc...

あるべき論なルールを作る

現状がすごすぎて列挙すると切りがないため、 まずは現状は気にせず世の中のデファクトスタンダードを踏襲したルールを作りました。

例えば、JavaScriptはAirbnbのコーディングスタイルガイド、cssではCyberAgentやGoogleの公開しているコーディングスタイルガイドのような、メジャーなものを参考にしました。

Lintツールの導入

上記で定義したルールを人間の目で見るのは限界があるので、各種Lintツールを導入して機械の力に助けてもらいます。

ルールを設定

各Lintにあるべき論ルールを設定しました。

ただ、既存のプロジェクトにあるべき論をそのまま適用するとエラー量が大変な事になります。多すぎるエラーはほとんどの人のやる気を失わせ、やがて放置され、形骸化するのが常です。

ですから、共通のルールを適用しつつ、プロジェクト毎にルールを変えられるようにしました。 （もちろん最終的にはあるべき論に少しずつ近づけていきます）

ESLint

ESLintはルールをnpmで取得して、それを継承する形で設定ができます。 その機能を利用するため、まず社内リポジトリに上記ルールを定義したeslint-config-medpeerを作成します。各プロジェクトはeslint-config-medpeerを継承した上でプロジェクトにあわせた妥協ラインを設定するようにしました。

scss-lint

scss-lintはESLintのような継承の仕組みがないですが、明示的に設定しなかったルールはデフォルトのルールが適用されるという仕様があります。

そこで、scss-lint本体のリポジトリをforkし、デフォルトの設定をあるべき論ルールにあわせて書き換えて社内リポジトリに設置しました。 これをインストールして利用することで、ESLintの設定の継承に近いことが実現できました。

html

htmlに関しては妥協を許さないスタンスで共通の設定ファイルを導入。 Nu HTML Checkerは https://validator.nu で確認するのではなく、ローカルで動かしているものを利用するようにしました。動作環境はdockerfileを作り配布しました。

Runnerを導入する

書き換えるたびに手動で実行するという運用では、面倒でやらなくなる、もしくは実行するのを忘れるので、ファイル監視して書きかわるたびにLintを通すようにします。

ESLintとscss-lint

gulp-watchで監視します。

html

htmlに関しては静的なhtmlファイルであれば同じくgulpでいいのですが、弊社はphpで作っているサービスが多いためテンプレートファイルです。 ビルドするまではhtmlの全貌が見えないので、ビルド済みのものを各種Lintツールに流す必要があります。

できればプロジェクトのセッティング(npm installとかcomposer installとか)しただけで環境が構築されてて欲しかったので、以下の2つをつくってみました。

  • BrowserSyncにmiddlewareで挟んでBrowserSyncのログに流すようにした
  • PHP debugbarにCheckerの結果を表示するタブを増やす

ただBrowserSyncは裏で勝手に動いているのでスルーしがちです。 debugbarはdebugbar自体入れていないプロジェクトもあるので、全てのプロジェクトで使えるわけでもない。

別途インストールが必要ではありますが、ブラウザの拡張ツールにしたほうが良さそうな気がしてます。htmlについてはまだベストな方法を模索しているところです。

今後の展開

ルールや仕組みはできたので次は実際に書き換えていく作業になります。 その際レイアウトが崩れていないかを人間の目ですべてを確認するのは難しいので、画面側のテストを導入しようとしています。

さらに実際に運用されているものの監視も不十分なため、エラートラッキングツールの導入も検討しているところです。

ほかにもjQueryバージョンバラバラ問題とかjQueryプラグインたくさん問題とかロードしているファイル多すぎ問題とかまだまだ問題は多く抱えています...

問題は多く抱えつつも、方針を決めることで今まで空中で漂っていた何かが問題として設定できるようになりました。これで問答無用で斧が投げられるようになったので、今後は改善していくしかないです。

ぼくらのたたかいはまだまだこれからだ！