今天，在寻找一段代码的问题时，遇到了一个低级错误：
// 正确
jobElement.style.width = 'calc(' + d * 100 + '% + ' + d + 'px)'
// 错误
jobElement.style.width = 'calc(' + d * 100 + '% +' + d + 'px)'
正确与错误只相差一个空格，在发现这个空格以前，我猜测了很多可能。比如，
const/let 使用不当、名称拼写不对等。这一次又认识到一个新的低级错误。
从开始找到确定是空格的问题，花了一个小时。效率不是很高。为什么会出现这种错误？在照着源代码输入的时候并没有在意这一细节。直到发现我的页面和原始页面有区别时，我才注意到这一点，当时的确是定位这个元素了，发现原始页面上有对应的宽度样式，而我的页面没有；这时并没有想到，直接去看这段代码有什么问题，而是直接选择最费力的方式——将原始代码和我的代码进行一一比对，进行调查。尽管找到问题所在，但是这种解决方式并不可取。
下一次再遇到低级错误，应该第一时间根据日志或者调试信息定位问题出现位置。另外，在确定问题位置过程中要沉住气，不能着急。
我前几天读到 tinyfool 的文章《程序员的成长从开窍开始系列 一、如何摆脱低级错误的困扰》时就开始思考如何摆脱低级错误。
遇到问题（不光是这些低级问题）时：
- 不要把问题向外推脱 。出了问题，有可能是系统 bug、API 调用问题，但是这些问题出现的几率比你犯低级错误的几率要低得多，先从自己身上找原因。这一点我做得不错。
- 要掌握工具 。最低限度是会 log，最好是 log 和调试器结合。在
JavaScript 调试方面，还只会用
console.log。 - 分析问题要有逻辑 。遇到问题先把所有的可能性都列举出来，然后一个一个地分析，肯定能找到原因。这一点我还做得不够好，一看到问题，就想着把代码从头到尾全部梳理一遍，代码量小的时候能做到，但代码量大的话就很吃力了。
- 要学会隔离问题 。问题涉及到的代码越多，越难以理解，问题越难以解决。遇到此类情况，可以利用 log 或调试器，将代码一行一行地进行筛选，洗清嫌疑，这样可以很快找到问题出现的地方。如果代码特别长，程序特别复杂，可以用二分法来做，效率很高。这一点我没想过。
- 千万不要懒惰，不要事事求别人 。
要想不遇到问题，写代码的时候：
- 要对写出来的代码负责 。作者写程序是写一两行执行一次，确定没问题后，继续。这样最开始可能很慢，但整体速度要比那些彻底写完再运行调试的人的效率更高。每写一两行停下来，思考代码，能够让自己对例子有更多理解。
- 函数体/功能块不要过长 。作者认为如果一个程序的一个函数体或功能块超过 3 屏，就变得很难阅读。
- 缩进要对 。
- 不断重构 。