如何做好技术调研

大家好,我是光源。

近日一直在思考一个问题,到底怎样做才算是完整且优秀得完成一次技术调研。

我曾经以实习生的身份做过糟糕或让老大称赞的技术调研;也以正式员工的身份独自负责过技术调研工作(意味着不用向谁汇报,直接进项目);也以导师身份分配技术调研工作给新人,看着几个新人经历着我之前的遭遇,他中有完成得漂漂亮亮的,也有完成得不够好的;最后也旁观过优秀的同事做过技术调研。

教技术的书籍很多,但是教做事的书籍很少——即使有也不会教那么细。我曾因这类工作而彷徨、受挫,现在又看着新人彷徨、受挫,于是就有了想法尝试总结一个范式出来。

因此下文会从个人的一些出发做一些总结和思考,与各位读者分享。当然作为追寻最佳实践的我而言,更欢迎能互相讨论以完善我的观点。因能力有限,如果有不妥或者补充的地方,还请联系我(微信公众号:guangyuan_coder),十分期待与你的交流。

一、了解需求

除去自己发起的技术调研,其他技术调研都需要先了解需求。估计很多人看到这个就会心想,切,这个谁都知道啊。

是的,“了解需求”这是个人尽皆知且每个人在技术调研前都会去做的一件事。但不夸张地说,在这个阶段栽跟头的人最多。

很多人,特别是新人,在这个阶段出问题的普遍原因大概有以下几点:

  • 作为新人畏畏缩缩,担心一开始问太多会显得自己很无知,担心对方轻视自己
  • 听到几个关键字就以为了解需求,没有在意对方说的一些细节
  • 对需求有疑惑的情况下硬着头皮做,缺乏沟通意识
  • 没有分阶段跟需求方沟通,可能在快完成了发现需求理解错误要推倒重做

诸如此类。

解决方案也很简单,咱们把问题一一解决。

首先是接到需求时,认真听对方讲,对对方所讲内容有疑惑的是可以在对方讲完后提问的。千万不要听的时候是懂非懂,想着待会私底下自己查(当然提问也要有技巧,这个自己琢磨去)。

然后假如不了解的东西太多(例如一上来就给新人分配一个陌生业务模块的任务,的确会一脸懵逼),又不想围着需求方各种打扰,完全可以请教下熟悉相应模块的同事嘛。

最后,假如是复杂的需求,可以在做的过程中,分步跟需求方确认,这个下文会展开。

这里举个例子:

一天,小明正热火朝天地写着代码,突然肩膀被人一拍,回头一看老大正站在背后。

小明,这有个调研工作你去做一下?

没问题,具体是做什么呢?

是这样,我们需要做一个 A 功能以支撑 B 模块,这块功能 iOS 端已经完成,可以与他们讨论下。

好的,没问题。

于是小明屁颠屁颠开始调研 A 功能是怎么实现,耗费了几天时间后,老大过来一看,诶,你这实现不是我想要的呀。

原来虽然小明选取的技术方案是业界知名的 A 功能实现方案,但却没法用到 B 模块上。而且需求隐含的意思是,既然 iOS 端已经实现了,需求的具体情况可以去询问 iOS 端对应开发。

二、进行调研

在做好需求了解的前提下,调研本身会显得轻松点。

需要注意的是,进行调研时要合理安排时间,调研过程往往伴随着对新知的探索,很容易“沉迷于学习”。别忘了这是一项工作。(当然不只是技术调研在日常工作中也一样,要学会合理安排时间,注意时间成本)

个人有个小技巧,按照以下步骤来做往往效果不错:

  1. 尽量多得收集各种方案和资料
  2. 迅速粗略得过一遍,大体上总结出几种可能合适的方案
  3. 针对几种方案,一边分别调研每种方案,一边做笔记
  4. 最后拿着笔记做最后的横向对比
  5. 得出结论,同时因为做了笔记,反馈的素材也有了

以上是关于“如何做”的。需要说明的是这只是我的个人习惯,你有自己的做事风格更好,没必要强行一致。

还有一点需要注意的是,千万不要埋头苦干

“沟通”应该是贯穿始终的一件事,在上文也提到了,对需求的理解偏差可能会导致整个调研工作推倒重来。

那么该如何沟通,以及沟通些什么呢?

第一个问题,如何沟通。我的方案是,阶段性得去跟需求方或者跟有经验的同事讨论。比如一个技术调研有四个阶段,那每完成一个小阶段,就可以尝试去沟通一次(必须强调下,规则是死的人是活的。假如对方很忙的情况下,你偏要强行打扰对方去沟通;或者一个很小的技术调研你也按阶段多次去沟通,就尴尬了)。

第二个问题,沟通的内容,我认为主要有以下几点:

  • 对需求的细节的分别确认
  • 将自己的工作进度汇报给对方(这点很重要,一方面是让对方知道你在做什么及完成到哪个阶段,另一方面是假如你路走偏了,对方能及时知道并纠正)
  • 将自己当前的工作成果告知对方

做到以上几点,应该就差不多了。下面说说第三阶段,结果验收。

三、反馈

做完技术调研后,一定要有成果。

可以是调研之后发现“某个方案是最佳的”,也可以调研之后发现“尚无解决方案”,还可以调研后对需求本身提出质疑,但一定不能做着做着无声无息得做没了(不是所有技术调研都有需求方催促或跟进)。

反馈的展现形式根据需求来,有几种常见的展现形式:

  • 假如是比较大的技术调研可以做一些分享的可以用 PPT 的形式展现出来。比如有同事调研 “兼容 Android 6.0 权限管理”,用一个 PPT 将技术方案的选择、6.0 权限管理的原理、最终方案的选取等分享出来就特别好
  • 假如是简单的技术调研可以以文档的形式展现,推荐用 markdown 来写,github/gitlab 可以直接展示,很方便
  • 再简单点则是以邮件或口头的形式反馈

个人比较推荐以文档的形式,大部分调研工作都很适合。

反馈的内容有几点是需要考虑写进去的:

  • 简要说明下调研需求
  • 介绍下跟需求相关的前置知识
  • 目前有哪些方案,具体分析下各个方案的优缺点及适合的场景
  • 技术调研的结果是怎样,不可行的话是因为什么,可行的话说说最终决定使用何种方案(自己无法决定的话可以弄个分享讨论会),并说说该方案跟其他方案比有何优势
  • 假如是新库的引进,需要简要介绍下该库的使用及内部原理
  • 调研过程中碰到了哪些问题,如何解决
  • 另外,假如时间允许,可以考虑把反馈当成分享来做,系统介绍下相关的知识——这个比较适合 PPT 的形式

大概是这些,总而言之,把一次技术调研当成一次绝佳的学习机会来做,那反馈的内容就不会显得空洞。

反馈的时机的话,在保证质量的前提下,尽量主动、提前向需求方或组内其他同事提出。一方面是你的反馈对别人而言也是一个学习机会,另一方面主动推送一件事也是一个优秀的表现。

写在最后

以上是一点个人浅见,必须要说明的一点是,本人能力有限见识浅薄,上文的一些观点不一定正确。各位看官切不可太过信赖,还是要有自己的思考为妙。

另外,写到最后,发现跟“技术调研”中的“技术”倒关联不大了,哈哈。我也就不纠结这个了。

最后,我写博客的目的就是希望将个人的观点、观念摆出来让读者评价或吐槽,因此假如觉得有不妥或者可优化的地方,还请不吝赐教。

大幅提高Android开发效率之Android项目模板化(下)

大家好,我是光源。

《大幅提高Android开发效率之Android项目模板化(上)》中我们了解了如何用 Android Studio Template 大幅减少写业务代码前的工作量,同时也稍微提了下用 Live Template 减少写业务代码过程中的“样板式代码”。

可能有朋友会问,我们这么紧张这点效率真的必要么?

这个问题我先不回答,我们先来看看一个场景:写一个单例。

单例模式应该是开发过程中最常见的设计模式之一了。写单例前总得先纠结一下吧,单例模式这么多种实现方式该用哪种好呢?选定了实现方式后,老老实实写一堆代码,然后你会突然发现除了类名不一样外,其他代码都是一模一样,这时你心里会不会隐隐约约觉得这是可以优化的?

我不知道你完成单例模式的实现需要多长时间,但我告诉你,我们可以用一秒来搞定,你会不会觉得老老实实写代码的自己很傻?

这就是 Live Template 的第一个作用,提高编码效率

再接着上面的话题,又有人吐槽另一个细节了,一般有点年头的程序员对于单例模式都有自己的一个默认实现方式,不需要花时间去纠结吧?

这话不假,像我就默认使用内部静态类的方式实现单例。但是你有没有想过,项目开发是一个团队协作的过程,就算个人不纠结,但多人开发情况下,要么每个人用自己的一套实现方式造成代码风格不统一,要么同事还是得事先通气、询问用哪种好。(编码规范文档也不会事无巨细把这类问题也事先规定好的)

再思考一下,很多有多方案且不属于编码规范的场景,我们又要怎么去统一呢?

答案还是用 Live Template。例如,Android 开发中,我们应该使 Message.obtain() 来获取一个 Message 实例,而不是去 new 一个,那么我们完全可以定一个 getMsg 的 Live Template,大家只要是用 getMsg 的,可以严格保证统一性——这就是 Live Template 的另一个作用了,保持项目中非编码性质的代码风格统一。(编码性质的代码风格统一果断用编码规范文档来实现了)

大家看到这里一定已经对 Live Template 有了一定的重视与好奇了吧,别着急,下面上正餐。

大幅提高Android开发效率之Android项目模板化(上)

一、两个场景的思考

大家好,我是光源。

首先思考一个最普通的场景:创建一个 Activity。你需要做的是:

1、 创建 Activity 类文件;
2、 创建对应的 Layout 布局文件;
3、 在 AndroidManifest.xml 注册;

当然现在 MVP 模式(mvp 模式有多种实现方式,这里选择一种普遍的)基本成为标配,所以你还需要接着:

4、 对应的 View interface;
5、 对应的 Presenter interface
6、对应的 View 实现;
7、对应的 Presenter 实现;
8、对应的 Model 类;

当你气喘吁吁地做好以上工作后,你又想起这个页面你需要用 RecyclerView 实现,所以你继续:
9、在布局中加入 RecyclerView;
10、设置 LayoutManager
11、创建 RecyclerView Adapter
······
终于,你可以开始写具体的业务代码了,而此刻距刚开始已经过去了 N 首歌的时间。

开始写代码后,我们再思考一下这样的场景:显示一个 Dialog
这时一般有两种情况,一种是你需要从零开始构造一个对话框、设置样式、编写逻辑等等,这与上面一个场景一样,一大堆的样板式代码;另一种情况是部门内已经对 Dialog 的设置样式、构造等代码做了封装,比较常见的方式会像这样:

1
DialogUtil.show(...);

那么你直接调用就行。但这同样存在“无脑写代码”的问题,以及对于部门内的新人来说,可能不一定会遵循这种使用封装好的代码的约定。

看到这里,假如你有一点点感同身受的话,那么恭喜你,本文将教你如何解决这些问题。如果没有共鸣也没关系,看完本文,你也会有一定的收获——实际上对于所有还不知道 Android 模板相关内容的开发者而言,看完本文都能大幅提升项目开发效率,这也是本文标题的由来。

写给Android开发者的混淆使用手册

写在前面

大家好,我是光源。

本文首发于我的个人公众账号,同时会在个人博客上同步。假如有任何建议还请移步博客点评,同时如果博客本身有修改或勘误,也会在博客更新。

综述

毫无疑问,混淆是打包过程中最重要的流程之一,在没有特殊原因的情况下,所有 app 都应该开启混淆。

首先,这里说的的混淆其实是包括了代码压缩、代码混淆以及资源压缩等的优化过程。依靠 ProGuard,混淆流程将主项目以及依赖库中未被使用的类、类成员、方法、属性移除,这有助于规避64K方法数的瓶颈;同时,将类、类成员、方法重命名为无意义的简短名称,增加了逆向工程的难度。而依靠 Gradle 的 Android 插件,我们将移除未被使用的资源,可以有效减小 apk 安装包大小。

本文由两部分构成,第一部分给出混淆的最佳实践,力求让零基础的新手都可以直接使用混淆;第二部分会介绍一下混淆的整体、自定义混淆规则的语法与实践、自定义资源保持的规则等。

一、Android混淆最佳实践

1. 混淆配置

一般情况下,app module 的 build.gradle 文件默认会有如下结构:

1
2
3
4
5
6
7
8
9

android {
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}

因为开启混淆会使编译时间变长,所以debug模式下不应该开启。我们需要做的是:

  1. releaseminifyEnabled的值改为true,打开混淆;
  2. 加上shrinkResources true,打开资源压缩。

修改后文件内容如下:

1
2
3
4
5
6
7
8
9
android {
buildTypes {
release {
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}

2. 自定义混淆规则

app module 下默认生成了项目的自定义混淆规则文件 proguard-rules.pro,多方调研后,一份适用于大部分项目的混淆规则最佳实践如下:

[转]QUIC和TCP

前言

这几天在研究部门内部的自定义协议,因此去了解Google的QUIC协议的特性,下面这篇文章将QUIC协议和TCP协议做了比较,个人比较喜欢作者的阐述,特地转到博客中来。

原文作者:henrystark henrystark@126.com
原文地址:http://blog.chinaunix.net/uid-28387257-id-4335291.html

正文

0.写作目的

QUIC由Google提出,基于UDP,用于加快网络速率。常用来和基于TCP的SPDY比较。Google在传输层、应用层或其他方面做出的提升网络质量的贡献令人佩服。本篇blog将论述QUIC的起源、优缺点,以及TCP存在的问题。

1.引言

Why QUIC is necessary? 每个接触QUIC的programmer总会这样问。答案也很简单:SPDY、TCP不够好!不过这样说太肤浅了,下面我来分析本质原因【引 1】。基于一条TCP连接的SPDY复用连接会面临这样的情况:当有丢包发生时,所有连接都将阻塞,这是由TCP的拥塞控制特性决定的【引 2 3】。丢包必须恢复,而恢复过程中,或早或晚,滑动窗口总有停等的时刻,耗费一个RTT。在广域网上,一个RTT相当于50-100ms。相比较而言,当x条并行HTTP连接中,有一条丢包,只会阻塞一条。

QUIC是和HTTP同一层的应用层协议,其核心是将丢包控制工作转移到应用层【注 1】。由于QUIC基于UDP,可以不理会丢包,快速投递,再用丢包恢复方法保证可靠性。除此之外,基于一条TCP连接的SPDY和多条并行HTTP连接相比,没有优势可言。多条连接中,每个连接都有一个拥塞窗口,不受彼此丢包影响。Google希望通过QUIC更好地处理多条连接下的拥塞状况。

2.TCP的症结

以上所述其实反映了TCP基于窗口的拥塞控制策略的问题。TCP的核心在于“丢包必须恢复”,正是这种丢包恢复导致传输速率降低。而除此之外,TCP拥塞控制也存在粒度不精细等问题。举例而言,往年有一道很好的面试题:早期网络中,为什么蚂蚁等下载器比网页下载快?答案是下载器使用多线程,多连接下载,而网页下载往往使用单连接。也许回答到这种程度,大部分人已经满意了。但往下问,还有更深刻的内涵:为什么多连接比单连接快?ISP给用户分配的带宽不是固定吗?

Fork me on GitHub