baserCMS開発合宿に至るまでの話（その1）
先の週末、1月27日から28日にかけて一泊二日でbaserCMSの開発合宿に参加してきた。場所はいいかねPaletteという、田川市にある廃校（旧猪位金小学校）を利活用した施設で行われた。メンバーは開発メンバーの他にサポーターズの方や、メンバーのお子さんを含めて20名強。今回は管理画面の改善を目的とした内容で臨んだ。
それに至るまでの話を数回にわけて綴ろうと思う。
前回の合宿
CMSの改善にあたっては、バグフィックスだったり新機能追加だったりAPIの整備だったりセキュリティの向上だったり、色々とやりたいこと・対応することは山積みだが、管理画面の改善についてはざっくり言ってしまうとGUIの刷新が望まれていた。
管理画面の改善プロジェクトがはじまったのは実はずっと前で、2016年9月に行われた開発合宿でもそれが目的だった。当時の合宿前日までに部分的に改善方針とカンプは完成していて、合宿の中である程度形になったのだが、合宿終了後に各メンバーの多忙で開発ブランチが置いてけぼりになり、ブラッシュアップができぬまま放置されてしまった。
プロジェクトの再起動
整理をすると、改善案は次のように計画していた。
バックエンドシステムに関わる機能は基本的に現状維持
導線（ナビゲーション）を主に改善する
グラフィカルな面を今風に刷新する
バックエンドはそのままなので、メインのタスクはフロントエンドに依る。悲しいかな当時のメンバーはフロントエンドが得意な人間が多くなく、タスクボリュームとモチベーションの維持に悩まされる。
改めてプロジェクトを再起動させたのは昨年2017年の4月。我らが@Garyutenさんが、フロントエンドエンジニアを2名誘ってくれて、とりあえずコツコツ始めようよということで、計画的にやることになった。
フロントエンドの開発計画
まずは技術的にどう対応していくかを検討する。そもそも作られた時代的にフロントエンドの開発環境というものがなかったので、そこから整備をする必要があった。昨今のフロントエンド開発手法が安定しないので下手に環境を導入すると新しい開発者が参入できないという懸念が挙がったが、どちらにしても参入者が少ないかったので思い切って整備を始めた。ダイジョブ、古くなったら整備し直せばいいだけだ。
タスクランナーはgulp
CSSはSASSに
JavaScriptはTypeScriptに
jQueryで処理している機能はVue.jsに
タスクランナーはgulp
導入しやすかった以外の理由はない。
CSSはSASSに
おおよそSASSを導入しない理由なんてないのだけど、主に次の2つが理由だ。
CSSファイルから記述されているID・クラスが想像できない状態だったので整理したい
GUIのパーツがそれぞれがなるべく依存せず・干渉せず、独立して成立するようにコンポーネント単位で管理したい
コンポーネントとして管理するのは後に控えてる計画にも通じる。
JavaScriptはTypeScriptに
この件と次の件は開発メンバーのエンジニア間で大いに論争になったが、一応決着はついたつもりでいる。
JavaScriptは便利で気軽な言語な反面、本当にきちんと設計しないといけない。思わぬところに簡単なエラーや不具合を産んでしまったり、セキュリティの責任を持つこともある。その「きちんと」をある程度補ってくれるのが型システムだったりするので、コンパイラに安全性の一部を任せるべきだという結論。
もちろん他にもリンターやテストコードなど、機械検出で安全にできるものは積極的に導入したい。
jQueryで処理している機能はVue.jsに
開発者がライブラリを扱えるか扱えないか置いといて、DOMを直接操作するか、Viewライブラリを導入するかの二択である。要素操作設計を自分でするか、ライブラリに委ねるか、と言い換えてもいい。やっぱりここでも「本当にきちんと設計できるか」どうかの問題があり、より多くの知見がつまったViewライブラリを選択するべきだろうという結論だ。
開発再開
挙げた4つのうち、まずはgulpとSASSを導入する。これはすぐに済んだ。gulpは設定ファイルを書くだけ。SASSも最初はCSSファイルの拡張子を.scssにリネームすればいいだけだ。あとはクラスをひとつひとつ丁寧に見ていって整理する計画をたてていく。
TypeScript化とVue.js化も同時に行いたかったが、どこをどうコンポーネントにしていくか、どういう単位になるかをクラスの整理で見極めていく必要があったので後回しとなった。また、GUI刷新にあたってCSSの調整はマストだがJavaScript部分は機能的にまったくどっちでもよかったので、コンポーネントごとに部分的に変換をしていくようにした。
つづく