图文并茂PHP跟老大的对话

开发 后端
叫老大不光是因为职位比我高,还因为技术也让人佩服!今天跟老大聊聊我们一些代码结构的问题,有些可能会对你是有帮助的。如果大家有不同的看法,可以提出来,一起讨论一下。

 思维导图

介绍

叫老大不光是因为职位比我高,还因为技术也让人佩服!

今天跟老大聊聊我们一些代码结构的问题,有些可能会对你是有帮助的。如果大家有不同的看法,可以提出来,一起讨论一下。

对话

1>单个文件巨大(超过5000行)

我:文件大会不会影响性能啊?PHP语言在处理源文件的时候(这个主要是php的词法分析和语法分析),会将源文件切分为一个一个的标记(token)。如果文件很大的话,把我们当前不需要的方法都会做标记的,这样不是明显影响性能吗?

老大:这个在性能方面的影响是比较小的。我们在考虑性能的时候,要考虑全局观,比如展示页面的时候,打开页面很慢,那我们首先考虑的就不是文件大小的问题,而是每个模块的加载速度。比如,通过你的断点设置,你发现某个产品列表的读取是比较慢的,那就要考虑,是不是组装数据慢了,还是从接口(数据库或者中间层)读数据慢了?如果是组装数据慢了,那就要重构这个算法,或者跟产品人员商量能否修改方案。如果是接口读取数据慢了,那是不是需要加机器或者加索引来解决问题。——所以,考虑性能问题,不能抓住小问题,要考虑的是最影响性能的地方进行修改。

我:那如果切分大文件类到不同的类有什么不好吗?

老大:如果在一个方法体中,你通过很多的require_once添加很多的类文件,那么不也是影响性能吗?——require_once本身也耗费性能!

给我画了一张图(类似于上面的图):

我:那我可以用include,逻辑加载文件,按条件加载文件。这样就能减少加载文件的数目!

老大:那么你怎么按照条件加载?

我:比如,我可以按照分类去加载文件,电影的时候,我就把电影相关的程序文件加载进来,电视的时候就把电视相关的程序文件加载进来。

老大:那将来电视要用到电影里的内容的时候,你怎么办?或者很多分类用到你电影分类里的内容的时候你怎么办?

我:那我就放置一堆的"||"代码(如if('电影' === $category || '电视' === $category || '音乐' === $category){})。 后来我琢磨了一下,确实是,这样做的话,一个方法里会有很多这种if语句,那我要对应某一个分类内容的时候,我就要看一堆的if了。还真不如写在一块呢或者重构代码了!

#p#

2>autoload()方法。

类似下面的代码。

  1. <?php   
  2. Test::getName();   
  3.     
  4. function __autoload($className){   
  5.     echo $className,"\n";exit();   

运行结果:

我们都知道__autoload()方法性能并不是很好,一般不鼓励去使用这个方法。所以,我在调用类的时候,我就加了这么一句:

对话:

我:我觉得__autoload方法性能不是很好,所以我在调用别的模块的时候,我就用了include方法。

老大:你这样做,一是整个代码看起来没那么规范,二是,如果将来要修改框架了,我们就要查看所有的这样的代码文件,因为比如,你的入口文件移动到别的文件夹下面,那么你的Test.class.php文件在什么位置,你知道吗?

如果我们调用__autoload()方法,我们只需要修改这个接口就可以了,因为所有的类调用都经过了这个方法,这样比较好管理。

#p#

3> 一个方法尽量保持在一个屏幕内,一行不超过80个字符。

我:我觉得我们的类里面的方法太长了,很多都超过几个屏幕,才能把当前的方法看完。我个人比较推崇"尽量把方法放在一个屏幕内"和"让一个方法做一件事"。有的时候看到一个很长的方法的时候头大了!

老大:

一个方法就是做一件事啊,比如test()方法,就做test()。以前php没有面向对象的时候,我们经常不是把代码都写在一个文件里吗?

我们不应该“为了拆方法,而把方法硬性拆分。而应该是因为业务需要而对方法拆分!”。而且函数调用我们知道,本身也是耗费性能和内存的。如果你这个方法体内的有些部分,其他方法也要调用,那么这时候你可以把这部分代码做成一个方法。如果你的方法里有很多调用其他类里的方法,不也看着很麻烦吗?还不如写到一个方法里呢!这样还比较直观些。

#p#

4> 找回以前删除的代码。

我:如果某个功能产品要求撤下来,但是过了很长一段时间,产品又要求再上这个功能。那么我原来的代码是删除呢?还是只做注释呢!

老大:删除掉!

我:那我怎么恢复呢?要把原来代码做备份吗?

老大:你可以使用版本管理软件做恢复。如svn。

例子演示:

(1)最初代码

svn提交代码:

 (2)产品要求下线代码

svn提交代码:

(3)隔了一段时间,产品又要求重新上线该模块。

svn操作:先查询日志,然后针对日志进行合并

总结

上面的问题,我估计你也遇到过,所以大家共勉下吧!

题外话:曾经我在离开一家工作一年的公司的时候!项目经理就跟我说你如果频繁跳槽,会对你的将来的发展是不利的,但是没有告诉我怎么不利?现在我有点明白了,因为我到过的公司很多技术过硬的人,都是在这个公司带过3年以上的人。我发现如果你在一家公司待很长时间,对你的技术提升是很有帮助的。

1》 不停的重构代码,提升你的代码质量。

我们开始进入公司的时候,一般都是公司急需赶个项目人手缺乏。等项目完成,一般都是1年左右。如果你在公司待足够长的时间,这个项目多多少少会跟你扯上边的,这时候,你会不停的翻看自己的代码,你也会不断的调整代码, 不断的重构你的代码——跟写文章一眼,你不停的看自己写过的文章,你会不停的做修改,越修改你的文章会越让你喜欢。

2》业务熟悉,能够更快更好的写出代码!——我个人比较喜欢“行云流水”似的感觉。

你如果在一个公司待了很长一段时间,那么你对这个领域是非常熟悉的。新需求上来,你会很快的知道怎么做代码架构,比如上面提到的,你就知道方法中,哪些代码部分可以抽出来,独立做成一个方法;你也会知道,将来什么地方会频繁修改的。——写代码,如行云流水般!

附件:跟老大对话

原文链接:http://www.cnblogs.com/baochuan/archive/2012/03/21/2409023.html

【编辑推荐】

 
责任编辑:张伟 来源: 川山甲的博客
相关推荐

2011-01-18 18:08:28

Thunderbird

2011-11-21 15:12:54

Java断点Eclipse

2011-01-18 18:29:28

Thunderbird

2022-07-18 14:33:05

PythonPDF报告

2023-05-16 08:01:13

架构网站演进

2012-07-23 14:39:27

移动

2011-01-19 17:30:21

Postfix邮件投递

2011-01-19 17:34:39

Postfix如何接收邮件

2021-12-27 08:04:49

架构网站高并发

2011-01-20 09:13:18

Postfix

2011-01-21 10:28:06

2011-01-19 10:30:20

UbuntuThunderbird

2012-07-27 10:27:19

OfficeWord

2011-07-04 16:57:36

QT 布局 界面

2011-08-03 15:21:23

ORM XCode 数据库

2009-07-15 14:49:16

2022-04-20 18:30:00

算法架构粗排

2012-05-28 15:32:05

PHP

2023-09-27 08:46:44

Java 技术编程语言

2022-07-25 06:44:19

ZooKeeper分布式锁
点赞
收藏

51CTO技术栈公众号