iT邦幫忙

2018 iT 邦幫忙鐵人賽
DAY 28
1

一個專業的專案,除了程式碼本身這份「文件」以外,其它相關的文件諸如 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 是受到 DockerLinux 啟發。

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

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


上一篇
Money Mom - 評估軟體架構、Style Guide
下一篇
Money Mom - 讓 CI 跑一會兒
系列文
iOS 三十天上架記帳 APP30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言