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

总有人说，什么方法论啊，价值观啊，人生观啊，都是一些虚无缥缈的东西，与现实中的自己距离太远，而且都是一些“虚幻”的东西，不如谈谈具体的技术实在，比如说什么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年参加北京全程马拉松时的跑步截图。量变引起质变。

通过保持稳健的节奏感以及刻意的练习，全程马拉松其实也不是遥不可及的事情；其实任何事情都是如此，几乎没有例外，特别是在学习这件事上。

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