<b>本文講的是一個人的 Android 開發，</b>
<b></b>
兩年半之前，在一個由四個人組成的 Android 團隊的幫助下，我開始從後端開發轉向移動開發。一年之後，我加入了一個已經完成了B輪融資的初創公司，在那裡主要做 Android 開發的工作。在一個小團隊裡工作，既能很好地保持獨立，還不耽誤向同僚學習。
結果證明這是一個大飛躍。單飛一直是一個挑戰，但它也帶來了很多回報。一路走來，我發現獨自工作是有利有弊的。不過最重要的是，你可以做一些事情來幫助自己走向成功。這裡有一些目前為止已經幫到我的政策。
對單飛的擔心之一是，我已經習慣了以前的角色，擔心沒有人能一起讨論新的想法并且給我出主意。
我用 GitHub 自帶的預覽功能完成第一步，之後把它放一邊然後過一段時間再來檢視。我盡全力來審查自己的送出，就像我審查同僚的代碼一樣，來確定我用同樣嚴格的标準要求自己。回過頭看自己的代碼還有助于發現 bug 和錯誤的邊界情況處理，以及讓你的代碼保持統一和整潔。
項目開始的時候，一開始的時候使用一種模式，之後意識到另一種模式更好，并由此帶來一些模式的重構和去除并不是一件新鮮事。
雖然在某些情況下打破你的模式是有意義的，但是當你發現更好的東西時，最好留心去重構并且改變之前的代碼來使整體保持一緻。這可能聽起來很明顯但是僅僅把新的模式用到新的代碼中更為簡單，是以當你一個人工作的時候可能會傾向這麼幹。但是這樣會在你察覺到之前迅速讓你的代碼變得蜜汁混亂！即使這個模式并不是很棒，保持代碼的一緻性會讓之後的修補變得更容易。
除非你是從頭開始，不然的話，考慮一下在下一個你将要寫的類裡試試吧。
我記得在 MVP 中，曾經花費過很多時間選擇一個庫來用，因為這些庫實在是太多了。被豐富的選擇慣壞是個很大的問題，最終我自己造了個簡單的輪子，用得很開心。
當選擇用哪個第三方庫的時候，我建議考慮好你是否真的需要它以及它會對你未來的開發造成哪些限制 —— 它會為單元測試增加難度嗎？它會限制使用 Android 自帶的特性嗎，比如多屏之間的過渡動畫之類的？它的開發是不是仍然很熱火朝天并且有很多 APP 使用它？這些考慮讓我好好權衡并做出決定。
我建議在盡可能保留掌控的情況下去優化，而無須重新造輪子 雖然有個庫已經幾乎包含所有的東西了，但是自己去實作一些東西會更好。（使用第三方庫的基礎元件，自己根據需要進行組合。—— 譯注）
如果你接手的項目是從頭開始，那麼你現在就可以去做了！不然的話，你可以在接下來你寫的代碼中這樣做。
面對張牙舞爪的 deadline，測試和輔助功能往往是下等公民。而你把一旦它們的優先級放得很低，由于沒有其他人跟你分擔，你就更難找到時間去實作它們了。
如果時間不允許來編寫測試，那就人工測試就很友善了。比如，在一個文檔中為每一個特性寫下不同的測試案例（正面的、反面的），確定在每次釋出前進行這些測試。為自己定下編寫測試和進行 Accessibility 改進的 deadline，不然你可能永遠也完成不了它們。
不要因為支援你的平台上的正确的事情而擔心！當你一個人幹的時候，你有責任帶着别人跟上最新的 Android UI 模式和代碼庫的發展速度。
至于代碼庫，在我的 CEO 來幫忙的幾個月内，我向她普及了我們的架構和 MVP、Dagger2、RxJava2 之類的概念。我建議保持向周圍的人進行 Android 概念的傳教，因為向别人解釋你的決定或者教給他們一個新的概念幫助你真正得掌握這個概念，有時還會讓你意識到自己的錯誤。
如果你在開發一個嶄新的 APP，我建議在上架前盡快開發出内測版，然後在這個内測版準備好了的時候把它轉為開放的公測版。 我們的第一個内測版隻有很少的幾個功能，但是它幫助我們及早發現了 bug，步入了周期性釋出的正軌，并且獲得了很有價值的回報。這也讓我們毫無壓力并且可以平穩上線。
第一次單飛是個很好的學習經曆，因為你挑戰自我了，這是之前從未有過的。 你變得更加依賴自己、鍛煉了對代碼庫的整體控制（或好或壞）、學習了更多自己喜歡的東西并且處理怪不得别人的錯誤（耶）。我曾經擔心單飛，但是在上面的建議的幫助下，結果是一個很好玩的經曆。我希望這些建議同樣會對你有所幫助。
<b>原文釋出時間為：2017年3月31日</b>
<b>本文來自雲栖社群合作夥伴掘金，了解相關資訊可以關注掘金網站。</b>