任务分解与保持节奏是使得你能够稳健持续前行的两大利器任务分解与保持节奏是使得你

今天，我们不谈具体的技术；相反，我们来聊聊关于方法论的一些话题。
总有人说，什么方法论啊，价值观啊，人生观啊，都是一些虚无缥缈的东西，与现实中的自己距离太远，而且都是一些“虚幻”的东西，不如谈谈具体的技术实在，比如说什么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千米（除非遇到雾霾天气等一些不可控的客观因素），否则一定会完成自己的预定目标，这不仅是锻炼身体的一种好方式，而且也是履行自己对自己的承诺的一种做法。