Excellence in any department can be attained only by the labor of a lifetime;it is not to be purchased at a lesser price
Paul Graham
前段时间, 看新闻说“微软4万多的软件开发工程师, 每天产生进3万个BUG”, 当时感觉有点震惊, 然后就哑然失笑. 震惊的是连微软这样厉害的公司, 工程师应该都很优秀, 人才济济, 为何却会每天产生这么多的BUG了? 于是,再想想自己的开发经历, 才恍然明白: 开发人员一旦走进办公室,打开电脑写代码, 就不可避免的要写出BUG来. 与BUG纠缠不清似乎是每个开发人员的宿命.恰逢最近遇到了一个BUG, 让我纠结不已, 痛定思痛, 觉得有必要把自己的开发”心得经验”写下来, 权当是给自己一点警醒, 给自己一点回顾的资料, 分享下自己在开发过程中遇到的困难与挫折, 苦恼与迷惑.
- 对业务理解的越深, 你对可能发生的问题就越透彻；认真思考每个需求/每行代码背后蕴含的业务逻辑, 这对于实现更优秀的方案具有重要的作用. 要对你所负责的业务领域的知识有广泛的把握, 这样也能够帮助你快速深入的进入一个全新的领域.
- 对于要提交的每个PR(Pull Request), 在提交前自己先过一遍, 检查格式, 检查拼写, 检查PR的描述是否清晰简单明确, 检查功能实现是否与需求一致, 同时还要问问自己这个修改是否有可以优化改进的地方, 是否存在更好的解决策略? 是否有疏漏的地方? 只有完整的走了必须的checklist, 才真正加上代码reviewer.
- 在每次实现方案, 提交代码时, 首先要摒弃的是”这个实现很完美, 我敢打包票, 毫无疑问没有问题了”类似这种自信爆棚的观念, 首先要正视可能存在的缺陷, 正视自己当前对于问题的认知可能还有不完善的地方, 把可能存在漏洞的地方在代码实现处comment出来, 这样后面再来看代码时可能会有更好的思路.
- 现代软件项目开发的核心在于高质量且如期交付产品, 而要确保高质量与项目日程预期的达成, 核心在于管控软件开发中的风险点. 因此, 对于大部分公司开发软件来说, 都要有质量/测试/开发多个部门的通力合作才能达成这一目标.对与软件开发工程师而言, 在确保自己提交代码的质量, 减少BUG的数量的同时, 还要关注项目日程安排, 确保修改正常合入到正确的分支, 确保给到用户都是稳定可靠/BUG更少的版本.时刻铭记交付质量对于一个优秀工程师来说至关重要.
- 产生的任何BUG都要保持警惕, 而不是防御心态: 总觉得这个BUG不是我的责任, 不会是我代码实现产生的问题, 当别人指出来你的错误时, 不是保持开放的思考, 而是一味的浪费时间与人纠缠争吵, 不敢承认自己思维上存在的问题; 一旦确认了BUG, 就要坦然面对, 而不是藏着掩着;诚实的面对自己犯下的错误, 总结经验教训, 这不仅能让你赢得同事的认可与信任, 也能让领导对你放心.
- 不时的想一想你的客户是谁? 你的客户不仅是产品的使用者, 也是你的上司, 你的同事, 你要确保你的每个产出物都具备高质量, 能让使用者感到舒服, 感到可信赖.要对自己所做的每件事情都负责, 对上司交代的任务要反馈; 对同事的问题要多关心;对产品的质量要严格的把控.
- 不满足于已有的知识, 不停的学习新的技能, 反复总结打磨自己的知识系统, 长此以往, 你的能力与视野就会得到质的改变；学习的同时, 也要不断的总结, 将所学所思分享给身边的同事, 保持影响力
- 软件从业人员经常被工作进度压得传不过气来, 时间紧张, 以至于忽略了锻炼身体. 想要平时尽量产生BUG, 保持良好的生活习惯, 必不可少. 这么看起来, 写好代码, 少产生BUG, 不仅仅是一个逻辑问题, 更是一个程序员自我修养与提高的问题
- 养成良好的工作习惯: 不时的总结些提升工作效率的方法, 比如修改分支代码时, 先同步远端代码
git pull --rebase; 修改好的代码要及时保存; 重要的数据要做好备份; 及时的梳理知识结构, 有时间最好将心得总结写下来 - 遵从项目流程，即便是日程紧急，也要遵守项目规范，确保发出的版本是可靠稳定的;定期发布版本，每个版本都要有对应的release分支(*_*笑，最近我们有个项目自始至终都只有一个dev分支，项目后期风险不断，时不时的掉坑里）