新⼿程序员必学的代码编程技巧
程序员往往渴望加⼊的是⼀⽀
“30%
的时间在写代码，⽽
70%
的时间在喝着咖啡讨论着如何将产品做好
”
的团队。
软件⼯作应该成为⼀项技术和艺术融合的⾼智⼒活动，⽽项⽬经理应该是⼀个⾼度理解质量、范围和进度客观规律的明⽩⼈，
“
⾼效⼯
作，快乐⽣活
”
才应该是程序员的座右铭。
可现实情况却是，团队在⼀边超负荷的做着需求，⼀边改着没完没了的
Bug
。
过点前⼣，项⽬经理熬着通红通红的眼睛盯着我们整晚整晚的加班，质量专员⼀遍⼀遍的催促质量数据还不够，软件⼯作已经⽆可挽回
的沦落成了体⼒劳动，别说快乐⽣活，⽣活都没了。
好吧，以上可能都对，项⽬经理和质量专员是⼀个不懂客观规律并且毫⽆同情之⼼的⼤魔头，让我们程序员们毫⽆尊严卑贱的活着。
只是，有句话憋了很久了：
“
醒醒吧，所有的这些，都是因为你的代码写的太烂，你制造了太多的
Bug!”
。
你可能会抱怨这分明是需求变更太快，领导计划太紧导致的。
嗯，听着挺有道理，但是要知道需求变更本⾝就是软件的客观规律，⽽领导要求进度，呵呵，你也可以认为是客观规律。
这不是⼀篇证明谁导致程序员加班太多的论证⽂，也不想给⼤家灌鸡汤，让⼤家⼀夜之间都变成编程⾼⼿，但是⾄少说⼀些实实在在的
经验和⽅法。总之让⼤家多看⼀点就多获得⼀点实际的价值。
⼀、不要⼀上来就开始写代码
你可能性⼦急，也可能早已按耐不住跃跃欲试昨天刚学会的⼀个编程⼩技巧，我想要告诉你的是，不急，收起你那磨⼑霍霍的表情，在
你拿到需求准备写出你第⼀⾏代码之前还有更重要的事情要做。
我想怎么强调这件事情的重要性都不为过，在我以前写的⾃⼰⾮常满意的代码经历中，我都采⽤了这个⽅法，它能消灭原来可能会被测
试提的
90%
的
Bug
单，甚⾄做到零缺陷，当然做到这点可能需要⼀个过程。
拿到需求之后你⾸先要问下⾃⼰对需求是不是已经充分理解了，得到肯定的回答之后，我们就可以开始了：
1)
先在你忙碌的⼯作中，找出你能完全掌控的⼀个⼩时时间段，这⼀个⼩时完全属于你⾃⼰，保证这⼀个⼩时不会有任何打扰，或者任
何能影响到你执⾏不下去这个⽅法的打扰。要记住这⼀个⼩时⾮常重要，⽐你后⾯要执⾏的所有活动的时间都重要，它绝对值得。
2)
在第⼀张⽩纸的上⽅写下
“
该需求特性的正常流程和影响范围
”
，然后在⽩纸下⽅逐条开始写下该需求特性正常流程包含的内容，⼤概
会使⽤到哪些库函数，会提供出哪些接⼝，是否会影响版本升级，是否影响资源⽂件，是否影响原有的接⼝等等。
3)
在第⼆张⽩纸上⽅写下
“
该需求特性所有的异常场景和本⼈以往经常会犯的⼀些错误点
”
，然后在⽩纸下⽅⼀条⼀条的开始往下写。
4)
不断重复第
2)
、
3)
步。
你可能会觉得这不就跟写的需求澄清材料差不多吗，我要告诉你的是这是两回事，它不是⼀项质量专员要求你做的质量过程活动，这是
你⾃⼰和⾃⼰之间的⼀次深层次对话，这不需要告诉任何⼈，不需要向其他领域输出任何交付物，这是对⾃⼰要写出优秀代码的⼀次⾃我驱
动。
⼀开始你可能会觉得很难，写⼏条就写不出来了，或者闪过
“
这玩意⼉是不是真的有⽤
”
的念头，不⽤着急，起⾝去窗户边呼吸⼀⼝新鲜
空⽓或者去打杯⽔喝，总之不要中断，除⾮办公室着⽕了，不要去⼲让这件事继续不下去的事情。
当你慢慢往下写到第
20
或者第
30
条答案的时候，你可能突然会有⼀种
“
这么隐晦的⼀个异常点都被我发现了，简直太⽜了！
”
的情感涌
出，这个时候你会暗暗惊呼有点难以抑制⾃⼰的兴奋，这说明你快要接近成功完成了，后⾯每写出来的⼀条都会让⾃⼰感动。
记住，中间不要放弃，你坚持下去的决定会将这⼀个⼩时变成你整个需求实现当中最重要的⼀个⼩时。
⼆、先忘掉后⾯还有该死的质量活动
所有编码之外的质量活动，都是基于公司对于你写代码⽔平的不信任产⽣的。
也就是说公司花了⼤量的钱招来质量专员、⽹元测试、解决⽅案测试这些⼈都是因为你没把代码写好造成的浪费。
常见⼀些开发⼈员，刚来的时候对质量专员安排的质量活动颇有微词，
“
我以前公司做项⽬根本不需要做这些东西还不是⼀样能把项⽬
做完
”
，
“
这些质量活动，简直就是对编码时间的侵占
”
。
说这些都没问题，但是你⼀边说着这些⼀边写完代码后
Bug
就乌泱乌泱上来，是不是有点不要脸？质量专员设计的这些活动，就是为了
不让你的烂代码⼀泻千⾥的冲到客户⾯前设计的⼀个个检查站，当你对于
“
写出好代码
”
什么事都没做，只想着取消这些质量活动的话，就只
能理解为耍流氓了。
那么，做好质量活动就能
“
写出好代码
”
吗？
答案是不能。
质量活动只是质量专员的监管⼿段，它既不是⽬标甚⾄也不是⽅法，你写代码的⽬标不是要满⾜质量活动标准，⽽是要追求零缺陷，也