持続可能なウェブサイトとは、単に持続可能性について語るウェブサイトのことではありません。長期にわたって保守し、拡張し、検証できるように技術的に構築されている必要があります。まさにその点に私たちは取り組み続けてきました。
その中心にあったのは一つの原則です。Single Source of Truth、略してSSOTです。すべての重要な情報は、信頼できる唯一の出所を持つべきです。色、ステータス表示、組織データ、テキスト、データベース構造、品質プロセスは、多くの場所でわずかに異なる形でコピーされてはなりません。そうでなければ、あらゆる変更がよりリスクが高く、遅く、コストのかかるものになります。
何を改善したか
私たちは、中心的なルールが守られているかを自動的にチェックする新しいコンプライアンスチェックを追加しました。これにはSSOT監査と、翻訳のためのi18n監査が含まれます。SSOTチェックは今や、とりわけデータベーステーブルがAPIルート内で生成されることや、古いhardcoded-contentパターンが再び現れることを防ぎます。
シッププロセスも厳格化されました。警告を無視したり、ビルド後にはじめてチェックしたりする代わりに、品質の経路は今やより明確に進みます。TypeScript、Linting、コンプライアンス、テスト、Production Buildです。これによりエラーがより早く可視化され、リリース前の信頼性が強化されます。
デザインシステムでは、複数のハードコードされた色指定が中心的なUI設定へと移されました。Open-Graph画像、フィードバックオーバーレイ、エラーページ、カテゴリーフォーム、ファクトシート、ヒーローパターン、顧客プロフィールのためのアプリ固有の色は、今や名前の付いた場所に置かれています。これにより隠れた依存関係が減り、後からの調整をより的確に行えるようになります。
もう一つのポイントは、コンテンツと設定の分離でした。「近日公開」のようなサービスバッジは、技術的なサービス設定に固定されるのではなく、翻訳の中に属します。こうした小さな移動が、長期的には保守性に大きく寄与します。
なぜこれが重要なのか
ハードコーディングはしばしば便利ですが、負債を生みます。ここに一つの色、そこに一つのドイツ語テキスト、ドメインファイル内のステータスクラス、APIルート内のデータベースステートメント。個々の箇所は無害に見えます。しかし合わさると、理解しにくく、安全に変更しにくいシステムへとつながります。
だからこそSSOTは自己目的ではありません。それは私たちがより速く、より正確に作業する助けになります。
- 変更は多くの場所ではなく、一箇所で起こる。
- デザインの決定は一貫性を保つ。
- 翻訳は測定可能になる。
- データベース構造はマイグレーションとスキーマファイルの中にとどまる。
- レビューは探し物ではなく、振る舞いに集中できる。
まだ残っている課題
方向性は明確ですが、作業は完了していません。次に取り組みたいのは、既存の翻訳の負債を減らすことです。新しいi18nチェックはすでに新たな欠落キーを防いでいますが、いくつかの既存の穴はまだベースラインとして記録されています。
さらに、ドメイン設定をUIテキストからさらに分離すべきです。active、sold、reservedのようなステータス値はドメインデータです。ドイツ語のラベルと視覚的な表示は、翻訳とUIマッピングを通じてきれいに供給されるべきです。
デザインシステムもまだより深い統合に値します。すでに良い中心的な構成要素はありますが、いくつかの古いトークン層が重なり合っています。目標は明確なアーキテクチャです。プリミティブトークン、セマンティックトークン、コンポーネントバリアント、そして領域固有のマッピングです。
私たちの基準
保守性は私たちにとって品質の特徴です。それは、プラットフォームが今日だけ機能するのか、それとも一年後もなお安全に発展させられるのかを決定づけます。
SSOT、Separation of Concerns、そしてDRYなコードは、そのための抽象的な概念ではありません。それらは具体的な作業ルールです。コピーを減らし、境界を明確にし、より良い自動化を行い、変更を不必要に難しくしないシステムを作ることです。
まさにその点を、私たちは引き続き築いていきます。