如何编写逼死强迫症的代码

前言

小张是个程序猿，工作有一段时间了，对外一直宣称自己是电脑维修管理员，他有一个毕生追求，那就是像搞艺术一样去写代码，有强迫症的他，一直在思考如何写出给人类阅读的代码，经过不断的摸索，他总结了以下几点

我全都要

众所周知，变量命名一直是世纪难题之一，小张年年绩效垫底的原因就是每次都要在取名上花太多的时间，导致别人都开发完 5 个需求了，小张才完成 1 个，直到有一天，小张痛并思痛，他想出了一种命名方式，完美提效，他取名为 “我全都要”。
小张一直想不明白，为什么常量要用全大写，一些专用业务名称不能用拼音，有大写，有小写，有驼峰，有下划线，名字不过是个代号，真的有那么重要吗？小张要打破规则

1	const Wode_NAMe_$haiXiNg = '?';

小孩子才做选择，小张选择我都要，别人告诉小张要学会融会贯通，不要在没有意义的地方浪费太多时间，小张他做到了！！！

大丈夫能屈能伸

众所周知，代码缩进也是世纪难题之一，是 Space，还是 Tab, 这是一个问题，世纪难题为什么这么多？小张为身在这个世界感到悲哀，即然不知道，那么就不缩进

1	const bUSuoJiin=()=>{if(tRue){console.log('tRue');}else{console.log('falSe');}};

小张满意的笑了，既节省了空间，也提升了代码的执行效率，V8 表示说真的我真的哭死！

抱团取暖

小张翻看同事代码，真的气不打一出来：

css 不写在一行提升浏览器执行效率
一个垂直居中代码，竟然要用 place-items 这种简写，晦涩难懂，align-items 和 justify-items 都写出来有这么难吗？妥妥的为了炫技
js 模块引入和样式之间还有空一行，白白浪费空间，按照成都的房价来说，四舍五入浪费了一个亿

// style.css
.center {
  display: flex;
  place-items: center;
}

import React from 'react';
import A from 'a';
import B from 'b';
import C from 'c';

import './style.css';

经过一番修改，小张满意的笑了，这才是一个高级开发工程师应有的水平

// style.css
.center {
  display: flex;
  align-items: center;
  jusitify-items: center;
}

import ReAct from 'react';
import _A from 'a';
import './style.css';
import B_ from 'b';
import _C_ from 'c';

每一个 css 秩序井然的排列在一起，一副团结有序的样子，模块引入中，样式文件混入其中，深藏功与名。

注重隐私

如今这个社会，作为社畜，生活的方方面面都被窥探，毫无隐私可言，小张也愈发觉得，作为最后的底线，他要在日常编码中捍卫自己的隐私权，他将同事的代码删掉

1 2	const DURATION = 200; const MAX_LIMIT = 3;

改成了这样，每个数字都是独立的个体，应该享有它自己的隐私权，它表示什么含义，此刻已经不重要了。

if (a===3) {
} else if (a===98) {
} else (a+68+82+23.2===666.2) {
}

相亲相爱一家人

人多力量大，团结的力量不容小觑，聚是一团火，散是一坨屎，代码也是如此，将每种类型的代码分门别类显然是最低级的程序猿才能干出来的事情，小张他打破了常规

// file.tsx

enum A{}
export const a=()=>{}
const _ConST={
_ConST1=""
}
const iCoN="aWNvbg=="

...

// L999999
export type WoShiTYPe = '?'

深夜两点半，小张写下了今天最后一行代码，一看代码行数来到了 999999 行，他得意的笑了，突然觉得好有成就感，接近百万级行代码的巨型项目，在他的手上完美运行，所有的类型定义，静态文件，常量，函数都在同一个文件里面井井有条的排列着，这哪里是代码，分明是一直训练有素的军队！同事问小张问他为什么文件名后缀是 .tsx, 但是却不是 React 组件，小张说道：隐射大于一切，最简单的伪装，往往是最有效的。

别让他人替你做决定

大家都是成年人，不要让别人替你做决定，做个低幼巨婴，说的就是你们：ESlint, Prettier, 小张如是说道，这些工具总是自作主张的将你辛辛苦苦编写的代码，按照它们喜欢的方式进行修改，格式化，比如将

1
2
3

const _ConST = {
  _ConST1 = '',
};

格式化为

1
2
3

const _ConST = {
  _ConST1 = '',
};

这实在是太荒谬了，一个合格的程序猿怎么能让工具替你做决定？于是小张关掉了 VSCode 所有的相关配置，高效人士的 7 个习惯又多了一个

"editor.codeActionsOnSave": {
  "source.fixAll.eslint": false,
  "source.fixAll.stylelint": false,
  "source.fixAll.markdownlint": false,
  "source.organizeImports": false
},
"editor.formatOnSave": false,
"source.organizeImports": false,

最可气的是，小张发现项目中配置了很多 lint-staged, pre-commit, commit-msg 等检测，每次提交代码都提交不上去，说好的自由民主呢？

1 2	git commit -m "fix1" git commit -m "tiJiaoWentI"

还好小张是一个高级程序猿，熟练掌握 Git 的使用，优雅的使用 -f 提交代码

1	git push -f

避免干扰

小张觉得像 Code Spell Checker, Error Lens，彩虹括号，ESLint, TypeScript 这类的工具，除了造成干扰，降低编码效率，以外没有任何作用

更别提什么 TypeScript 了，听说同事用它成为了 体操运动员，正考虑去参加国家队比赛，小张觉得太过于鸡肋，多花时间写类型，还不如多花点时间做点需求，好得到好绩效，最后都会被编译为 JavaScript，写类型的意义在哪里？

只有做到心如止水，才能写出优雅的代码，去掉这些鸡肋的插件和工具，化繁为简才是正解。于是他决定开始使用记事本

灵活复用

经过不断的摸爬滚打，小张愈发的得到老板的重视，其中一个原因就是做需求快，天下需求，为快不破，别人每次排期都是少则一个月，但是小张每次都能给出比别人时间少的排期，而且还主动加班到深夜，老板很喜欢他，同事问他怎么做到的，他说：
“你们每次做需求都是各种封装组件，减少代码重复度，又是各种抽象，各种解耦，实在是在过低效了，技术是给业务服务的，一个字，快，快就完事了，我每次做需求都是把以前的代码直接 Ctrl+c/v 复制一份，随便一改，完美复用”
经过小张的一番讲解，同事们都悟了，什么 Ant Design, Element UI 都是锤子，有我直接复制粘贴巴适？

1	复制粘贴才是最好的复用 - 鲁迅；

自由发挥

FreeStyle 是否厉害不能评价一个说唱歌手的好坏，但是适用于程序猿，小张做需求最讨厌的就是参考需求文档和设计稿，需求文档写了和没写一样，有什么参考价值，想象力是不能被扼杀的，小张遇到不能理解的需求细节时，不喜欢和产品经理讨论，作为高级程序猿，他更喜欢自由发挥，研发也需要有产品思维，这是老板时常对小张的教诲，小张牢记在心，并付诸实践

结语

作为高级程序猿的小张，今天被通知 毕业了，他收拾了东西，包括那本被他用来垫显示器的《重构》，没了收入，但是难不倒作为高级程序猿的他，开始搬运各种开源项目的官方文档，编写了《你不知道的 React 100 个 API》, 《antd 的 Button 组件使用详解》等热门文章，阅读量甚至超过了官方文档。
但小张很是懊恼，想不通自己为啥被裁，公司用代码量来评价一个程序猿的好坏，小张觉得自己要开发效率，有开发效率，要代码量，有代码量，要产品思维，有产品思维，想了一个晚上，小张还是不明白比别人差在哪里？

你能告诉小张吗？

PS：（以上内容纯属娱乐调侃，请勿当真）

参考链接

MDN place-items
如何向开源项目提交无法解答的问题
 怎么写 Bug

李金珂的小屋