大厂程序员的反思：低级程序员的四个坏习惯，看看你中了几条？

txc

作者：东东拿铁

前言
当我们谈论程序员的工作习惯时，常常想到的是高效的编码技巧、精密的逻辑思维以及对新技术的敏锐洞察。

本文不聊技术，想谈谈在日常工作中，程序员可能会有的四个坏习惯，如果你认识不到，可能会影响你的工作效率、影响团队协作，甚至影响你的职业发展。

下面就让我们看看这些坏习惯都有哪些，你有没有中招呢？

如有雷同，纯属巧合

低头干活，不看方向
对于方向的迷茫
每天睡眼惺忪的上班，打开开发工具，CRUD开始了。喷喷老板，吐槽吐槽产品经理。

开发前

这需求是啥啊，就一句话？

有产品吗，没产品没法做？

这prd写的不清晰啊，好多东西没写清楚，没法做

开发中

延期了？没事，需求拆解的就不到位。

这个功能什么时候上线？who care，测试完了，你们上线就行

上线后

现场出问题了，异常case你prd也没要求，报错了不能怪我？

这个功能给谁做的？who care，我的需求完成就行了

这个功能上线效果怎么样？who care，我的任务完成了，其他的我不需要关心了



如何避免
不知道你有没有遇到过上面的场景呢？如果有，那么恭喜你，看完我的讲述，你会知道如何改变自己的一个思维误区，那便是学会”以终为始“。

我们常见的思维模式，是线性且顺序的，先有A，再有B，走完B，再走C。为什么会这样呢？

我们人类都是从远古进化而来的，在那个危机四伏的生存条件下，思考并不是一件特别有用的事情，且会耗费多余的能量，所以几十万年的进化，留给了我们一些短视的行为与习惯。

那什么是以终为始呢？很简单，做一件事情之前，想一想做完结果是什么样子的。

如何改进
似乎你也发现了，在做事之前，你要记住一件事情：遇到事情，倒着想。

任何事物都会经过两次创造：一次是在头脑中创造，然后才是付诸实践，进行第二次创造。

比如，互联网环境，北上广深，是非常好的选择，你在二线城市，你会怎么去选？ 去北上广、或者留在小城市的抉择。那么你得想清楚，去一线城市，你会更换工作环境，面临互联网较大的压力，甚至没时间恋爱，陪伴家人。但同样的，工资可能会很高，你也能获得更快的成长。

留在家乡，你的工作可能非常清闲，五点半就能下班。但你可能***没法参与到一个几千万用户都在使用的APP中去，你的技术能力和眼界，会受到环境制约。

工作中，领导安排的任务，是为了解决什么问题，问题的背景是什么？谁是你的用户，谁是你的客户，功能做出来，真的能解决一开始面临的问题吗？工作是否能量化，如何更快的拿到用户反馈，来持续迭代与改进。这些你也要去考虑，而不是简单的编码、测试、发布。

不做任务分解
是什么
事情想清楚，下一步就是动手去做了，面对任务

老板问你排期几天，你说评估不了，做一步看一步

或许你技术能力很强，听到需求内心里大致就有了技术方案，然后就，直接上手敲码了。。

不区分核心功能，事情不区分轻重缓急，想到什么做什么

代码方法都不拆分，金箍棒代码满天飞，更不用提单元测试



为什么
有一个关于程序员的经典段子：这个工作已经做完了80%，剩下的**20%**还要用和前面的一样时间。

为什么会出现这种问题，很重要的一个原因就在于没有很好的拆解任务，所以并不知道要做的事情有多少。

面对一个大问题，我们都很难给出答案，主要有以下三个原因：

复杂性和不确定性，一个大问题通常有很多复杂的结构和多种因素考虑， 我们很难掌握完整的情况去做出判断。
资源限制，解决大问题通常需要很多资源，比如说新建一个系统，可能需要7个工作日，但是一个小模块，只需要1个工作日就能完成。
失控感，进度无法把控，就像最开始的例子，完成进度和实际进度，有着较大的偏差，会让我们有极强的失控感。
但回答小问题却是我们擅长的。 通过任务拆解，我们面临的就是一个个清晰可落地的问题，可以更集中地解决每个小问题，逐步地朝着解决整体问题的方向前进。

怎么做
如何去做的关键，是怎么给出一个可执行的分解。

重点来了，拆分的，一定要可执行。每个人对于可执行的区分，是有很大不同的。不同的地方在于可执行的定义，你是否能清楚地知道这个问题该如何解决。

举一个例子，比如要做一个登陆页面，而我是做后端的。那么我的任务可能会这么拆分

后端：提供验证密码接口
前端：前端技术选型，学习前端语法（目前我啥也不懂）
前端：写html页面
前端：完善前端样式
可以看到我对前端部分拆分较细，因为我不了解，所以我把它拆分成了我能想到并且可执行的多条任务。后端部分虽然可能需要建表、确认密码加密，提供接口，但对我而言，一个任务拆分就可以了。

所以，面对复杂任务，拆解成你可以直观评估并且可执行的子任务，更好的完成任务拆分。

不沟通，不聆听
是什么
产品的需求评审完了，没听懂也不问，做不下去了再说

合作同事进度怎么样？不知道，测试进度我不管

上线后效果如何，用户反馈怎么样，那更不需要关心。



为什么
有一些新晋程序员，并不是特别爱沟通，其实这可能也与我们从事的工作有关系。

专注于技术：程序员对技术本身非常感兴趣，他们更愿意花时间学习和掌握新的编程技能，而不是花时间与他人交流。

时间压力：在工作中，我们通常面临着时间限制，我们既要技术方案设计，还要完成编码工作和配合测试。在这种情况下，他们可能会感到沟通会消耗过多的时间，因此更倾向于专注于编程任务本身。

很多程序员只希望安安静静地写好代码，但事实上，对于大多数人来说，安安静静是不太可能写好代码的，只有不断扩大自己的工作范围，才有可能把工作做好，那么我们要怎么做呢？

怎么做
作为员工，我们需要向上沟通，了解领导的目标、预期，确保工作进度，规避风险，做出成绩。

作为领导或者组长，你不但要做好向上沟通，与团队的沟通更为重要，为大家制定目标，确定方向，甚至是关注每个成员的状态与后续的成长。

做为普通开发人员，我们要关注使用情况，及时拿到线上反馈，完成迭代。因为我们通常会欠缺用户视角，在与产品经理的交流中，你是不可能有机会的，因为他很容易用一句话就把你打败：“这就是用户需求。”

（顺手推几个技术大厂的机会，前、后端or测试，感兴趣就试试https://jinshuju.net/f/o38ijj ）

用人工，不用工具、自动化
如何用好工具和自动化？
程序员的日常工作，是打造工具、系统，来解决别人的问题。但是你有想过，你自己的工作，有合适的工具来帮助你自动化，减轻你的压力吗。

在上家公司，我遇到的一个案例，第一次让我认识到，程序员的自动化，有多么的重要。

推荐团队负责的系统，涉及到多个推荐模型、数十个数据源，甚至是线上的多个配置，在信息流中刷出来的内容，对用户是黑盒的，因为你最终看到的5个内容，可能是由几万个内容里面根据推荐策略选出来的，看到什么，不看到什么，非常复杂。

但是对于公司内的开发人员，需要排查推荐问题时，即使有ELK，logId,来定位问题也是极为繁琐且耗时的，因为数据量大，不可能所有地方都输出日志，因此排查问题非常麻烦。

后来他们开发了一个内部工具，需要排查内部问题时，只需要把你的用户ID配置上实验参数，推荐出来的几条内容，每一条为什么展示，被抛弃内容的原因和其他关键信息，都能结构化的输出在工具内，无需去看日志，即可排查各类问题，起码提供了很多信息。

反观我自己，产品需要我排查的问题，我可能要去看日志，甚至看代码，或者因为某个关键信息没打印日志而焦急，偶发的一些问题，占据了我非常多的时间。



为什么要用好工具
程序员的工作中，天然就存在着需要重复的工作，我们需要从重复的工作中跳出来。

BUG的排查定位，某一个业务流程出现了阻塞，你是不是需要查询数据库数据，定位上下游有没有问题。

代码重构，业务不断迭代，功能需求也在逐步丰富，原有的设计不满足，频繁进行重构。

测试、调试，构建各种测试数据，编写测试用例，尤其是在复杂的系统中，可能需要重复执行相似的测试和调试过程。

部署与发布，代码修改后，发布上线也是重复的工作，代码是否能自动合并，能否自动发布，是否能够监控发布状态，都是些重复性的任务。

怎么做
使用脚本、工具或自动化流程来简化和自动化重复性任务的执行。

将常见的功能封装成可重用的模块或库，以便在需要时进行调用，减少重复编写代码的情况。

审查和改进工作流程，消除不必要的重复步骤，提高工作效率。

说在最后
好了，文章到这里就要结束了，总结一下，程序员的四个坏习惯

低头干活，不看方向。学会“以终为始”思维模式，先在脑海中构思，再去落地实践。
不做任务拆解。学会拆解成，可执行的子任务，以便更好的管理时间，拆分任务优先级。
不沟通，不聆听。学会向上沟通了解大方向、目标，让自己有着明确的前进方向。向下沟通，保证团队能够拧成一股绳，劲往一处使。
不会用自动化。 学会变“懒”用工具，解决自己工作、生活中重复的工作，让自己轻松起来。