<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>