标签：注意 info 日常 线性时间 man 判断 程序员面试 组织 机器
最新互联网大厂面试真题、Java程序员面试策略（面试前的准备、面试中的技巧）请移步GitHub我们在日常工作中，总会这样感慨：事情，是干不完的。既然干不完，那我们就要分清轻重缓急，哪个重要，哪个不重要，给它们划分一个优先级，这样不至于让自己手忙脚乱。
能给手头的事情排上正确的优先级，是一项很重要的工作能力。
当然，我们在生活和学习中，事情也可能不少。但是和工作中的优先级相比，生活和学习里的事情是我们自己的事情，只要安排得让我们自己满意就可以了。在工作中，事情的优先级的标准，是要让公司受益，让老板满意，让同事认可。
首先呢，我们先谈谈优先级为什么重要。
我工作中有一段时间，就经常被工作的优先级所困扰，经理也时不时地批评我：“这个事情这么重要，你怎么到现在还没开始弄？”我心里也有点憋屈：“我又没闲着，我做的事情还不都是经理安排的么？”
这里有一个很重要的字眼——重要。
优先级有很多的考量，并不是简单的先来后到的线性时间顺序，我们需要根据事情的要紧程度安排优先级。
还有一个需要考虑的因素就是程序员的工作性质。对于软件工程师来说，一个事情可以用一天的时间做完，也可以用一个星期的时间精心打磨。如何在时间有限的情况下安排自己的时间，让时间用在最值得做的事情上，就是排优先级需要考虑的内容。
给不同的工作安排优先级，不仅会让我们的工作效率更好，也可以让我们和同事之间达成良好的合作关系，为什么这么说呢？且往下看。
首先，我们可以从两个维度去给工作划分类型，一个维度是工作本身的性质，另一个维度从合作角度出发，然后根据这些工作的重要与否安排优先级。
基于工作本身的性质，我把工作划分为公司发展计划、安全相关的事情和生产上的事情。
每个公司都有自己的发展计划，并给这些计划划定不同的权重，以指导协调公司内有限的资源。
拿我所在的公司来说，每年公司高层都会制定当年的发展目标，然后以此为依据，制定不同的发展项目，再根据项目，一层层地将项目分解为各个部门的子项目等等。每个部门，以顶级项目的优先级为参考，安排自己的资源，以达到公司的发展目标。
我们程序员作为公司人员组织的基层员工（我习惯称为叶子结点），自然不需要操这么大的心。但是我们需要了解公司的发展方向和重点项目。一般来说，公司的发展目标和与之相关的各个项目的优先级都会对内公开，公司也鼓励所有员工都熟悉这些内容。当和这个项目相关的工作安排到自己手里的时候，一定要给予这种工作足够的优先级。
同时，这种重要的事情，最好多花点时间在上面，力争做到最好。因为这种重要的事情是拖不起的，如果因为没做好拖累整个项目的进度，可能会影响自己甚至整个组的表现（performance）。
我们再来看看安全相关的事情。
“安全无小事”这个口号在所有工程类的工作中都适用。软件开发里的安全问题虽然不会直接影响生命安全，但是它会带来很大的经济损失和商誉损失，现实中各种数据泄漏的例子不胜枚举。
我随便举个 Java 的例子。在 JDK 的早期版本中，有一个执行任意代码漏洞。Java 可以启动新的进程，执行任何命令，方式是使用 Runtime 的 exec 方法，传递一个命令的 String数组。这个漏洞在于，它先检查了 String 数组里的命令是否允许被执行，然后再遍历数组，依次执行每条命令。而在多线程环境下，完全可能在检查完毕后，数组里的内容又被别的线程恶意更改了，改为不应该通过检查的命令。这样的话，一条本不应该通过检查的命令，就这样被执行了。
作为承担着软件开发和运维工作的现代程序员，我们首先要遵守安全部门的安全规范和检查，这就好像进入工地要戴安全帽，是没得商量的。
安全部门有时候还会发布紧急安全升级等要求。比如升级有安全隐患的 jar 包 / 组件等，这时候，我们一定要把这个当作优先级最高的任务，不要有任何的犹豫或轻视。
站在我们程序员的角度想一下，一旦出了安全问题，如果是因为自己执行不到位，这个责任肯定是要自己承担的，即使后期再怎么弥补，也无济于事。
试想一下，如果你没有配合安全部门的任务，导致一个有漏洞的 jar 包被利用，造成了数据泄漏。即使接到任务的时候你没有闲着，甚至为了完成业务开发挑灯夜战，但你觉得业务的人会为你说话，替你挡箭背锅吗？
如果你不确定，那么就换位思考一下吧。如果你是业务方，给开发提好了需求，进度也排好了，结果忽然开发组跟你说，因为做你的项目，导致我们没时间做安全升级，造成了公司损失，你要背锅。你是不是觉得这锅来得匪夷所思？
安全部门的要求就是最高的要求，是一切需求的“挡箭牌”。当一个安全部门给的任务到了你手上，告诉经理你要放下手中的工作，立刻开始执行安全任务吧。这既是为了公司，也是为了自己。
除了安全问题需要注意外，我们还要注意生产上的问题。
如果生产出了问题，那么作为 DevOps 的程序员，要第一时间放下手头的事情，冲上去搞。理清问题之后，马上开始行动。生产上的问题都是火烧眉毛。火烧眉毛的时候，你会等着别人给你送水，还是自己想尽一切办法找水呢？当然是自己找水了。如果需要别人配合，
马上联系相关的人或者其经理。
讲完工作本身的性质，我们再来看看那些需要跟别人合作的事情，毕竟有人的地方就有沟通，如果优先级没有排好，那就很容易导致沟通不到位，出了纰漏，就很麻烦了。
在日常工作中，我们有很多任务都是经理下达的。经理往往掌握着更多的信息，也更能判断一件事情的优先级。现在一般都是敏捷开发，经理会给每个 story 排优先级。在给任务排优先级的事情上，程序员可以提建议，也可以和经理讨论，但是一定要以经理的决定为准。
还有一些经理临时安排的事情，这种事情有时候更急一些，可能也不用耗费很长时间。所以这种事情也要先做。
如果一个事情需要别的部门配合，那么优先做。比如申请资源，和自己的上游讨论需求等等。这样一方面可以让别人尽早开始工作，另一方面也可以尽早交换信息，避免日后翻车。
举个简单的例子，如果有一个需求依赖上游服务。那么在自己这边需求明确的情况下，你要尽早和上游的组通气，看自己的需求能不能做，排期是怎样的。如果自己觉得没问题，先开展自己的工作，结果上游那边无法做或者无法排期，那工作就彻底翻车了。
如果事情没有太明显的轻重缓急，那么换位思考，与人为善，优先做那些阻塞了别人工作的事情。有些事情是来自组内的，有些来自组间合作。良好的合作关系就是这样一点点打磨出来的。
给工作排好优先级之后，我们还要注意工作内部各项事情的优先级。工作需要拆成不同的步骤来实施，这些步骤也有优先级，其实基本道理和我们上面讲的都一样。
我举一个开发新功能的例子。开发新功能可能要申请机器，要找上游谈依赖，要开发代码，要找下游谈需求，要和上下游联调接口等等。
你看，这里有“申请机器”“找上游谈依赖”“找下游谈需求”，那么这个时候，申请机器和找上游就是应该尽早开始的。同时，接口和联调也应该尽早开始，接口具体实现的代码不需要写得那么完善，甚至 mock 一些过程也是可以的。这样一方面可以和上下游尽早落实集成的细节，另一方面也可以尽早将阶段性的成果展示给需求方，随时 review，避免最后来个大“惊喜”。
我们做事情的时候，如果能把其中的每一步都想清楚，理清依赖关系，安排得井井有条，这就已经事半功倍了。
我们的工作繁杂而琐碎，今天我也仅仅是给出了一些通用的建议。在不同的工作内容，工作岗位上，可能有不同的维度。但是需要牢记的是，当你觉得自己工作手忙脚乱的时候，不妨停下来，先理理自己手头工作的优先级。怎么整理优先级呢？这里我给出一个简单的方法。首先把所有的事情列出来，然后对每件事情问自己两个问题：不做这个会怎么样？做了这个能怎么样？剩下的事情，就是顺着这个思路走下去了。
其实，给工作排优先级，不仅仅是一个提升工作效率的方法，也是提升自我和磨合团队的重要方式。
程序员的工作不只是低着头写代码，也不只是别人让干什么就干什么。给事情排优先级，是一种能够帮助把事情做对，做成，做好的重要能力。它不仅需要你对事情本身有准确的认识和判断，还需要你有清醒的思维，能够将事情分解，按照最优的顺序执行。给工作安排优先级的过程，也是锻炼自己能力的过程。
进一步说，这种能力更是一名经理的必备能力。经理的很大一部分任务就是理清事情，排列优先级，让自己的手下去做事情。程序员能控制的就是如何安排和使用自己的时间，而经理要对手下所有人的时间负责。所以经理眼前的事情更多，关系更复杂，需要做的判断也更重要，对这个能力的要求也更高出好几个层次。所以如果你有转做管理的计划，不妨在这件事情上多花点心思吧！
标签：注意 info 日常 线性时间 man 判断 程序员面试 组织 机器
原文地址：https://blog.51cto.com/14799494/2503460
