Kickstarter-iOS源碼地址 >>
Makefile
在把項目 clone 下來之后，我們一般首先會想著怎么把它運行起來。在項目的 readme 中的 Getting Started 我們可以看到，運行 make bootstrap安裝工具和依賴，運行 make test-all 構(gòu)建項目并進行測試。而這兩個命令就是在 Makefile 中定義的。
打開 Makefile 文件，我們可以從中看到：1）文件的開頭定義了各種變量；2）剩下的是項目中用到的命令。我們以 make bootstrap 為例：
bootstrap: hooks dependencies
brew update || brew update
brew unlink swiftlint || true
brew install https://raw.githubusercontent.com/Homebrew/homebrew-core/686375d8bc672a439ca9fcf27794a394239b3ee6/Formula/swiftlint.rb
brew switch swiftlint 0.29.2
brew link --overwrite swiftlint
執(zhí)行 make bootstrap ，就會依次執(zhí)行 bootstrap 下面包含的所有命令。
使用 Makefile 的好處是，我們可以把項目相關(guān)的一些命令操作都放到這個文件，即便是剛剛接手項目的同事也一目了然。項目還沒有用 Makefile 的，可以趕緊用起來了啊。。。 ??
沒了解過 Makefile 的可以自行搜索了解一下。
Git submodule
把項目 clone 下來之后，會發(fā)現(xiàn)文件夾里面沒有我們常用的 Podfile 和 xcworkspace 文件。沒錯，Kickstarter 不是用 Cocoapods 來管理第三方庫的，而是使用 git submodule。
除了上面提到的兩個之后，還可以用 Carthage 來管理第三方庫。找到一篇文章，描述了這三種工具的優(yōu)缺點，點擊前往>>。至于選擇哪一種，就看我們更看重的是什么了。
兩個 Swift 編寫的腳本工具
在根目錄下的 bin 目錄，我們可以看到兩個用 Swift 編寫的腳本：ColorScript 和 StringsScript。
ColorScript
開發(fā)者把項目中用到的顏色，保存在Colors.json文件，然后通過 ColorScript 轉(zhuǎn)換成 Colors.swift文件。開發(fā)者在使用的時候只需要通過 UIColor.ksr_dark_grey_400就能得到相應(yīng)的顏色了。后續(xù)如果 UI 設(shè)計師想要微調(diào)顏色，直接修改顏色， json 中的 key 的值不變，我們只需要重新生成 Colors.swift就都搞定了，而不需要更改代碼。
{
"apricot_600": "FFCBA9",
"cobalt_500": "4C6CF8",
"dark_grey_400": "9B9E9E",
"dark_grey_500": "656868",
"facebookBlue": "3B5998",
...
}
這種統(tǒng)一管理顏色的方法，我覺得其實就是把顏色管理的工作交給 UI 設(shè)計師了。設(shè)計師寫好 json 文件，交給開發(fā)者，開發(fā)者用腳本生成 Colors.swift，就一切都搞定了（如果顏色名字有變動或有新添加的顏色，還是需要開發(fā)者手動更改和添加）。如果不通過這種方法去做，而是開發(fā)者自己手動去寫，那么可能會經(jīng)常去手動修改 Colors.swift，這樣就麻煩一些。
至于是否要使用這個思路，我覺得如果公司有專業(yè)的 UI 設(shè)計師，并且大家遵守約定的規(guī)則，用這種方法是非常好的；否則還是開發(fā)者自己手動寫來的實際些吧！
StringsScript
做過國際化的開發(fā)者應(yīng)該知道，如果不通過其他處理的話，我們需要通過 NSLocalizedString("Hello_World", comment: "") 去獲取對應(yīng)的本地化字符串，這種寫法非常麻煩，而且很容易出錯。
在 Kickstarter-iOS 中，開發(fā)者用 StringsScript 把 Localizable.strings轉(zhuǎn)換生成 Strings.swift 文件，然后我們在使用的時候，就可以像這樣去獲取想要的字符串 Strings. Hello_World()。這個腳本把 key 變成了方法名，讓我們避免了在使用的時候出現(xiàn)錯誤，而且使用起來非常方便。
如果有做本地化的項目，采用這種方法可以給開發(fā)者帶來很大的便利。
豐富的測試
測試，是軟件開發(fā)中非常重要的一個環(huán)節(jié)。甚至有些公司執(zhí)行 TDD （測試驅(qū)動開發(fā)(Test-Driven Development)），可以見測試的重要性。
在 Kickstarter-iOS 中，我們可以看到大量的 xxxTests.swift文件，包括了 Unit Test 和 UI Test。
據(jù)我了解，國內(nèi)很多小公司因為進度比較緊急，都是沒有寫測試的。我覺得如果時間允許的話，還是要盡量寫測試，否則自己寫的代碼都沒有自信。有些人可能會問，測試要測些什么？不妨仔細去研讀一下 Kickstarter-iOS 源碼，看看人家的測試文件，相信都會找到一些靈感的。
獨立的代碼庫
用 Xcode 打開 Kickstarter-iOS 的項目，你會發(fā)現(xiàn) KsApi、Library和 LiveStream這三個文件夾不是存放在 Kickstarter-iOS文件夾里面的，而是跟它處于同一個目錄。因為這三個文件夾存放的是獨立于 Kickstarter-iOS 之外的 framework。
這么做的好處當然是代碼可以復(fù)用。目前我看 iPad 上的 Kickstarter 應(yīng)用是跟 iPhone 共用一個的，如果以后要為 iPad 單獨做一個 app，這三個 frameworks 就可以直接拿過去用。
完
想及時看到我的新文章的，可以關(guān)注我。同時也歡迎加入我管理的Swift開發(fā)群：536353151。
