整洁代码4

1.往往辞职是因为糟糕的代码让人退避.

　　只要你干过两三年编程,就有可能被某人的糟糕的代码绊倒过.如果你编程不止两三年,也有可能被这种代码拖过后退.进度延缓的程度会很严重.每次添加修改代码,都得对那堆糟糕的代码添加更糟糕的混乱.久而久之团队的生产力趋向于零.当生产力下降管理层能做的事情就是增加更多的人到项目中去,期望提升生成力.可是新人并不熟悉系统设计,他们搞不清楚什么样的修改符合设计意图,什么样的修改违背了设计意图.而且他们以及团队其他人都背负着提升生产力的可怕压力,于是他们就开始制造更多混乱和更糟糕的代码.最后开团团队造反了,他们告诉管理层,再无法在这糟糕的代码基础上继续开发了,于是他们要求重新设计重新开发另起炉灶.管理层尽管不愿意,但是最终迫于生产力降低的可怕压力他们妥协了.他们只要同意开发者的要求,授权去做一套新的看上去的华丽的新设计.于是我们就组建了一支新军.谁都翔加入这个团队,因为他是一张白纸.他们想怎么画就怎么画无所顾及.当是只有最优秀的家伙被选中了,其余人还是只有继续维护现在的系统.现在就有了两支团队在竞赛.新的团队必须搭建一套新的系统,而且还有更要兼容旧的系统,在新系统足以抗衡旧的系统之前,管理层是不会替换掉旧系统的.竞赛可能会持续很长很长的时间.当然等到新系统完成的时候,新的团队老成员早已不知道去向了,而现有的成员则要求重新设计一套新系统,因为这套新系统太糟糕了.

2.程序命名也是一种技术.

　　没有意义的命名有多可怕,当你在你的程序中发现有全局变量名的为a1,a2...的时候头都大了,因为有时候你往往只是想维护它然而当你ctrl+f收索的a的时候vs工具瞬间卡顿的感觉你能明白吗等几十秒后出来了上万个引用,那时候我的内心是崩溃的
　　搞笑的命名,有幽默的队友喜欢在系统有一些幽默的名称.我记得有一个队友在一个删除集合目的方法名称为HolyHandGrenade(神圣的手榴弹)没错这名字的确狂拽炫,不过用DeleteItem或许是更好的名称,宁可明确,切勿好玩.

3.稍后等于永不

某天天气阴天我在做在办公室里编码着一个极其繁琐的业务代码,这个业务代码本着是在同事的原有的业务上扩展新的业务因为懒惰的思想导致不想去理那堆代码,用了程序员最最高的技术(Ctrl+CV)编写完了那块业务,本想着后面有空在去整洁代码,然而3年过去了 现在那块重复的代码已经用10多份了.

4.装B被打脸

　　想当时我刚刚出道的时候,本着程序性能的目标,把程序代码全部些到1行.结果被项目经理很很的批斗,你把这些应该是代码块和缩进的全部都优化了,那我们的编译器还那来做什么啊.