Android团队的组建和管理

最新推荐文章于 2024-03-15 19:47:12 发布

狂镀余光

最新推荐文章于 2024-03-15 19:47:12 发布

阅读量974

点赞数 1

分类专栏： android

本文链接：https://blog.csdn.net/GEN216IUS/article/details/82734822

版权

android 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

这个首先要从两个大方面说起：

A、产品定位（因为产品不同导致功能不同，所面对的应用场景就不同，这个产品定位并不是市场方向的产品定位，而且是要了解所做产品的技术实现及用户习惯等等方面，具体来说应该是产品技术实现方面的定位）；

B、技术层面，最终还是要实现产品功能，让产品达到量产阶段才有意义（这个需要从Android的架构说起，毕竟Android是一个庞大的系统，单独某个人全部做完，在产品快速迭代的今天不太现实，android架构图如下）；

1、Team Leader(一个强力的Team Leader，外加一些愿意干活的人就行了，在工作中培养人才，提升从业人员水平，有强力Team Leader的指引下，每个人都是能够发挥出最大作用，而且不会走偏)

2、名校论不适用研发（类似于搜索之类涉及复杂算法的软件行业，固然需要较高学历良好背景的人去研究。但对于App应用类软件而言，每天的开发工作大都是重复性画UI和调用MobileAPI获取数据，并无需名校出身）

3、面试时需要考察的几个点

主要考察3个方面：

(1)、技术水平，主要是候选人的编程技术水平，比如C语言、C++语言、JAVA语言、脚本等等。

(2)、领域知识，主要是候选人对业务的了解程度，这个相当于是对产品功能的熟悉，有很多是针对性的产品。

(3)、软件技能，包括沟通能力、抗压能力、性格以及查找BUG的技能（即解决问题的能力，这个是最主要的）。

一般而言，面试有两轮最重要。第一轮是Team Leader面试，考察技术水平。第二轮是用人部门的负责人面试，考察领域知识和软件技能。

--->如何考察面试者的技术水平？对于App而言，分为3个方向：

(1)、应用类：共同特点是页面特别多，都需要频繁地调用MobileAPI获取数据，都涉及到支付流程，所以这类App的开发人员需要对UI、网络、登录、支付流程都非常熟悉。

(2)、手机管家类：这类App虽然也算是应用类，但是很少调用MobileAPI,它更多关注的是手机系统内部数据的读写，所以这类App的开发人员需要对ActivityManager、Service、BroadcastReceiver之类的知识很熟悉。

(3)、游戏类：必须对动画引擎很熟悉，比如说Cocos2d和Lua。

此外，还有一类Android从业人员，是在华为、三星这样的硬件厂商做手机系统的二次开发，包括手机系统上自带的一些软件，严格地说，不属于App开发。

--->面试时经常考察的几个方面：

(1)、Activity的生命周期。

(2)、Activity的4的4种启动方式及使用场合。

(3)、做过的项目中，Activity是否有基类，如果有，封装了哪些共用的逻辑？

(4)、事件的各种使用方法及优缺点。

(5)、与HTML5页面的相互调用。

(6)、UI线程的阻塞与解决方案(Runnable 与 Handler)。

(7)、采用什么姿势调用MobileAPI并解析返回的数据？

(8)、怎样做列表的分页和刷新。

(9)、登录的实现，包括从哪里来，到哪里去的页面跳转机制，记住密码的逻辑设计。

(10)、性能调优，包括Layout调优、Activity中如何使用CONST常量、时间换空间策略、ViewHolder、图集的优化策略、数据缓存和图片缓存，等等。

(11)、全局变量过多怎么办？

(12)、写过UT没？

(13)、是否做过自动打包？Ant、Maven或gradle任意一种都可以。

对于TeamLeader的要求会更高一些，包括如何检查内存泄漏，如何优化内存、多线程、自动打包、框架设计、整个android系统都应该熟悉，才能带好整个团队，保证每个人问题点都能把控，版本管理等诸多方面。

4、无线团队必备的10份文档

一个团队成熟与否的标志是文档。文档太多，就违反了敏捷的原则，但有几个文档是必须提供的：

(1)、新员工入职文档（这份文档包括：部门组织结构，新员工所在的团队和将要担当的角色；个人简介，用于群发给部门其他成员；要加入的公司邮件组，部门内部用于沟通的QQ群或微信群；Android项目的地址，权限申请；Bug管理工具及权限申请；测试环境和仿真环境的地址；产品需求的地址；WIFI设置、VPN申请、手机邮箱配置、打印机安装，等等。）

(2)、加强版新员工入职文档：(这是一份更适合Android团队的新员工入职文档：SVN或GIT的权限申请；Android开发常用软件下载；迭代的节奏；业务名词解释；Android App的项目结构；Android自动打包地址；模板<模范标准>页面。)；代码规范。

(3)、测试机清单（测试机型号、操作系统、使用人。采购测试机可以看友盟统计）

(4)、模块分工表：（把开发人员按照业务线<模块>进行划分）

(5)、页面逻辑流程文档

(6)、MobileAPI接口分布图：(一般用XMind思维导图来描述一款App所用到的MobileAPI接口。好处：定期检查IOS和Android在做同一功能时所使用的MobileAPI是否一致；每次MobileAPI发版上线，相关的测试人员，就可以根据这张图，找到这些MobileAPI接口改动影响了哪些页面和功能，需要进行相应的回归测试。)

(7)、版本管理策略文档：(无论是使用SVN还是GIT，都要制定一套发版流程。Android团队中要有专门的开发人员熟悉并遵守这套流程，包括:

正常迭代的流程；开新分支做技术调研的流程；紧急上线流程。

流程一般有两种，要么是主干开发主干上线，要么是主干开发分支上线，无论是哪一种，都要落实文档，切记口口相传。)

(8)、框架设计文档：（当我们把AndroidLib这个业务无关的类库从App中抽象出来的时候，就该有一份框架设计文档了。）

(9)、发布流程文档：(Android要发布到各大市场，为此，需要修改清单配置文件中的友盟渠道号，才能统计各大市场的下载量。此外发布的apk包要混淆：渠道号是否正确？代码是否混淆？版本号是否正确？是否release包(而不是debug包)？临时决定关闭的功能是否露出来了？是否可以支付、分享、扫描二维码？升级安装是否会引起崩溃？

鉴于以上各点，需要制定发布流程并形成文档，包括：

<1>、产品经理准备发版所需要的描叙文字、图片等材料。

<2>、开发人员进行批量打包工作。

<3>、测试人员要随机抽取一个apk包进行测试，包括功能点测试。

<4>、推广人员发布到各大市场，要有邮件持续跟踪各个渠道的版本更新进度。

<5>、在版本仓库上打Tag,合并分支上的代码到主干。 )

(10)、App启动流程图

（如果要做App性能优化，最好的着手点是App从启动到进入首页的流程。大多数Android App的启动Activity并不是首页HomeActivity,而是一个叫做LaunchActivity的页面，它的UI就是简单的Splash动画，同时它肩负着更多的职责，如：

<1>、注册友盟、推送等等第三方组件。

<2>、加载Splash图，同时下载新的Splash图以便下次开启时使用。

<3>、如果是首次打开，则进入引导页。

<4>、友盟打点，统计激活数。

<5>、如果有消息推送到达，点击消息后想不经过首页而直接进入某个二级页面，其实在代码层面还是要经过LaunchActivity的，由它对推送消息进行分发，以决定该跳转到哪个二级页面。

以上这些逻辑交织在一起，非常复杂，尤其是要区分升级版和全新安装版的时候，为此我们需要用Visio之类的软件绘制一个App启动流程图。在业界，我们将LuanchActivity称为Bootstrapper。LuachActivity把上述这些事情都做完，才会进去到首页HomeActivity。）

}

5、一对一沟通

{

走简便流程，要求：

<1>、最近一个月做了哪些事情，有什么提高？

<2>、自身想要有什么提高？需要我帮助做些什么？

经常反馈的有:

<1>、强烈要求团建。

<2>、有的程序员想转行做产品经理，想得到一些锻炼的机会。

<3>、初级程序员希望分配到一些更高级的Task。他们渴望新知识，而不是天天画UI。

<4>、有些程序员比较好学，希望团队有大牛，能学到东西。

<5>、渴望被表扬。

}

6、每周技术分享

{

技术分享是提高团队技术水平的3个方法之一，另外两个是Code-Review和修复线上Crash。

技术分享关键在于坚持。技术分享并不是天马行空，不为所云的技术畅谈，要根据团队整体技术水平和实际项目需要，弥补团队短板。建议可以罗列Android或IOS必须掌握的若干技术点，然后发给大家给自己打分，每个技术点都是5分制。<完全不知道：0分听说过：1分看过介绍的文章：2分亲手做过demo：3分项目中使用过：4分非常熟悉：5分>，把大家的自我打分收集上来进行汇总，对团队的整体技术水平就一步了然了。对于团队的技术短板，在每周的技术分享上，会安排团队成员进行讲解。

}

7、代码评审

{

常规代码审核会出现一些情况，首先在我们是个互联网公司，App迭代的周期只有两周，所有的开发人员都疲于奔命做需求，哪有时间去审核别人的代码，会出现一些情况：

<1>、能力强且责任心强的开发人员，一天大部分时间在审核别人的代码。

<2>、能力强且责任心差的开发人员，看都不看直接审核通过了。

<3>、技术能力弱的开发人员，要审核别人的代码也是心有余而力不足。

另一个副作用是：因为每次请别人Code-Review都要等，所以开发人员倾向于每天下班前一次性提交所有改动，并没有遵守持续开发、持续提交、持续测试的持续集成思想。

===应变解决方案为:

<1>、对老员工不再进行Code-Review。

<2>、对新员工和实习生、应届生，要为他们每人指定一个Code-Review的老员工，至少3个月之内，对他们的Code-Review还是要严格执行的。

大致的标准为：看编码规范或看编码逻辑。

---->互联公司没有时间去搞太繁琐的流程，可以把Code-Review的策略改为，每周一下午，技术经理从上周提交的代码中找出10处写的有问题的代码片段，然后给大家进行讲解和讨论。在达成共识后，今后就再也不能写类似的代码了。

那么对于有问题的代码，处理方式建议，对于首页、会员中心这种一级页面，不能改要保证稳定性。对于二级或三级页面，局部某个功能可以安排人员去修改。

在进行Code-Review的同时，有一个东西可以顺便搞出来，那就是模板页面，即符合编码规范要求、可以作为编写其他页面的模板页面。对于Android应用类App而言，一个模板页是不够的，至少要提供Activity、Adapter、Entity、Fragment这4个模板页，其中Acitivity要包括对MobileAPI的调用。

有了模板页，所有开发人员的编码就有章可循，单纯搞Code-Review和编码规范都太抽象，一定要有能落地的东西，那就是模板页。

}

8、对Android团队Leader的定位

{

Android团队Leader要负责的工作罗列入小：

<1>、每次迭代把Tesk分配到具体的开发人员。

<2>、组织线上Crash的修复。

<3>、处理线上突发bug。

<4>、排查每日客人投诉的问题。

<5>、解决团队遇到的技术难题。

<6>、组织每周Code-Review。

<7>、组织每周例会。