翻译自Anita Singh的Flying Solo with Android Development
我的Android职业生涯开始在两年半前，当我从一个四人的Android团队的支持下，从后端开发转向移动开发。 一年以后，我加入了一个B系列的初创公司，在那里我是大部分时间里的两个Android工程师之一。 在小团队工作是一个好的独立方式，也可以从其他工程师那里学习。
但是在五个月前，当我加入了6名员工的天使轮初创公司作为他们唯一的Android工程师时，我才从小团队飞跃到没有团队。 在我的新角色，我从头开始构建Winnie app，刚刚发布！
原来这是一个大的飞跃。 独立开发一直是一个挑战，但也是非常有益的。 我一直在学习，有利弊单独工作。 最重要的是，有一些事情可以让自己取得成功。 这里有一些帮助我的手段。
与论坛联系。 做你的家庭作业。
我对独立开发的一个担忧是没有Android队友讨论出新的想法，或者提出他们的想法，我非常喜欢我以前的角色.
好消息是，网上有大量资源可以扩展您的知识和观点。 从DroidCon，360 | AnDev,Fragmented Podcast，Android Dialogs和Android Weekly等网站，您可以通过多种方式来拓宽您的思维。
我个人最喜欢的是Caster.io - 每个带有示例代码小而美的讲义让我一直注意！ 当卡住的时候本地会议或虚拟论坛（如AndroidDev subreddit，Google+社区，Slack群组和Twitter）是继续聊天和问问题的好地方！
审查自己的PR，并保持高标准。
我非常鼓励公开PR，然后自己审查自己。 在自己的PR上会看到有愚蠢的评论，但是我认为这是一个健康的习惯（在这个相关的Android对话框中也讨论过）。 我使用Github的预览功能进行第一遍监查，过一会儿，然后再看一遍。 我尽力监查我的PR，因为我会监查同行的PR，因此坚持相同的标准。 第二次看看你的所有代码也有助于找到错误和边缘案例，并保持你代码的一致和干净。
“坏”架构通常比没有明确的架构更好。
您将不得不作出许多决定 - 应该使用MVVM，MVP，Flux和/或其他架构模式？ Fragments或自定义ViewGroups？ 应该有什么抽象和什么不应该？
从一个不常见的模式，然后在项目开始时实现另一种更好的模式，这会导致模式的一些重构或分歧。
尽管在某些情况下破坏您的架构是有意义的，最好仔细的重构并且当你找到更喜欢的架构可以随时随地的重构他。 这可能听起来很明显，但是独立开发时，即使对新代码使用新的架构很简单,但是这可能会在您了解新架构之前快速导致代码库混乱！ 即使模式不是很好，也使得它更容易修复。
强烈的考虑使用Kotlin
特别是如果你从头开始！ 如果没有，请考虑下次使用它. 我没有使用Kotlin，因为我对这个想法没有信心，因为我当时没有经验 不过，在看了克里斯蒂娜的谈话，进行更多的研究后，如果我再做一次，我至少会尝试。 Kotlin有很多优点 - 即使只是避免因空指针异常而导致的崩溃的功能使我蛰伏！ 杰克·沃顿（Jake Wharton）的这个演讲也是一个很好的起点。
尝试通过不太依赖第三方库来保持控制。
我记得花费一大堆时间来决定一个用MVP的lib，因为他们中有很多代码。 当出现一个很严重的问题时候，我最终自己实现一个简单的版本，并非常高兴！
当选择使用哪些第三方库时，我建议您考虑是否真的需要它，以及如何限制未来的应用程序的开发 - 是否使单元测试更加困难？ 它是否限制Android免费提供的功能，例如屏幕之间的转换动画？ 它正在开发中，并且许多应用程序使用它？ 这有助于我做出明智的权衡和决定。
我建议尽可能的修改已有库，而不必重新写一个。 几乎所有的东西都有一个lib的时候，但你最好自己实现一些东西。
有一个测试和无障碍计划。
如果你是从头开始构建项目的，这是非常令人兴奋的，你有机会从第一天就这样做！ 如果没有，您可以尝试使用所有新代码编写正确的代码！
测试和辅助功能可能会延长交付时间，并不罕见，而且当您独立开发时，可能难以找到时间节点，因为您没有与任何其他人分担压力
我会承认，我本来只是刚开始，但是我通过使用依赖注入，MVP模式，仅将我的Model对象暴露给UI，并以目标等方式编写了测试代码 使其更容易测试。 在项目开始后的每个提交之后，我也建立了CircleCI，作为一个健全检查，并且更接近运行测试。
对于辅助功能，我可以随时添加内容描述，并在发布之前使用辅助功能扫描程序来确定下一步应该关注的内容。 有更多的工作要做，但这是一个开始。 以下是Kelly Schuster的一个很好的演讲，介绍开发人员可以采取的可行步骤，使他们的应用程序更无障碍。
如果您无法花时间撰写测试，那么手动测试计划便于使用。 例如，在每个功能的文档中记下不同的测试用例（正，负），并确保在每次发布之前测试这些测试用例！ 设定自己开始编写测试的最后期限，并对辅助功能进行改进，否则很可能永远不会完成。
告诉你的iOS设计师，他们错了，寻找可以用Android代替的东西:-)。
不要害怕你的平台站不住脚,当你独立开发时,您有责任使其他人能够加快最新的Android UI模式以及代码库。
我主要从事iOS屏幕截图，但使用material design规范和精心设计的Android应用程序作为资源来帮助我将这些设计转换为Android。 此外，没有什么比链接到官方material design文档更好的观点！
关于代码库，我帮助我的CEO加快了我们的架构和概念，如MVP，Dagger2，RxJava2等，当她帮助了几个月。 我建议您注意潜在的Android转换器，将您的决定解释给某人或教他们一个新的概念可以帮助您真正拥有它，或者yi意识到你的错误.
尽可能的早点测试
如果您正在处理尚未启动的应用程序或正在对现有应用程序进行重大更改，则此功能适用。 Google Play拥有Alpha和Beta版频道，而在beta版频道中，您可以使用封闭式或开放式的测试版。
如果您正在使用现有的应用程序，则您仍然可以并行运行Beta版，只要其版本高于生产应用程序。 如果是开放式测试版，用户将可以选择加入商店或点击链接。 如果您试图测试较小规模的更改，那么分阶段推出可能会更好。
如果您正在开发一个新的应用程序，我建议尽快关闭测试版，并在启动之前将其转换为开放测试版。 我们的第一个封闭测试版功能非常少，但是它帮助我们早日解决了错误，在整个过程中获得了定期的发布列表并获得了宝贵的反馈。 这也导致了无压力和顺利的发射！
第一次独立开发是一个伟大的学习经验，因为你从未像以前一样挑战自己，更自力更生，对代码库进行全面的控制（更好或更坏），更多地了解你喜欢的内容，以及 处理自己写的错误，你只有自己责怪。 我很紧张的去独立开发，但事实证明是一个有趣的经验，因为上述建议对我有用。 我希望他们也对你有帮助！
扫一扫
174
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
