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