标签：
本文转载于文章原文链接，版本归原作者所有！
随着工具链的完善，语言的升级以及各种优质教程的涌现，做一个 App 的成本也越来越低了。尽管如此，有些事情最好前期就做起来，避免当 App 有了一定规模后，再感慨当初为什么没有多留点心。
此处由标哥的技术博客站长点评：
看完本篇文章之后，也让我想起了不少以前做过的蠢事，做过很多重复的工作。之前在项目中使用过cocoalumberjack，个人感觉是很不错的日志管理框架。当然，不一定要求使用它，也在另一家公司里，原来的人将NSLog重定义了，改写了输出，但是总体并没有cocoalumberjack的强大。
使用git或者SVN提交代码时，一定要加上详细注释，否则出现问题时，都找不到是哪次提交的，而且没有好的注释也不利于code review。对于代码规范和编程准则，在公司通常都有要求的，除非你是来公司的第一人。其他就不多说了，大家慢慢体会吧，这些是很常用的！
完善的日志系统
以 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 开发后整理的，肯定还会有疏漏，不过如果真能做到这些，就已经很不错了，至少当有新人进来时，不会背上沉重的「历史包袱」。
标签：
原文地址：http://www.cnblogs.com/gongyuhonglou/p/5799078.html
