虽说开发者的日常工作离不开编码，但能够做到正视代码的，却并不多见，
我不敢说自己就是正视代码的那些人，
但有几个常见的对代码理解的误区，却值得跟大家探讨一下。
对代码造成误解，常常体现在以下几个方面，
（1）认为代码无所不能
（2）认为某种形式的代码不是代码
（3）认为代码越少越好
下面我们分别讨论，看看有没有似曾相识的感觉。
超能力
专长人才更喜欢用自己的专业去解决问题，这是毋庸置疑的。
但这同时也就衍生出了另外一个问题，
那就是，某些问题是否还存在非本专业的解决方案呢？
具体而言，软件开发过程中遇到的问题，是否全都适合用技术手段（代码）去解决呢？
这应该不尽然吧。
强行用技术手段去解决，可能造成危害，甚至走进死胡同。
首先，代码在理论上无法解决所有的问题，例如停机问题。
其次，在实践中，与人相关的问题，也不太适合用代码去解决。
比如，为了证明代码完全没有问题，我想通过写另外的一些代码证明一下，
这种想法看起来很简单，但几乎是很难实现的。
理论上，我们只能证明某些代码不存在某类问题，而无法对任意代码排除所有的问题。
再比如，为了避免遭受接口变更的影响，我们再写一个系统来监控接口的变更吧，
我觉得这么做几乎完全没有必要，
因为这本来就应当是软件研发流程的问题，缺乏接口变更流程才是问题所在。
认为代码无所不能，不只是浪费精力这么简单，
更重要的则是，让我们忽视了问题的非技术性特点。
很可能舍近而求远，缘木而求鱼。
给我的启示是，在考虑技术方案的同时，不妨多问自己一句，
是不是自己对代码过于自信了，不写代码有没有更高效的解决方案？
代码形态
代码说白了其实就是一段文本，编码了一些信息进去。
有很多情况下，我们觉得不是代码的 “东西”，其实也是代码。
（1）配置
配置就是代码。
从编码的角度来看，配置应当跟代码是平权的，
唯一不同的是，所谓的 “配置” 和 “代码”，经历了不同的解码过程。
能用代码来表示的，其实无需再发明一种配置语言，让用户配它了。
不要以 “安全性” 作为挡箭牌。
对于用户行为的安全性，我这里有个不一样的观点，
有些人可能认为，系统有权提供足够高的安全性，让用户无论如何都不会搞错。
我却偏偏认为，但凡涉及编码的用户行为，其正确性都应该交给编码者来保证。
稍微复杂一点的编码，都无法通过其他代码来证明它没有问题。
所以，除非你有能力证明 “配置” 的正确性，否则还不如让用户直接写 “代码”。
（2）数据
代码可以作为数据，输入给其他代码。
所以，代码跟数据，其实本质上也没啥不同的，不应该严格区分。
编译器以用户代码作为输入，转换成了目标平台的机器码，
很多语言的预编译功能，会对用户代码进行预处理，编译器看到的也不是我们写的那些代码了。
所以代码作为数据来看，其实完全没有任何问题。
理解了这一点之后，我们就能写出具备超高表现力的代码来。
有些业务逻辑实在是太复杂了，把它封装成一段 “代码”，往往会是神来之笔。
举一个例子，如果我们想找到页面中所有的超链接，常用的办法是，
1 | document.querySelectorAll('a[href]') |
a[href] 是啥意思？
指的是 HTML 元素中，标签为 <a>，且具有 href 属性的元素 <a href="...">。
document.querySelectorAll 接受了一段字符串（代码），作为输入，
返回了所有的满足这个条件的超链接。
如果不这么做，我们就只能自己遍历整个 HTML DOM 树了，过程会更麻烦。
所以，我们自己能发明一些 “字符串” 或 “代码”，然后当做 “数据” 来传入吗？
少写代码
少写代码其实是有助益的，因为写的越少，就表示需要测试的也越少。
更少的代码，也更好维护，想想看到几万行代码，和简短几行代码的感受，肯定是不同的。
但是，有些场景下并不是代码少就完事了。
这是因为业务逻辑被编码到了非文本形式中，测试起来可能会更难。
因此，我们需要测试的是业务逻辑，而不是代码。
一个常见的例子是，拖拽生成页面，
用户确实能只通过拖拽就把页面给搭建出来，甚至把某些业务逻辑也 “拖” 出来，
但请留意，这些 “拖拽行为” 如何进行测试呢？
“拖拽” 是不是一种编码行为？
我认为是的。
不论 “拖拽” 对信息的编码结果是什么，是数据库中的数据，还是中间语言，
对逻辑进行测试，仍然是逃不过的一个环节。
我们怎样保证自己 “拖拽” 出来的页面是正确的呢？
除此之外，当我们调整拖拽结果并点击提交之后，
有人会意识到，这是一次发布行为吗？
因此，非文本形式的 “编码”，可能会因为它没有留下代码，而对 “开发者” 产生误导。
使得它们发布未经严格测试的软件功能。
从这一点上来看，少写代码可能并不是一个特别好的主意，
结语
本文介绍了自己从业以来遇到了一些代码认知误区，有些反例具有强烈的偏见，
目的是为了说明在某些场景下频繁出现的一些问题。
但这并不是在说文中提到的解决方案就一定是错的，
只是说，方案总有利有弊，需要深思熟虑。
得多问自己几个问题。
能够做到正视代码，才会把代码写的恰到好处，
不贪功，不鄙视，不迷信。
但即使认识到了以上所有的误区，我们每个人都还有很大的进步空间，
保持开放的心态，多听听别人的看法总是有益的。