サクッとREADMEに最低限の情報を入れるテンプレート
2024-02-22
10 months ago
開発環境
- git
前提
READMEをあまり書く機会のない方、毎回書く前に何を書こうか迷う方が対象です。
また、個人的によく利用するNextjs x Nestjs構成のNextjs(フロントエンド)のプロジェクトを想定しています。
本題
エンジニアの方であれば、お仕事や個人開発で一度は書くタイミングがあると思われるREADME。
今回はこれだけ書いとけば新しくプロジェクトにアサインされる方でも、ある程度スムーズにスタートラインには立てる最低限のテンプレートを紹介します。
# プロジェクト名
1. [プロジェクトの概要](#プロジェクトの概要)
2. [アーキテクチャ](#アーキテクチャ)
3. [セットアップガイド](#セットアップガイド)
4. [テスト](#テスト)
5. [トラブルシューティングガイド](#トラブルシューティングガイド)
6. [APIドキュメント](#apiドキュメント)
7. [コンポーネントドキュメント](#コンポーネントドキュメント)
8. [リソースとリンク](#リソースとリンク)
(コメント)
冒頭に目次を入れます。
見たい情報にアクセスしやすくなるので、必ず入れましょう。
## プロジェクトの概要
(コメント)
プロジェクトの概要を簡単にまとめます。
他のプロジェクトとの関連があるものであれば、それも記載します。
## アーキテクチャ
### システム全体図
(コメント)
ここは他のプロジェクトとの関わりのないシンプルなアプリケーションなら省略しても良いです。
ただ、ほとんどの場合、フロントエンド、バックエンド、その他のアプリケーションと連携すると思われるので、
そういった場合はdraw.ioなどツールを用いて図を入れると全体像を想像しやすくなります。
### ディレクトリ構成
(例)
- `app` : アプリケーションのページ
- `components` : アプリケーション全体で使用されるすべての共有コンポーネント
- `config` : アプリケーション構成ファイル
- `features` : すべての機能ベースのモジュール
- `hooks` : すべての共有Hooks
- `lib` : アプリケーションで使用されるさまざまなライブラリの構成
- `providers` : すべてのアプリケーションプロバイダー
- `stores` : すべての共有グローバルステート
- `styles` : すべてのCSSファイル
- `testing` : テスト関連のモック、ヘルパー、ユーティリティ、および構成
- `types` : アプリケーション全体で使用される基本の`TypeScript`型定義
- `utils` : すべての共有ユーティリティ関数
:memo: features example
```
.
└── features
├── api : 特定の機能に関連する API リクエスト宣言と API フック
├── components : 特定の機能に限定されたすべてのコンポーネント
├── types : 特定の機能の TypeScript タイプ定義
└── index.ts : アプリケーションの他の部分に対してパブリックにする必要があるもののみをエクスポート
```
(コメント)
上記は一例ですが、ひと口にNextjsのプロジェクトといえど、ディレクトリ構成はプロジェクトによって多種多様です。
ドキュメントにまとめることでコードを読む助けになりますのでぜひ入れてください。
また、上記の例ではfeaturesを採用していて、より良くするのであれば「なぜfeaturesを採用するのか?」のWhyの部分や説明を加えてあげると良いです。
## セットアップガイド
(コメント)
ここでは環境変数の設定から開発環境の起動、認証が必要なアプリケーションであればユーザー登録、初回ログインあたりまでを詳しく記載します。
ここはつまずく可能性があるので、キャプチャなど用いながらできるだけ詳細に記載してあげましょう。
依存するプロジェクト(同時に立ち上げる必要があるなど)があれば、漏れずに記載します。
## テスト
(コメント)
ユニットテスト、E2Eテストなど、このアプリケーションではどこまでのテストを実施しているのか記載します。
もちろん詳細に書く必要はないですが、注意点やテストを各基準などがあればここで記載します。
## トラブルシューティングガイド
(例)
### Q1. tailwindのデフォルト色が利用できない
-> 利用できる色に制限をかけています。`tailwind.config.ts`で定義されていない色を利用したい場合は`theme->colors`に色を追加してください。
(コメント)
ここにはおそらく遭遇するであろうポイントとその解決策を記載します。
上記はtailwindの設定の例ですが、ここは実際に運用していく中で付け足していくべき点です。
## APIドキュメント
(コメント)
できれば、どのようにサーバーと通信を行なっているか簡単なフロー図をdraw.ioなどのツールで入れたいです。
また、ポイントとしてはあまり文字で説明しようとしないでください。
サラッと目を通してもらって、詳細は外部で管理しているドキュメントやバックエンドのレポジトリで管理しているドキュメントへのリンクを貼るぐらいにしたいです。
APIは実装が進む中で変わっていくことがほとんどです。
ドキュメントが追従しきれなくなる可能性が高いので、あくまでも大枠を図などで説明するぐらいにとどめてください。
## コンポーネントドキュメント
(例)
`Next.js`が提供している固有のコンポーネント以外は以下のルールで実装しています。
- 型は`type`で統一
- `props`は分割して受け取る
```jsx
import type { ReactNode } from 'react';
type SampleProps = {
children: ReactNode;
};
export const Sample = ({ children }: SampleProps) => {
return (
<div>
{children}
</div>
);
};
```
(コメント)
コンポーネントの記述法を統一したい時に記載します。
細かくやりたいのであればESLintのルールやscaffdogなどを用いて自動化してあげた方が良いです。
ただ、その場合でもドキュメント化している方が分かりやすいです。
## リソースとリンク
(例)
- [Notionドキュメント](https://www.notion.so)
- [本番環境](https://xxx.xxx)
- [検証環境](https://yyy.yyy)
(コメント)
ここには外部で管理しているドキュメント、各環境へのリンクをまとめます。
意外にここの情報が抜けているドキュメントがよくありますが、READMEをプロジェクトの入り口と考えるのであれば記載してあげた方が親切です。
さいごに
あまり文字文字しすぎると読むのが億劫になってしまうので、詳細の情報はリンクを貼るなど、READMEへの記述はできるだけ避けるのが無難です。