性能,不是不重要,而是,它没有可维护性重要

简介:   刚才看到文章这个看法很有同感,以前也没有深刻理解到可维护性的重要性。在现在的公司呆了一年半,才明白。因为现在的公司用户量大,团队开发人员多,遇到很多难以维护的代码,花费人员沟通成本,延缓功能的开发进度,去填补遇到的坑.....   http://www.cnblogs.com/freeflying/p/4788494.html 一、性能不是不重要,而是他没有可维护性重要。

 

 

刚才看到文章这个看法很有同感,以前也没有深刻理解到可维护性的重要性。在现在的公司呆了一年半,才明白。因为现在的公司用户量大,团队开发人员多,遇到很多难以维护的代码,花费人员沟通成本,延缓功能的开发进度,去填补遇到的坑.....

 

http://www.cnblogs.com/freeflying/p/4788494.html



一、性能不是不重要,而是他没有可维护性重要。要理解这一点,首先要理解可维护性的重要(请再读上一篇我花数周找bug的段子);然后要明白:解决性能问题,我们可以有很多代码以外行之有效的方法,而可维护性基本上就只能靠代码了;最后,还是要牢记:没有牺牲,就没有胜利!

二、所以,在绝大多数情况下,当性能和可维护性相冲突的时候,性能让位于可维护性。我们采用其他办法来弥补代码性能不够高的问题。



优化首先需要找到性能“瓶颈”。否则,任何人都可以随手一指,“这段代码需要优化”。
可读性更强的代码总是更好优化
硬件永远比软件便宜(即硬件比技术人员便宜,看系统规模而定)

 

 

 

 

 

合理浪费堆硬件

 

说了这么多,不知道有没有引起同学们的反思。可能大家还是过不去心里那道坎:明明有一种性能更高的方法我们为什么不用?

 

因为浪费呗!

 

什么?你有没有搞错?我的代码,至少省了一块内存条!那是你还没从“穷学生”的角色里转换过来。你花一周的时间对代码进行了优化(就先不考虑你的优化带来的维护成本增加了),为老板省下了一块内存条的钱。你以为老板会拍着你的肩膀表扬你么?老板打不死你!

 

兄弟,账不是你那样算的。当你是学生的时候,你的时间成本是0;但你进入工作岗位,每一天都是要发工资的。

 

通过代码来调高性能,是一种无奈——对硬件性能不够的妥协(参考:80年代游戏开发者的辛苦困境。这样写性能就高,但为什么现在没有谁再这么写代码了?)。否则,绝大多数情况下,堆硬件比优化代码的效果好得多,而且便宜得多硬件的成本按摩尔定律往下降,我们程序员的工资也能按摩尔定律减么?(注:硬件越来越便宜,而人员工资越来越增加,就拿工厂的普通工人用工成本也在增加

 

 

 

 

明明window 10 比window 95更耗性能,为什么今天没人用window 95?为什么VS 2013要10G的空间我们都还屁颠屁颠的赶紧装上?为什么现在大家都用C#,没人用汇编?(注:汇编比高级语言性能强,接近机器)

 

 

 

我们站在人类文明积累的今天,就应该理所当然的享受这一切成 果。有打火机你不用,你要钻木取火。如果你是因为要学贝爷荒野求生装逼,可以理解;如果你说你是因为怕浪费天然气,我……我……我怎么说你呢?“给做打火 机的一条活路,行不?”同样的,程序员大神同学,你就当做好事,给下面写底层做硬件的一条活路吧!你的代码都是 010001000010000001010101……了,你让其他人怎么活啊?

 

最后,我突然想到的一个程序员为什么对性能如此敏感疯狂,对可维护性毫不在意的一个可能原因:

  • 性能很好理解,卡得要死和跑得飞快;可维护性很不好理解,至少得跑个两三年才能体现,那时候,谁知道爷在哪里偷着乐呢
  • 性能上不来,程序员只有羞愧的低着头,都是我的错;需求有变更,开口就骂,“哪个SB又要改……”;

大家觉得是不是这样的?所以,愿意把代码百炼成钢绕指柔的人少。想来,是一种莫名的悲哀和凄凉。

 

 

 某网友说:

 

 感觉性能问题属于眼前问题,可维护性问题属于以后的问题。很多人就是感觉先把眼前自己的事儿处理完就行,程序只要能运行,老板满意就万事大吉,至于以后维护爱谁谁吧,那个时候老子已经另谋高就了,烂摊子留给后面的倒霉蛋吧。

 

这段话的确说出了目前的现状,被逼的,上面只看功能完成与否,功能完成的质量不管。那还关系代码的可维护性干嘛。于是把代码复制,拷贝函数,只要能跑起来就好了。

 

性能、可维护性从来都是要折中,过分从代码中追求性能会增大开发成本、降低可维护性。
现实中老板、客户真不在意那点硬件成本。只要项目快点上线。二期三期四期优化都好说。

 

张口闭口 谈性能的 经理 我之前在北京 也见过 几个。


最后 用几个 实际的项目,堵住了他的嘴


—— 别跟我谈性能,即使我用滥反射,性能也比你的快。

 

 同意,除了核心功能和高并发的页面,一直以来写代码的风格,首先就是可读性,可维护, 然后再是性能。

 

 

 我的思考:

 

性能问题:关键是找到性能的瓶颈点。而不是纠结于细微的。也就是主要矛盾。把主要矛盾解决掉后,就好多了

 

就拿php来说,是解释性语言,解释性语言是比不上编译型语言快。但是在web应用中,不涉及到复杂的cpu计算(简单的增删查改数据库,不是分词这么复杂的算法,这种属于cpu密集型),瓶颈在磁盘读写(磁盘i/0)和数据库上。

所以看不出php的劣势出来。当达到facebook这样的应用,他们就会感到一点点php优化,对整个成本的减低,省去很多服务器。

 

所以有规模,就是规模成本。经济学中有个规模效益。通俗例子理解,生产100个要这么多成本,生产1000也是差不多的成本,但是可以得到更多利润。所以只能把规模扩大,才能赚到钱。

 

你达不到那个规模的时候,去谈优化性能,带来的是得不偿失的。

 

而且,就算是解决性能问题,关键是找到瓶颈在哪里,解决了瓶颈,就会带来质的变化。而不是纠结于细节优化。主次矛盾要分清楚。

 

单纯说性能,那直接用汇编写代码,发明高级语言干嘛,汇编语言更加接近机器二进制,所以性能更强。但是汇编语言不容易维护,因为难懂,难上手。不接近人类的思维习惯。

记得国外有本书中提到一个观点:代码是写给人(对象是程序员)看的,不是写给机器看的,如果是写给机器看的,那么,直接使用二进制01011这样的方式去写代码呢,机器识别就是二进制。而且,性能更强,不用经过中间转换,是不是。

 

目录
相关文章
|
1月前
|
设计模式 算法
提高代码复用性,减少冗余代码
提高代码复用性,减少冗余代码
18 3
|
2月前
|
算法 程序员 PHP
编写魅力十足的代码:优化可读性、维护性和性能的关键
本篇汇总了平时在工作开发中常遇到的业务逻辑的优雅写法,也汇总了自己还是新人时,拿到一个业务不知道怎么下手的痛点,依稀记得那时候总感觉自己写的代码不规范。 写完之后,感觉还是美好的,又学到东西了。
|
3月前
|
缓存 编译器 Go
反射的双刃剑:性能与灵活性权衡
反射的双刃剑:性能与灵活性权衡
31 0
|
8月前
迪米特法则:降低耦合,提升代码质量与可维护性
迪米特法则是一项强大的设计原则,可以帮助我们构建松散耦合的软件系统,提升代码的质量、可维护性和可扩展性。通过减少模块之间的依赖关系,我们可以更轻松地进行修改、重构和扩展。
53 1
迪米特法则:降低耦合,提升代码质量与可维护性
|
8月前
|
编解码 NoSQL 网络协议
4. 软件设计中的可维护性
4. 软件设计中的可维护性
114 0
|
存储 缓存 运维
系统稳定性设计原则:简单、冗余、标准化、健壮
系统稳定性设计原则:简单、冗余、标准化、健壮
541 0
系统稳定性设计原则:简单、冗余、标准化、健壮
|
算法 编译器 C++
C++ 最佳实践 | 4. 可维护性
C++ 最佳实践 | 4. 可维护性
57 0
如何提高代码的扩展性(4)
如何提高代码的扩展性(4)
103 0
如何提高代码的扩展性(4)
|
程序员
如何提高代码的扩展性(3)
如何提高代码的扩展性(3)
319 0
如何提高代码的扩展性(3)
如何提高代码的扩展性(6)
如何提高代码的扩展性(6)
188 0
如何提高代码的扩展性(6)