对于一个程序员来说,是应该有价值观的,然而最朴素的基本价值观,就是要写好的代码。然后,要做到这一点不容易,
对些,我针对这些价值观有自己的一些看法:
(当然,在网上有关于价值观的内容一大片,各有视角,这里仅仅说说我的看法)
1,good software != quality code
2,软件开本 = 开发成本 + 维护成本
注意,尤其是维护成本,被很多程序员所忽视,认为我只在几天开发完了这个代码,这个软件的成本就并不高,这个观念万万要不得。 久而久之,这个观点慢慢地被产品,项目经理所学习到,也自然而然的认为,只在几天内开发完的功能,所投入的成本并不高。然而残酷的事实是,投入维护它的成本数倍于甚至数十倍于开发成本,扔下的往往是一个烂摊子,后续接手的开发人员也会苦不堪言。
有时候,我们程序员总感觉自己被产品催着,有忙不完的事,而背后的原因往往是程序员自己本身,因为在与产品沟通过程,总是会释放出这个很容易,那个也很简单的信号,而给产品造成错觉。
3,代码就是债务
同样的功能,写的代码越多,相应的测试、维护、升级等等成本也越高。 尤其是过度设计的危害,太过于高瞻远瞩,而忽略现实情况,结果可能恰得其反。
还有一个是不得不说的:关于设计和代码。我们期望的是设计与代码无限接近,但是,现实中,设计与代码往往是脱离的,甚至有时候看到设计,对代码的理解反而是一种误导。不仅无助于还原软件的真实面目,反而让软件蒙上神秘的色彩。
程序员之间沟通,最佳的语言就是代码,代码说了什么,就是软件实际运行的真实表达。
有一个观点我需要表达的是:代码写出来,除了要运行之外,就是为了给别人看的。而后者,有很多程序员会忽视,甚至都没有意识。 如果有程序员认为,写出来的代码,只要能运行,有高效率,有什么可动态扩展等等就可以了,至于别人能不能看得懂,那可就不关我的事了。事实上,这个观点很有害。如果只是说代码能执行等等这些观点来看的话,那么,什么格式化,变量命名规范等等都可以不要了,甚至换行都不是必须的。
关于这一点,不得不承认,代码很难做到一点坏味道也没有。
但我想表达的时,我们需要培养这种嗅觉。 如同一个摄影师,要想出好的作品,首先需要培养审美能力,否则,再好的器材,也出不了好作品。
培养了对坏味道的灵敏嗅觉,一旦在自己的代码中闻出了不好的味道,就会有强迫症一样逼迫自己去消除之。 (我们假定一个合格的程序员,有那么一点点代码洁癖,看到不好的代码总会坐立不安,在不需要别人的催促下能自己消除坏味道。)
代码中有哪些常见的坏味道,在互联网上能搜索出一大堆,在此,我只列举一些,有空无空看一眼,以培养自己嗅觉。
第5点和第6点有时感觉很接近,发散式变化主要是指软件在某个细节点需要增加相同的功能,如原来支持mysql,现在要增加对postgre数据库的支持,则要修改若干个函数。而霰弹式更强调细节,如代码中要增加或变化某个变量的,若干个类也需要做许多细小的修改。 发散式一般指一个class受多个变化影响,而霰弹式则指一个变化引起多个class要做修改。 但我觉得刻意去记清这个差异没有必要。理解它的本质就行:一个地方微小的变化,总会引起若干地方有关联的变化,如果有这种情况,就要警觉是否有坏味道在产生了。
函数对某个class的兴趣比自己的所在class兴趣还要高,这个比较难以理解,如,一个函数中,一大半的代码都在调用某一个类的方法,如取值等。
这个没啥好说的,面向对象最好少用switch , 尽量用多态,不过,也要分情况,不要杀鸡用牛刀了。
如: A extends SuperA , B extends SuperB , 如果有需要定义 AA extends SuperA时,总需要需要定义 BB extends SuperB 。 当然,这种也要会情况来对待,如果两边各代表一系列的继承关系,这个味道就不对了。
定义一些无用的类,或者考虑的某种变化根本不可能存在,而代码中却有大量相关的类实现定义等。总之就是想得太多,但实际不会出现。
在定义类时,总想着在未来的某一天会用到,而提链出一堆抽象类,接口等,而实际上,却无用处,甚至测单元测试也用不到。纯粹为了复杂而复杂。常见的情况就是,某些程序员总是无脑地定义抽象类,定义各种复杂的继承关系。
类中的一部分属性,只有在特定的方法才有作用,而这些属性,往往又不对外暴露。常见的是把某些方法的临时变量,作为类的属性。
这个比较通俗的理解是: a调b,然后a调c, 然后又有b调c等等,可以改在 a调b, b调c。
委托(delegation)的过度使用,而且这个委托人不干实事。
两个class关系太过于亲密。这一点有点难以嗅到,不过,当发现用一个两个class类时,感觉用其中一个类时,又不得不花时间这个类的私有成员或者另外一个类的内容,两者很难分清它们之间的关系,往往会这种坏味道。这种情况下,相办法拆散它们,让他们关系明确一些。
两个函数做着同一件事,却有着不同的签名,请按照用途重新命名或者其它方法消除这种表达不一致的情况。
这一点我理解倒不像是一个坏味道,更新是在某些特殊场景下解决方法。
引入第三方的库不可能能满足所有需要,遇到这种情况,可以尝试引入外加函数或者引入本地扩展来解决这个问题。当然,这个是要分情况的,不能一概而论。
而如果要求第三方库完美,满足所有情况,这个就有点要求过度了。
常见一些看上去像bean的java对象,它的属性,除了有get/set方法外,我们还发现这些属性居然是public的,有的属性是容器等等,这样的代码看上去像是无脑的代码,哪些属性能够public,容器对象应不应该这样暴露出来,都没有思考,只是知道这样可以修改这些属性的值而已,至于这样写,会造成什么危害,对模型的数据和行为定义是否准确完成没有考虑过。
这个坏味道有时并不那么强列,SubClass 继承了 SuperClass,但是又不支持SuperClass的接口,这个一般情况也就无所谓,当然,这么做有那么一点点别扭,但是,不要因此去随意改变模型间的继承关系,可以尝试用委托(Delegation)。
这一个的正确理解是:一个本身很简单的功能,因为实现的代码过于糟糕,而造成注释不得不随之变长,而使得内容难以理解。 因此,不要一看到这一点就惊呼,不是提倡代码要写注释么,注释要详细么,怎么这又说是坏味道了,注意,不是这样子的,要正确理解。
总结:以上的坏味道,有些是可能存在争议或者只在某个场景中才算,所以,对于这些场景应理解其本质所要反映问题的本质,区别情况对待。但是,这不妨碍对于这些坏味道的识别,却培养一个码农应具备最基础的嗅觉能力。
另外,对于出现了坏味道的代码,也不太可能一味地追求去消除它,毕竟追求极致是要付出时间成本的,而且有些时间会出现首鼠两端的情况,一定要权衡利弊。
2,创建子程序的理由:
提高可移值性
....
3,使用异常代替直接返回错误码
这一点,会有使用异常会影响性能一说,但是,这里想表达的是,对于性能的追求,也需要分场景,在不分场景的情况下刻意追求性能,如异常所产生的性能对系统整体影响微乎其微,这种情况下,回避代码的可维护性而去追去所谓性能,实在是不提倡。
1,单一抽象层次原则
2,驯服深层嵌套
4,函数单一职责
5,函数的命名
6,好的函数名称
7,关于函数的参数
使用参数对象
保持对象完整
关于参数的顺序
应避免以下情况
8,复杂的表达式应对办法
9,关于循环
while , for 使用场景
10,关于常量
避免魔法值
11,关于变量
总的来说,变量应尽可能地轻量级
12,注释
理想情况:不需要注释,代码自解释
好代码 > 坏代码 + 好注释
13,重复代码
想一下,IntellijIdea工具中,Refactor菜单中的功能 ,你用过几个?
你是去治疗病人,而不是去伤害病人
1,持续进行,而不在版本发布后才想起重构。
2,小步骤进行,不要尝试硬着陆