关于代码的病 有解吗?

所以……你不写测试的吗

一行一行检查是一个好习惯...

@maichael 我是做 java 后端的嘛, 之前用 junit 写测试, 但是到后来发现写测试需要花太多的时间维护就没坚持了

@Guaidaodl 但是检查了之后还是会对自己写的代码不信任, 感觉就很...

@shazh520 #3 你这些问题都能通过写测试解决。

@maichael 回想一下, 好像是哎, 之前写测试的时候虽然写测试的时间比业务代码时间还要多很多, 但是看着 n 多测试用例亮绿灯就感觉很踏实

感觉不是代码的问题了，你疑心太重了，或者说对自己的产出要求太高。
再别的事情上（需要你用心的事情）也会这样吗？

自己的代码自己做单元测试就是脱裤子放屁。

我不反对单元测试，但是我觉得单元测试应该是一个独立的岗位，跟开发分开才有意义。

这是病，得治，也有得治，如一楼所说，TDD 啊

需要一个女朋友吸引你的注意力.从而达到缓解病症的效果

@zw1one 对于其他事情没有这种情况, 就是关于软件这一块这种现象特别严重; 我主力机的系统每一两个月我就要重装一次, 软件只从官网上下载, 付费软件要么买正版, 要么买激活码;

就像你每天走出了单元楼还会担心自己有没有锁上门; 这是病

@wangxiaoaer 其实我对自己写的单元测试的看法是可以让自己放心的重构代码吧; 保证代码正确性可能确实有局限的地方;

我改了一行代码，到生产回家地铁上总是不断回想有没有问题，甚至想回去在看一遍

@luchenwei9266 女朋友这么厉害吗

@chickenJuicer 可是我总是记得我出门到底有没有关门, 很放心^_^; 就是不放心代码, 郁闷了; 汗!!

@wuwukai007 有点意思, 有点意思, 难道是病友?

OCD 得治

@shazh520 官网下软件没毛病，但是一两个月就重装系统干嘛啊，感觉有点强迫症了。我之前也对这些要求很高，直到后来加班治好了我的这毛病。

有点强迫症，按能让自己放心的方式来，如果怎么都无法放心，就该看医生了
代码让你受过伤吗？

#19 说的很对

这种好员工给我来一打

@chickenJuicer 戳中，每次我都怀疑没锁门，还得半路回去确认一下

@ddzzhen 没有, 就是感觉代码如果不完美的话心里很不爽

你们可以改用 rust 了，一般不用测试 （狗头

@zw1one 喜欢非常纯净的系统, 感觉好像刚刚抹盘重装的系统自己能够完全掌控一样; 文件整整齐齐, 软件只安装了自己需要的, 而且是正规渠道安装的;

@shazh520 你试试嘛~

@leafre 一看就是资本家 ^_^

@araraloren 据说 Java 是世界上最好的语言-_-

@shazh520 完美主义人格，可以写个工具，不断优化，最终实现完美自动化测试

楼主可以轻松点：bug 很可能是存在的，很多大公司的产品也有 bug 嘛，所以不用执着哈。

这是强迫症吧。。。 检查是个好习惯，但是过头了就浪费时间了。

再说了，检查多了也没有意义，高考的时候给你检查几十遍你也看不出自己的错误。

症状比楼主轻，但基本都有吻合。
个人认为是强迫症太严重了…

上学时会一直检查答题卡是不是涂错格子了，一场英语考试下来能检查好几遍。强迫症太揪心了。
抱着出 bug 我再修的心态，可能会有帮助。

测试是测试 开发是开发（开发兼测试工程师？哈哈哈

@fancy111 希望我能够早日康复吧 哈哈

@icyluna 你现在有没有治愈

@liuzhiyong 感谢 学着接受不完美

@liquid207 尝试一下 尝试一下

你需要结对编程

@pipixia 牛批 我百度了一下, 触及盲区了

建议转行测试，发挥自己的优势

@xianxiaobo 角度特别, 耳目一新 甚至有点想看看测试岗的招聘需求

检查代码是好习惯,测试请面向接口测试而不是白盒测试

有点强迫症哦~ 得治。。放宽心

难度你们部门没有测试人员？

@saltedFish666 没有 目前供职的公司 10 人不到

@shazh520 #48 单元测试百利无一害 赶紧补起来

测试都不写就没什么好说的了。
开发的时候，你怎么知道写得对不对？不写测试那就要手工跑，你把这个手工的过程，写成代码，就成了测试了。连这个都不做，那是非常差劲的。如果说整个系统难以让你方便地写测试，那就是系统差劲，赶紧换个环境吧。

像是处女座

这些倾向都是好的，但解的方法不大对，靠手工去降低自己的不安感是有极限的，除非你不做人了
所以多想想哪些自动化、哪些工具能降低这种不安感，往这个方向走更有成长

@otakustay 探索一下

@charleyking 就是

谨慎是好事。
但谨慎也是负担。
过度谨慎也是过度负担。
但话说回来，负担是有上限的，因为你的精力有限，deadline 也有限。而且长期来看，可以通过水平提升来提升自信，通过方法论来降低成本，从而降低负担。
而谨慎性格本身却是非常难修炼、改变的。

所以综合来说，你这是好事啊。。。自带优异属性，额外成本又可以通过后天努力来消除。
相比那些缺乏严谨思维做事毛毛糙糙的程序员来说，先进到不知道哪里去了！隔壁老板和技术经理都馋哭了！

适当做单测
感觉你跟我很像，我也是，从来不用之前的项目修修改改就用于新项目。
不要成为一种负担，这是有责任心的体现

TDD 了解下 LZ

……这个我的心理很像，哪怕是测试过了，上生产了也会时不时有这样的疑虑。
然后做一下模块开发的时候一直会想这个是不是有一个比较成熟的“最佳实践”是我没有想到或者找到参考的？我的代码只是纯粹实现了功能，而没有做好更多的扩展性，安全性和性能的考虑。

楼主是不是吃过亏啊 /滑稽

敏捷开发流水线了解一下
CI -> 静态检查 -> 编译 -> CR -> 单测 -> 功能测试 -> 回归测试 -> 打包 -> 沙盒部署 -> 小流量上线 -> 全流量上线 -> 回滚 =。=
楼主其实考虑的是软件工程能力

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

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

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

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

你这是对自己太苛刻了

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

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

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

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

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

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

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

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

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

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

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

以下代码很难出错吧？

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

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

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

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

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

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

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

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

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

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

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

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

我也是一行一行提交的

还是要写测试，我相信有代码的地方就会有 bug，即使是修改一行代码一个变量也会有意想不到的事情发生。这种情况尤项目本身是受东侧起来很麻烦的那种，没测试真的没法做。

我没有你这么严重的病，只是我写代码喜欢所写所见，也就是写一行调试一行，确实输出符合自己的预期之后才会写另外一行，也就是俗称的面向过程。

TDD 能治好你的病

太多了回复不过来了 受益良多 感谢大家

@flyingghost 突然感觉好多了, 哈哈; 谢谢

@Takamine 关于最佳实践很有同感 ^_^

@qza1212 一直都很向往工程化的这些东西, 希望明天可以找到一个很棒的团队一起实践

@LancerEvo 看到你的回复就绷不住了 {笑哭}

@encro 这种方法我在逻辑有点复杂的模板方法里会用, 但是平常大多数的场景我没有实践过;

@Johnny168 #75 我现在帮忙测同事的项目已经快被吐槽死了

习惯挺好的。
不过楼主你要知道你用的编译器也是有 bug 和坑的（笑），所以不要太吹毛求疵啦，太严重了反而影响工作效率(￣ω￣ｏ)

@EscYezi #76 深有同感, 维护老项目的时候只能尽量的保证每一次提交都比检出的时候代码更好一点, 一些没法儿优化的缠在一起的代码真的感觉难受

@vanishcode 这个角度就新颖了 ^ __ ^

@miv #81 我也看了相关的资料呀, 实践下来感觉每好太多, 郁闷了;

这不是病，这就是能力差不会写代码，包括楼上那些说测试没用或者不写测试的。

首先你需要一个好的 ide，inspection 全绿能有效的屏蔽低级错误，改善代码风格。
然后你需要证明自己写的代码是是符合预期的，并且每次关键提交都要再自证一遍，如果能做到这个程度，考虑开始自动化测试就是自然而然的。

@wangxiaoaer 问题是，你找不到愿意干这个岗位，并且水平足够的人

同感，强迫症，些许健忘，注意身体和心态的调节

测试驱动开发（ TDD ）的艺术 http://e.dangdang.com/products/1900703930.html