APP重构工程师
2014年 08月 09日
相信很多人都听过网页重构工程师，但是对于原生App来说，就很少听说有专门的重构工程师，基本上都是开发一个人包揽的界面还有一些数据和逻辑的开发。我第一次听说这个词也是两年前听我们部门的leader在webRebuild年会上的一个关于App重构主题分享，那时候就有了一些概念。加上最近看的一篇文章，结合团队这半年来积累的一些有关App重构的经验，才有了下面这篇文章。
关于上面的那篇文章所提到的，因为app的界面和逻辑都是一个人干，所以就出现了这样的问题：
- 周期相对较长。
- 代码耦合强。
- 沟通成本高。
- 设计还原质量低。
所以就有了这样的一个结论结论：让擅长用户体验的前端同学来进行App界面重构。
在web开发中，前端或者重构的同学，应该是最注重用户体验的一群人。在他们眼里，是容不得界面上有一个像素的差错的，所以把App上的界面交给他们来做，是最放心不过的了。但是，这样一群没有接触过App开发的同学，要怎样习惯，甚至成为App开发这个流程中重要的一环呢。首先，先说说想要进入App重构这个角色，需要做一些什么事情。
##角色定位 首先，拿到设计稿后先跟设计师过稿，看看哪些可以抽取公用的模块，哪些实现起来会有问题，要怎样调整设计稿。 过完稿后，和开发那边约定界面需要提供的接口，然后开始制作界面。（甚至可以搭建一套UI组建或者框架）。 界面制作完成，跟开发联调，将你制作的view跟开发的数据打通。 功能开发完成后，如果需要修改界面需求，我们只需要维护自己的界面层代码。如果改动大，需要改到逻辑层，则再跟开发联调。
##现阶段难题 大概知道了App重构这个角色的定位，那么，现阶段要实现这个角色的价值，会遇到哪些困难呢？你可能会问：开发的同学或者PM对这部分界面重构同学能力不会产生怀疑吗，毕竟都是没有接触过iOS的相关支持；多了这样一层角色，沟通上不会出现断层吗，信息传递不会很容易不同步吗，项目的进度难道会更怪吗；还有，小公司人力好，资金少，也适合这种合作模式吗； 这些问题都很好，现阶段确实存在这几个难题：
- 开发或者PM或担心我们的能力而导致项目进度受到影响。
- 沟通的成本是否会比原本的工作模式大。
- 小公司或者小团队没有足够的人力和资金。
##解决途径 凡是有难题，那肯定有解决难题的方法。 第一个问题：一开始确实肯定会受到其他人的质疑，这也是不可避免的，关键是要如何让别人慢慢的接受我们，肯定我们的能力。在一开始的磨合期，可以先从小项目入手，在项目的过程中不断的总结经验，储备知识。 第二个问题：在沟通上，我反而不会觉得多了一层角色会导致沟通上的障碍。因为对于界面重构的同学来说，他们更擅长跟设计师打交道，能够更好的理解设计，甚至能够在设计上提出自己的观点。 第三个问题：确实，如果是人力或者资金不充足的团队，那这样的工作模式就不适合你们，反而会导致项目进度受到影响。
当App重构这个角色很好的融入到App开发中，那么就可以看到很明显的效果。开发的同学可以把更多的精力放到功能逻辑上，缩短项目时间。界面的代码由重构单独维护，不仅可以提高代码质量，还可以形成一套比较系统的UI套件，有利于以后新项目的开发。最后一个就是设计稿的还原，这一点不用多少了。反正，设计师们会说：妈妈再也不用担心我的设计稿被还原变形了。
##路才刚刚开始 界面重构的同学请注意，我们主要的任务是维护界面view层的代码，自然需要对这一层的代码学的比较深，至少要比开发的同学好（不然跟直接把界面交给他们做有什么区别呢）。但是这个还是不够的，我们还需要扩大代码的广度，至少要看得懂除了view层之外的代码，不然你跟开发的同学就没法沟通了，我还是比较推崇所谓的“全栈工程师”。 在项目的积累过程中，要不断的积累，逐渐形成并整理一套适合团队的UI框架，对于以后的新项目，直接套用这一套UI框架，可以节省很多时间。
##UI框架 对于UI框架，我们团队也正在从平时的项目中整理出一套适合我们的框架，框架还在不断的完善中。UI框架我觉得可以从下面这几个方面入手：
- 统一的宏和数学计算接口。我们会定义一些每个项目固定不变的宏(比如判断iOS版本，屏幕大小之类)，以及一些会更具不同项目而改变的宏(有个config文件，每个新项目只需要修改这里的配置即可，比如app的主色调，cell的高度之类)。然后还有一系列的数学计算接口，用来方便设置view的frame或者其他一些参数。
- 对原生UIKit的重写和封装。也就是正对自己团队的设计风格，对系统UIKit进行一些样式的格式化(包括不同iOS版本的样式统一)或者增加新的接口。
- 对原生UIKit的拓展。比如UIButton，我们可以在它的基础上拓展出其他一些各种各样的button样式。
- 比较完整的UI控件。比如查看大图控件、下拉菜单控件等比较完整，可以独立工作的模块控件。
##App重构的展望 我们团队已经使用这种工作方式一年左右了，我们在保证app界面质量的同时，也在慢慢的积累经验，提高开发速度。 相信未来这种工作模式在大公司会慢慢发展起来，至少注重界面用户体验的团队，会慢慢的接受这种工作模式。 希望更多人参与进来，一起把这种模式慢慢的推动和完善起来。