如何写出让同事崩溃的代码

    个人网站：https://aijianli.site/ 可以免费在线制作简历，提供PDF下载，方便快捷。

    废话不多说，咱直接进入主题。手把手教你如何写出让帮你维护代码的同时瞬间崩溃的代码。

一、方法或变量名字随便取

    首先，让同事看不懂自己代码的第一步就是，想尽办法让他看不出来我定义的变量或者方法到底是干嘛用的。哎！对，就是让他去猜，哈哈哈。
来来来，空说没意思，举个栗子。

    假设现在想要点击某个input框时，显示一个自定义的组件用于选择选择时间。

    正常的写法如下：定义一个 toggleDatePicker 方法

    这个一看就知道是时间选择器的显示切换方法。

    但是呢，我偏不，定义成下面这样：让同事摸不着头脑，哈哈哈

当看到很多这样的方法名或变量名时，同事的表情估计时这样的。

接下来，第二招

二、方法体尽可能的长，长到不能在长

    这一步至关重要，将所有逻辑全部放在一个方法中写完，坚决不分步骤，不按逻辑一步步拆分方法。让同事为我的超长方法体感到叹为观止，默默流泪。

    老规矩，上栗子

    假设现在有个方法需要处理比较复杂（需要递归，而且每层数据有不同的类型）的json格式的数据回显到页面上（这是用于拼一些条件）。数据格式大概是这样的

[
    {
      type: "group",
      relation: "or",
      conditions: [
                {
                    type: "condition",
                    field: {
                      name: "员工状态",
                      id: 12345678
                    },
                    logic: "=",
                    val: 1,
                    relation: "and"
                 },
                 {
                    type: "condition",
                    field: {
                      name: "入职时间",
                      id: 12345678
                    },
                    logic: "<",
                    val: "2011-07-09",
                    relation: "and"
                }
            ]
        },
        {
          type: "condition",
          field: {
                    name: "入职时间",
                    id: 12345678
                },
          logic: "<",
          val: "2001-07-09",
          relation: "and"
    }
]

    由于上面的 json 数组格式中是一个对象，对象都有 type 属性，一种是 group 类型（表示是一组条件），一种是 condition 类型（表示是真正的条件内容）。

    因此，正常情况下，我们应该是遍历数组，不同的类型分别用不同的方法去处理，并且在处理条件中各个部分的时候分别处理。如下所示：

    但是呢？咱主题是啥，让同时崩溃啊，怎么能把方法拆成这样清晰的逻辑呢。

    来给你看看怎么让同事对你的代码叹为观止

    怎么样，牛不牛，一个方法写完所以逻辑，从1825行一口气写到2103行，足足… 2103 - 1825 是多少来着，3减5 不够，向前借位 ，嗯。。。278 行。
****怎么样，有没有被哥的机智震惊到，如此代码。同事看到肯定心生敬佩，连连称绝。此时想到得到同事应该是这样的表情

    同事还没进到方法体里面，就已经被我的 迷之方法名 和 超长方法体 所折服，接下来就让他在方法体里面快乐的遨游吧

    接下来，继续让同时崩溃。

三、坚决不定义统一的变量

    这个怎么说呢，就是因为有点懒，所有很多代码直接复制粘贴，多么的方便快捷。

    正常情况下，如果某个我们需要的对象在是其他对象的属性，并且层次很深，我们先定义一个变量来接收这个对象，再对这个对象操作。

例如：

let a = {
  b: {
    c: {
      d: {
        name: "我是最里面的对象"
      }
    }
  }
}

    我们要对d对象进行很多次的操作时，一般先将d赋值给一个变量，然后对变量操作。如下：

var dOfA = a.b.c.d;
dOfA.name = "我现在被赋值给dOfA ";
dOfA.data = 1;
dOfA.other = false;

    但是呢，我就不这么干，就是要写得整整齐齐

a.b.c.d.name = "就要这么干，你打我呀";
a.b.c.d.data = 1;
a.b.c.d.other = false;

    老规矩，没有 实际的 栗子 怎么能说的形象呢，上图

    正常写法：

    我偏要这么写

    多么的整齐划一，

    全场动作必须跟我整齐划一

    来左边儿 跟我一起画个龙

    在你右边儿 画一道彩虹

    来左边儿 跟我一起画彩虹…

    咋突然哼起歌来了，不对，咱是要整同事的，怎么能偏题。

    继续，此时同事应该是这个表情

    然后，方法体里面只有这么点东西怎么够玩，继续 come on

四、代码能复制就复制，坚决不提成公用的方法

    代码能 CV ，干嘛费劲封装成方法，而且这样不是显得我代码行数多吗？图片图片图片

    就是玩儿，就是不封装

    来，上栗子

    看到没有，相同的代码。我在 1411行 - 1428行 写了一遍， 后面要用，在1459行-1476行复制一遍

    这还不够？那我在1504-1521行再复制一遍

    这下，爽了吧，哈哈哈

    就是不提方法，就是玩儿，哎！ 有意思

    这个时候同事估计是这样的吧

    怎么样，是不是很绝？不不不，这算啥

    虽然以上这些会让看我代码的同事头疼，但是，只要我在公司，他们还会让我改啊。怎么能搞自己呢。

    最后一步

五、离职

    洋洋洒洒的写完代码，尽早离开。够不够绝，哈哈哈

六、申明：

    以上场景纯属个人虚构的，单纯为了给文章增加点乐趣。写这个文章的目的是让各位程序员兄弟尽量避免写这种难以维护的代码。真的太痛苦了！代码质量、代码重构真的是编程过程中很重要的一个步骤。不能抱着能用就行的心态。还是要对自己有一定的要求。只有你看得起自己的代码，别人才有可能看得起你的代码。加油吧！各位