谈一下最近工作中遇到的几个思维误区

前言

我们都知道在工作中很看重一个人的工作年限，也就是工作经历，不同层次的工作岗位往往要求着对应的工作经验要求。比如拿程序员这一行业来说，初级程序一般要求1-3年工作经验，高级程序员对应3-5年工作经验，资深程序员就要求5年以上的开发经验。

这里的原因也很直接，更高的岗位要求必定需要去应付更复杂多变的工作场景，而工作经验这东西就是靠时间给堆出来的，一般来说，每个一天只有8个小时的工作时间，同等的工作强度下，一个年限长的开发人员肯定比一个年限短的经历过更多的开发任务。

但是这里有个前提那就是随着工作经验的增长，你每天所处理或者面对的事情是不是一直处于变化之中的，如果说每天你做的都是流水线的工作，那么这种年限的增长可能并不能体现出你的优势，而且一般人在处理或者是解决一个问题上的思维很有可能还是停留在早期的解决方案上，这也是我今天写这篇文章的初衷，想聊下最近工作中遇到的几个思维误区，我会谈一谈这些误区是怎么造成的，又该怎么去应对，只有这样我们的才能积累更多实际有价值的工作经验。

误区一：面对一个相似的问题，很容易直接先入为主

这个事情的经过是这样，有个很老的单体系统，前端的页面是由freemarker渲染出来的，早些年还在维护这个系统，那时候比较熟悉ftl语法。

最近这个系统出了点问题，于是又回过头去看模版，发现里面有这么一段可能有问题的代码

<#if x! == 1>
  isX = true;
<#else>
  isX = false;
</#if>

我的第一反应就是这个写法逻辑上有问题，为什么呢？是这么想的，第一个if后面跟着的! ==不是不等于比较吗？既然x不等于1，为什么最后还要给isX赋值为true呢？想到这里就已经陷入一个思维误区了，就开始想以前的人这么写这段代码，难道就没有发现有问题吗？如果有问题的话，怎么到现在才发现呢？

后面就想到很有可能这个isX变量最初赋值的地方是不是不对，所以判断这里不得已只能这么写，于是又开始找代码里给isX赋值的地方，找了大半天，还没有找到，这下整个人就陷入一个误区，可以说是死循环里面了。

就这样一来一去看着都过去2个多小时了，想想就算了吧，可还是不心甘，于是把这段话发给了同事让他看看，我问起他来有没有觉得这段话逻辑上有问题，结果人家回复说没有毛病，我就奇怪了，跟他聊了不等于这个逻辑，他的回复让我豁然开朗，这! ==就不是不等于!==,要知道不等里叹号和等于号之间是没有空格的，这里的叹号仅仅是告诉ftl模板这个变量可能不存在不要报错的意思。

想到这里，我才反应过来，我一开始就用前端的思维就固化这个情况了，另一方面也代表了本身我对不等于这个运算没有真正的去理解，除此之外，还应该先去了解下ftl里面叹号的语法作用，而不是掉到一个坑里面再也爬不出来，这就好比我们考试做题时，自己单方面觉得答题前后能够串联的起来，考完试以后一切感觉良好，其实一开始就已经错了。

后面该怎么处理类似的误区呢，我想还是得放下执念，抛弃一切的固化思想，及时从思维怪圈里跳出来，重新梳理已有的信息从头进行分析。

误区二：遇到疑难杂症，查询网上资料无果时，不妨先放一放

程序员这一行业最怕遇到底层问题，我们往往把它归类为疑难杂症，具体表现为按照正常的流程预期应该得到正确的结果，可是有时候就会出现由于种种外部因素导致在验证过程中出现了其它问题。

很多时候不是代码本身的原因，而是出在外部因素导致触发了底层基础的框架出现了问题，一般程序员都是开发上层应用，出现这类底层有关的问题就显的束手无策了。

这个时候我们一般会查询资料，大多数问题按照网上前辈老师的解决经历都能处理掉，但是也会偶尔遇到一些问题目前也没有一个解决方案，我这次就遇到了这么一个typescript编译器报错

The inferred type of X cannot be named without a reference to Y" . This is likely not portable. A type annotation is necessary.ts(2742)

对应的报错代码如下：

import {useState} from 'react';

export default () => {
  const [v, setV] = useState(0);

  return {
    v,
    setV
  }
}

这个问题出现的前提是使用了pnpm包管理器，一开始看到这个也摸不着头脑，因为一个模块的时候使用是不会有问题的，模块多了之后，这错误就出现了，网上好多解决方案都属于网友们的一些猜测，还没有看到官方的一些说明，总之，在我看来就是没有找到这问题背后的发生的根本原因。

于是，我便打算靠自己验证试试，前后来回捣鼓了差不多有一天的时间，验证了脑海中的无数猜测，可还是没有成功。这一来，无疑又陷入了上面提到的思维陷阱，花了很多的时间在解决一个问题上面，其实这个问题如果真的要安全解决，也不是不行，只需要在上面给导出的函数手动添加一个类型声明即可，但是一开始就是绕不过去这道坎，总觉得再花一点时间试试其它方案，总能解决的。

事后想起这件事，其实正确的做法是在花了1小时收集资料还没有结果的时候，就该将这个问题放一放了，因为本身这个问题还是有安全绕过去的办法的，因为程序员每天都有原先计划好的开发任务的，若是因为在这种事情上耽搁很多时间的话，必然会影响到原有的工作计划，那时候只能靠加班加点来追赶了，说不好还会影响进度出现任务延期，那时候就得不偿失了。其实可以先把这个问题统一收集起来，等到某个空闲时间，再回过头来看看怎么解决。

误区三：太过于注重系统后期的可维护性，而忽略了当下功能的实现

有经验或者资深的程序员在开发一个新项目的时候就会强调开发的时候要注意设计模式，后期维护性，底层框架搭建，开发统一标准等等，这样的理念的确是没有问题的，但是在目前市场经济情况下，谁先做出产品谁就可以说就能提早占领市场。

先不说上面提到的这些要求有多少人能够真正理解并贯彻下去，后期的维护也是一大难题。可以这么说吧，让你画一个简单的页面，一般人第一反应就是用原生的html+js+css来实现就行了，但是有些老师就不同意了，你这个不行啊，我们为了后期的升级维护，我们得上react、vue框架，殊不知用原生的开发首先不用引入多余的第三方框架资源，可以带来页面打开速度的提升，有些简单的功能最后可能就只用到了整个框架层百分之一的功能。

最近我就遇到了这么个情况，新项目里原先出于性能和代码整体统一性，对某些逻辑统一封装在了底层模块里，上层的所有功能统一由底层接收处理，再转发给上层组件，上层组件根据再根据实际情况按需进行处理。

一开始这种做法是按照我的计划成功实现了，后面发现还有更加复杂的逻辑，按照原来的设想，只要统一调整底框架层处理逻辑就行了，但是这次的复杂程度超出了原来的预期，上层逻辑也必须得跟着统一调整。到这个时候，我就回过头来想原来的在底层统一封装处理逻辑是否真的有必要了？

如果底层处理逻辑一开始存在是为了减轻后期维护的话，那现在发现与最初的初衷有了偏离，我就在想目前这个底层处理逻辑是不是可以暂时先去掉了，全部在上层组件各自处理各自的好了。想了想，马上行动起来，通过在上层组件单独来实现马上就把这个需求给搞定了。

总结

说了这么多心里话，无非就是想讲明白一件事，目前程序员开发看重的还是尽快交付需求，当然是在保证功能无误的前提下。

我们在每天在实现需求的过程中，总会遇到各种各样的问题，在解决了问题之后，它们就会成为我们工作路上的宝贵经验财富。

有些时候被问题卡住陷入思维怪圈的时候，我们不妨先把问题放一放，让大脑休息一会，待到它轻松之后再回过头来看看，在完成任务需求的前提下，哪怕是推翻之前的假设也好，尽快的给出实际可行的解决方案，这样我们才能按预期完成任务交付，在程序员这条开发路上走的更远。