卓越人生的两大利器——任务分解与保持节奏

今天,我们不谈具体的技术;相反,我们来聊聊关于方法论的一些话题。

总有人说,什么方法论啊,价值观啊,人生观啊,都是一些虚无缥缈的东西,与现实中的自己距离太远,而且都是一些“虚幻”的东西,不如谈谈具体的技术实在,比如说什么Spring Cloud啊、Docker啊、Kubernetes啊、Angular啊、Kafka啊,这些都是实打实的技术,掌握了就是掌握了,没掌握就是没掌握,来不得半点虚假。

没错,上面所列举的技术都是一些硬实力,这些硬实力是确保你职场竞争力的根本所在,特别是对于技术人员来说,掌握的技术越深入、越扎实、再有一些广度,那么你就是一个在职场非常具有竞争力的人,也是公司所需要的人,同时不可替代性也会越强。因此,很多开发人员就容易陷入这样一个误区:只关注于眼前,只关注于技术本身,但对于一些具有指导意义的方法论视而不见或是漠不关心。其实,我想说的是,若想在人生这场马拉松赛事中永葆活力,关注当下纵然不可或缺,但掌握了正确的方法论则会令你越走越远,同时越走越好。

那到底什么是方法论呢?这个词语我们每个人都知道,但它到底有什么作用呢?其实,按照我的理解,方法论就是指导我们行事的一套理论体系,每个人每一天都在使用它,只不过很多人并未感知到它的存在而已。究其原因,每个人的方法论都已经成为这个人根深蒂固的习惯了,在不经意间其实就已经在运用了。只不过,有的方法论是好的,是优秀的,是有价值的;而有些方法论则是不好的,应该被摒弃的。但正所谓,当局者迷,旁观者清。当事人往往对于自己所运用的方法论浑然不知。因此,即便自己所运用的方法论需要改进,他也完全不知晓。下面我举一个例子,相信大家都会感同身受。

当我们接到一个新的功能需求时,不同人的做法是截然不同的。有的人会选择立刻开始编码,写着写着开始发现问题,然后又修改代码;改完之后写了一阵,又发现有问题,然后接着改。上来就编码的做法看似快,但实则却会浪费不少时间,因为他会用所谓编码的忙碌来掩饰自己不愿意,或是不擅长思考的本性。而有的人则不会采取这种做法,他会根据功能需求首先进行设计,仔细思考这个新的功能需求会给既有系统带来哪些改变,对既有系统会产生何种影响,应该采取什么方式来更好地实现这个功能需求,最后一切都想清楚了,并且在纸上画明白了,最后才开始编码。这看似很慢的做法往往会带来更好的结果,而且总体时间会减少很多。这其实就是一种方法论的体现。

又,在学习一项新技术时,有些人采取的做法是在百度上到处搜,搜索完一篇文章后,走马观花地看一下,然后再继续搜,不得不说,这其实是很多人学习方式的真实写照,这么做看起来是挺快,不过结果可想而知。但,总有那么一群人,同样学习一项新技术,他会仔细阅读官方文档,阅读API说明,采取系统化的学习方式,先从宏观上对所要学习的技术有一个总体的把控,然后再由浅入深地学习技术的各个组成部分,正所谓从总体到局部。花费了足够的时间与精力对各个局部都有了较好的理解后,最后再从总体上审视这项技术,如果是一项重要技术,那么他还会花费足够的时间研究技术底层的源码与设计。看,这又是一种学习技术的方式。显然,这又是方法论的不同所导致的学习方式的不同,而且这种不同的差别还是非常大的。孰优孰劣,大家可以自行评判。

回到正题,本文我想谈及的两个要点分别是任务分解与保持节奏,下面逐个解释。

任务分解,顾名思义,就是将一个大任务划分为若干小任务,接下来再对分解之后的小任务继续划分,直到粒度足够细为止,没错,这其实就是Java 7所引入的Fork-Join框架的做法。编程语言中的很多问题解决方式都是来源于现实生活的。我们在现实生活中就会常常面临任务分解的场景。比如说,我们制订了为期一个月的开发任务。显然,我们需要对这一个月的时间进行细粒度的划分,明确每一天,每一周要完成哪些工作,要达成什么样的目标,每一周的里程碑是什么。确保每一天的工作都能完成是确保当周工作能够顺利完成的前提;而每一周工作的顺利完成则是确保整月工作顺利完成的重要前提。只有这样,我们的开发工作才能有条不紊,沿着既定的路线前行,不至于工作了一段时间后发现“跑偏了”。正确地做事与做正确的事哪一个更为重要呢?

有的人可能会说,开发会由于产品的不断修改而导致各种问题。没错,在现实工作中这种情况注定是不可避免的。但你要知道这样一个观点:制订计划的目的是为了更好地应对变化。如果没有良好的计划与任务分解能力,那么每天萦绕在你脑海中的总是这个待完成的任务整体,你丝毫体会不到一天工作下来对于整体任务的推进程度如何。这实际上是非常打消人的积极性的。

我毕业后的第一份工作是在理光软件研究所,接手的第一个项目就是公司自己开发的一个项目管理系统,这个系统涉及到PMBOK项目管理所涵盖的时间管理与范围管理两个领域。因此,这令我对项目管理有着更加深刻的认识。在团队协作中,总是存在依赖关系的。正如Spring Bean之间的Dependency一样,及BeanA依赖于BeanB,那么在初始化BeanA时,Spring会首先实例并初始化BeanB,然后将其注入到BeanA中。日常工作中也是如此,你的工作可能会被其他同事所依赖,如果你延误了,那么就会对其他人造成干扰。几次延误后,你在其他人眼中就是一个不遵守承诺的人,这与技术水准毫无关系。长此以往,你的口碑在团队中就会越来越差,对于个人所造成的影响不言而喻。因此,为了避免这一局面的出现,首先要做到的就是信守承诺,承诺别人的事情就一定要办到;如果因为种种原因无法达成,那么一定要提前与对方沟通,千万不要到截止日期前才告诉别人,说你没完成,这实在是下下的方式。

若想达成这样的结果,任务分解就是不二之选。对自己要做的工作与完成工作的时间进行合理的规划,并且对任务进行细粒度划分。明确自己每一天的工作成果,只有这样才能稳妥地完成各项工作与任务。每次都能很好地完成任务,你的口碑我相信在团队中一定会越来越好,这对于自己自信心的提升也是有诸多裨益的,这才是一个良性循环。

第二个话题:保持节奏。

其实,这是我一直在不断强调的四个字。很多人无论做什么,总期盼着一下子做完。不过实际上,除非是那种比较简单的工作;很多时候,很多任务,我们是根本不可能一下子搞定的。这时就需要我们保持一个良好的节奏,平稳地完成每天的工作,按照既定的目标不断前行。

在当下之时代,很多人并不是不努力,而是太努力了。用力过猛是很多人的真实写照,无论是工作上,抑或生活上。总期望一下子用猛力将事情做完。但结果往往不尽如人意。要知道的是,用力过猛极易导致过早放弃。我举一个我的实际例子。我从毕业到现在已经翻译了24本技术图书。每次接手一本新书的翻译工作时,我都会花费足够多的时间对图书内容进行一个较为细粒度的划分。一般来说,一本技术图书的翻译周期是3-4个月。这其实是一项长期的工作。为了让这长期的工作能够按照计划执行,我都会按照预先设定的节奏每天翻译几页,这样看起来其实每天翻译的工作量并不大,1-2小时而已,但我知道,只要我每天完成了这些工作,就不会造成翻译工作的拖延;同时,为了预防一些意外事件的发生(比如说生病、状态不好就是不想工作、工作比较忙等),我都会预留一些缓冲时间(这是不是又与Java IO中的缓冲区一样呢)。通过这样有节奏感的工作,我会确保翻译工作的不拖延,同时每天又不会感到很疲倦。

另外值得一提的就是目前的课程录制工作。现在,圣思园的课程是每周定期发布,这其实就是我保持节奏感的一种很好的体现。我从来不会一下子发布太多课程,也不会一下子什么也不发。从我们的JDK 8课程发布以来,我们已经持续了几个月的时间,这期间从未出现过因为我个人原因导致课程无法按时发布的情况。这正是保持节奏感的最佳实践,我准备每周的课程都是分为几个部分进行的;首先,当然是准备课程内容,这部分是最花费时间与精力的,我都会提前准备好,越提前越好;接下来,准备好后,我一般会找周末的时间完成录制,然后在预定的发布时间按时发布(也许我后面可以专门写一篇文章谈谈我是如何录制一节课程的)。

此外,我平时很喜欢跑步,下面是到目前为止我的总跑量,这其实也是我保持节奏感的做法。我一般是每周跑步20千米(除非遇到雾霾天气等一些不可控的客观因素),否则一定会完成自己的预定目标,这不仅是锻炼身体的一种好方式,而且也是履行自己对自己的承诺的一种做法。


下面是我2016年参加北京全程马拉松时的跑步截图。量变引起质变。通过保持稳健的节奏感以及刻意的练习,全程马拉松其实也不是遥不可及的事情;其实任何事情都是如此,几乎没有例外,特别是在学习这件事上


说了这么多,其实中心话题就是:在你的生活与工作中,任务分解与保持节奏将会令你冲破层层迷雾,以一种稳健的方式达成自己的目标,同时在这个过程中你又不会感觉到很疲惫;相反,你是带着自信的笑容迎接人生的每一个挑战的


欢迎大家加入圣思园,网址:http://iprogramming.cn。


欢迎扫码加我微信好友,交流技术



欢迎扫码关注圣思园微信公众号

  • 24
    点赞
  • 76
    收藏
    觉得还不错? 一键收藏
  • 24
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 24
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值