随着工具链的完善，语言的升级以及各种优质教程的涌现，做一个 App 的成本也越来越低了。尽管如此，有些事情最好前期就做起来，避免当 App 有了一定规模后，再感慨当初为什么没有多留点心。
以 iOS 为例，有时图方便，就直接用 NSLog 了，甚至线上都一直开着。一方面会影响性能，尤其是输出比较频繁的时候，另一方面也容易泄露敏感信息，所以一般做法是在 Release 模式下禁用 NSLog，比如在 pch 文件中，通过对环境的判断，对 NSLog 做不同的处理。
但这样仍会有问题，比如我们发现线上的 App 在特定场景下会有某种异常的表现，这时就很希望能有日志来提供更多的信息。可以考虑使用像 cocoalumberjack 这样功能更完善的第三方日志工具，在线上仍然开着日志，但不消费，这样就不会泄露敏感信息。当我们需要看日志时，可以通过「调试模式」打开它，然后连上 iOS Console 来看。
因为 Log 是一个很普遍的行为，所以最好前期就规范起来，后期遍地都是 NSLog 时，再要改动会有点麻烦，当然也可以偷懒点，直接把 NSLog 的宏定义改了。
在前期开发的时候，往往为了快速实现功能，而忽略了 Commit Message 的规范，然后就会出现很随意的 Commit 信息。这样别人在 Review 代码时就会很累，写某个版本的 Release Notes 也会变得艰辛，甚至过一段时间自己都不知道这些 Commit 代表的意思。而如果自己也讲不清这次改动究竟该怎么描述时，往往是这次改动混杂了较多的信息。
这篇文章 简洁精确地描述了为什么要写好 Commit Message，以及如何写。遵守这些规范后，就很方便产出这样的 Release Notes 了。
这个最好在前期就抓起来，如果前期不做约束，每个人的风格往往会有比较大的差异，导致代码看起来会比较累，甚至有些人是从其他语言转过来的，还会保留之前语言的一些书写习惯，就容易有「出戏」的感觉。一致的代码规范不仅看起来舒服，而且让团队更像一个整体。
这个实施起来会有一定难度，尤其是团队中有一些「老人」的时候，他们往往积累了一套自己的编程习惯，而且不容易被说服。
里面包含了「最佳实践」和「不要踩的坑」，这个可以一定程度上提高开发效率，避免一些低级错误。比如以 iOS 为例，「不要随便使用通知」，因为通知使用起来太方便了，用得多了调试起来就会很累，而且也不好管理；「通知用完之后记得 remove observer」；不要使用 containsString (如果还需要支持 iOS 7 的话)。随着时间的累积，这份守则里的内容会越来越多，也是一件挺宝贵的财富。
这个在 Android 相对还好，基本都是通过 xml 来进行布局。在 iOS 里玩法就多了，有用 storyboard 的，有用 xib 的，有直接计算坐标和大小的，有用原生 autolayout 的，有用第三方布局类的。总之就是各显神通，尽量用同一种布局规范（但不建议直接计算坐标和大小），看起来也会方便些。
这是很重要的一块，客户端所有的数据基本就靠它了，所以尽量选择一个灵活、稳定的数据方案，同时最好在他们提供的 SDK 上再封一层，方便做一些额外的事情（比如想同时接入另一家服务作对比）。
统计埋点还有很重要的一点是「验证」，是否有错打、漏打等现象；iOS / Android 是否有用同一个点；有些点还需要额外的参数，这些参数的格式是否正确等。这些工具往往只能自己来做了，这也是比较花时间的一部分。
App 架构会随着业务、人员的增长而演进，所以当发现当前的架构无法满足日常的业务迭代时，就需要考虑对它做调整了。一般来说，大方向上也就是 MVP / MVVM，等人员多起来时，基本就是组件化开发，当然组件化也会有它的问题（比如资源 / 类重用、组件间通信等），这里就不展开了。
在前期选择一个相对轻量级，但比较清晰的架构（尽量不要选择 MVC），大家都遵守这个架构开发，也能一定程度上提高效率。
虽然 Android、iOS 都原生支持 open 特定 scheme 的 url，不过可能的话，还是通过 router 统一处理会比较方便，也更灵活。比如可以知道注册了哪些 URL；可以知道页面的跳转成功率；方便处理一些奇奇怪怪的需求等。
在线配置可以赋予 App 极大的灵活性，比如运营的一些活动、banner 位调整、首页弹窗等；还可以针对特定机型、系统分发特定的内容，结合规则引擎甚至可以给一部分有相同特征的用户发推送；可以做流量切分等。所以一个强大/稳定的配置中心就显得尤为重要，A/B Test 也可以基于配置中心来做。
这里有些注意事项，因为不少配置的值是运营填的，她们对 value 不那么敏感，所以会出现 value 为空，或者不是想要的类型，或者配了张图片，但是体积超大等，有可能造成客户端 crash / OOM 等异常表现，所以客户端要有足够强大的容错能力。
Crash 会给用户造成极大的负面体验，所以需要经常关注 Crash 情况，尤其是刚发版的那段时间。这块 fabric 做的比较好，只是由于是国外的服务，会有些许数据上的丢失，不过问题倒也不是很大，也可以考虑国内的一些服务，如 bugly，毕竟腾讯自己也在用。
这也是容易忽视的一点，当业务需求压过来时，先把功能实现了再说，而且在初期往往人手也不够，抽不出时间来做 Code Review。如果是这样的话，可以先 Review 一些核心的点，保证重要的代码是经过 Review 的，不太重要的业务代码可以先放放，等人员充足后再覆盖更大的范围。
Code Review 的主要作用是保障代码质量，同时促进双方成长，一个担心点是质量偏低的代码比例如果较大的话，会影响开发者的心情，增加维护成本，日积月累就成了重重的「历史包袱」。
如果是使用 git 来做源码管理的话，可以采用 flow 模式，基本能满足大部分的需求，而且不少 git 工具也内置了 flow 的支持。这样当需要处理 feature / hotfix / 发版等场景时，就会很方便。
持续集成的目的是让产品在快速迭代的过程中还能保证质量，当有错误发生时，可以第一时间被检查出来，方便修复。如果想偷懒的话，可以直接使用成熟的服务，如 travis，也可以自己基于 Jenkins 来搭，iOS 的话，配合 fastlane 效果会更好。自己搭的好处是灵活度更大，可以加入一些个性化需求。
如果有打包平台的话，还可以定时出一个包，这样当发现某个功能使用起来有问题，代码上又没什么头绪时，可以对比以前的包来定位。
这个 Bug 包括测试阶段和线上的 Bug，Bug 管理工具有很多，使用在线服务或自己搭都可以，但要有，不然很有可能忘了还有哪些问题需要修复，哪些已经修复了。
在 App 开发初期，人员较少，沟通起来比较方便，所以很多需求当面就说了，一些原型/设计图可能也是直接 AirDrop 过来的，这样效率自然高，但不便管理。比如没有 prd，产品、开发的理解可能不一致，到头来发现做的不是产品想要的，或者一些细节不符合要求；设计图有更新，但没有同步到所有的开发；需求有变更，但当时在专心做某个 feature，可能就忘了，或者没有理解全面等。所以最好还是有一个项目管理工具来统一处理，再结合敏捷开发，项目的质量和进度就容易得到保障。
一个 App 发布上线之后，要保证不出大的问题，就要在发布之前，先检查一下「一定不能出问题」的点是否正常，就像飞机起飞之前一定会走一遍 checklist 一样。比如推送是否正常、log 是否关闭、组件版本是否正确等，随着 App 功能的增加，这个 list 也会越来越长，虽然过一遍 checklist 会花费些时间，但跟收益相比还是值得的。
以上这些点是在感受不过不同量级的 App 开发后整理的，肯定还会有疏漏，不过如果真能做到这些，就已经很不错了，至少当有新人进来时，不会背上沉重的「历史包袱」。