专栏首页腾讯云TVPWork at home, Work as a distributed team | TVP思享
原创

Work at home, Work as a distributed team | TVP思享

Tetrate.io是一家北美的企业级Service Mesh服务商,提供基于Istio, Envoy, SkyWalking的企业级Service Mesh产品:Tetrate Service Bridge。Tetrate.io创立之初就是以分布式团队、在家办公为工作模式,所有成员都不在统一办公地点工作。目前,公司团队分布于北美,欧洲,中国,东南亚等多个国家。本文是对TVP吴晟老师的直播演讲整理,分享在分布式工作模式下,如何保证高效沟通。「TVP思享」专栏,凝结大咖思考,汇聚专家分享,收获全新思想,欢迎长期关注。

一、 分布式工作的背景和难点

1. Tetrate成立背景

我们公司是在前年成立,下图所列是最早期的所有的技术团队成员,涵盖了全球绝大部分的时区,包括日本、中国、印度等。

随着团队人数越来越多,其中有一些同事,并不总是固定在一个时区。例如有的同事有段时间在北美,其他的时间在日本,包括我自己每年也会有大量的出差,会频繁切换自己的时区。

这样可以带来一个好处,除了大家能够保持一致的协作模式外,也可以有更多的私人时间,这是我们公司的经历背景。

其实现在有非常多有名的上市公司,都在以远程协作的方式来工作,基本上成了一个西方新进的技术公司一种标准模式。因为它可以把更多地方的人联合起来,而且这样的公司会有一个特点,它们更多使用了开源作为背景。

如果大家熟悉开源或者了解过开源社区的状态的话,会发现开源协作即使是在同一个时区,因为大家还有其他的工作,能抽出的时间不一样,它也是一个极度分散的时间。有人是早上有时间,有人是晚上,或者有人最近在其他的国家,这是全球化协作的难点。

2. 分布式工作的挑战

(1)沟通难度

不管是在国内还是在不同的时区,都有可能面临到一个最大的问题:无法进行面对面的沟通。没有办法到别人的桌子前拍拍人家,然后跟他说这个问题,你帮我解答一下。或者我有这个事情想跟你来讨论,然后马上会进行一个快速的高频次的沟通。

(2)作息时间

在我们公司这是一个必然,会出现有人在休假,有人在工作,有人在不同的时间点有假期。比如美国的圣诞节和中国的春节,显然它不在一个时间点上。

另外每个人的工作时间、工作习惯是不一样的。有很多技术人员是夜猫子,喜欢晚上工作,并不喜欢一大早起床,但有些人会有非常严格的作息时间,可能会起得很早,比如说五六点起床,他就去锻炼身体,跑步,然后回来再工作。

(3)进度追踪

这可能是所有的分布式管理的领导都非常想解决的问题,他觉得没有办法看到员工,那也不知道员工在干什么,那工作的进度怎么保障?以及谁对工作更用心,谁的产出更好。这是很多领导想知道的一个事情。

二、如何在线协作

1. 利用SaaS服务

对于在线协作,有大量的在线的文档、会议的工具来帮助大家去解决远程沟通的问题。

但即使有如此多的工具,依然没有解决大家的心理问题,在线协作还是让人感觉到非常别扭。首先就是让人感觉到它并不顺畅。好像在远程的过程中,会让人觉得效率很低。

但有这么多的西方的公司,它们并不是由于疫情而开启在线协作,而是在正常的状态下进行,保持日常的分布式的工作的模式,公司的整体效益并没有受到损失。

所以到底什么东西的缺失,让我们觉得在线协作模式很别扭,效率不高呢?在绝大多数公司远程协作的过程中,缺少的东西叫时间协同。

因为不管是任何人,他如果在家办公,最希望的肯定是想兼顾家里的生活。不管是家里的老人、孩子,还是自己单身的生活状态。想给自己做一顿饭,想现在去看一会电影,或者今天有点生病,他想多睡一会......

不管怎样,首先就是需要透明的时间管理,透明的时间管理和现在的996(所谓的加班文化)之间是有巨大的隔阂的。现在国内很多IT公司领导可能更多的认为,工作的时间越长,得到的收获就越高。

但如果大家关注一个特定的技术领域,或者关注一个非常明确的开源的方向,会发现绝大部分的技术社区或开源项目都是由国外的公司在引领,而那些人其实并没有去付诸中国所谓的高效的996的这种工作模式。首先要做到的是把工作时间安排透明化。比如我今天不想上班,想要陪伴家人孩子,那么可以不去上班,但要让所有人都知道这一情况。

在另外的时间我可能会告诉其他团队成员,这周末我准备上班,因为我这周只上了4天班。我会把自己的Calendar进行调整,这周改成休周二或周日,而周六是工作日,大家有时间可以来找我。如果有事你想建立一个会议的话,也可以以这种透明的方式,包括团队成员要出差,哪些时间是无法应答的,也需要第一时间告诉大家。

下图是我们公司去年10月份的截图,在下图中,你会看到不同的人,用不同的颜色,标识自己不同的状态。那么其他人就会知道在这些时间内是不能联系他的,因为他在休假联系了也没有价值。

2. 合理进行远程会议

在远程会议的过程中,我们公司内部会有一些原则,在这里给大家做一些分享:

(1)避免全员会议

前段时间刚开始远程工作的时候,很多人发帖子和朋友圈抱怨公司开晨会。每天早上开晨会,让大家早早起来,这本来就是效率很低的事情,至少浪费了所有人一个小时的时间。

其实也并没有聊任何有价值的问题,其实只有极少数公司才会有早晨的例会,或者说能坚持下来做有意义的例会的公司是不多的。既然在面对面的时候,都无法发挥效率,那么所谓的在线会议,包括有的公司上班、下班的打卡制度,实际上严重的违背了远程办公的高效性、让每个人变得更灵活这样的原则。

(2)会议提前48小时预约,紧急会议仅限于必要时

在远程会议里面大家都会觉得开一个远程会议的成本很低,因为随时可以联系其他人开会,而这样的会议一旦被传承了,形成一种文化,那么就会发现每一个人都在不停的开会,而根本就没有时间静下来去做自己该做的事情。

而又因为是远程,容易造成相互间的不信任。不能看见,所以被邀请会议的人不能像在公司当面一样,拒绝跟自己无关的会议。更多的时候,可能会被没有远程工作经验的人理解成:他现在肯定没有在干活,所以他不想跟我开会。

所以会议的预约制决定了会议能够保证正常进行,受邀人一定能够按时的参加,除了个别的紧急的会议。当然这样的会议更多时候会遵守第1条,只会邀请必要人员,不会全员,不会浪费绝大多数人时间。

(3)在会议前发送背景介绍和议题文档

这反映了大家文档工作的能力。我知道在中国很多的工程师文化里,对文档是非常排斥的,特别不愿意写文章。实际上全球的工程师们都是一样的,都愿意去实现它,并不愿意去写文档。

而多数远程办公的公司文化都有开源的经历,开源需要文档。全球在招收远程工作的职位时,一般同时会写着需要这个人有开源或者远程的工作经验。因为在这样的过程中,你才能懂得文档的重要性,才能懂得用文字表达,会比语言、开会更高效更准确。

(4)会议的时间不能超过30分钟

绝大部分的议题能在30分钟内结束。如果是一个长篇大论的争论性质的讨论,那这个会议其实可以在前期通过邮件、文档的在线审议来决定。而不需要占用所有的在线评议人、参与人的时间,聚在这进行无休止的争论和讨论。会议本身最大的目的是做出决议,避免有漏掉的一些情况以及同步信息。

(5)可能关系人采用邮件通知讨论结论

有些会议有人会缺席或不到场,那在这过程中,只需要把结论形成文档。就好像我们平时在公司有人发会议纪要一样,远程工作会议纪要,对于那些没有与会的人是非常重要的。他们需要知道结论,但不用像会议纪要那样去描述所谓的讨论的细节。因为对于其他最弱相关的人来说,他要的更多只是一个结论。

3. 形成Gossip文化增强团队凝聚力

Gossip文化是远程公司一个非常大的特点,几乎所有的公司都会有,包括在Google内部,也会有Gossip的文化。一般一周只有一次会。当然可能像我们公司是不同时区的话,可能会有两次,我们是会有北京时间的早晨和北京时间的晚上,因为这样两个时间可以协同全球的不同时区,大家选择自己合适的时间来参加会议。

Gossip的内容更多的是闲聊,是除了技术问题之外的问题,比如说这两周大家会问我,中国的疫情情况,中国政府到底是怎么样去应对的?你了解到什么信息?需不需要我们帮助你什么?

或者有一个同事出去玩了,他会分享玩了什么东西,觉得哪个地方不错,大家有机会可以去玩。当然也会有和公司相关的,比如公司的合同进展状况,客户关系的进展。最大的差别是,它都是非常粗线条的东西,并不要去讨论细节、方案、目标,更多的是分享给大家,公司其他的团队成员在做什么?把自己的信息共享给大家,因为这种全面的公开信息,可以让大家更容易为团队寻求支持。

三、 管理模式和沟通方式

在远程工作的时候,技术手段反而是最容易被解决的。不管是所谓的Git,还是在线的会议系统、视频聊天系统、文档协作自动化的流程,这些都是工程师非常擅长的东西,无非是敲代码和软件应用。但是管理是分布式团队最大的挑战,分布式管理需要要靠很多的细节去支撑。

1. 问题追踪

对于问题追踪,我相信很多公司都有看板这样的东西,并不稀奇。但细节可能是远程工作和现场工作最大的一个区别。因为在现场的话,很多时候领导看到看板没有动,他可以站起来去询问这个事情做得怎么样?

那么在远程工作的时候,他不可能不停找人问,成本是非常高的,而且对于领导或team leader来说,它会浪费了大量的时间。所以在远程工作的时候,就要求问题要更细致,最好是分阶段的,而所有的问题都应该被管理出来。

比如说它是一个简单的issue,可能要做三四步。那么这三四步很有可能是3~4个issue不停的在操作,这样的话你的工作进度对于领导来说是非常容易被发现的。

并且当你去报告被阻塞的时候,是可以很明确的知道哪一个非常细的任务阻塞了,其他人可以快速的去解决掉这个问题,而不会是说一个大任务阻塞了,但你实际上这事情根本就说不清。

另外就是在整个过程中间,它需要有Owner和Reviewer,这在国内是非常少见的,我们需要结对编程。所谓的结对编程,并不是说一个人编程,真的有另外一个人在旁边坐着看。而是两个人工作在相同的领域,他们工作在相同的技术方向上,能够理解对方在干什么,对于细节都能理解。

那这两个人可以交叉互审,同时也变相达到了交叉考核进度。因为他自己在做这个方向,能够非常准确的评估出对方的工作量,相互之间可以形成一个很好的团队。而上面只需要一个相对比较大的人物去考核、去负责就可以。所以问题的细化和责任到人,这是在管理时和平时在做任务追踪时,非常大的区别。一个是非常粗犷的管理,一个是大力度细化的管理。

2. 状态同步

我们公司会用文字的形式代替在国内的每一天的视频例会,描述的内容其实对员工来说是一种鞭策。你需要写出内容,而你昨天的内容就在这上面放着,当你天天写一样的内容,或者进展非常慢,这是非常容易被看见,并不在乎于它是文字形式还是口述。

而对于视频会议,因为十几个人不停在说,对于听的人根本无从判断昨天这个人到底说了什么?所以会议除了在视频上看见人以外,其他并没有什么太大的好处。而且因为每个人的工作结构不一样,有人可能到晚上这个活才能干完。那么你下午去问他的进展的时候,其实他并没有办法给你回复,每次都跟你说的是这个事情正在做,这也变成了没有意义的。

同时Standup和刚才前面的issue管理是要呼应的,因为前面的issue是非常的细的,所以在Slack standup的channel里,大家会发现细节的进展都可以被反馈出来。最大的核心就是Block,因为任务被拆细后,可以更离散地活动,那么肯定会在特定的时候,受到一些阻碍。

比如说任务协调不合理,或者有一些设计出现了问题,或者有一些技术障碍需要被排除,以及有一些不可预知的错误,需要大量的时间,这都有可能。

Block是你向团队申请援助的最大的帮助,因为每个团队都有不同职级不同能力的技术人员。不管是开源,还是公司内部都一样。那么你的block被报告出来,有助于上面更好地对你进行帮助,而你能够把Block说清楚,更多地证明了你对这件事情的了解是非常透彻的,你能分析出它的Block在哪个地方。

很多人都会告诉leader,我快做完了。这是国内最容易上报的一个事情。但实际上可能三天都做不完。这就是我们的工程师们没有把自己的任务分析清楚,可能需要两三周才能完成的功能,没有做到任何的拆解。

3. 以开源的模式公开工作内容

公开工作内容,在技术团队之间,这和很多大型公司现在推广的所谓的inner source,就是对内开源的公开信息,其实是有很大的关系的。

要防止员工不干活,最好的方法就是把他工作的内容公开出来。提交了多少代码,做了多少次提交,向哪些库提交过代码,向哪些库提交过issue的讨论,每次工作的讨论重心有多少?有多少review的细节......

在这样的过程中,就能看到其他人的工作状态,这种公开透明的方式,是对管理最大的支撑。没有这些,管理就无从说起。因为在管理都讲一个事情,就是对事不对人。一定不能按你个人的某个感觉,比如我感觉这个人好像没有好好干活,这是非常不科学的事情。但如果他的提交量、参与度显著达不到平均水平,那我就知道在这过程中,他可能是真的没有好好的干活。

4. 邮件沟通准则

(1) 每封邮件只包含一个主题,以免遗漏

邮件在发送的时候,一定要避免长篇大论,包含几十个主题,寻求不同的人说明不同的事情,这样的邮件很容易中间被遗漏。因为有人读了前三个,觉得跟自己没关系,可能这篇邮件就跳了。

(2) 使用[topic]明确邮件内容领域。

就是你在公司内部哪个项目或哪个技术方向,一定要通过邮件的名称来明确自己是在哪个领域,方便大家快速检索。

(3)必须使用回复全部

所有的邮件系统除了涉及公司机密外,一定要尽可能的使用回复全部,避免有人漏掉了上下文的信息,而不是使用直接回复给发件人。因为大家也需要同步你在讨论过程中间的一些观点。

(4) 领导接受异步回复

如周末或非工作时间发出的邮件,需要等到工作时间才会回复,这是对领导的一个要求。

(5) 只有紧急问题才使用即时通讯软件(Slack)

一定是已经紧急到必须他出面来解决的时候,才会使用即时软件。在国外的公司可能更多的是Slack,那么国内可能会是微信。

但想告诉大家的是,在国外即使是Slack,所有的工程师都可以选择在休息时间并不进行回复的。所以这也回到前面,需要结对编程的目的,每一个技术细节都是有另外一个人在备档的,两个人同时不在的情况是很少发生的。

(6)在休假期间设置自动回复

当你不能在规定的时间内,大家预期的时间内回复,比如你有个人的事务要处理,或者你有一些特殊的情况,比如在休假或者出差。不管是因公还是因私,或者你在进行时区的切换,你都需要用自动回复的方式来告诉大家,以免大家产生误会,就觉得好像我问你的事情没有得到一个合理的回复。

5. 即时通讯软件(Slack)准则

其实在国外,Slack会比类似于微信这样的工具更加流行。

(1) 使用Thread进行上下文讨论

Slack会有典型的上下文,可以针对一个点反复的进行讨论,而不像微信会一下就刷没了,对这次讨论的上下文没有非常明确的联系。这就是为什么微信更适合于点对点的聊天,绝大多数的国内通讯工具更适合于点对点,或者说闲聊,并不适合作为工程工具来进行使用。

(2)不使用 @here/@channel

就相当于在微信群或者QQ群里@所有人一样,如果所有人都干这个事情,那最后的结果就是没有人关心谁@我。

(3) 对于留言信息,尽量提供明确的上下文,甚至示例和步骤(原则上应使用email代替)

即使是Slack也和邮件需要遵守同样的原则,需要提供明确的上下文,不能说就写两句话,别人看完后都没明白你在说什么。

你需要大家在没有你详细解释的情况下,读这段文字就知道你要说什么。那这需要大家对跟自己有衔接的工作细节,有一定的了解,你要花时间去了解别人。

(4) 即使使用slack也要接受异步回复模式

同样Slack和邮件一样,要能够支持异步回复,公司也会有明确的指导告诉大家说,如果你这段时间不想进行即时聊天,那请打开勿扰,原则上是允许员工每天抽出一到两个小时。

如果你是这样性格的人,可以抽出一个到两个小时的时间,集中去进行Slack上的问题和邮件的回复,而在其他的时间内保持你自己的专注力。

这个是因人而异的,有人可以做到非常快的上下文切换,比如说在3~4个讨论中间,他的脑子可以换得非常的快。而另外一些人是需要非常大量的准备时间,但可以非常深入的去讨论某个问题,或者做某一个技术上的coding这样的动作。所以大家可以根据自己的情况来决定。同样的,管理者要能够接受这样的一种讨论方式。

6. 开发准则

(1)面向设计文档

这可能又是工程师们最不喜欢的。

(2)面向API和协议

尽可能让API和协议文档化。对于网络接口和需要调用的类,一旦定义出来,不允许被随便改动。

(3)在原型状态即提交pull request,并标识WIP

因为我们有结对编程的一个策略,所以pull request是要尽早的提出来,这样别人才能看到你的pull request的内容,并在早期指出一些你可能犯的原则性的错误。因为所有的工程师都有状态不好的时候,或者对某些技术领域不熟悉,从而犯一些非常低级的错误。

如果pull request真的会break某些协议或者设计,那你应该在pull request刚刚发起的时候,就在第一时间通知所有可能会受到影响的团队和个人,或者让他们尽早的看到pull request以及针对pull request预先做针对性的一个调整。

在所有以开源项目为背景的公司中有一个非常重要的文化:所有的功能在提交代码的时候,都需要通过全自动的端到端测试。会有大量的测试,而这些测试实际上是由工程师自己来完成。比如你提供rest接口,那么你在做的时候,就应该有相应的测试程序去调用rest接口,并测试rest接口是不是能够真实的完成数据的写入、更新,以及相应的一些行为特点。才能保证系统在每一次交付的时候,不用频繁去沟通,为什么系统运行不了这样最常见的问题。

四、分布式工作的核心要点

1. 异步工作核心

异步工作的核心原理,并不是让团队连得更紧,而是为了让个体工作效率的最大化。在这过程中,发挥个人的主观能动性才是工作的核心。现在绝大部分的中国公司都是因为疫情被迫进行异步工作,他们希望把在线下的那一套东西移到线上的,而实际上反而成为了降低工作效率的一种方式。

因为传统的管理是基于人没有主动性,那企业把员工拴在公司,完成工作。而不是依靠额外的考核制度、追踪能力,去反向证明你是不是有足够的工作效率和工作积极性,以及自我约束的一个能力。

2. 团队工作原则

如下图所示,右侧的几个原则,是我们公司指导文件的一角:

如果你正在做的工作,不是一个非常敏感或者优先级很高的工作,而别人做的东西正在被卡住了,做不下去了。那你现在最应该做的事情,就是去帮人家解决Block的问题,而不是继续做你的工作。

如果你自己现在正在做一个非常高效的积极的工作,你脱不开身,那你应该去找被阻碍的那个人解一下,到底是什么东西阻碍到他了,有没有办法能够绕过去?实在绕不过去了,再去考虑是他的优先级高,还是你的优先级高。

如果即使在这之后,你依然发现你的工作还是优先级更高,那这时就出现了结对编程时的最后的解决方案,你去找跟你结对编程的那个人,因为他和你的技术领域是类似的,很有可能帮助被Block的人快速或暂时过滤掉阻碍的问题。所以这是一个非常有顺序的流程。大家需要了解的是,在这个流程里面可能会帮你自己把事情做得更顺畅一些。

3. 远程办公对公司的影响

远程办公对公司的影响其实也是远程办公的要求。

(1) 需要具备远程工作经验的员工

现在绝大多数人被迫远程办公,实际上他们中的大多数并不知道如何正确远程办公。

(2)对员工个人素质、自驱能力、时间规划能力,专注力要求更高

在办公室,因为领导就住在你背后,所以你不可能瞌睡。而在家里手机就摆在旁边,你可以去随时去打游戏,或者看电影。

那么你怎么保证每天的工作效率以及每天工作的输出,这对个人是非常高的一个要求。

(3)需要远程办公管理经验的管理者

对于管理者也是如此,怎样去协调不同工作习惯的员工,怎样保证他们的工作效率,怎样去协助他们,做好协调,这是非常重要的。

(4) 办公成本降低

因为大家都在家里,用自己的网络、自己的屋子,那么实际上对于公司来说,降低了非常多的成本。以及每天加班的打车费、餐补,所有的这些东西,公司都省掉了。可能唯一成本的就是公司的几台物理服务器变成了云服务器,以前的架设的一些服务,变成了购买云厂商的或者第三方的SaaS服务。

(5) 差旅

比如像我们这样的公司,每年会有一次到两次全球飞行的成本,需要去连接更多这样的团队,去提供一些短期的面对面沟通。

最后分享给大家,不要认为所有的工作只要是远程就是最高效的。即使对一个非常有经验的远程工作的团队来说,依然需要时不时的去面对面沟通。

这既是一个人性的问题,成员之间需要社交活动。另外当面的讨论,对于涉及这种不需要实践,更多的是需要经验以及规划能力上的问题时,面对面会比远程工作来得更好。

五、Q&A

Q:在开发过程中,如果缺少专业的测试工程师,需要自己来承担不大不小的bug的问题,这个事情怎么处理?

A:像我们这样的公司都没有测试工程师这样的一个职务,也没有测试组这么样一个团队。

实际上在这样一个过程中间,工程师要向自己的代码负责。为什么我刚才说端到端的测试会非常重要,这个是保证你在交付的过程中间不会出现大大小小的bug。

Q:未来3~5年,远程办公会不会成为一个主流形式?

A: 从我的理解来说,短时间内应该不会,至少在中国不会。因为中国的大多数管理者还没有准备好适应这样的制度和文化。可能相对于技术人员、技术平台来说,管理能力是最大的障碍。

讲师简介

吴晟,腾讯云最具价值专家(TVP),Tetrate.io Founding engineer。开源技术和开源社区爱好者,Apache和CNCF基金会多个开源项目核心团队成员。Apache SkyWalking创始人,VP和PMC成员;Apache孵化器PMC成员;Apache ShardingSphere(incubating) 联合创始人,PMC成员;Apache Zipkin(incubating) 贡献者和孵化器导师。CNCF KubeCon + CloudNativeCon 2019 Program Committee 成员;CNCF OpenTracing标准化委员会成员。关注和推进云计算、服务化、云原生和服务网格技术的技术发展。并积极为中国开源项目提供帮助。

关注云加社区公众号,回复“TVP直播课”,即可获取老师演讲PPT~

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 开源社联合创始人刘天栋:开源​社区重于代码,应避免“KPI”项目

    导语 | 正处于井喷前期的国内开源项目,能从全球最大的开源基金会 Apache 学到什么?个人开发者应该如何参与到开源中来?腾讯云最具价值专家(TVP)刘天栋,...

    TVP官方团队
  • 腾讯云专家工程师廖龙:CDN边缘智能助力5G

    10月19日,云+社区开发者大会(北京站)圆满落幕。本次开发者大会的主题为“5G探索:核心技术与挑战”,邀请了腾讯内部及业内行业大咖就5G场景下应该如何面对新业...

    TVP官方团队
  • 同程艺龙资深架构师牛提罚:同程艺龙小程序性能监控系统的探索与实践

    11月24日,云+社区开发者大会(苏州站)圆满落幕。本次开发者大会的主题为“姑苏城外论技术:物联网·小程序·微服务”,邀请了腾讯内部及业内行业大咖就物联网、小程...

    TVP官方团队
  • WordPress版微信小程序3.1.5版的新功能

    产品的完善是无止境,每过段时间就会发现产品的新问题,使用的人越多,提的需求也会越多,我听得最多的一句话就是:如果加上某某功能就完美了。其实,完美是不存在的,每个...

    Jianbo
  • 揭秘框架的本源:开源中文书「TensorFlow内核剖析」

    项目链接:https://github.com/horance-liu/tensorflow-internals

    机器之心
  • 开源书:TensorFlow 内核剖析(中文)

    项目链接:https://github.com/horance-liu/tensorflow-internals

    Amusi
  • SpringBoot的@Value注解设置默认值

    在Spring Boot中,如果使用@Value注解对属性进行赋值,但如果在配置文件或启动参数中未指定对应的参数值,则会抛出异常。异常信息往往是对应注入属性的类...

    用户1161110
  • Java常用集合源码级深度解析

    Java集合工具包位于Java.util包下,包含了很多常用的数据结构,如数组、链表、栈、队列、集合、哈希表等。学习Java集合框架下大致可以分为如下五个部分:...

    互扯程序
  • 出租车行业的一点了解

    出租车业务是每个城市必备的基础服务,出租司机也是很多人进入到一个新的城市接触到的第一批人。

    jeanron100
  • 简化深度学习实践流程:新鲜出炉的TensorFlow项目模板来了

    林鳞 编译自 GitHub 量子位 出品 | 公众号 QbitAI 新的TensorFlow项目模板来了。 昨天,用户mrgemy95在Reddit上发帖,称这...

    量子位

扫码关注云+社区

领取腾讯云代金券