漏需求这种比较不应该,很可能是一开始就没理解清楚需求,没分解好功能点,没做必要的各种情形的沙盘推演。
标题,格式,字体那种,从单纯开发的角度来说有点难发现,多做一些单元测试,多做换位思考,比如把自己换位成测试的角度来审视自己的产出,换成用户的角度来审视自己的产出, 尝试用TDD的方式开发,做checklist逐项检查之类的。
我看到好多进步慢的开发,大多是只能站在开发的角度想问题,不能去了解真实环境下会遇到的光怪陆离的情况,生活的空间跳不出IDE, 连生产上的log都分析不了,说个反面例子供参考。
要明白维护程序员的尊严靠的不是能写代码,而是你的产出物对别人有帮助,你的下游测试,运维,客户终端用户以及你自己的生活质量被你的产出物的质量影响很大。这样可以提升你的责任感。
没关系的,你自身问题肯定有,但不要太过焦虑了。马虎是天生的,但是管理方法可以改善。你看你越着急就更容易出错了,先静一下,放轻松。
我也是个天生很马虎的人,刚工作没几天就开行政大会要开除我,那段时间真是完全吃不下饭,晚上不想回家,也不想蹲公司,一边在大街上闲逛一边哭。后来我想明白了,这是因为缺乏自我管理,说白了还是自己的原因,但我们又是很急性子的人,所以会更焦虑。
慢慢改善,比瞎着急强多了。看一看管理、习惯养成的经验,慢慢来。
而且,你这种状态,很有可能是心理原因加剧的,你本来可以更稳一点的。加油。
作为一名贼粗心的人,命运使然做了前端。
代价就是,起初一年bug数在公司创新高(其中至少一半是前人遗产,我特么的。。。),之后慢慢有所好转。
如今工作两年半,bug的出现率直线下降,并不是我这个人变得细心了,而是这份工作更得心应手并且“稳重”了一些。
就我自己来说,还没做到bug数喜人的少的地步,只能说马马虎虎的数量,毕竟我也不是一个优秀的前端哇(假装哭唧唧,其实只是不想那么累没有那么没人性的努力)。多与产品和后端沟通,需求稍微有不清楚的或者文档写的不够清楚的,确认后再写,自测的时候再遛一遍文档。再加上我本人记性还可以,出过的bug下次再写的时候会有意去关注一下,避免出现以前出现过的bug。我们后端和产品都是很好的人,提测前会集体点一点,发现问题会互相告知,以此来减少测试小姐姐暴走的概率。其实就是职责互相分摊了一下,他人更容易发现自己写的的bug。
设计稿的话我们项目组已经抛弃设计师,嫌弃他们拖慢项目时间,其实就是用户夺命催,功能开发出来已经很难了(比如让我们半个月做一整套系统这种啥b要求),再去计较这个table的颜色一会要这个灰一会要那个灰(表示用户的电脑贼渣看起来根本就是乌突突一片说了无数遍设计不理啊)那个select的啥啥的基本不可能(用的antd,样式改起来很烦的,再加上设计团队给的所谓标准并不让客户满意,所以被我们团队直接舍弃)。于是前端说了算,全部都走的ant配置之后的样式,一切样式以开发方便+用户用着舒服+开发人员看着也舒服为基准。如此样式问题很少,而且经过一年多的摸索和讨论,我们前端团队已经弄出来了几乎一整套封装好的组件,功能和样式基本统一,不放飞自我的时候还是比较可控的。
再有就是从开发的角度上来说,组件化以及公用方法和hooks提取使用是一个减少bug的有效方法,只要统一,任何bug都是小意思。试错到一定程度,自然就是一个大致可以的成品了。仿照ts做一些propstype的限定也有用,可以避免一些乱七八糟的问题。
最后说一下,心态很重要。有bug不可怕,不要纠结也不要烦,有问题就解决问题(毕竟老子是被测试组约谈过的女汉子,心态真的太重要了),如果记忆力不好就养成写工作日记的习惯,将bug和解决方法都记下来。
秒开云-奥利给!