（譯）第一次Android開發單飛
兩年半之前，在一個由四個人組成的 Android 團隊的幫助下，我開始從後端開發轉向移動開發。一年之後，我加入了一個已經完成了B輪融資的初創公司，在那裡主要做 Android 開發的工作。在一個小團隊裡工作，既能很好地保持獨立，還不耽誤向同事學習。
但隨後，五個月前，我從原本的小團隊跳槽到了一個“根本沒有團隊”的地方，我去的這家是剛剛成立的創業公司，只有六個人，而我是其中 唯一的 Android 工程師。在這個新的崗位，我從零開始完成了 Winnie，這個 APP 最近已經發布 了！
結果證明這是一個大飛躍。單飛一直是一個挑戰，但它也帶來了很多回報。一路走來，我發現獨自工作是有利有弊的。不過最重要的是，你可以做一些事情來幫助自己走向成功。這裡有一些目前為止已經幫到我的策略。
跟社群保持接觸 業餘不忘充電
對單飛的擔心之一是，我已經習慣了以前的角色，擔心沒有人能一起討論新的想法並且給我出主意。
好訊息是有很多線上資源可以拓展你的知識和視野。 從 DroidCon 、 360|AnDev 這樣的開發者大會上的線上分享，到 Fragmented Podcast 、 Android Dialogs 和 Android Weekly 這樣的時效性很高的網站，你有很多方法來拓展自己的想法。
我個人最喜歡的是 Caster.io —— 程式碼示例加上簡短的解說視訊讓我隨時脈動回來！ 線下聚會或者 AndroidDev subreddit 、 Google+ communities , Slack groups 和 Twitter 這樣的社群對於繼續討論和解疑釋惑，都是很好的去處。
審查之前提交的程式碼 保持高標準
我特別建議開啟提交記錄來審查自己的程式碼。在自己的提交下評論可能看上去很傻，但是我認為如果你一個人工作的話，這是個很好的習慣。這一點在 一個跟 Android 相關的對話節目系列 中也有討論。
我用 GitHub 自帶的預覽功能完成第一步，之後把它放一邊然後過一段時間再來檢視。我盡全力來審查自己的提交，就像我審查同事的程式碼一樣，來確保我用同樣嚴格的標準要求自己。回過頭看自己的程式碼還有助於發現 bug 和錯誤的邊界情況處理，以及讓你的程式碼保持統一和整潔。
一個“不好的”模式通常比沒有模式要好
你不得不做出很多決定 —— 應該使用 MVVM 、 MVP 、Flux，還是其它的架構模式？使用 Fragment 還是 ViewGroup？哪些應該是抽象的而哪些不應該是？
專案開始的時候，一開始的時候使用一種模式，之後意識到另一種模式更好，並由此帶來一些模式的重構和去除並不是一件新鮮事。
雖然在某些情況下打破你的模式是有意義的，但是當你發現更好的東西時，最好留心去重構並且改變之前的程式碼來使整體保持一致。這可能聽起來很明顯但是僅僅把新的模式用到新的程式碼中更為簡單，所以當你一個人工作的時候可能會傾向這麼幹。但是這樣會在你察覺到之前迅速讓你的程式碼變得蜜汁混亂！即使這個模式並不是很棒，保持程式碼的一致性會讓之後的修補變得更容易。
牆裂建議使用Kotlin
除非你是從頭開始，不然的話，考慮一下在下一個你將要寫的類裡試試吧。
我最終沒有在 Winnie 中使用 Kotlin ，因為我當時沒有經驗所以對這個想法不夠自信，加之不想打擊團隊中的 Java 後端工程師向程式碼庫中貢獻程式碼的熱情。
然而，在看過 Christina的關於 Kotlin 的演講 並且做了一些研究之後，如果能重來，我至少會試試這門語言。 Kotlin 有很多優點 —— 即使只是防止 null pointer 引起的異常和不與 Java 笨拙的模式化程式碼同流合汙（Kotlin 的語法比 Java 要精煉得多 —— 譯註）就讓我佩服得五體投地。 Jake Wharton 的 這個講座 是個很好的學習 Kotlin 的起點。
掌握自己的程式碼 不要過分依賴第三方庫
我記得在 MVP 中，曾經花費過很多時間選擇一個庫來用，因為這些庫實在是太多了。被豐富的選擇慣壞是個很大的問題，最終我自己造了個簡單的輪子，用得很開心。
當選擇用哪個第三方庫的時候，我建議考慮好你是否真的需要它以及它會對你未來的開發造成哪些限制 —— 它會為單元測試增加難度嗎？它會限制使用 Android 自帶的特性嗎，比如多屏之間的過渡動畫之類的？它的開發是不是仍然很熱火朝天並且有很多 APP 使用它？這些考慮讓我好好權衡並做出決定。
我建議在儘可能保留掌控的情況下去優化，而無須重新造輪子 雖然有個庫已經幾乎包含所有的東西了，但是自己去實現一些東西會更好。（使用第三方庫的基礎元件，自己根據需要進行組合。—— 譯註）
規劃好測試（Testing）和輔助功能（Accessibility）
如果你接手的專案是從頭開始，那麼你現在就可以去做了！不然的話，你可以在接下來你寫的程式碼中這樣做。
面對張牙舞爪的 deadline，測試和輔助功能往往是下等公民。而你把一旦它們的優先順序放得很低，由於沒有其他人跟你分擔，你就更難找到時間去實現它們了。
我承認，我自己只是才開始做這方面的工作。但通過使用依賴注入，MVP 模式，只暴露 Model 物件的介面到 UI 等等方法來在腦海中寫測試程式碼，來達到更容易測試的目標。從專案開始的時候，每次提交之後，我都會同時在 CircleCI （一個持續整合和釋出的平臺 —— 譯註）上進行編譯，以便進行簡單的檢查和執行測試。
對於輔助功能（Accessibility），我在任何可以的時候都新增上內容描述，並且在釋出前使用 Accessibility Scanner 來找出我接下來還需要做哪些這方面的工作。毫無疑問還有更多的工作要做，但這是個不錯的開始。Kelly Schuster 的 這個演講 給出了一些可行的建議使得開發者可以讓自己的 APP 變得對有缺陷的人群更友好。
如果時間不允許來編寫測試，那就人工測試就很方便了。比如，在一個文件中為每一個特性寫下不同的測試案例（正面的、反面的），確保在每次釋出前進行這些測試。為自己定下編寫測試和進行 Accessibility 改進的 deadline，不然你可能永遠也完成不了它們。
告訴你的 iOS 設計師他們是錯的 自己尋求到 Android 設計的轉換 :-).
不要因為支援你的平臺上的正確的事情而擔心！當你一個人乾的時候，你有責任帶著別人跟上最新的 Android UI 模式和程式碼庫的發展速度。
我工作中通常得到的是 iOS 系統上的截圖，但是使用 Material 設計規範 和一些優秀 Android APP 作為資源來把那些設計轉換到 Android 裡面。還有，沒有什麼比引用官方的 Material Design 文件更適合來說服別人了！
至於程式碼庫，在我的 CEO 來幫忙的幾個月內，我向她普及了我們的架構和 MVP、Dagger2、RxJava2 之類的概念。我建議保持向周圍的人進行 Android 概念的傳教，因為向別人解釋你的決定或者教給他們一個新的概念幫助你真正得掌握這個概念，有時還會讓你意識到自己的錯誤。
儘早釋出 beta 版
如果你的 APP 還沒有上線或者在現有的基礎上進行了重大的變化，這條會很適用。Google play 有一個 alpha 和 beta 頻道，在 beta 頻道，你可以自由開關你的 beta 版本。
如果你在繼續開發一個已經存在的 APP，你仍然可以平行地釋出 beta 版，只要版本比當前的正式版高就好了。如果是開放的 beta 版，使用者將可以通過在 play store 安裝或者點選一些連結下載安裝來使用。如果你要對變化進行小規模的測試， staged-rollouts 將會是個很合適的選擇。
如果你在開發一個嶄新的 APP，我建議在上架前儘快開發出內測版，然後在這個內測版準備好了的時候把它轉為開放的公測版。 我們的第一個內測版只有很少的幾個功能，但是它幫助我們及早發現了 bug，步入了週期性釋出的正軌，並且獲得了很有價值的反饋。這也讓我們毫無壓力並且可以平穩上線。
第一次單飛是個很好的學習經歷，因為你挑戰自我了，這是之前從未有過的。 你變得更加依賴自己、鍛鍊了對程式碼庫的整體控制（或好或壞）、學習了更多自己喜歡的東西並且處理怪不得別人的錯誤（耶）。我曾經擔心單飛，但是在上面的建議的幫助下，結果是一個很好玩的經歷。我希望這些建議同樣會對你有所幫助。
打算單飛或者和分享你的單飛經歷？很高興聽到你們的聲音。歡迎加入Android開發技術交流QQ群；701740775
本群提供Android高階開發資料、高階UI、效能優化、架構師課程、NDK、混合式開發（ReactNative+Weex）等相關資料和解答
不懂得問題都可以在本群提出來 還會有職業生涯規劃以及面試指導
進群修改群備註：開發年限-地區-經驗
方便架構師解答問題