一個專業的專案，除了程式碼本身這份「文件」以外，其它相關的文件諸如 Readme、Contribution、License 等等之類的文件也很重要，即便是公司私有專案也不例外。

研究開源專案作為參考

最快的方式，就是直接到目前地球上的開源大本營 GitHub。

apple/swift

首先就先參考老大的專案。

在 Contributing Code 裡面，有兩個部分值得參考：

1. Incremental Development
2. Commit Messages

其它部分不是不值得參考，是暫時還沒有急迫需要，但是閱讀這樣的文件，可以讓我知道一個專案大概有哪些面向需要特別注意。

matteocrippa/awesome-swift

這個專案的 Contributing 則是明確定義出什麼樣的「專案」可以被列入 awesome-swift，也註明其 Readme 是由程式產生。

有趣的是，大部分專案都會特別註明，如果是安全性的議題，都會盡可能請發現到人用私下聯絡的方式，而不是直接開一個公開的 Issue，應該都是想避免有心人發起零天攻擊（Zero-day Attack）。

另外這個專案特別在最後提到，其 Contributing Guidelines 是受到 Docker、Linux 啟發。

盡可能開放、盡可能減少規矩、能用機器完成的就不要硬性規定，主旨是增加人們貢獻開源的可能性

moby/moby

有趣的是，moby 特別在 Contributing Guidelines 中，提到如果有針對「架構」、「功能」的整個「大改」，保持開放的態度，並特別註明如果有這類的行為，請參考另一份進階的 Contributing Guidelines。

網路上看到絕大多數的 Git commit message 格式，都是參考 How to Write a Git Commit Message。

laravel/laravel

Laravel 的 Contribution Guide 是我看過最簡短不囉唆的，而且在 Style Guide 上面，Laravel 的做法我認為是最符合人性的，Laravel 表示基本上是遵從 PSR，但如果有一些地方沒有注意到沒關係，會有 CI 協助調整，也就是說如果 PSR 沒規定且 CI 沒有特別處理的部分，就是開放個人喜好自由使用。

融合練蠱

Style Guide

在 Style Guide 的處理上，我覺得用 Laravel 的方式處理比較好，程式碼排版本來就存在個人喜好，因此基本上只要遵守部分規定，其餘都可以自由使用。

在基礎上需遵從 Ray Wenderlich 和 Swift API Design Guidelines 的規定，之後使用 Swift Lint 之類的工具就能有更標準化的流程。

Architecture

基本上是希望能朝著 MVVM 的概念去規劃，但是不用強制遵照其架構設定，只是碰到需要選擇時，以 MVVM 作為選擇的基礎。

Contributing Guidelines

我認為不應該存在任何限制、規範，只要遵守基本禮儀即可，任何事情都是可以商量的，前提是願意提出來，反正現在也只有我開發。

: ]

License

MIT 不解釋。

Readme

放上 Money Mom 的目標、目前畫面的 GIF，未來功能規劃，其它文件的連結。

展示

GitHub - shavenking/money-mom