本文翻譯自 WWDC 2019 Session 239
演講者：Josh Tidsbury
成功的
APP開發需要掌握方方面面的東西。瞭解可納入開發流程的實踐以提高你的生產力，提升你APP的效能和穩定性。學習如何提高通過Xcode編寫的程式碼質量。獲得一些有價值的開發技術的切實理解。
早上好，我是Josh，來自蘋果技術佈道團隊。我們的團隊與像你這樣來自世界各地的開發者一起工作是難以置信的榮譽。我們的目標是幫助你們開發出真正優秀的APP。在與你們的交流中我們學習到了很多，得以瞭解您所採用的流程，面臨的挑戰，目標和願景。我們學習可以幫助你擺脫困境的技巧和工具，雖然我們聽到的每個故事有些許不同，但無論來自世界何方，它們均有諸多的共同主題。
當你想象手藝這個詞時，你首先可能會聯想到設計。開發人員和工程師從事的也是手藝，畢竟手藝的定義如下：
- 規劃、製作和執行的技巧
- 用心、熟練或創造性地製作和生產
程式碼是用手寫出來的，它涉及非常多的技能，在構建APP時需要創造力的技術和抉擇。今天我想和你談談這門“手藝活”所在乎的事情，將這種在乎融入到你的程式碼、storyboards和產品中。開始看起來可能很容易，但結合對當今我們開發者提出的所有要求來看，有時會相當困難。手藝的技能水平隨著時間而發展，這需要敬業、耐心和專注。這是關於學習去享受過程中帶來的樂趣，幾乎與到達目的地時的一樣多。這個過程的一部分是將那些開始時需要強烈並有意識關注的事情轉換為習慣，類似於實際中駕駛汽車，我們駕駛時有意識地關注的事物數量會隨著時間的推移而減少，因為我們已經將這些事物轉換為自然而然的習慣，在App開發中我們也能做到同樣的事情。
要做到這一點，就意味著要擁抱好習慣拋棄陋習。當開發一個APP時，開發者需要關注非常多的細節，而這些細節很少有被使用我們APP的使用者直接觀察到，然而他們能感受到因這些細節影響的效能、可靠性和穩定性。
我們沒有足夠的時間關注這裡所有的細節。今天我想花一些時間來回顧一些有希望改進我們開發工作中的實踐，將它們納入到常規的工作流程後再形成習慣，這在將來會把我們從挫敗、麻煩和浪費時間的困境中拯救出來。我相信你們大部分人已經在實踐很多相關東西了，但也許還有一些沒能成為你的習慣，說不定在這裡會受到一些啟發而去實踐更多。
組織：
1. 組織
除了APP開發人員的身份外我還是一名木工，對我來說是很好的從現代生活逃離的一種方式。有一點可以肯定的是，在乾淨的工作間中更加容易打造出又好又漂亮的傢俱。如果你的工作臺是雜亂無章、毫無條理的，那麼很難去找尋所需的工具和材料，不得不為你目前的工作騰出空間而攪亂更多的東西，花費了較往常更多的時間同時過程中也伴隨著更多的意外和錯誤。
我們團隊每年接觸很多Xcode專案，有一些實踐經驗可以幫助你確保工作空間的乾淨整潔，讓你能夠最好地進行工作。
Xcode專案受益於Group帶來的程式碼結構和組織。讓你程式各部分的程式碼檔案一目瞭然，在你嘗試修復Bug時，快速地為你做好準備。
利用Group以功能模組的角度來組織你的專案，這與使用者操作App的方式邏輯上一致。我們經常看到有些專案使用檔案型別來分組，或者乾脆就不分組，這樣對想要快速瞭解原始檔如何相關聯的人來說沒有任何好處。
此外分組有助於你的Xcode專案結構與實際的檔案系統結構相匹配。從Xcode 9開始，當你在專案中新建Group同時會在磁碟上建立一個資料夾來存放組內的檔案。這意味著無論當你從專案、原始碼管理或者磁碟上檢視都是相似的結構，有助於減少疑惑和混亂。
Storyboard是非常強大的工具，通過視覺化的方式構建使用者介面。我們確實遇到了許多專案將所有的UI一股腦的全部放在一個Storyboard中，沒有理由可以這麼做。
感謝Storyboard之間可以引用。應該針對應用程式的主要部分分別建立各自的Storyboard，然後通過引用將它們連線起來。你會發現這樣能很好的隔絕各自獨立的變化，並使你在大型團隊合作中更加簡單，避免那些令人討厭的合併衝突的風險。就像你不會把所有的程式碼放在一個檔案中一樣，所以千萬也不要把所有的UI放在一個Storyboard檔案中。
將專案檔案保持在最新狀態是確保Xcode幫你解決並避免問題累積的關鍵方法。如果你定期處理這真不能算是一個問題，要是放置不理，在未來確實會引起問題。首先，當你更新到新版本的Xcode時，有時候需要你來決定讓Xcode更新專案設定和專案檔案到最新的格式。因此，除非你有重要的原理不這麼做，否則我們建議你在出現彈出框提示或在issue navigator出現警告時執行此操作。
其次，確保你的專案使用新的構建系統New Build System，該功能於2017年首次推出。它在效能、依賴管理方面作出了重大改進，對採用Swift包起到至關重要的作用。它從Xcode 10起始作為預設的構建系統，你可以通過從File選單下的Projects Settings中進行檢視驗證。
作為木工，我們常常會保留一些小的廢料以防以後可能會用到，直到都要裝滿它們時我們才不得不接受這樣一個現實：這些小廢料從未真正被使用到專案中去。開發人員也有這個偏好，好在有一個(比起木工)更容易的決定，由於你已經將專案程式碼加入原始碼管理之中，你有吧？ 去掉那些不需要並且沒有使用的程式碼，不要僅僅將它們註釋掉。萬一有天你想要把它找回來，如果你真的需要的話，你也可以從那個檔案的歷史版本將其找回來，扔掉這些“小廢料” 吧。
另外一件我們不想失去控制的事情是警告Warning。為此，你和你的團隊應該開始零警告的實踐，包含警告的程式碼不應該被簽入，你應該像對待錯誤一樣對待警告，儘快地修復它們。如果我們的專案有著成千上萬個警告，其大部分的原因都是因為開發人員放棄並且沒有安排時間去修復它們而累積起來的。此外，如果你在維護這樣的一個專案，當新的警告產生時你也根本發現不了。
通過以下這些方式讓你的工作空間和專案有條無紊並整潔乾淨，這對你的APP的長期健康和成功起到至關重要的作用：
- 利用
Group來組織你的專案，與檔案系統結構相對應 - 利用
Reference拆分過大的Storyboard - 確保專案檔案是最新的
- 清除廢棄、舊的程式碼；
- 出現警告時就找到並解決引起它的根本原因。
做好這些事情使得您的專案變得靈活，你的開發流程在專案生命週期中將運轉得更好。
2. 追蹤
說起原始碼控制，在搭建專案時你就應該啟用它。我們確實遇到過許多沒有原始碼管理的專案，特別是那些獨立開發團隊的專案。在你搭建Xcode專案時，你只需要確保這個核取方塊被選中就可以了，這樣你的專案就會使用Git進行原始碼管理。
首先，每次提交的粒度小一點。經常性地檢查讓你的當前程式碼和分支，保持小增量的更新，讓這些變更儘可能的區域性性和自包含。當你以後需要線索或解決迴歸bug的時候，這會給你提供一條回顧的路徑。同時因為你做的這些都是小的變更，從而降低引入侵害的機率。
其次，編寫有用的commit messages。因為有一天我們都會問出這個希望自己能回答的問題：當時究竟在想什麼。當你試圖回憶當時程式碼發生變更時的情形和原因時，你的commit messages就是給你未來的筆記。
即使你是獨立開發人員也像參與大型團隊那樣進行原始碼控制。這樣意味著修復bug和新增新功能都可以通過分支來完成，一旦你完成之後便可壓扁合併回主分支或dev分支，同時使用有意義的commit message。如今你有多種選擇和模式可以遵循，建議你嘗試使用它們，找到最適合你的那種並將其整合到你的開發流程中。
這就是追蹤。原始碼的管理對成功的現代App開發工作流程至關重要，請將它作為你專案的一部分、視作日常實踐的一部分。保持較小的提交，填寫有用的commit message，以及利用分支的幫助進行管理和隔離因修復bug或新增新功能引起的程式碼變更。
3. 文件
在我看來，對程式碼清晰度和可維護性貢獻最大的是註釋和文件，它們對你和你的同事們來說就像麵包屑導航那樣的作用。有人說我不需要程式碼註釋，我的程式碼是自記錄(self-documenting)的，我對此並不買賬。從演算法角度看，良好編寫的程式碼確實清晰的描述了它所做的事情，確實是自記錄的。但是它並沒有說明為什麼，為什麼會有這些程式碼的原因，這些程式碼該如何在更大的上下文中進行適配，也沒有描述當時編寫時採取這種方法的背後原因。我工作過的最好的開發人員，不僅編寫令人難以置信得清晰簡潔的程式碼，而且還花時間在程式碼中留下有用的審查記錄或註釋，引導未來的讀者領會原作者的意圖。初級開發人員能在這個過程中受益更多，因為你的經驗會在專案開始到結束時變化很大，開始時做出的決定可能實際上與最後做出的決定不一致。（譯者注：初級開發人員因為經驗的緣故，導致程式碼變動的因素更多，因此更加需要清晰描述的文件和註釋）
怎麼樣算作好的註釋呢？好的註釋假設讀者瞭解所用的程式語言，能夠走查程式碼序列以及採用的步驟，它真正關注的是程式碼起初寫在這裡的原因和支撐這麼做的理由。舉個例子，這是我們經常看到而實際沒什麼價值的註釋：
//A constant string id value
let id = "2ADA155F-1529-4D2D-98C4-0E4BD06940E8"
複製程式碼我假設你們大部分人都使用Swift寫過一些程式碼，知道這裡是建立了一個字串常量來攜帶這個值，但是我們不知道這個id是什麼，它的用途以及被硬編碼到APP中的原因。給它加了一點註釋後，我們就明白了這個值存在的原因，以及它來自哪裡。
// The permanent identifier for this application when interacting
// with the CMS, provided by the vendor of the CMS.
let id = "2ADA155F-1529-4D2D-98C4-0E4BD06940E8"
複製程式碼我們還可以更進一步，給變數換個名字後變得更加清晰。
// The permanent identifier for this application when interacting
// with the CMS, provided by the vendor of the CMS.
let cmsApplicationIdentifier = "2ADA155F-1529-4D2D-98C4-0E4BD06940E8"
複製程式碼如果你發現你自己的變數使用了單個字母或者類似id等方式命名，也許這是你給它們選擇一個更具描述性的名字的好機會。自動補全功能讓Xcode充滿魅力，你甚至都不用再輸入任何更多東西了。這個案例中的識別符號在任意時間使用時在貫穿整個程式碼庫都是清晰的。
文件帶來的好處和註釋相似，但這些好處是遍及整個應用程式甚至之外的。
當你編寫自己的APP時，你建立了一層層的抽象和演算法，將大段蜿蜒的程式碼分解成整齊可測試、可重用的函式。如果你沒有選擇給這些函式新增文件，那麼你是在強迫你自己每次使用該函式時都得在頭腦中過一遍這個函式的文件，常常必須從頭瞭解這個函式內部的實現，包括每個引數的用途以及如何產生的結果。
如果你不知道如何在Xcode中新增文件，很簡單，只要你將游標定位至函式簽名的第一行，再按option + command + /組合鍵，您需要的所有佔位符文字將自動生成，填充空白就好了。
按住option並點選任何使用該函式的地方都會顯示跟你已經熟悉並喜愛的原生SDK/Swift標準庫風格類似的快捷幫助彈出框。
註釋和文件對你的時間來說真是低投入高回報的投資，收益在整個專案週期中都會源源不斷。所以請為你的程式碼新增有用的註釋，讓讀者能更好地理解原始作者的思路。為你的變數選擇更具描述性的名字，為你的函式、屬性、結構體和列舉都新增上說明文件。
4. 測試
接下來，我要談論一下測試，特指單元測試。為此我還要介紹一下Marshall, 他是我們Swift和開發工具的佈道師，一個非常聰明和友善的夥伴，恰好也是一部Swift領域的Lint 對講機。
Marshall在單元測試的另外一個主題上也把我引向了正確的方向。現在，我必須承認，我在寫單元測試方面並沒有無懈可擊的記錄，我並不是不欣賞它們帶來的潛在價值或者是對它們不熟悉，而是我總是傾向於在寫完實際程式碼之後再來寫單元測試，我老想把它放到最後來做。
然而，有一天我在為某APP 的新功能實現資料模型層的時候，Marshall跟我說：“你在做這些事的時候，最好新增一個單元測試來確保字典和結構體這兩種表示之間的來回轉換能夠正常工作”。
我的真的想不通這在將來怎麼可能會出問題，不過我還是聽從Marshall的意見給這個簡單的流程加上了單元測試。跑了下單元測試，看到綠色的複選標記表示測試通過時，我感到無比的滿足，所以我提交了程式碼進行評審。我再次想起這個測試是幾周後我們需要給這個結構體新增額外的資料，修改之後執行時也沒有問題，我的工作做完了，對嗎？就準備簽入程式碼了，然後我想起來執行一下那個單元測試，果然我因為忘了修改字典反序列化的方式被單元測試抓了現行。這個Bug可能會在我們實現UI的時候才會暴露出來，那樣毫無疑問會浪費我們相當多的時間去找到原因。所以感謝Marshall提醒我將單元測試作為日常實踐的一部分，Marshall:"不客氣，Josh！"
編寫單元測試相當重要，即使那些看上去貌似比較簡單的程式碼正如我碰到的這個例子一樣。程式碼的易受影響性帶來了潛在的迴歸bug，鑑於此我們並沒有那麼多的時間進行徹底地測試，讓我們將Xcode作為一組額外的“眼睛”。
因此，將單元測試的實現作為常規開發實踐的一部分，並在每次提交之前執行它們。單元測試也是持續整合的關鍵組成部分，所以你可以為此做好準備。 測試是使用者永遠不會真正看到的隱藏細節之一，但是可能會帶來不同的後果，給使用者帶來極致的體驗或是APP重要資料受到破壞造成的令人沮喪。
5. 分析
如今有多種形式的分析可以作為你部分日常工作流程，其中一些需要額外時間的投入，也有一些可以在後臺中為你工作，你甚至都不需要去管它。
一個叫Network link Conditioner的工具非常有用，APP開發往往在網路效能良好的家中或辦公室，卻不是你的APP通常被使用的典型環境。
Network link Conditioner可以人為地將網路效能限制為類似典型蜂窩網路的效能，甚至是較差的網路環境，你會驚訝於在這種載入和爭用條件中產生的問題數量，這樣你的客戶就可以避免。
在你的Scheme設定中有一些Sanitizer選擇器，通過它們可以在開發週期裡發現多種多樣的錯誤。Address Sanitizer將監視類似記憶體錯誤和緩衝區溢位的問題，記憶體問題通常是導致安全漏洞的原因，因此使用Address Sanitizer可以幫助你確保不會將這些問題暴露給線上。
通過啟用Thread Sanitizer可以在你使用模擬器測試或除錯你的APP時發現資料競爭問題。資料競爭是指兩個未同步的執行緒，而且至少其中一個試圖對同一塊資料進行寫操作，這可能的惱人錯誤會讓程式執行出現不可預料的問題甚至出現記憶體異常。
Undefined Behavior Sanitizer可以捕獲諸如除零錯誤、浮點數的轉換超出範圍或溢位、以及未對齊指標等bug，當程式出現未定義的行為時它可能會崩潰，也可能不如預期的方式工作，又或者看上去沒問題，但在不同的時間看似沒有任何理由的不同結果。Sanitizer可以在幫助你擺脫令人沮喪的bug，在它們對你的專案造成嚴重破壞之前。
最後要介紹的是Main Thread Checker，它確保你沒有在後臺執行緒中對AppKit和UIKit的API的無效呼叫。舉個例子，如果你在主執行緒之外的執行緒上去更新介面，它可能會導致介面更新丟失、視覺錯亂、資料丟失和崩潰。有時候這些bug因為間歇性地出現而變得非常難以追蹤，而啟用這個功能對效能的影響非常少，所以我們推薦你儘可能就留著啟用它。
在除錯你的App時請時刻關注效能和資源利用率，確保app儘可能高效地利用系統資源。首先可以使用除錯儀表盤，這些儀表盤可以在你構建和執行專案時隨時在Xcode中的Debug Naviagtor中找到，你可以通過它們檢視整個App生命週期的CPU、記憶體、磁碟和網路利用率，快速瞭解你的App是否通過網路正在連線未知的伺服器或者不斷地輪詢某個端點，消耗大量的頻寬和電量。
最後你可以通過Profile中的Instruments按鈕進行進一步的深入分析。我經常使用的其中一個是Time Profiler，它允許你查明程式碼的哪些段落佔用了最多的週期，並且允許我們縮小那段也許應該變成非同步或者被不可擴充套件的方式實現的程式碼的範圍。
分析是一個相當廣泛的主題，但我在這描述的大多數工具只需要你記得啟用就行了。使用Newwork link Conditioner模擬典型的或者較差網路條件；經常使用Sanitizers和Checkers，只要把它們開啟就好了；定期的檢視除錯儀表盤，並密切關注你APP的足跡和效能；利用Instruments分析你的App，深入研究並更精確地解決那些問題。將這些小小的努力轉化為習慣後將大大提高你APP的效能和可靠性。
6. 評估
我住在多倫多的時候有一個車庫，後來將它改成了我的木工車間，這是一個舒適的空間，它完全都屬於我。
我覺得這在App開發中的類比就是程式碼評審。過去幾年我都是以獨立開發人員的身份完成許多App的開發，這就好像我擁有自己的工作間一樣，不可思議得快速和靈活，只有自己的意見才重要。缺點是你自己沒有從同事或同行中學習更好地使用語言、框架和SDK的機會。
雖然解決問題的辦法通常有多種，但總有更好的那一種。比如那種更簡潔或者在效能、可維護性和可靠性方面更突出的方法。不能因為它起作用了就意味著它必然是正確的，就不能通過某種方式可以去明顯地改進它。（譯者：結合個人工作間 vs 共享工作間, 個人開發 vs 團隊開發的優缺點來理解這段話）
蘋果的所有團隊都有一項未經評審的程式碼不能併入專案的政策。我們團隊通過這個過程互相學到了很多東西，程式碼風格更加一致，更不用說在可靠性方便的改進了。它還確保我們整個團隊更熟悉更廣泛的程式碼庫，使得我們可以解決的bug和功能的範圍也更廣。我有幸處在這麼一隻經驗豐富的團隊，這讓事情變得簡單。但是如果你經營著自己的公司或者是獨立開發者，試著找找你所在地區或者來自世界各地的夥伴，並與他們互相進行程式碼評審。或許還可以從聚會、當地會議或者共享辦公室去找找。所以，現在你已經打算將程式碼評審納入你的開發實踐了吧。
好的程式碼評審是怎麼樣的？首先，意味著需要花時間去理解每一行變更的程式碼，匆匆一瞥是沒有意義的。其次，構建專案並跑起來看看，不要假設原作者之前做過，特別是在你記錄中看到最後的提交是一次合併時。執行這些測試，首先這麼做是提醒你去檢查實際上是否有這些測試以及測試是否通過，記住編譯通過不代表不存在某種方式上的破壞。徹底閱讀這些註釋和文件，我的意思是它們有的，對吧？接著尋找是否有拼寫和語法錯誤。繼續查詢變數名的拼寫錯誤，作為一個加拿大人，我有長期使用colour作為顏色變數名的習慣，這讓我的團隊在查詢color變數時簡直抓狂。確保程式碼庫中的函式、變數名的一致性可以更容易的查詢，也節省時間。
可能會覺得這個過程在短期內也許減緩了您的速度，但從長遠來看，通過減少潛在的錯誤和問題，將毫無疑問地為您節省時間、金錢和客戶。你作為開發人員的經驗在將來處理類似的模式或挑戰時受益匪淺。
7. 解耦
開發人員致力於建立小而精的可重用、可測試的程式碼，畢竟我們不想總是一次次的編寫重複程式碼。
App，其他的App也能利用這些成果。
如果你的App包含Extensions並且將它們的共享程式碼打包成Framework，那麼你的應用二進位制包大小會減少，因為你的主App和Extensions可以共享這個Framework。當然，建立包也給你了在社群分享你努力成果的機會，特別現在與Xcode 11包的整合更緊密了。但是除了你App、共享框架、包和庫中的程式碼外，還需要附帶優秀的文件才能讓其他人更好去使用。
因此，將框架和包作為你拆分程式碼庫的一種方式，這可以讓你的成果作用於多個正在開發或維護的app。
Framework可以幫你減少二進位制包的大小，然後你可以將成果與社群共享，但請務必附帶優秀的文件。
8. 管理
最後一個我想談論的是依賴管理，尤其是搞清楚它給你的專案帶來的好處和風險。使用Swift包、框架和其他庫有很多好處，但是在你開始使用之前，瞭解庫裡面包含的內容以及在帶來潛在的問題是非常重要的。
你要確保瞭解依賴包對資料的影響，你要對App的內容負責，包括對使用者數的所作所為。
確保Framework沒有收集不必要的指標或裝置資訊，確保它沒有把資料從你的裝置傳送出去。
同樣也要了解和研究給定依賴包的依賴。
畢竟引入包含依賴的依賴包後意味著你App的安全和成功與這整條鏈掛鉤了。
最後還有另外一種可能性會破壞你的App，如果依賴包不維護了怎麼辦？或者直接就消失了呢？重要的是你要有一個計劃決定你在任何時候遇到這些情形時該如何去處理，畢竟你在專案中引入了一個新的依賴後，專案的未來就真的依賴它了。
那麼是你準備自己來修復這個公開的bug呢？還是將它轉為內部的專案並維護它，又或者你計劃不得不把那個依賴在以後全部清除出去以及包括因此帶來的必要工作？
使用外部依賴包(如Swift包)可以讓你更快地完成工作，並避免重複創造社群中已經存在的工具。本著掌握它們用途的態度, 確保它們只按照你期望的那樣做，務必要它們尊重使用你App的使用者的隱私。做好它們在未來出錯或者消失的應對措施計劃。在專案中新增新的依賴時問問自己這些問題，把這件事變成你的習慣，你將最大限度地發揮出它們的長處並得到長遠的回報。
總結
對於App開發專案，有時候覺得專案的最後10%的工作花費的時間與前90%的時間一樣長。但是我認為嘗試通過將這些實踐轉化為習慣之後，你可以避免這種感覺。
通過有效的組織你的工作區，讓你更快更高效的工作，專注於實際程式碼。
利用原始碼控制追蹤你的程式碼庫，可以減少迴歸bug的機率，加快調查可能導致bug的原因。
編寫有幫助有意義的註釋和文件，你可以在未來閱讀這些程式碼以及每次使用自己編寫的類、結構體、函式時減少負擔成本。單元測試能在最後一刻拯救你，在引入一些迴歸bug的時候。
Sanitizers和checkers提供對你的程式碼持續分析的能力，它們在後臺執行，你都甚至不用去操心。儀表盤和Instruments確保你高效地利用系統資源，允許你精確地追蹤效能和其他問題。程式碼評審不僅僅是評估程式碼樣式和功能，更是一個巨大的學習機會，讓你提升你的開發技能並與你的開發團隊在社群進行分享。將你的專案分解為更小的、可重用的包和框架，幫助你讓你的成果延伸到多個專案，並允許你共享它，這樣做同樣有利於減少二進位制包的大小。最後，使用外部依賴（比如Swift包）可以重用社群中已經開發好的功能，幫助你更快完成工作。但是一定要把關好它們的所作所為, 記住了嗎？包括它對你使用者資料做了什麼，也要做好沒有它們的準備。
將這些實踐作為你工作的一部分，只會給專案每個階段增加一點點時間，但是從長遠來看將會為你節省不可思議的時間，確保你的專案基業長青。我希望今天為你提供的想法和建議可以讓你思考如何進一步提升作為開發人員的手藝。你正在想納入的這些實踐可以提升你工作質量和穩定性，把這些自覺的努力轉換為習慣將允許讓你將精力投入到更重要的領域。那些使用你APP的人也許不能說出個所以然，但是能感覺到你投入這些工作所帶來的關愛，你能為自己打造的這些而自豪。謝謝！
【全文完】