程序员往往渴望加入一个“30%的时间写代码，70%的时间喝咖啡讨论如何把产品做得更好”的团队.软件工作应该成为技术与艺术相结合的高智力活动，项目经理应该是了解质量、范围、进度等客观规律的人。“高效工作，快乐生活”应该是程序员的座右铭。但现实是，团队在修复无休止的错误时被要求超负荷。前一天晚上，项目经理红着眼睛盯着我们加班通宵，质量专员一遍又一遍地催促质量数据。软件工作已经无可挽回地沦为体力劳动，更谈不上幸福的生活了，命没了。好吧，以上所有可能都是正确的。项目经理和质量专员都是大魔头，不懂客观规律，没有同情心，让我们程序员活得没有尊严，受人鄙视。只是有一句话憋了很久：“醒醒，这一切都是因为你的代码太烂，你制造的bug太多了！”。你可能会抱怨，这分明是需求变化太快，领导时间太紧造成的。嗯，听起来很有道理，但是要知道，需求的变化是软件的客观规律，领导要求进步。呵呵，你也可以认为是客观规律。这不是一篇论证谁导致程序员加班过多的论文，也不想给大家泼鸡汤，让大家一夜成编程高手，但至少说说一些真实的经验和方法。总之，让大家多读一点，多一点实用价值。1、不要一上来就开始写代码。您可能很着急，或者您可能已经迫不及待想要尝试我昨天刚学的一点编程技巧。我想告诉你的是，别着急，收起你磨刀霍霍的表情包，在你拿到需求准备写你的第一行代码之前，还有更重要的事情要做。我怎么强调都不为过。我以前写的所有代码都用过这个方法，它可以消除90%的测试可能出现的bug，甚至达到零缺陷，当然，这可能需要一个过程。拿到需求后，首先要问问自己是否已经完全理解了需求。得到肯定的答复后，我们就可以开始了：首先，在你繁忙的工作中，找一个你完全可以控制的时间段，这个时间完全属于你自己，并且保证在这个时间里不会有人打扰小时，或任何可能影响您执行此方法的中断。请记住，这一小时是如此重要，它比您之后将要进行的所有活动都重要，而且绝对值得。在第一张白纸上面写下“这个需求特性的正常过程和影响范围”，然后开始在空白纸下一个一个地记下这个需求特性的正常过程的内容，哪个库会用到哪些功能，会提供哪些接口，会发布哪些接口，会不会影响版本升级，会不会影响资源文件，会不会影响原来的接口等等。在第二张白纸上面写上“这个需求特性的所有异常场景和我过去常犯的一些错误”，然后在白纸下面开始一一记下。连续重复步骤2)和3)。您可能认为这与编写需求说明材料不同。我想告诉你的是，这是两个不同的东西。这不是质量专家要求你做的质量过程活动。这是你和你自己之间的时间。深入对话，这不需要告诉任何人，不需要向其他领域输出任何可交付成果，这是一种自我驱动，写出优秀的代码。一开始你可能会觉得吃力，写了几篇就写不下去了，或者你可能会产生“这东西真的有用吗？”的想法。别着急，起来到窗边呼吸一下新鲜空气或者去拿杯水喝吧，反正不要打扰，除非办公室着火了，不要做让这件事继续下去的事情.当你慢慢写到第20或30个答案时，你可能会突然有一种“我竟然发现了这样一个隐藏的异常，太神奇了！”的感觉，这时候你会暗自惊叹难以抑制的激动，这意味着你已经接近圆满完成，后面写的每一项都会让你感动。记住，不要中途放弃，你坚持下去的决定将使这一小时成为你整个需求实现中最重要的时刻。其次，忘掉那些该死的质量活动吧。除了编码之外的所有质量活动都是基于公司对你的代码编写水平的不信任。也就是说，公司花大价钱请了质量专家、网元测试人员、方案测试人员，都是因为你代码没写好而造成的浪费。一些开发人员在刚来的时候批评质量专员安排的质量活动是很常见的。编码时间的侵犯”。说这些还好，但是你边说边写代码，bug就出来了，是不是有点不要脸？质量专家设计的这些活动是为了防止你的烂代码冲到客户面前设计的检查点，当你对“写好代码”什么都不做，只想取消这些质量活动时，你只能理解为流氓。那么，做品质活动能“写出好代码”吗？答案是不。质量活动只是质量专员的监督手段。它既不是目标也不是方法。你写代码的目标不是达到质量活动标准，而是追求零缺陷，不会因为Wbit测试做得好就写不出代码。好的代码。你要做的一件事是“不要一上来就开始写代码”，二是尽可能多地掌握重构的方法，重构自己的思维方式。掌握重构并不一定意味着重构原来的代码，而是在写之前就知道如何写出好的代码。我让大家忘掉质量活动，不是让大家不听质量专家的话，而是写代码的时候要有敬畏之心。代码写好之后，所有的活动都是你造成的浪费。你必须消除这些浪费。并尽力而为。3.你要记住，你写的代码是给人看的。好的代码让人看得开心。任何因缺乏能力或表演技巧而增加人们阅读障碍的行为都需要改进。你能不能用几句话，把你自己写的代码的上下文说清楚。当然，这也涉及到你要掌握尽可能多的重构方法和重构思维方式。另外，还有一个自我判断的标准，就是问问自己，“你有没有被自己写的代码动心过？”写完之后，你会忍不住反复阅读自己写的代码，并暗暗惊叹代码的美吗？作为一名程序员，我希望有一天你在离开公司后回忆起的几个快乐时刻中，一个是因为你面对刚刚发布一段让你心跳加速的代码的那一刻，不要成为“离开后”，公司知道他有多重要”上面提到的那个人。4.现在开始刻意练习。你是否发现自己长期保持着“刚好够把故事讲完”的代码水平，写了几年代码还是会被测试人员追杀？各种疑惑都是因为代码能力的提升和你写代码多少年没关系，需要做的是刻意练习。比如反复练习我上面提到的方法，或者把自己想通的方法分解成一个个环节，刻意练习，从测试中得到反馈，然后不断改进，慢慢的你就会从一个开始整个人天天被测试人员追，变成了发现自己很容易达到质量流程标准的人，然后逐渐发现你写的代码越来越难被测试人员发现问题。最后，只要你状态好，你就可以定期编写零缺陷代码。事实上，我们似乎知道了一些道理，但我认为我们离真正理解还有两步之遥。第一是你需要自己去体验和实践这些原理和方法，第二是你需要能够释义，让别人理解。所以最好的学习方式就是亲身体验，然后写下来分享给大家，让你真正明白那些你以为明白但不一定明白的道理。
