作一个App前须要考虑的几件事

 

本文转载于文章原文连接，版本归原做者全部！

 

随着工具链的完善，语言的升级以及各类优质教程的涌现，作一个 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 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 架构

App 架构会随着业务、人员的增加而演进，因此当发现当前的架构没法知足平常的业务迭代时，就须要考虑对它作调整了。通常来讲，大方向上也就是 MVP / MVVM，等人员多起来时，基本就是组件化开发，固然组件化也会有它的问题（好比资源 / 类重用、组件间通讯等），这里就不展开了。

在前期选择一个相对轻量级，但比较清晰的架构（尽可能不要选择 MVC），你们都遵照这个架构开发，也能必定程度上提升效率。

页面跳起色制

虽然 Android、iOS 都原生支持 open 特定 scheme 的 url，不过可能的话，仍是经过 router 统一处理会比较方便，也更灵活。好比能够知道注册了哪些 URL；能够知道页面的跳转成功率；方便处理一些奇奇怪怪的需求等。

在线配置

在线配置能够赋予 App 极大的灵活性，好比运营的一些活动、banner 位调整、首页弹窗等；还能够针对特定机型、系统分发特定的内容，结合规则引擎甚至能够给一部分有相同特征的用户发推送；能够作流量切分等。因此一个强大/稳定的配置中心就显得尤其重要，A/B Test 也能够基于配置中心来作。

这里有些注意事项，由于很多配置的值是运营填的，她们对 value 不那么敏感，因此会出现 value 为空，或者不是想要的类型，或者配了张图片，可是体积超大等，有可能形成客户端 crash / OOM 等异常表现，因此客户端要有足够强大的容错能力。

选择合适的 Crash 平台

Crash 会给用户形成极大的负面体验，因此须要常常关注 Crash 状况，尤为是刚发版的那段时间。这块 fabric 作的比较好，只是因为是国外的服务，会有些许数据上的丢失，不过问题倒也不是很大，也能够考虑国内的一些服务，如 bugly，毕竟腾讯本身也在用。

Code Review

这也是容易忽视的一点，当业务需求压过来时，先把功能实现了再说，并且在初期每每人手也不够，抽不出时间来作 Code Review。若是是这样的话，能够先 Review 一些核心的点，保证重要的代码是通过 Review 的，不过重要的业务代码能够先放放，等人员充足后再覆盖更大的范围。

Code Review 的主要做用是保障代码质量，同时促进双方成长，一个担忧点是质量偏低的代码比例若是较大的话，会影响开发者的心情，增长维护成本，日积月累就成了重重的「历史包袱」。

选择合适的开发模式

若是是使用 git 来作源码管理的话，能够采用flow模式，基本能知足大部分的需求，并且很多 git 工具也内置了 flow 的支持。这样当须要处理 feature / hotfix / 发版等场景时，就会很方便。

持续集成

持续集成的目的是让产品在快速迭代的过程当中还能保证质量，当有错误发生时，能够第一时间被检查出来，方便修复。若是想偷懒的话，能够直接使用成熟的服务，如travis，也能够本身基于 Jenkins 来搭，iOS 的话，配合 fastlane 效果会更好。本身搭的好处是灵活度更大，能够加入一些个性化需求。

若是有打包平台的话，还能够定时出一个包，这样当发现某个功能使用起来有问题，代码上又没什么头绪时，能够对比之前的包来定位。

Bug 管理系统

这个 Bug 包括测试阶段和线上的 Bug，Bug 管理工具备不少，使用在线服务或本身搭均可以，但要有，否则颇有可能忘了还有哪些问题须要修复，哪些已经修复了。

项目管理工具

在 App 开发初期，人员较少，沟通起来比较方便，因此不少需求当面就说了，一些原型/设计图可能也是直接 AirDrop 过来的，这样效率天然高，但不便管理。好比没有 prd，产品、开发的理解可能不一致，到头来发现作的不是产品想要的，或者一些细节不符合要求；设计图有更新，但没有同步到全部的开发；需求有变动，但当时在专心作某个 feature，可能就忘了，或者没有理解全面等。因此最好仍是有一个项目管理工具来统一处理，再结合敏捷开发，项目的质量和进度就容易获得保障。

Checklist

一个 App 发布上线以后，要保证不出大的问题，就要在发布以前，先检查一下「必定不能出问题」的点是否正常，就像飞机起飞以前必定会走一遍 checklist 同样。好比推送是否正常、log 是否关闭、组件版本是否正确等，随着 App 功能的增长，这个 list 也会愈来愈长，虽然过一遍 checklist 会花费些时间，但跟收益相比仍是值得的。

以上这些点是在感觉不过不一样量级的 App 开发后整理的，确定还会有疏漏，不过若是真能作到这些，就已经很不错了，至少当有新人进来时，不会背上沉重的「历史包袱」。