如何正确的制定目标
我相信绝大多数的人应该都制定过目标，比如“我要减肥”，“我要学习XXX技术”，“我要看书”，“我要写博客” …. 。
那么请问：你曾经制定的目标完成了吗？
我猜肯定有人是从入门到放弃，有的人甚至还有些不甘心，当时间过了之后就把之前的目标时间延后，如：2017年过了但是还是没完成年度目标，于是把7改成了8。其实这个和制定目标的方法是有很大的关系的，接下来我就来说说如何正确的制定目标。
1.目标不要多
现在这个时代可以说信息爆炸的时代，我们能很轻松的接触到很多信息，这样就会导致我们今天看这个技术不错明天看那个技术也不错都想去学习，结果就是今天学习pyhton，明天学习前端，后天学习后台，甚至有的人，一天学习三种技术，每一种学习半小时。这样虽然看上去学习了很多的技术，但是学习效果却很糟糕。过于杂乱到学习只会导致整天都很焦虑，解决办法就是把事情分散开，每一段时间只做一件事情，这样能让你专注，只有专注才能让你更高效。切记“贪多嚼不烂”。
2.目标四要素
当我们选择一个目标之后，我们就要开始制定目标了，这个时候要注意一个好的目标需要做到“明确可执行”这一点。怎么才算明确可执行呢？
需要有以下四点：
时间区间
行为方式
目标对象
时间长度
如：这周用4个小时写一篇时间管理的文章。
分解：
时间区间（这周）
行为方式（写作）
目标对象（时间管理）
时间长度（4小时）
这样的目标就很清晰了，简化成一个固定的句式：在什么时候，做什么事情，和谁，需要多久。
3.目标拆解
上面我们得到了一个很清晰的计划，接下来再把这4个小时再细分一下具体的任务，以及每天花多少时间，还是拿上面到写作举例。
定文章大纲（0.5小时）；
翻阅笔记，提取概念（0.5小时）；
写出自己的践行经历（1小时）；
将概念和经历整合（1.5小时）；
对文章内容进行修改（0.5小时）；
每完成一个小的任务，都可以更新下任务表，快速的给自己反馈，这样让会自己有一种成就感。
4.预留时间
需要注意的是不要把计划和当天的时间全部排满，预留出30%的容错时间。在《稀缺》中提到稀缺会导致管窥效应。面对稀缺，我们就更倾向于把注意力集中在最需要关注的事情上面，这么一来，我们往往会忽视那些真正重要的事情。
据报道美国的消防员80%都是死在了去火场的路上，因为没有系安全带，在急转弯的时候被甩出车外殉职的。他们在接到出警通知的时候，就会进入时间稀缺的状态，他们要在很短的时间里做大量准备工作，导致一些重要但平常的事情被疏忽了。
任何系统留一定的余闲都非常重要，它不是对资源的浪费，而是让系统更加高效运转的保证。
总结
如何正确制定目标？
明确目标
目标制定
拆解目标
预留时间
从现在开始认真审视自己的目标，循着这些内在逻辑从新规划自己的目标，稳扎稳打地践行。你会发现，制定一个可完成目标如此简单！
一个优秀的程序员应该具备哪些技能和修养？
首先是“快速学习能力”。这里不是说一定要去快速去学习各种各样的新技术，而是说当有需要时，能够快速的学习。很多人开始学新的技术和技能时，一开始就一头扎进去写样例、写Demo、看源码，我认为这不是好的方法，而且比较耗费时间，收效也不明显。
我给大家分享我的4W2H快速学习方法。我在学习新的技术的时候，都是按照这样的步骤去了解的：
1）这个技术能解决什么问题（why）
2）比较适合在哪些场景应用（where + when)
3）这个技术跟我已经掌握的哪个知识或技能类似，有什么差别、有什么特点、 有什么优点和缺点（what）
4）了解前面的问题后，我才会开始去尝试写写Demo，或者更进一步去应用（How to use）
5）觉得有兴趣或者其实现很牛逼的情况下，我就去研究一下原理机制，看看源码等 （How it implements）
其次是“良好的理解能力”。程序员需要将产品人员或者用户用自然语言表述的需求翻译成程序语言。自然语言有一个特点就是通俗但不严谨，而程序语言必须是非常严谨的。如果对产品人员或者用户提出的需求没有很好的理解，即使程序语言写的再漂亮，技巧再高，最后做出来也是一个不符合要求的产品
记得有一个关于“美女”的笑话：人听到“美女”后的反应是想到“天使面孔魔鬼身材童颜巨乳”，而猪听到“美女”后的反应是“乌克兰大白猪”，猫听到“美女”后的反应是“有着金色光滑皮毛的波斯猫”。如果程序员给了猫一个“天使面孔魔鬼身材童颜巨乳”的美女，猫一定会觉得很难看。
第三是“持续不断的学习”。软件开发领域设计的知识和技能太多了。从广度上来说，有操作系统、数据库、编程语言、网络、设计等，编程语言又有几十种；从深度上来说，操作系统、数据库、编程语言等都是可以不断深入去学习的。无论你是从事对技能广度要求更高的业务开发，还是从事对技能深度要求更高开发专项系统，都需要不断的学习，这样才能不断的提升自己的能力。
第四是“乐于分享”。如果单纯从个人完成工作的能力来看，可能确实也有很多程序员不爱分享但确实很厉害。但我认为真正优秀的程序员一定是除了自己优秀外，还能让其他人也变得优秀，或者能够贡献优秀的开源项目以降低别人的重复工作。分享的途径有很多种，可以给公司人员做培训，可以写博客，可以贡献开源项目等。
我不会以码农自卑，但一定以常年码农为耻！
大家讨论的地方，如果你总期望有高手总无偿指点你，除非他是你亲戚！！讨论者，起码是水平相当的才有讨论的说法，如果水平真差距太远了，连基本操作都需要别人给解答，谁还跟你讨论呢。?
---浮躁的人容易问：我到底该学什么；----别问，学就对了；?
---浮躁的人容易问：有钱途吗；----建议你去抢银行算了；?
---浮躁的人容易说：我要中文版！我英文不行！----不行？学呀！?
---浮躁的人分两种：只观望而不学的人；只学而不坚持的人；?
---浮躁的人永远不是（也成不了）一个高手。
java开发人员可以看过来。
对于参加工作1年到2年的同学。这部分时间段的同学，已经对Java有了一个更加深入的了解。
对于参加工作2年到3年的同学有的同学在这个时候觉得自己已经很牛逼了，于是忍不住开始慢慢松懈。
参加工作3年到4年的同学这个阶段的同学，提升已经是很难了，而且这个阶段的学习往往会比较多样化。
参加工作4年到5年的同学经过前面一年的历练，相信你在自己所钻研的领域已经有了自己一定的见解，这个时候，技术上你应该已经遇到瓶颈了。
可以一起学习：454377428?java架构\多线程\高性能 一起交流学习吧、 帮你提升自己，图片瓶颈，跟上时代的脚步。
为大家分享自己总结的架构师学习路线图，大家可以拿来做一个参考：
一、分布式架构体系
分布式怎么来的。传统的电信、银行业，当业务量大了之后，普通服务器CPU/IO/网络到了100%，请求太慢怎么办？最直接的做法，升级硬件，反正也不缺钱，IBM小型机，大型机，采购了堆硬件。
但是互联网不能这么干，互联网没有那么财大气粗，还有很多初创，能不能赚钱还不知道。所以就有了软件方面的解决方案：分布式系统，简单说，就是一台服务器不行，我用两台、10台、100台...这就要软件系统需要支持。
那么多台机器，我如何让他们协同工作，这就需要一个调度中心（或注册中心）；肯定涉及到机器间通信，那么需要一个高效的RPC框架；一个请求过来了，如何分发，需要一个请求分发系统（负载均衡）；然后还要考虑每个角色都不能成为性能瓶颈；还有要能方便的进行横向扩展，还有考虑单节点故障。
需要分布式系统，并发量肯定不低，
那么有了上面的还是不够的，还需要考虑cache、mq、job、db等方面的问题。cache，现在第三方缓存也比较成熟，redis/memcache等；mq，rabbitmq,kafka等等也不错；job，现在第三方任务框架有elasticjob和tbschedule，或者你用quartz也支持分布式环境下的任务，不过quartz就没有运维工具了。DB，数据库最好在项目前期就考虑好业务拆分，系统拆分后DB对应的垂直拆分，后期可做读写分离，一主多从，甚至多主多从，业界也有了相应的解决方案。
总结一下，首先要了解分布式原理，然后对应着每个功能区找业界内成熟的产品来实时。互联网行业，基本都有开源的产品供你选择。
下图是我总结的分布式的技术攻克点：
二、微服务架构
微服务（Microservice）这个概念是2012年出现的，作为加快Web和移动应用程序开发进程的一种方法，2014年开始受到各方的关注，而2015年，可以说是微服务的元年；
越来越多的论坛、社区、blog以及互联网行业巨头开始对微服务进行讨论、实践，可以说这样更近一步推动了微服务的发展和创新。
微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的
类上应用很多SOLID原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。
概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。
定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。
本质：用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。
这些知识点都是我从业多年总结出来的的经验，都是当前最主流的技术。想学习这些技术的朋友可以加群：454377428。群里会分享这些技术知识点供大家学习免费下载
下图是我总结的微服务的技术要点：
三、阅读源码、分析源码
程序员每天都和代码打交道。经过数年的基础教育和职业培训，大部分程序员都会「写」代码，或者至少会抄代码和改代码。但是，会读代码的并不在多数，会读代码又真正读懂一些大项目的源码的，少之又少。这种怪状，真要追究起来，怪不得程序员这个群体本身 —— 它是两个原因造成的。
我们所有的教育和培训都在强调怎么写代码，并没有教大家如何读代码
大多数工作场景都是一个萝卜一个坑，我们只需要了解一个系统的局部便能开展工作，读不相干的代码，似乎没用
我常常把写代码和写作进行类比 —— 二者有很多相通之处;但从培养写代码和写作的过程来看，二者又有很多不同。我们的写作能力，是建立在大量基础阅读的基础上的，是除了学习语法和文法知识外，从小学开始，经年累月，通过阅读各种不同层次的名家的作品，再加上各种各样的写作训练，累积出来的;而我们的写代码的能力，在了解和掌握了语法/文法之后(学习和抄写 example 代码也算语法/文法学习的一部分)，跳过了大量阅读名家作品的过程，直接 biu 地一下就自动养成了：学会基础的语法和试验了若干 example 后，我们就火箭般蹿到了自己写代码打怪赞经验的阶段。这样略过大量阅读代码的阶段有三个害处：
写代码的基础是不牢靠的，打怪升级的过程也是最慢的。道理很简单 —— 前辈们踩过的坑，总结的经验教训，你都不得不亲自用最慢的法子一点点试着踩一遍。
很容易养成 stackoverflow driven 的写代码习惯 —— 遇到不知如何写的代码，从网上找现成的答案，找个高票的复制粘贴改吧改吧，凑活着完成功能再说。写代码的过程中遇到问题，开启调试模式，要么设置无数断点一步步跟踪，要么到处打印信息试图为满是窟窿的代码打上补丁，导致整个写代码的过程是一部调代码的血泪史。(见我的文章：你要避免的软件开发模式)
你周围最强的那个工程师的开发水平的上限就是你的上限。
下图是作为程序员最需要了解的源码体系：
四、工具的使用
工欲善其事必先利其器，工具对Java程序员的重要性不言而喻现在有很多库、实用工具和程序任Java开发人员选择。下图列出的工具都是程序员必不可少的工具
五、性能优化
性能优化，简而言之，就是在不影响系统运行正确性的前提下，使之运行地更快，完成特定功能所需的时间更短。性能问题永远是永恒的主题之一，而优化则更需要技巧。
相关文章
