LoginSignup
1
1
@yukimura_tech

【ポートフォリオ】筆者のフロントエンド開発をまとめる（2024年07月時点）

Last updated at Posted at 2024-07-18

本記事では、筆者が取り組んできたフロントエンド開発から得られた知見と開発環境について詳述します。

はじめに

私は約5年間ほど、ECサイトやランディングページなどの静的ファイルのMPA（Multi Page Application）でのウェブサイト制作やWordPressのテーマ開発に携わってきました。

現代のフロントエンドエンジニアとしては未熟な筆者の開発環境や開発知見を、自己スキルの現状認識としてまとめています。

開発工程の各分野におけるベストプラクティスを取り入れることを心掛けているので、何かの参考になれば幸いです。

開発環境 / 開発知見

Windows OSでの開発環境の説明となります。

Visual Studio Code （VS Code）

■ Git操作（"ソース管理"パネル）

当初は、GUIでGitを取り扱うツール『Sourcetree』を別途インストールして利用していましたが、今はもっぱら "ソース管理"パネル を利用しています。

"ソース管理"パネルでは、
通常のGit操作はもちろん行える他

  • 変更及びステージングファイルの表示（git status）
  • 変更差分の確認（git diff）
  • 一時的な変更の退避（git stash）

などといった機能がエディター内臓のGUI上の操作で利用できます。

前述した『Sourcetree』やターミナルのCUIでもコマンドを利用して操作することができますが、標準機能として提供されている管理機能を使わない手はないでしょう。
ここでは詳しく説明しませんが、より機能を充実させるVS Code 拡張機能も存在します。

▼ 公式ドキュメント

■ AIペアプログラミング 『GitHub Copilot』

GitHubにて月額$10からで契約する必要がありますが、
コーディング文脈からおおよそ正しいと思われるコードの補完提案を行ってくれるため、生産性の向上に繋がっています。

VS Codeで利用するためには、Copilot契約済みのGitHubアカウントとの紐付けと拡張機能『GitHub Copilot』をインストールする必要があります。

『GitHub Copilot』では以下の機能が利用できます。

  • コード補完機能
  • チャット機能（GitHub Copilot Chat）

▼ 公式ドキュメント

AIエディタ『Cursor』のアップデートが目まぐるしいと聞いているので結論出たら乗り換えも検討したいと思っています。

■ 拡張機能

ここでは開発環境構築に関わる拡張機能のみを紹介します。

― ■ FTP操作 『SFTP』

VS Code上でSFTP/FTP接続を行えるようにする拡張機能です。
サーバーへ直接アップロードする開発環境でFTP接続情報があれば、こちらの拡張機能を利用してファイルの同期を行います。

『SFTP』では以下の操作が利用できます。

  • ローカルファイルのアップロード及びリモートファイルのダウンロード
  • ローカルファイルとリモートファイルとの差分確認

長い間FTPクライアントソフト『WinSCP』を利用していましたが、『SFTP』を利用するようになってからはフォルダ間の差分を取得したいとき以外は使わなくなりました。

Git / GitHub

バージョン管理は、前述のセクションでも説明した通り、Visual Studio Code内でGitの操作を行って管理しています。

■ ブランチ戦略

基本的には『Git flow』のブランチ戦略を踏襲することを心掛けています。
プロジェクトによりけりですが、『GitHub Flow』のようにクイックに開発を進めることもあります。

― ■ 『Git flow』

『Git flow』の固有ブランチと特徴は以下の通りです。

  • mainブランチ
    • リリーズ済みのソースコードを管理します
    • 原則としてreleaseブランチとhotfixブランチからのみマージします
  • developブランチ
    • 開発中のソースコードを管理します
  • featureブランチ
    • チェックアウト元はdevelopブランチ
    • 機能実装や開発段階のバグ修正などの作業を進めます
  • releaseブランチ
    • チェックアウト元はdevelopブランチ
    • リリース準備作業を進めます
  • hotfixブランチ
    • チェックアウト元はmainブランチ
    • リリース済みの緊急対応を進めます

― ■ 『GitHub Flow』

『GitHub Flow』の固有ブランチと特徴は以下の通りです。

  • mainブランチ
    • 常にデプロイ可能なソースコードを管理します
    • プルリクエストでfeatureブランチをマージします
  • featureブランチ
    • チェックアウト元はmainブランチ
    • 機能実装や開発段階のバグ修正などの作業を進めます
    • 放置されるブランチが生まれないよう定期的にプッシュを行います

■ コミットルール

当たり前のことですが、複合的な内容となるコミットは避け、可能な限り単一な内容でコミットを行うように心掛けています。

コミットメッセージには、

  • 『gitmoji』のアイコンを使って外見上での見えやすさを優先するか
  • 『Conventional Commits』という宣言されている規約を優先するか

をプロジェクトによって合わせるようにしています。
特に厳格ではない場合には、基本的に見た目で分かりやすい『gitmoji』を使っています。

― ■ 『gitmoji』

『gitmoji』で頻繁に利用するアイコンは以下の通りです。

  • :sparkles:: sparkles : 新規
  • :zap:: zap : 修正
  • :fire:: fire : 削除
  • :construction:: construction : 作業途中

― ■ 『Conventional Commits』

コミットメッセージの形式を標準化するためのガイドラインです。
基本的な形式は以下の通りです。

  • fix: バグの修正
  • feat: 新機能の追加
  • docs: READMEを更新
  • chore!: 不要なファイルの削除

変更したソースコードを解析してコミットメッセージを作成できる時代なので、ベストプラクティスは模索中です。
標準化が確立できたらメッセージのテンプレート設定等も行いたいと思っています。

Node.js と NPM

■ Node.jsバージョン管理 『Volta』

以前は『nvm-windows』を利用していましたが、複数のプロジェクトに参画している場合のNode.jsバージョンの切り替えに対して、柔軟に対応することができないため、
現在はプロジェクトごとに異なるNode.jsバージョンを指定することができる『Volta』を利用しています。

『Volta』では、Node.jsの他にnpm、yarnもバージョン管理することができます。
コマンドはとてもシンプルで種類も多くないですが、主に利用するコマンドを記載しておきます。

  • ツール（Node.js）のバージョンを指定してインストールする 
    volta install node@lts
  • インストール済みのツールの一覧を表示する 
    volta list
  • ツール（Node.js）のバージョンをプロジェクトにピン留めする 
    volta pin node@20.XX.X

ピン留めを行うことで、プロジェクトで開発を進める際に自動的に指定のバージョンのツールが選択されます。
対象のプロジェクトのpackage.jsonには、次の記述が追加されます。

package.json
"volta": {
  "node": "20.15.1",
}

package.jsonに追記されることで、共同開発者に対して使用するツールを標準化することができます。

コーディングガイドライン

コードを書く際には、『リーダブルコード』を遵守するように努めます。

■ HTML

― ■ 『Markup Validation Service』

マークアップ言語（HTML）が規格に準拠しているかどうかをチェックします。

■ CSS

― ■ CSS コーディング規約

基本的な規則はWordPressハンドブックにて公開されている規約を準拠します。

― ■ CSS設計 『FLOCSS』

CSS設計には、保守性と拡張性の確保のために『FLOCSS』を利用します。
デザイン要素に対してレイヤーを分けを行い、プレフィックスを付けた命名規則を持っていることが特徴です。

FLOCSS（フロックス） は、OOCSSやSMACSS、BEM、SuitCSSのコンセプトを取り入れた、モジュラーなアプローチのためのCSS構成案です。

FLOCSSは次の3つのレイヤーと、Objectレイヤーの子レイヤーで構成されます。

  • Foundation - reset/normalize/base...
  • Layout - header/main/sidebar/footer...
  • Object
    • Component - grid/button/form/media...
    • Project - articles/ranking/promo...
    • Utility - clearfix/display/margin...

Objectレイヤーの中で分類されるモジュールに対し、役割を明確にするためにプレフィックスをつけることを推奨します。

  • Component - .c-*
  • Project - .p-*
  • Utility - .u-*

■ JavaScript

― ■ JavaScript コーディング規約

基本的な規則はWordPressハンドブックにて公開されている規約を準拠します。

アクセシビリティ

ウェブアクセシビリティの合理的配慮の提供が義務付けられているため、実施すべき対応を記載します。
障害者差別解消法によって、『JIS X 8341-3:2016』に準拠したウェブサイトを作成することを目指す必要があります。

2024年4月1日より、障害者差別解消法（障害を理由とする差別の解消の推進に関する法律）の改正により、国や地方公共団体などに義務付けられている合理的配慮の提供が、民間の事業者も義務化されました。
~ (中略) ~
ウェブサイトの場合ではJIS X 8341-3:2016に準拠したウェブサイトを作り、ウェブアクセシビリティを確保することがこれに当たります。

ウェブアクセシビリティの導入にはデジタル庁の公開している『ウェブアクセシビリティ導入ガイドブック（2023年1月20日発行）』が参考になります。

■ 『JIS X 8341-3:2016』：国内規格

－ ■ 対応度表記ガイドライン

上記ガイドラインを基に、
ウェブコンテンツの際は下記の対応度表記となることを目指します。

ウェブページ一式において、JIS X 8341-3:2016 の適合レベルAA に準拠

注記：本方針における「準拠」という対応度の表記は、情報通信アクセス協議会ウェブアクセシビリティ基盤委員会「ウェブコンテンツのJIS X 8341-3:2016 対応度表記ガイドライン – 2021年4月版」で定められた表記によるものです。

－ ■ 試験実施ガイドライン

試験の方法として、掲載されている実装チェックリストをカスタマイズの上で利用して結果を検証します。
検証結果の公表は『ウェブアクセシビリティ検証結果｜デジタル庁』を参考にする。

■ 『Web Content Accessibility Guidelines (WCAG) 2.2』：W3C勧告

『JIS X 8341-3:2016』の大元となった『WCAG 2.0』の技術文書の改正された内容です。
JIS規格は、原則5年ごとに見直されることになっているため、最新のウェブアクセシビリティの勧告はこちらを参照する。

パフォーマンス

現状は各項目への対応方針が完璧ではないものの、知見として把握している内容を記載します。

■ コアウェブバイタル

検索エンジン最適化（SEO）に関わる内容ですが、
Googleではページエクスペリエンスの指標としてコアウェブバイタルをランキングを決定する際に考慮する要素としています。

コアウェブバイタルの指標は以下の3点です。

  • LCP（Lagest Contentful Paint）
    • 読み込みパフォーマンスの尺度
  • CLS（Cumulative Layout Shift）
    • 視覚安定性の尺度
  • INP（Interaction to Next Paint）
    • インタラクティブ性の尺度
    • 旧 FID（First Input Delay） ※すべてのインタラクションを対象に変更

Google公式では、
優れたページエクスペリエンスを保証するために良好なコアウェブバイタルの達成が推奨されますが、Google検索結果の上位表示が保証されるわけではない
と見解を表明しています。

■ パフォーマンスの計測

― ■ 『PageSpeed Insights』

サイトパフォーマンスの計測に焦点を置いて確認するには、実際のユーザーから取得したデータと分析エンジンで測定したデータを合わせて確認できる『PageSpeed Insights』を利用します。

『PageSpeed Insights』では以下の指標を確認することができます。

  • フィールドデータ
    • 実際のユーザーから取得したデータ
  • ラボデータ
    • 分析エンジン（『Lighthouse』）で測定したデータ
      • 基準に満たない項目には、要因となっている対象ファイルが指摘されます

フィールドデータはユーザーの累計データを基に表示されるため、ソースコードの改善で即時に反映されるものではありません。

― ■ 『Lighthouse』

ユーザー環境で評価を行うことができるため、主に開発時のパフォーマンス分析及び改善に利用します。
アクセシビリティの評価と改善提案もこちらで確認することができます。

『Lighthouse』では以下の指標を確認することができます。

  • パフォーマンス（Performance）
  • ユーザー補助機能（Accessibility）
  • ベストプラクティス（Best Practices）
  • SEO
  • Progresive Web App

■ 脱炭素スコアの計測

サスティナブルウェブデザインに取り組むことは、環境負荷を下げると同時にパフォーマンス及びアクセシビリティの高いサイトを提供することができます。

Webサイトの環境負荷を測定することのできるツールとして下記を利用しています。

▼ 『Ecograder』

Ecograder は、 The Green Web Foundation の CO2.jsと Google Lighthouse のオープンソースページ メトリックを活用して、Web サイトを改善するタスクを特定します。

サイトパフォーマンスの計測においては、先述した『Lighthouse』と同じ指標を利用していますが、スコアリング アルゴリズムは変更されており、炭素排出量の削減に関するアドバイスも提供されます。

テスト（機能 / セキュリティ）

現時点ではあまりテストを入念に行うプロジェクトに参画したことはないものの、把握している内容を記載します。

機能テストにおいては、テスト駆動開発の開発手法を今後は取り入れたいと思っています。

■ 脆弱性診断ツール『OWASP ZAP』

一般的なセキュリティ脆弱性（SQLインジェクション、クロスサイトスクリプティング、CSRFなど）を迅速に検出します。

まとめ

以上が、現時点での筆者のフロントエンド開発のまとめとなります。

まだまだフロントエンドエンジニアとしては学び、経験する必要のある内容が数多くあるため、数年後この内容を見直したときにアップデートされている領域が増えていることを目指します。

今後は『Frontend Developer Roadmap』のロードマップに沿ってフロントエンド開発者としての対応領域を広げていくことを宣言したいと思います。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
1