国产BBAAAAA片,韩国爱情电影在线完整版,在线无码中文字幕一区,无码免费人妻A片AAA毛片西瓜,国产亚洲精品久久777777黑寡妇,农村熟妇高潮精品A片,性做爰1一7伦,成人片黄网站色大片免费毛片,少妇搡BBBB搡BBB搡野外,国产偷人妻精品一区

當實現新功能時，如果忽略可維護性而引入技術債務，那將會需要延遲解決它或導致增加維護成本。

近我們已經思考通過哪些方式來提高代碼的質量：

• 當代碼的質量下降時，通過設置一些工具來馬上提醒開發者；

• 文檔化一些編碼規范和思考在過去的幾個項目中如何避免維護性差的問題。

我將會簡單地概括我們需要設置什么才能自動監控代碼質量。

基礎

我們選擇一個持續集成工具Jenkins，讓它運行在一臺放在我們工作室的Mac Mini。其實我不怎么喜歡Jenkins，但到目前為止，它是穩定和適合的工具來完成這些工作。

我們已經通過Homebrew和rbenv來分別安裝Jenkins和Ruby，而rbenv能夠為我們提供一個新和穩定的Ruby Gems環境。有個Homebrew和Ruby Gems兩個包管理工具之后，我們就幾乎能夠安裝所有我們需要的工具，但很少會破壞與原有OS X系統更新提供的Ruby。

單元測試

我們使用Specta和Expecta來測試我們的iOS項目。

Specta讓我們采用行為驅動開發(BDD)風格的語法來編寫測試，相比于XCTest的語法，它更加易讀。它還有一個強大的分組測試功能，在測試之前或之后運行一些代碼塊，這樣的話，能夠極大地減少重復代碼。

Expecta是一個匹配器框架，我們可以在測試中使用它來創建斷言。它的語法非常強大，與此同時，它比內建的XCAssert套件更加易讀。例如：

expect(@"foo").to.equal(@"foo");
expect(foo).notTo.equal(1);
expect([bar isBar]).to.equal(YES);
expect(baz).to.equal(3.14159);

我們在開發時，通過XCode來運行測試；而使用通過Homebrew來安裝的Jenkins時，會借助XCTool。XCTool是一個可代替的選擇來xcodebuild，它能讓你通過命令行的方式來非常輕松地運行測試套件和生成JUnit風格的測試報告。

$ xctool -workspace Project.xcworkspace -scheme Project -reporter junit:junit-report.xml test

這些測試報告會發布在Jenkins上，而Jenkins會使用JUnit Plugin來根據時間的推移提供單元測試結果的圖表，同時會向我們顯示我們的測試是否穩定。

Pull Request測試

我們想我們的測試盡可能運行以至于如果我們破壞什么東西，我們就會馬上知道。我們在feature branches做些修改，然后提交一個pull request到Github，那么代碼就會被另一個開發者審查。只要被打開，我們就能運行所有的測試來確保沒有任何東西被破壞。

當新的pull requst是開放狀態時，為了管理這些，我們安裝Github Pull Request plugin來將信息從Github發送到Jenkins。如果有任何測試失敗，它將會顯示在Github，然后我們就不將代碼合并，直到代碼被修復為止。

代碼覆蓋率

我們也會用Gcovr工具來生成代碼覆蓋率報告，Gcovr的安裝方式也是Homebrew。你需要針對main target的debug congfiguration改變兩個構建設置來配置項目。將Generate Test Coverage Files和Instrument Program Flow都設置為YES。

當我們運行單元測試來生成代碼覆蓋率報告時，我們需要將OBJROOT=./build添加到XCTool命令行的尾部。

$ gcovr -r . — object-directory build/Project.build/Debug-iphonesimulator/Project.build/Objects-normal/x86_64 — exclude ‘.*Tests.*’ — xml > coverage.xml

Gcovr輸出的代碼覆蓋率報告也會被插件Cobertura Jenkins plugin發布，這個插件會提供一種可視化的方式來根據時間的推移來顯示代碼覆蓋率。

現在我們不僅可以看到測試是否通過，還可以看到代碼的測試覆蓋范圍。

靜態分析

在工具集中，其中一個強大并能夠保持高質量的代碼的工具就是靜態分析工具。這些工具會掃描你的代碼，然后生成一個報告，這個報告會告訴你破壞代碼風格規則的代碼位置。舉幾個規則的例子：

• 未使用的變量或參數

• 長變量名，方法名或代碼行

• 覆蓋一個方法，但沒有在這個方法調用super

• 方法太長或方法過于復雜

• 還更多的規格...

我們使用OCLint靜態分析工具，這個工具能夠支持C，C++和Objective-C語言。OCLint通過結合XCTool使用來生成json-compilation-database reporter，從而提供great integration特性。我們首先添加另一個reporter到我們的XCTool命令行，然后將那個report傳遞到OCLint來執行靜態分析。

$ xctool -workspace Project.xcworkspace -scheme Project -reporter junit:junit-report.xml -reporter json-compilation-database:compile_commands.json test
$ oclint-json-compilation-database -e Pods -report-type pmd -o oclint-pmd.xml

這個report以PMD的方式來生成，然后使用PMD Plugin被發布到Jenkins。有了這些插件之后，你也可以在測試失敗之前，設置每個警告的優先級(底，中，高)中一些限制。初，我們設置這些限制為低，那么只要我們引入代碼，就會被提醒，從而提高代碼質量。

自動部署

后一個問題不是如何提高代碼質量，而是如何節省時間。開發者通常都會將編譯好的代碼通過Crashlytics發送到設計師來設計審查，或在sprint結束演示時發給用戶。發送一個已經編譯好的App通常花一個開發者的10分鐘左右時間，但它需要他們來切換任務和干擾他們的心流。

近我們已經配置一個在夜晚構建系統，它會在早上自動發送一個新版本的App給每個人。

為了做到這樣，我們使用fastlane。fastlane是一個定義lanes的一些操作來執行的強大工具集?，F在我們有三個已經定義好的lanes，一個是用來發布給ribot開發者，一個是用來發布給在ribot的每個人，后一個是發布給用戶。

before_all do |lane|
 cert
 sigh
end
desc “Deploy a new build to ribot iOS developers over crashlytics”
lane :dev do
 ipa
 crashlytics({ groups: ‘ribot-developers’ })
end
desc “Deploy a new build to people at ribot over crashlytics”
lane :internal do
 ensure_git_status_clean
 append_build_time
 ipa
 crashlytics({ groups: ‘ribot’ })
 reset_git_repo
end
desc “Deploy a new build to everyone over crashlytics”
lane :external do
 ensure_git_status_clean
 increment_build_number
 ipa
 crashlytics({ groups: [‘ribot’, ‘client’] })
 commit_version_bump
 add_git_tag
 push_to_git_remote
end
after_all do |lane|
 clean_build_artifacts
end

通過使用fastlane工具(通過Ruby Gems來安裝)來運行一個lane。

fastlane internal

在開始使用所有的lanes之前，我們應該自動確保我們有一個有效的signing certificate和新的provisioning profile。所有我們的配置都放在一個.env文件，它讓我們有些默認配置，但當我們運行fastlane根據需要來覆蓋它們。

在將來，我們會通過使用deliver操作來自動化App Store提交過程。

后總結

到目前為止，我們已經嘗試這些過程，并在工程中呈現出好的結果。我們期望看到只要適當地使用這些工具，就能提高代碼的質量，這些報告將會讓我們隨著時間推移來量化代碼質量。我們期待在下一個工程中適當地使用這些工具會發生什么。