2.14 プロジェクトとリポジトリの構造

概要と動機

プロジェクトとリポジトリの構造とは、コードベースの物理的な編成です。あるものがどこにあるかを決める、フォルダ、ファイル、命名規約。リポジトリ(しばしば「repo」と短縮されます)は、プロジェクトのファイルとその履歴を保持するバージョン管理された入れ物です。プロジェクトは、関連する複数のコンポーネントをまとめるときにはソリューションとも呼ばれ、作っているソフトウェアの論理的な単位です。構造は、そのソフトウェアを見つけ、理解し、変更するために使う地図です。

小さなチームでは、一人が配置の全体を頭に収められます。何百、何千人ものエンジニア、チーム間の頻繁な異動、出入りする契約者がいる大きなチームでは、異なる編成のリポジトリが一つあるたびに、新たな認知的な税がかかります。見慣れないリポジトリを開いたとき、マニュアルを読まなくても、ソース、テスト、ドキュメント、デプロイ設定がどこにあるか推測できるべきです。すべてのリポジトリがそれらの問いに同じように答えれば、異動は安く、オンボーディングは速くなります。各リポジトリが雪片のように唯一無二なら、すべての文脈の切り替えが小さな調査プロジェクトになります。

企業や政府の設定では、一貫した構造は、統制と保証の関心事でもあります。監査人、セキュリティレビュアー、長期の保守担当者は、しばしば元の作者がいなくなって何年も経ってから働き、仕様書、ライセンスファイル、セキュリティポリシー、ビルド定義を確実に見つける必要があります。予測可能な配置はまた、自動化されたツール(スキャナー、依存関係アナライザー、コンプライアンスチェック)が、システムのポートフォリオ全体で同じように機能できるようにします。そこで本章は、構造を、一度決めてどこでも適用する規約として扱います。それは、コーディング標準とスタイル(2.1章)、バージョン管理とソース管理(2.6章)、ドキュメント(2.7章)と密接に関連します。

主要原則

最小驚きの原則に従います。配置は経験豊富なエンジニアが期待するものに合うべきで、何も暗記する必要がないようにします。
リポジトリ間の一貫性は、局所的な巧妙さに勝ります。あらゆる所で十分に一様な構造は、一か所の完璧な構造より価値があります。
READMEは玄関口です。新参者はそれだけで状況をつかめるべきです。
命名を通じて構造を自己記述的にし、フォルダとファイルが目的を告げるようにします。
構造は、意志の力やレビューのコメントではなく、スキャフォールディングとテンプレートで徹底します。
関心事を物理的に分けます。ソース、テスト、ドキュメント、ビルド、デプロイは、別々の予測可能な場所に属します。
依存関係が、安定した中核から不安定な周縁に向かって、一方向に流れるように整理します。

推奨事項

一貫した最上位の配置を採用する

すべてのリポジトリが、適用できる所で使う標準の最上位フォルダの集合を定義し、それぞれが何のためのものかを文書化します。一般的でベンダー中立の規約には、次のものが含まれます。本番コードのためのソースフォルダ(しばしばsrc)、自動テストのためのテストフォルダ(しばしばtestかtests)、ドキュメントのためのdocsフォルダ、ビルド定義と出力のためのbuildフォルダ、デプロイとInfrastructure as Code(サーバー、ネットワーク、サービスの機械可読な定義。8.2章で扱います)のためのdeployフォルダ、自動化と開発者ツールのためのscriptsフォルダ、実行可能なサンプルのためのexamplesフォルダ、要求と設計の仕様のためのspecかspecificationフォルダ。すべてのリポジトリにすべてのフォルダが必要なわけではありませんが、関心事が存在する所では、期待される名前で期待される場所に置かれるべきです。

READMEを入口にする

リポジトリのルートに、唯一の正規の出発点としてREADMEファイルを求めます。プロジェクトが何か、どうビルドして動かすか、どうテストを実行するか、より深いドキュメントをどこで見つけるか、誰が所有しているか、どう貢献するかを述べるべきです。READMEはドキュメント一式の全体ではなく、残りを指し示す索引です(2.7章)。READMEの欠如や古さを欠陥として扱います。それは、すべての新しいエンジニア、監査人、統合担当者が最初に読むものだからです。

エディタと設定ファイルを標準化する

共有のエディタとツールの設定をリポジトリにチェックインし、すべての貢献者が自動的に一貫した振る舞いを得られるようにします。.editorconfigファイル(空白、インデント、改行のルールを定義する、エディタに依存しない単純なファイル)は、異なるエディタとオペレーティングシステムにわたって基本的な書式を一様に保ちます。バージョン管理システムのための無視ファイル(ビルドの出力やローカルの成果物が決してコミットされないように)を、2.1章で述べた共有のフォーマッターとリンターの設定とともに加えます。これらのファイルは、リポジトリの規約を、文書化されているだけでなく、能動的にします。

命名とフォルダの規約を定義する

フォルダとファイルの命名の規約(ケース、区切り文字、単数と複数、テストを示すような必須の接尾辞)に合意し、一様に適用します。名前は意図を明らかにし、組織の他の場所で使われるドメインの語彙に合うべきです。目標は単純です。パスが意味を伝え、フォルダやファイルの名前を読めば、開かなくても中身がわかるようにすることです。

層と依存関係を意図して整理する

コードベースを、アーキテクチャ上の層がフォルダの配置に現れ、依存関係が単一の妥当な方向に流れるように構造化します。高水準の方針は、低水準の詳細に依存すべきではありません。共有の安定したコードは、多くのモジュールが循環を作らずに届く場所に置きます。層の構造をディレクトリツリーに反映して物理的にすると、エンジニアはそれを尊重しやすくなり、違反はレビューや自動の依存関係チェックで見つけやすくなります。

スキャフォールディングとテンプレートで構造を徹底する

スキャフォールディング、つまり出発点となるプロジェクトの自動生成を提供し、新しいリポジトリが最初から正しい状態で始まるようにします。テンプレートやcookiecutter(少数のプロンプトへの回答から、すぐ使えるリポジトリを生成する、パラメータ化されたプロジェクトの骨格)は、標準の配置、README、設定ファイル、CIの設定を一か所にまとめて符号化します。エンジニアが共有のテンプレートから新しいサービスを作れば、一貫性は願望ではなく既定になり、テンプレートへの改善は将来のプロジェクトに流れていきます。

多数のリポジトリにわたって規模で構造を一貫させる

配置そのものを、統治される標準として扱います。他のエンジニアリング標準(1.7章)と同じように中央で維持し、コード(2.6章)のようにバージョン管理します。それを公開し、実装するテンプレートを提供し、「標準」が意味を保つよう、文書化された例外のプロセスを通じてのみ逸脱を許します。ポートフォリオの規模では、構造の価値のほぼすべてが、リポジトリ間の一様性から来るので、ずれが管理すべき主なリスクです。

構造に、モノレポかマルチレポかの選択を知らせる

構造を、2.6章で扱ったリポジトリの境界の決定に関連づけます。モノレポ(多くのプロジェクトを保持する一つのリポジトリ)は、一つのツリーをたどりやすく保てるよう、プロジェクトとその共有コードを分ける明確な内部規約を必要とします。マルチレポのアプローチ(プロジェクトやサービスごとの多数の小さなリポジトリ)は、各リポジトリが単独で立っていても馴染みあるものに感じられるよう、リポジトリ間の強い一貫性を必要とします。どちらにせよ、文書化され、テンプレート化された構造が、ナビゲーションを予測可能に保つものです。境界の選択が変えるのは、規約をどこに適用するかであって、規約が必要かどうかではありません。

トレードオフ: 長所と短所

選択	長所	短所
厳格な組織全体の標準配置	即座に馴染む。エンジニアの可搬性。一様なツール	変わったプロジェクトにはときに合わない。ガバナンスが必要
チームごとの配置の自由	局所の最適化。高い自律	分断。コストのかかる文脈の切り替え。ツールの不統一
スキャフォールディングとテンプレート	最初から正しいリポジトリ。変更が伝わる	テンプレートの保守。生成されたリポジトリがずれるリスク
深く層をなすフォルダ階層	明示的な構造。明確な境界	ナビゲーションのオーバーヘッド。長いパス。過剰設計のリスク
平らで浅い配置	見渡しやすい。儀式が少ない	分離が弱い。プロジェクトが育つと破綻する

支配的なトレードオフは、一様性と自律です。単一の標準配置は、コードベースの間を行き来する多くのエンジニアの摩擦を取り除きますが、そのコストは、ニーズがその型にきれいに収まらないときどきのプロジェクトが払います。大きな組織では、馴染みによる集団的な利益が、その局所的な損失をほぼ常に上回ります。だから推奨される姿勢は、硬直した一様性でも管理されない自由でもなく、強い既定の標準と文書化された例外の経路(1.7章)なのです。二次的なトレードオフは、深さと単純さです。本物の関心事を分けるのに十分な構造を持ちつつ、ナビゲーションが空のフォルダをたどるハイキングにならない程度に。

チームで議論すべき問い

エンジニアが私たちの見慣れないリポジトリに移ったとき、テスト、デプロイ設定、所有者を見つけるまでどれくらいかかりますか。 これは、構造が取り除くために存在するナビゲーションの税であり、ポートフォリオの規模では、年に何千回も小さな増分で支払われ、積み重なって深刻なエンジニアリング時間の損失になります。最小驚きの原則の要点は、経験豊富なエンジニアが、マニュアルを読まなくても、ソース、テスト、ドキュメント、デプロイがどこにあるかを推測できるべきだということで、正直なテストは、その推測がリポジトリ間で成功するかどうかです。本物の数字を会議に持ち込んでください。見慣れない社内のリポジトリを二、三、自分たちで時間を計って把握してみるか、新しく加わった人が最初の変更を行うのにどれだけかかるかのオンボーディングのデータを引き出します。答えが、数分の見分けではなく数日の調査で測られるなら、雪片のようなリポジトリのコストを定量化したことになり、すべてのリポジトリが共有する標準配置への一度きりの投資を正当化します。
私たちのアーキテクチャ上の層はフォルダツリーに現れていますか。それとも、依存関係の循環が平らな配置の中に隠れていますか。 構造は見つけやすさ以上のものです。層を物理的にすると、エンジニアはそれを尊重し、レビュアーと自動の依存関係チェックが違反を見つけられますが、平らな山は、変更が危険になるまで気づかれずに、不適切な結合や循環が忍び込むのを許します。大きく長寿命のシステムでは、これが、高水準の方針が低水準の詳細に静かに依存するのを防ぐものであり、まさに、防ぐのが安く、解きほぐすのが高くつく浸食です。依存関係グラフを持ち込むか、素早いチェックを実行してください。循環はあるか、安定したものが不安定なものに依存していないか。答えは、層をディレクトリに反映し、依存の向きの自動チェックを加えるよう促し、境界がツリーで見え、パイプラインで徹底されるようにするはずで、誰かの頭の中のモデルにだけ存在するのではなくなります。
新しいリポジトリはテンプレートから正しく始まりますか。それとも、ウィキのページと善意に頼っていますか。 スキャフォールディングによって徹底される構造が既定であり、文書で記述された構造はずれていきます。現実は、ページがそうあるべきと言う姿ではなく、リポジトリを生成するものに従うからです。大きな、あるいは規制された組織では、これは保証の関心事でもあります。すべてのリポジトリが共有のテンプレートから生成されれば、セキュリティスキャナー、依存関係アナライザー、監査人が、ベンダーをまたぎ、年月をまたいで、ライセンス、セキュリティポリシー、仕様、ビルド定義を毎回同じ場所で見つけます。証拠を持ち込んでください。最近のリポジトリのうち、標準のテンプレートからスキャフォールドされたものと手で組み立てられたものがいくつあり、テンプレート化されたものがその後どれだけずれたか。行動は、テンプレートを、リポジトリを始める唯一の簡単な方法にし、文書化された例外の経路を伴うバージョン管理された標準として統治し、ずれを自動的に検出することです。構造の価値のほぼすべてが、一様性に宿るからです。
標準がモノレポにも多数の別々のリポジトリにもまたがるかを決めましたか。そして同じ規約は、その境界の両側で実際に成り立っていますか。 リポジトリの境界の選択が変えるのは、規約をどこに適用するかであって、規約が必要かどうかではなく、間違えれば、誰もたどれない一つの巨大なツリーか、それぞれが異質に感じられるリポジトリの乱立になります。モノレポは、一つのツリーをたどりやすく保つために、プロジェクトとその共有コードを分ける明確な内部規約を必要とし、マルチレポのアプローチは、単独のリポジトリでも馴染みあるものに感じられるよう、リポジトリ間の強い一貫性を必要とします。現在の一覧を持ち込んでください。リポジトリがいくつあるか、モノレポの中で共有コードがどう分けられているか、そしてエンジニアが大きなツリーの中のプロジェクトを、単独のリポジトリの中のものと同じ速さで見つけられるかの時間を計ったテスト。異なるベンダーが別々のリポジトリを納品する大企業や政府のプログラムでは、規約のどの部分が普遍的で、どの部分が境界に固有かを意図して決めてください。監査人とプラットフォームのツールは、コードが一つのツリーとして届いても、五十個として届いても、同じように機能しなければならないからです。
私たちの構造標準は誰が所有し、プロジェクトが本当にそれに合わないとき、実際に何が起こりますか。 ポートフォリオの規模では、構造の価値のほぼすべてが一様性から来るので、本当のリスクは、腐る所有者のいない標準と、あまりに曖昧で、あらゆるチームが静かに独自の配置を発明してしまう例外の経路です。緊張は、変わったプロジェクトには合わない硬直した一様性と、すべてを分断する管理されない自由との間にあり、健全な答えは、強い既定と、名前のある所有者に統治され、コードのようにバージョン管理される、文書化された監査可能な例外のプロセスです。証拠を持ち込んでください。責任ある所有者が一人いるか、変更履歴を伴うバージョン管理された標準の文書があるか、認められた例外とその理由の記録があるか、そして実環境で見つけられる文書化されていない逸脱の数。企業や政府の設定では、誰も記録しなかった例外は統制のギャップなので、各逸脱を書面の正当化とレビュー日に結びつけ、配置を義務づける調達契約が、そこからの逸脱を誰が承認できるかも名指しするようにします。
私たちのREADMEとチェックインされた設定ファイルは、規約を能動的にしていますか。それとも飾りですか。 READMEは玄関口で、チェックインされた.editorconfig、無視ファイル、リンターの設定が、規約を自己徹底的にするものですが、これらは最初に古くなり、監査人や新しく加わった人がプロジェクトをビルドできなくなるまで、最後に誰も気づかないものです。緊張は、最新に保たれる簡潔なREADMEと、ずれていく徹底したREADMEとの間、そして人々がコードを正しくフォーマットすると信頼することと、共有の設定が自動的にそれを徹底することとの間にあります。サンプルを持ち込んでください。五つのリポジトリを取り出して、いくつのREADMEが、プロジェクトが何か、どうビルド、テスト、実行するか、誰が所有しているかを実際に述べているか、いくつが個人の習慣に頼らず共有の設定ファイルを持っているかを確認します。統合担当者、セキュリティレビュアー、長期の保守担当者が何よりもまずREADMEを読む大きな、あるいは規制された組織では、欠けたり古くなったりした玄関口を、担当者のいる欠陥として扱い、準拠が善意に依存しないよう、設定ファイルの存在を自動的にチェックしてください。

セクター別の視点

スタートアップ。 速度が勝つので、最初のリポジトリのために、単純で十分に平らな配置(src、test、docs、scripts、記入済みのREADME、.editorconfig、無視ファイル)に合意し、その日の午後のうちに軽いテンプレートとして保存してください。二つ目のサービスをそこから生成し、両方のリポジトリが馴染みあるものに感じられ、新しい契約者が雪片のようなものをリバースエンジニアリングする代わりに、数時間でオンボードできるようにします。まだ必要のない深い階層や重いガバナンスには抵抗してください。ここでの見返りのすべては、二人の創業者と一人の契約者が一枚の地図を共有することです。

小規模事業者。 プラットフォームの専門家はおらず予算も厳しいので、独自のものを発明するのではなく、言語やフレームワークがすでに想定する慣例的な配置を採用し、既製のツールと新規採用者がそれに慣れた状態で到着するようにします。スキャフォールディング(フレームワークのジェネレーターやcookiecutterテンプレート)は自作せず買い、乏しい労力を、記入済みのREADMEを最新に保つことに使います。そのREADMEは、配置を知っていた唯一の人が異動する日のための、最も安い保険です。

大企業。 多くのチームと何百ものリポジトリにわたって、目標は一様性です。バージョン管理された構造標準を公開し、すべての新しいサービスを共有のテンプレートから生成し、ずれを自動的に検出し、文書化された例外のプロセスを通じてのみ逸脱を許します。すべてのリポジトリが同じに見えるので、新しいチームに配置換えされたエンジニアは数時間で生産的になり、ポートフォリオ全体のセキュリティと依存関係のスキャナーが、ライセンス、セキュリティポリシー、ビルド定義を毎回同じ場所で見つけます。テンプレートの保守とずれの検出を明示的に予算化してください。その維持こそが、規模で標準を意味あるものに保つからです。

政府。 調達、透明性、長期の説明責任が配置を形づくるので、すべてのベンダーを縛る納品標準に共通の構造を義務づけます。コードを承認された要求にリンクするspecificationフォルダ、ルートのライセンスとセキュリティポリシーのファイル、Infrastructure as Codeの定義を保持するdeployフォルダを求め、監査人がコンプライアンスの成果物を、どのシステムでも同じ方法で見つけられるようにします。異なるベンダーの契約者が皆一つの地図に従うので、契約が終わった後の保守ははるかに安くなり、公衆は、要求から稼働するコードまでの、擁護できる検査可能な跡を得ます。

事例

スタートアップ。 3人のスタートアップは、最初のリポジトリのために単純な標準配置(src、test、docs、scripts、記入済みのREADME、.editorconfig、無視ファイル)に合意し、軽いテンプレートとして保存します。一か月後に二つ目のサービスを立ち上げるとき、そのテンプレートから生成するので、両方のリポジトリはすでに馴染みあるもののように感じられ、新しい契約者は午後のうちにオンボードします。まだ必要のない深いフォルダ階層には抵抗し、ツリーを一目で見渡せる程度に平らに保ちます。コストは設定の午後一つで、そうでなければ将来のあらゆるリポジトリを小さな調査プロジェクトにしたはずの、雪片の乱立を省いてくれます。

大企業。 多国籍の小売業者が、複数の言語で何百ものサービスを運用しています。プラットフォームチームが、バージョン管理されたリポジトリ構造の標準と、それを実装する一連のプロジェクトテンプレートを公開します。すべての新しいサービスはテンプレートから生成されるので、標準のsrc、test、docs、deploy、scriptsのフォルダ、記入済みのREADME、.editorconfig、無視ファイル、動作するCIパイプラインとともに届きます。すべてのリポジトリが同じに見えるので、新しいチームに配置換えされたエンジニアは数時間で生産的になり、組織全体のセキュリティと依存関係のスキャナーは、常にファイルが期待する場所にあるため、一様に動きます。

政府。 レガシーシステムをモダナイズする国の機関が、すべてのベンダーに対する納品標準の一部として、共通のリポジトリ配置を義務づけます。各リポジトリには、コードを承認された要求にリンクするspecificationフォルダ、文書化されたREADME、ルートのライセンスとセキュリティポリシーのファイル、Infrastructure as Codeの定義(8.2章)を保持するdeployフォルダを含めなければなりません。異なるベンダーの契約者が皆同じ構造に従うので、機関の監査人はコンプライアンスの成果物をどのシステムでも同じ方法で見つけられ、引き継ぐ保守担当者がすでに地図を知っているため、契約が終わった後の長期の保守のコストははるかに低くなります。

ビジネスケース: 動機、ROI、TCO

構造標準を採用するコストは、おもに一度きりです。配置に合意し、テンプレートを作り、規約を文書化すること。継続的なコストは低く、テンプレートの保守と例外の統治に集中します。標準を持たないコストは、繰り返し発生し複利で増えます。見慣れないリポジトリを開くすべてのエンジニアはナビゲーションの税を払い、すべてのオンボーディングは遅くなり、何も期待する場所にないため、自動化されたツールはリポジトリごとに設定しなければなりません。大きな組織全体では、これらの小さな摩擦が掛け合わされて、エンジニアリング時間の深刻な損失になります。

見返りは、より速いオンボーディング、より安いチーム間の異動、ポートフォリオ全体のツールからのより高いシグナル、そして規制された設定では、成果物が常に見つけられることによる、より低い監査と長期保守のコストとして現れます。総所有コスト(TCO、システムを作り、動かし、保守する生涯のコスト全体)は、長寿命のシステムで最も下がります。予測可能な構造から恩恵を受ける保守担当者は、通常、それを作った作者ではないからです。リーダーシップに論拠を示すには、構造を、開発者の生産性と監査への備えを改善する、低コストでてこの効く標準として枠づけ、オンボーディング時間のデータと、見慣れないリポジトリで物を探すのに費やした労力を使って、今日の一貫性のなさのコストに数字を付けてください。

アンチパターンと落とし穴

雪片のリポジトリ: すべてのリポジトリが異なる編成で、それぞれを一から学び直さなければならないこと。
欠けた、あるいは古いREADME: 玄関口がなく、新参者がプロジェクトのビルドと実行の方法をリバースエンジニアリングせざるを得ないこと。
テンプレートではなく文書による構造: ウィキのページが標準の配置を説明するが、それを生成も徹底もするものがなく、現実がそこから離れていくこと。
テンプレートのずれ: テンプレートから生成されたリポジトリが時間とともに乖離し、テンプレートへの改善が届かないこと。
過剰設計の階層: ほぼ空のフォルダの深い入れ子が、ナビゲーションを助けずに儀式を加えること。
混在した関心事: ソース、テスト、ビルドの出力、シークレットが、明確な分離なしにごちゃ混ぜになること。
コミットされたビルドの出力とローカルの成果物: 無視ルールが設定されなかったために生成ファイルがチェックインされ、履歴と差分を汚すこと。
平らな構造に隠された層の違反: 物理的な境界がなく、依存関係の循環と不適切な結合が気づかれずに忍び込むこと。

成熟度モデル

レベル1(開始): 各リポジトリは作者によってその場その場の必要に反応して場当たり的に編成され、配置は大きく異なり、READMEは欠けているか信頼できず、新参者はすべてのリポジトリを手で案内されなければなりません。
レベル2(発展): 基本的な規約が非公式に存在し、多くのリポジトリが互いに似ています。独自の出発点の配置を持つチームもありますが、権威ある標準も共有のスキャフォールディングもなく、構造はチームごとに目立ってずれます。
レベル3(標準化): 文書化されたバージョン管理された構造標準が組織全体で徹底されています。新しいリポジトリは、標準の配置、README、設定ファイル、CIを備えた共有のテンプレートから生成され、逸脱は静かに起こるのではなく、文書化された例外のプロセスを通ります。
レベル4(管理): 標準への準拠がデータで測定され、制御されます。自動チェックが、配置に合うリポジトリの割合、テンプレート化されたリポジトリがどれだけずれたか、READMEの完全性、依存の向きの違反を報告し、すべてベースラインに対して追跡されます。オンボーディングとナビゲーションの時間が測定され、例外は記録されレビューされ、テンプレートの変更は意見ではなく証拠に基づいて承認されます。
レベル5(オーケストレーション): 構造は継続的に改善され、適応的です。テンプレートの改善は既存のリポジトリに自動的に伝わり、構造のガバナンスはセキュリティ、コンプライアンス、プラットフォームのツールと統合され、標準は言語、アーキテクチャ、ポートフォリオの変化に合わせて意図して進化し、組織が周囲で変化する間も、一様性を高く保ちます。

議論のためのアイデア

組織全体で本当に普遍的であるべき最上位のフォルダはどれで、任意であるべきものはどれですか。
テンプレートから生成されたリポジトリが、時間とともにそこから離れていかないようにするにはどうしますか。
役に立つ層をなす階層と、過剰設計のフォルダの儀式の境界線はどこにありますか。
モノレポとマルチレポのアプローチで、構造標準はどう異なるべきですか。それとも異ならないべきですか。
本当のニーズが標準の配置に合わないプロジェクトのための、適切な例外のプロセスは何ですか。
構造のどれだけを自動的にチェックでき、何がまだ人間のレビューに頼っていますか。
構造標準とそのテンプレートは誰が所有し、変更はどう提案され展開されますか。

要点

すべてのリポジトリを、最小驚きの原則に従って、どのエンジニアも期待によってどのコードベースもたどれるように整理します。
一貫した最上位の配置(ソース、テスト、ドキュメント、ビルド、デプロイ、スクリプト、サンプル、仕様)を採用し、READMEを入口にします。
エディタとツールの設定(.editorconfigなど)をチェックインし、規約を文書化されるだけでなく能動的にします。
スキャフォールディングとテンプレートで構造を徹底し、新しいリポジトリが既定で正しくなるようにします。
規模では、価値は一様性にあります。標準を統治し、ずれを管理し、文書化された例外によってのみ逸脱を許します。

参考文献とさらなる読み物

Robert C. Martin, Clean Architecture: A Craftsman’s Guide to Software Structure and Design
Steve McConnell, Code Complete: A Practical Handbook of Software Construction
Andrew Hunt and David Thomas, The Pragmatic Programmer
Titus Winters, Tom Manshreck, and Hyrum Wright (eds.), Software Engineering at Google
Scott Chacon and Ben Straub, Pro Git
EditorConfig project documentation (as a reference standard for editor configuration)