保守性を考慮したコーディング
下記は扱う言語にかかわらず、広く応用できる考えである。
システム時刻の取得
システム時刻は、個別の業務ロジックのなかで取得せず、汎用的なモジュールを一度はさんだほうがよい。
そうすることで、テストの際に擬似的に時刻を変更して動作確認することが容易となり、テスト工数の削減につながる。
→ 具体的にどうテストしやすくなるのか、まだ分かっていない。今後の勉強が必要。
クラス名のつけかた
class・IDなどの「定数名」の一部に「変数」をつけたすのは悪手である。
たとえば、"class-" + $var といったクラス名を用いるべきではない。
なぜなら、後々保守をするときに検索がかけづらくなる。
class-alpha の仕様を改修する必要が生まれたとき、class-alpha でソースコードを検索しても "class-" + $var はヒットしない。
このぐらい単純な例なら class- で検索すれば十分かもしれないが、もう少し複雑な例ならどうか。ソースコードを調査する時に「さまざまな区切り方の可能性」「検索漏れの可能性」が脳内にチラつくこと自体がノイズであり、作業効率を下げる。
「海外の電話番号」に対応した入力フォームの作成
JSライブラリ「intl-tel-input」を利用することで、海外の電話番号に対応した入力フォームを作成した。
各国の事情に応じて、適切なバリデーションをかけてくれる。たいへん便利だ。
「onsenUI」を用いたSPAの改修
「onsenUI」というフレームワークを用いた SPA の改修作業に従事した。
ページの切り替えひとつを取っても、今まで扱ってきた通常のウェブサイトとは勝手が異なるため、学ぶことが多い。
「WordPress.com」への移行作業
WordPress を用いたとあるウェブサイトを「WordPress.comへに移行する作業に従事した。
WordPress は何年も触ってきた経験があるが、「WordPress.com」は初めてだ。
Github と連携して自動でデプロイする機能や、ステージングサイトを半自動で作れる機能があり、便利だ。
その一方、サブディレクトリを切ることで、1つのドメインのもとに複数のサイトを並立運用することは出来ないというデメリットもある。