我现在写程序，那叫一个稳，基本上交上去的东西，自己心里就有数，不会半夜被电话叫起来抓虫子。但你们知道我以前多惨吗？那简直是 Bug 生产专业户，代码一运行，屏幕上红光闪闪，全是报错。
我记得刚入行那会儿，真是年轻气盛，觉得写程序就是个体力活，谁先写完谁牛逼。拿到需求，鼠标一甩，键盘噼里啪就敲起来了。结果？一个中型项目，我一个人愣是耗了三个礼拜，上线前夜，测试那边给我丢过来一张A4纸，上面密密麻麻写满了各种奇葩的错误。当时真是脑袋嗡的一下，感觉职业生涯都要结束了。更要命的是，很多错根本不是功能实现错了，而是我前面逻辑搭错了，后面所有代码都要推翻重写。
那次教训把我彻底打醒了。我花了好几天，把自己写代码的方式从头到尾扒了一遍。我发现，不是我技术不行，是我压根儿没养成好习惯。我发现那些真正厉害的大牛，他们写得慢，但是改得少。他们一开始就避免了那些低级的错误。现在我把这几年亲身实践、亲手摸索出来的三个习惯分享给你们，保证比那些书本上的理论管用多了。
习惯一：动手之前，先在纸上把路走一遍
以前我图省事，拿到需求文档，眼睛扫两下就开始敲代码。结果就是，写到一半发现逻辑死胡同了，这个变量跟那个变量对不上，整个结构都崩了。我不得不把写好的几百行代码全删掉，又重新来过，时间浪费了一倍不止。最亏的是，你重新写的时候，因为心里着急，又容易犯新的错误，简直就是个死循环。
现在我学乖了。接手任何一个任务，哪怕再小，我也强制自己先停下来十分钟。我找张白纸，拿支笔，把用户可能的操作路径、数据是怎么流动的、模块之间怎么沟通，用最丑的流程图画出来。就是那种方块、箭头，自己能看懂就行，不求多专业。我管这个叫“把路走一遍”。
别小看这十分钟的涂鸦，它能提前帮你发现 80% 的逻辑漏洞。因为你画的时候，大脑在整理思路，哪里有分支，哪里需要判断，你都提前想清楚了。等到你开始写代码的时候，大脑只需要负责翻译执行。这样一来，思路理顺了，代码自然就顺畅了，Bug 从源头上就少了一大截。我动手写代码前，起码先在纸上磨蹭半小时，磨蹭得越久，后面写得越快越稳。
习惯二：代码块一旦长了，立马给它“瘦身”
很多新手都喜欢把一个功能从头写到尾，一个函数几百行，里面套着七八个循环和条件判断。我以前就是这样。那时候看自己的代码，感觉像是在看一坨面条，绕来绕去，自己都不知道哪根是主线。
后来我发现，代码越长，越容易藏污纳垢。一旦出错了，你根本不知道是哪一行的问题。如果这个功能有十个小步骤，出了错，你得把这十个步骤全查一遍。这效率太低了，而且改错的时候，很容易影响到旁边的逻辑，引入新的Bug。
现在我的规矩很简单：我写着写着，如果发现一个函数超过了六七十行，我就立马停下来，找个理由把它拆开。一个功能只负责干一件事，比如说“验证用户身份”，那它就只负责验证，别让它同时去管“写入数据库”或者“生成日志”这些杂活。
我给这些拆出来的小块起个能一眼看懂的名字，然后把主要逻辑那里加上点大白话注释。注意，我写的注释不是解释“这段代码在干什么”，而是写“我为什么非要这么写”。比如，我会写“这里之所以要用这个临时变量，是因为后面要考虑兼容旧版本的数据结构”。这样等我过几个月再来看，或者同事接手的时候，就像有个人在旁边给我解释一样，逻辑清晰了，想植入Bug都难。
习惯三：写完一点点，就赶紧跑一跑
这是我以前最容易犯的错误，也是最浪费时间的坏习惯。我总觉得，我要一口气把整个功能写完，然后一次性编译运行，期待它能完美成功。结果往往是，编译倒是过了，但一运行就崩了，因为逻辑错了一堆，甚至一个小小的变量名写错了，我都找不到。
然后我就得从几百行代码里，一行一行地翻找那个微小的拼写错误或者逻辑反转。每次调试，我都要花费比写代码多两倍的时间，人也搞得焦躁不安，修好的时候往往已经半夜了。
现在我的做法彻底变了。我不再信任我的“一次成功”幻想。我写完一个小的步骤，哪怕只是实现了一个数据的输入，或者完成了一个简单的计算，我都要赶紧跑一下，确认它能正常工作，看到预期的结果，我才继续写下一步。这就叫“小步快跑，及时确认”。
这个习惯，说白了，就是让你随时发现错误，随时修理它。一个小的Bug，刚写出来的时候修它，可能只花三分钟；要是等到几百行代码堆上去之后再修，你可能得花三个小时。等你发现，咦，这段数据流有问题，马上就回去看刚写的那十几行，目标明确，几分钟就搞定。这笔账，我算是算明白了。避免 Bug 虫，真不是靠天赋，是靠这些笨办法，一点点积累出来的稳定。
