程序员日常工作中如何正确的偷懒？

摘要：大胖心急啊，自认为也是个优秀的程序员啊，再出现低级错误的话，专业能力会被人怀疑的。此时大胖已经在积极的谋划了，他深深明白了日常的工作中也有很多可以提升的空间，而这些提升不仅仅是技术上的，更多的是思路和思想上了。

这是北京的雪，昨天刚拍的

又是一个艳阳天，张大胖像一个天真无邪的孩子屁颠屁颠的欢快的走进公司，做到办公桌前，深情的打开了陪伴自己多年的电脑，如往常一样按部就班的和他玩耍了起来，大老远就听到张大胖那里噼里啪啦敲键盘的声音，透露着坚定和对梦想的执着，但似乎又让人感受到一丝悲凉。

突然键盘的声音戛然而止，只看到大胖愣住了，他看着旁边公司刚发的台历，上面有个大大数字9201，对现在已经是2019年了的2月了，还有10个月就是2020年了，18年给自己立的 flag 到现在还没开工。大胖此时陷入了沉思，他不想再让19年重复18年的状态 不想这样碌碌无为下去。大胖还是有比较强的自驱力，也是有理想的小伙儿，对前端技术充满热爱，希望可以成为一个比较 nb 的程序员，大胖算着自己还有几年就要奔三了，26 7啷当岁已不年轻了，不由的悲从中来。

大胖伤感的是工作太忙，每天忙于业务开发，很少能挤出时间来做自己想做的事儿，甚是无奈。

大胖深深的明白如果不提升自己的能力，不超越这个层次到哪里都是一样，换工作并不能解决这个问题，哪个公司也不会养闲人。对于公司来说公司的业务才是第一，对于我们个人来说成长才是第一。所以应该想办法在做好业务开发的同时，加速自己的成长，让自己有更多的时间来学习和提升。

大胖刚刚从伤感中爬出来，又眉头紧锁起来。大胖在想怎样才能挤出更多的时间，又不耽误正常工作的进行，这样就能有足够的时间去做喜欢的事儿。

过了一会儿，远处又传来噼里啪啦的键盘声音，是大胖在敲代码？在改 bug？ 其实大胖是在做分析总结，他认真的分析了自己以往的工作状态和工作流程中因为惰性而没有优化的地方，想到了以往可以做的更好，可以让效率更高的地方。

不一会儿大胖列了一个清单出来

大胖想起来以前被产品坑的情景，需求中有一处逻辑很玄妙，但是仔细想是存在一些问题。大胖当时么有在意，也没有和产品提，就去开发了。到最后快要开发完的时候，产品发现了这个问题，然后非要改。结果胳膊拧不过大腿，后面的事儿想必大伙儿都知道了，就是加班熬夜赶工期。

回头想想，看似是被产品坑了，好像是被自己坑了。发现了问题但没有及时提出，多大影响也无从判断，把自己当成了一个纯粹执行者，完全处于被动状态，结果吃苦受累还废人。

所以啊，要扔掉执行者的思维，产品的需求也不可能100%对，所以从现在起你也是半个儿产品经理了。

以前大胖接到了公司的需求，觉得这玩意也是轻车熟路了，拿过来不假思索的就开始干，撸代码。

写着写着，发现这里不对，遇到了一些问题，然后就改。

写着写着，发现那里不了，原来是当初自己想错了，又开始一顿改。

好了，开发完了，结果代码也是一团糟，毫无规范和美感，也埋下了不少坑和 bug。

如果当初能对需求理解清楚，然后对技术方案做充足的思考，复杂的业务逻辑是不是应该画个流程图什么的，如果前期工作做的比较完善，也不至于在开发的时候反复修改，浪费了时间，也导致最后的代码难以维护。

所以，需求来了别着急写代码，确定好技术方案和各种异常边界情况，甚至可以落地到一个文档。

也可以避免出现一些流程和功能性问题。

大胖的一大特点就是手快儿，做什么都能快速的给你整完。可是这个质量吗有点不敢恭维，bug 不说特别多把，但是总会出现一些不该出现的 bug。

大胖心急啊，自认为也是个优秀的程序员啊，再出现低级错误的话，专业能力会被人怀疑的。不过现在已经有人在怀疑了。这些 bug 也浪费了大胖不少时间，回过头来想想真想掐死自己。当时脑子去哪了？

最基本的稳定性、健壮性都考虑不全，猪脑子了。

距离上次被测试同学催命，过去了大约1个月的时间，但是记忆犹新，历历在目，因为惨不忍睹。大胖平时有点轴，不撞南墙不回头，处理问题有时候午饭都不吃。当时碰到一个 bug，吭哧吭哧的研究了大半天，终于解决了，可是还有很多特别小的 bug，测试在等着测呢？后来测试同学找大胖询问下情况，他们两个去旁边聊了聊....

当然大胖的公司的非常团结有爱，每个工作人员的人身安全和名誉是绝对不会受损的。嗯，这个就到这儿了。

大胖也是很懊恼，为啥我就那么有耐心去解那一个 bug 呢？放弃了一大片森林。大胖痛定思痛，绝对重新梳理自己处理问题的方式。

日常开发中问题有很多，但是有很多类似的，有简单的复杂的。最好先把所有的 bug 过一遍，按照优先级进行划分，先处理简单的问题。也就是把不费时间的先搞定，费时间的往后排。所有问题都应该处理，但是所有问题可能不能在较短的时间内彻底的解决。处理和解决是两回事。

都是大胖的伤心事儿，辛辛苦苦的搞定了项目，马上就要提测，此时不巧了，领导来了，说要体验下新功能，大胖气定神闲的给领导演示。偏偏就是这么尿性，出问题了。问题不大不小，但是会阻碍测试流程。这下 sb 了。

大胖深深吸取了这次教训，原因是自己做好的东西，没有进行全面自测，对于大胖如此负责的帅哥程序员来说那简直就是奇耻大辱啊。

暗暗发下毒誓，如果我不自测，以后老子就不提测了。(这种心态是不可取的)

大胖想起了另外一个同事的遭遇，当时那哥们认为做前端开发不用太注重对业务的了解，有接口文档就可以了。领导感觉他对项目已经比较熟悉了，后面的需求就让他独立负责了，最终的完成时间和排期有点误差，也就延期了 2 3天吧。但是具体的原因就是对业务知识了解不足，也无法给小组成员提供帮助，经常需要向其他部门同事寻求帮助，导致开发过程中沟通成本过高。

大胖回过神后，唏嘘了一下，幸亏没让自己上啊。不然捅娄子的就是我了。

处于应用层的开发，如果对业务知识了解不足会感觉走起路来有点瘸，时间长了还会影响正常的腿，所以要想高效的完成工作，熟悉业务知识太重要了。

此时大胖已经在积极的谋划了，他深深明白了日常的工作中也有很多可以提升的空间，而这些提升不仅仅是技术上的，更多的是思路和思想上了。大胖坚定了自己的信心，要认真按照自己的路子去执行，高效高质量的做好业务开发，然后去做自己的事儿，逐步提升自己的技术，完成自己的 flag。

不一会儿......

远处又传来了噼里啪啦的声音，原来大胖又敲起了代码，但是这次似乎有所不同，速度好像更快乐,听起来更悦耳了。

作者：八门
个人微信公众号 - 重度前端
专注前端领域，分享工作、技术、生活感悟
少走弯路，少踩坑 
欢迎关注 重度前端-和我保持长期关系