真正的高手，做事绝不会平均用力，而是把大部分精力投入在价值更大的事情上，从而提高自身效能。
这篇文章来讲，做独立开发，在新功能的开发上、个人工作量的排布上，该做什么，该不做什么。
事倍功半
做独立开发的，大部分都有在公司全职任职开发的经历，做过很多产品经理要求的、细枝末节的功能。很多东西可能 1000 个用户里面只有 1 个人用，但由于产品经理认为这个东西有价值，那作为工程师，也不得不去把它完成。
而这样的东西，在我们独立开发的过程中，往往事倍功半。所以我并没有说“不该做”，我的措辞是“该不做”。独立开发往往一个人要干十个人的活，如果事事都按公司里面那套流程来，必然效率低下。
既然独立开发要干的活是全面的、时间是宝贵的，那么做东西必然要考虑投资回报率。如果一个需求，既不能在功能上对你的产品有明显改变、也不能在体验上有明显优化，那么投资回报率就是很低的，就不值得去做。
反之，有些事情在公司里找人专人负责的，我们或许只需要几行代码就能做到 80% 的效果，这种东西就必须去做。
该做 - 刷评分
无论是苹果的 App Store 还是各类安卓应用商店， 应用都有办法跳转到商店来让用户给应用评分。iOS 10.3 之后还有这样一个方法，来让用户留在 App 内就可以方便地给 App 进行评分。
class func requestReview()
然而很多人对于评分这件事，都是最多在设置页里面加一个按钮之类的入口，让用户主动去给应用评分。
这是不行的，这是低效的，让用户来主动做一件对他没什么好处的事情，我们要积极主动，而不能冷淡处理。更不能嫌麻烦，觉得这和产品本身无关，就不去做。
而实际上，拿 iOS App 举例，只需要上面那一行代码，就可以引导用户评分。你只需要选择一个恰当的实际就可以了，比如用户刚刚成功地保存了一张图片到相册。有人说这种评分机制被苹果限制了，一个用户对一个 App 一年只能用三次，于是不敢乱用。然而你看看自己的用户留存率就知道，绝大部分用户下载了 App 之后可能就把它删掉了，或者是再也没有打开。这三次机会，多数情况下，你一次都用不掉。所以一定要积极让用户去评分。
很多应用在这方面没做好，应用下载量很大，但是应用商店 5 分的满分评分，用户评分只有 4 分不到，评分数量也非常少。这一点可能只需要花掉你不到 10 分钟的时间就可以改变，然而它对用户看见你的应用的印象分提升却可能是比较大的。
大公司雇专人来做的刷评分这件事，你没理由不做。有关去淘宝花钱给自己刷评论、提升关键字搜索权重的 …… 涉及灰产，有兴趣可以自行搜索。
该做 - 常更新
个人开发没必要和公司里面的 App 排期更新一样，比如固定一个月更新一次。
当看到用户有反馈（问题或新功能需求），自己确定可以马上实现的话，没必要等到很多东西攒到一起再打包更新。
一直迅速迭代、小步快跑。不仅可以让新用户觉得你的产品一直在更新，可以获取用户信任。当用户发现自己的反馈，及时地出现在新产品中时，用户也会有一种参与感，从而帮助你的产品形成口碑效应。（小米的 MIUI 论坛就是这样做的）
当然，如果对仓促加入的内容的稳定性不放心，也要使用灰度来发布新版本，并且时常关注后台统计的 App 崩溃等问题。
该不做 - 永远自己写后台
之前写过一篇 《入门：独立开发者如何解决后台问题》 也提到过。
我的建议是，有适当的需求和能力的话，独立开发者是可以自己写后台的。重点在于，不要认为独立开发者永远应该自己写后台。
很多时候，如果你不是对自己的后台维护特别放心，使用第三方服务是可以提高后台的稳定性的。并且，独立开发很难 24 小时做运维，使用第三方服务，是把运维工作外包出去的一个好方法。
该不做 - 过度兼容机型与系统
对于各种多年以前的老版本系统，以及很多年前发布的旧机型，一般大公司都是选择尽量兼容的。因为哪怕是多照顾 1% 的用户，都可能是上百万的收入，远大于做决策的人的工资。
而对独立开发者来说，放弃 1% 的用户一般不仅不会对收入带来太大负面影响，并且这 1% 的旧机型用户，很多年龄偏大，或者是有人把手机当做备用机来用的，这部分的用户的付费意愿是很低的，这 1% 的用户量，体现在收入上，可能连 0.1% 都不到。
这样一来，为了兼容旧版本系统和过旧机型所付出的工作量、以及解决出现率很低的 bug 所耗费的时间，就都可以节省下来了。用这些时间、精力，去做开发新功能、收集用户反馈等工作，可能是投资回报率更高的事情。
该做- 尽可能多地存档资源文件
对于平时会用到的设计稿、图片资源、应用商店需要用到的各个语言版本的 App 描述、不同尺寸的应用截图等一系列与代码无关的内容，都可能在你日后做重构、改版的时候用到。
平时多花点时间，把这些内容都索引起来，直接放到 Git 来托管，是非常值得做的一件事情。一点小习惯，可以为日后找不到文件节省大量的时间。
以及，对于 Git 里面的哪一次提交，对应于 App Store 的哪个版本，也要有记录。这样在用户反馈的时候，可以一眼看到用户使用的版本，是不是没有进行过某次更新的旧代码。
该不做 - 过于详细地产出设计文档与代码文档
与公司里面，文档产出尽量要让别人看懂不同。独立开发过程中，由于从设计原型到代码落地，这一过程很多时候是自己在完成。如果整理了很多中间步骤的设计文档、开发文档，其实是对时间的浪费。
唯一的标准，其实应该是自己可以把控的 —— 未来自己能看懂即可。
我个人的习惯是，无论是设计的 Sketch 文件、还是工程的 Xcode 文件，都尽量有完整的注释、明确的文件命名，尽量不出现 image1、image2、rect1、rect2 这种没有实际意义的命名，但是尽量少地单独产出文档。
