关于代码的病 有解吗?

[shazh520]

• 每天写的代码最后提交的时候都会一行一行的仔细看;
• 从来不用之前的项目修修改改就用于新项目,觉得自己不熟悉的代码肯定隐藏了很多 bug;
• 对自己的代码没有信心,即使功能跑通,经过很多测试没有发现 bug(自己测的),依然需要一行一行的检查之后才稍微有点底,甚至要检查好几遍;
• 跟技术不好或者对代码不上心的同事合作项目总是心里不踏实;

我的同事都是说代码功能正常,你有什么理由怀疑它不对呢? 我感觉就好像代码会隔一段时间就不一样了亦或者代码执行一段时间就会产生 bug 一样;不断的检查已经给我造成了很大的心理负担;

v 友们怎么看?

[CeresLC]

楼主和我一样，不过我现在都随缘了，出了 bug 大不了改呗。

[laravel]

为什么写代码，写着写着就不自觉地打开了 youtube，甚至 pornhub

[esolve]

你这个效率，年终奖还有？

[herotiga]

@laravel 哈哈哈哈兄弟，你这回复太牛逼了

[Caijl]

你这是对自己太苛刻了

[youxiachai]

单元测试,费时间..其实很正常啊...毕竟你要写那么多 case..不过这些 case 也就写一遍,其实,还是蛮有价值的...

[xiangyuecn]

@maichael #1 我跟楼主这种几乎完全一样😂 经常好几百行源码，4 5 个文件一次性写完，一次性跑通，小问题会有一些，大问题很少，不过很少写测试代码，修改代码提交也是一行行仔细看。包括别人写的代码也经常全部看一遍，应该算是病的不轻了😂😂

[libook]

一方面，开发过程要有可靠的 Code review、DevOps 和 QA，可以大幅提升团队的安全感。
另一方面不要怕 bug，要勇于直面 bug，从 bug 上总结经验教训，找到合理的方案来避免以后出现相同的 bug，方案不限于合理化代码结构、总结编码原则、养成好的上线习惯等等。举个例子，我们团队规定每周五不上线，其他工作日每天下午 5 点后不上线，避免上线后出问题赶上下班或休息，以及避免问题在高峰期出现，上线尽量在用户活跃少且开发和测试人力充足的时候。再举个例子写代码尽量不要用“懒返回”风格，即避免用 return 机制可以直接跳出代码块的特性来替代 if/else 机制，逻辑上是 if/else 就严格按照 if/else/else if 来写，这样能避免很多因为偷懒导致的逻辑不严谨的问题。

如果过于焦虑以至于影响工作和生活了，那建议去医院看看会不会是轻度焦虑症。

[KentY]

逐行审视自己做的修改是对的. 就像你做个东西, 起码自己满意了再提交给别人 review, 甚至业务人员测试. 当自己都不确定是不是自己最满意的东西, 拿给别人, 再反复 pingpang, 只能说明自己不认真.

这样当自己最满意的东西被别人找出问题, 而且不是吹毛求疵那种, 才会真正学到东西.

剩下的, 应该有测试, 不光 unittest, 还应该有自动化的 integration test.

[LancerEvo]

我觉楼主的习惯是好事
你得把自己的项目当作是在造火箭一样小心才能做出精品

[encro]

代码能力不足，或者逻辑不清晰，是写代码大忌，不能写出明显没有 BUG 的代码。

试试伪代码编程，先用伪代码（注释）实现一遍，然后用代码填空，这样逻辑如果没有错误，就只剩下语法错误了，而语法错误，IDE 和类型限制基本上可以帮你排除。

注意伪代码不是解释你在做什么(what)，而是为什么这么做(why)！

以下代码很难出错吧？

function 计算订单总价(订单商品){
// 遍历计算商品价格(单价*数量)
// 计算优惠金额（满 100-50 ）
// 计算运费（优惠后金额金额少于 100 元按 6 元，大于 100 免运费）
// 订单总价：商品价格 - 优惠金额 + 运费
}

[aristotll]

不写测试的评论居然有三个赞。。。

[Xbluer]

@aristotll #72 反过来想：还好，目前只有三个。。。

[liuxingbaoyu]

我跟楼主相反.....
从来不写测试，能跑就行
现在正在尝试以后多点自检

[Johnny168]

如果你去做测试，信不信会被开发打死

[EscYezi]

我希望同事都有楼主这么认真，然后也能被迫保持代码整洁。现在的项目里面遗留代码太多，又不能从头做起，为了能用上之前的东西，感觉自己写的代码都快成面条了……

[cedoo22]

@wangxiaoaer 单元测试手动造数据就会造成黑盒 变成白盒， 我更习惯写一个生产随机数据的工厂。。。。会解决 95%以上的 BUG

[miv]

说一点我的体会。之前我也有类似楼主的心情：1，感觉自己代码写的烂，病怏怏的。2，总担心自己代码会出问题。
后面，看了一些改善代码风格的数据以后，意料之外的是这种对代码没信心的心态降低了。
这真出乎我的意料。
后来我想到几个点：代码分格改善了，可读性大大提高，方法只做一件事，合理抽取公共特点，合理封装等等。
这些情况，让逻辑清晰了，bug 减少了，扩展性加强了，维护容易了。

[prenwang]

不反对， 特别是精简的 python 代码，肉眼就能扫一遍有没有问题， 通常大部分代码都是写完一次性就运行通过，不像初期老是改。个人项目练就一双火眼更有用。

如果是多人协作，团队项目，单元测试更可靠。

[Deepseafish]

有点强迫症状了，属于心理问题，就像出门担心门没锁，提交手机号身份证等资料来回反复检查好几遍都不放心。