(jp) =
5 月は、私が Spatie で取り組んできたクライアント プロジェクトの 1 周年を迎えます。 いくつかの統計をコミュニティと共有し、「実際の Web プロジェクト」がどのようなものかを感じてもらうことは有益だと思いました。
一般的な概要から始めましょう。 プロジェクトである Web アプリケーションは、在庫、連絡先、および契約を管理するための管理インターフェイスを備えています。 予約、自動請求、約 10 のサードパーティ統合。
将来的には、これらの機能のいくつかを API を介して外部に公開する予定です。その主な目標は、プラットフォームのクライアント向けのモバイル アプリを強化することです。 管理パネルはすでに本番環境で使用されています。
プロジェクトは Laravel で構築されています。 PHP フレームワーク。 多くの VueJS コンポーネントと組み合わせて、Blade をテンプレート エンジンとして使用します。 追い風は、 CSS 使用されるフレームワーク。
# いくつかの数字
では、過去 1 年間にどれだけのコードを作成したでしょうか。 phploc パッケージで集めた要約を以下に示します。
- 2,062 ファイル
- 126,736 コード行
- 97,423 コードの論理行
私の領域であるバックエンド コードに関する統計を拡大してみましょう。
- 1,086 クラス; 32 インターフェイス; 28 特徴
- 平均 LLOC クラスごと: 8
- 最大 LLOC クラスごと: 139
- 3,245 公開メソッド
ファイルの種類ごとに分割された行数は次のようになります。
Stefan の laravel-stats パッケージを使用して、バックエンド コードがどのように構成されているかをさらに掘り下げてみましょう。
まず、大きな Laravel プロジェクトについて説明する必要があります。 デフォルトの Laravel プロジェクト構造を使用する代わりに、コードは「アプリケーション コード」と「ドメイン コード」の 2 つの名前空間に分割されます。
ドメイン コードはすべてのビジネス ロジックを保持し、アプリケーション層で使用されます。 このトピックをさらに掘り下げたい場合は、ここでそれについて読むことができます。
次のグラフは、アプリケーション コードとドメイン コードの相互関係を示しています。
ビジネス コードとアプリケーション コードを分割することで、柔軟で保守しやすく、テストしやすいコアを提供できます。 アプリケーション コードはこのコアを利用し、平均的な Laravel プロジェクトと非常によく似ています。
ドメイン コードの大部分は、次の 3 種類のクラスで構成されています。
- モデル — 80 クラス
- 行動 – 205 クラス
- DTOs — 63 クラス
アプリケーション層は主に次のもので構成されています。
- コントローラー — 130 クラスと 309 ルート
- ViewModel — 82 クラス
- ブレード ビュー — 313 ファイル; これらは上の表には含まれていません
プロジェクトのライフサイクルのため、改善の余地があります。 たとえば、私たちは使用していません DTO後で追加されたため、どこにでもあります。
すべてのものと同様に、私たちは進むにつれて学びます。 1 年後、コードの一部が「古い」と見なされるのは普通のことです。 コードベースのこれらの古い部分で作業するときは、それらをリファクタリングするというルールがあります。
コードをドメインに移動することの大きな利点は、テスト容易性です。 私たちのドメイン コードは徹底的に単体テストされていますが、アプリケーション コードはほとんど統合テストのみです。 私たちの経験では、これは、高度にテストされたコードと締め切りに間に合うことの間の実用的なバランスです。
現時点では 840 やってるテスト 1,728 アサーション。 私たちのテスト スイートは常に改善される可能性がありますが、私たちのテスト スイートのおかげで、何かを壊すことを恐れることなく、新しい機能とリファクタリングを展開できることに非常に自信を持っています。
# コード構造
私はきれいなコードの大きな支持者です。 いくつかの経験則を設定することにより、コードをクリーンで保守しやすい状態に保つようにしています。
- クラスは小さくする必要があります。コードは最大 50 行にする必要があります
- メソッドも小さく、推論しやすいものにする必要があります
- 短い名前や不可解な名前よりも明確な名前を好みます
お気付きかもしれませんが、私たちは常にこれらの規則を守っているわけではありません。 より長く、より複雑なクラスがいくつかあります。
これらのクラスは、選択を行った結果です。私たちが認識している限り、技術的負債の一部が締め切りに間に合うことが許される場合があります。
過去に、コードベースの「ヒート マップ」を生成するために使用する小さなツールを作成しました。 フォルダー内のすべてのコードを取得し、その上にコード構造を重ねて画像を生成します。
このツールを使用して大きなファイルを見つけ、時間があるときにそれらをリファクタリングできます。 過去にこれを行ったことがありますが、非常にうまく機能しています。
このプロジェクトのサブドメインの画像の一部を次に示します。
画像が暗いほど、その位置にあるすべてのファイルのコードが多くなります。 一部のファイルはより長くなりますが、ほとんどのコードは上位 50 行に収まっていることがわかります。これは私たちが目指していることです。
いくつかのツールとメソッドを使用して、これらの短いクラスと一貫したコードを保証します。
- 内部 広報およびコードレビュー。 あなたがどう思うかもしれませんが、これは時間を節約します
- 静的分析、より具体的には PhpStan を使用します。 微妙なバグを防ぐために
- を使用しております PHP CS 一貫したコードスタイルを確保するためのフィクサー
前に言ったように、私はクリーンなコードの確固たる支持者です。 同じコードベースで複数のユーザーと作業している場合、コードの将来を確保するために、コードをクリーンで明確に保つ必要があります。
＃ 最後に
最後にお見せしたいのは、 ギット プロジェクトの歴史をGourceで可視化。 このプロジェクトに取り組んできたのは、合計で、 7 貢献者、そして今ではそれ以上を持っています 4,000 コミットがリストされています。
https://www.youtube.com/watch?v=KkgAnOklQ7w
先ほど説明したさまざまな「ブランチ」をはっきりと見ることができます。アプリケーション コードとドメイン コードです。 この概要には、Blade、JavaScript、 CSS ファイル。
では、あなたのプロジェクトはどうですか？ 自分の統計を共有できますか？ お気軽に つぶやき またはメールで！