本日跟老大聊聊我们一些代码构造的问题，有些可能会对你是有帮助的。如果大家有不同的意见，可以提出来，一起谈论一下。
10年架构师领你架构-发展之路-（附口试题（含答案））点击与我互换企鹅群.
1>单个文件巨大（超过5000行）
我:文件大会不会影响性能啊？PHP措辞在处理源文件的时候(这个紧张是php的词法剖析和语法剖析)，会将源文件切分为一个一个的标记(token)。如果文件很大的话，把我们当前不须要的方法都会做标记的，这样不是明显影响性能吗？
老大:这个在性能方面的影响是比较小的。我们在考虑性能的时候，要考虑全局不雅观，比如展示页面的时候，打开页面很慢，那我们首先考虑的就不是文件大小的问题，而是每个模块的加载速率。比如，通过你的断点设置，你创造某个产品列表的读取是比较慢的，那就要考虑，是不是组装数据慢了，还是从接口(数据库或者中间层）读数据慢了？如果是组装数据慢了，那就要重构这个算法，或者跟产品职员商量能否修正方案。如果是接口读取数据慢了，那是不是须要加机器或者加索引来办理问题。——以是，考虑性能问题，不能捉住小问题，要考虑的是最影响性能的地方进行修正。
我:那如果切分大文件类到不同的类有什么不好吗？
老大:如果在一个方法体中，你通过很多的require_once添加很多的类文件，那么不也是影响性能吗?——require_once本身也耗费性能!
给我画了一张图(类似于上面的图):
我:那我可以用include，逻辑加载文件，按条件加载文件。这样就能减少加载文件的数目！
老大:那么你怎么按照条件加载？
我:比如，我可以按照分类去加载文件，电影的时候，我就把电影干系的程序文件加载进来，电视的时候就把电视干系的程序文件加载进来。
老大:那将来电视要用到电影里的内容的时候，你怎么办？或者很多分类用到你电影分类里的内容的时候你怎么办？
我:那我就放置一堆的"||"代码(如if('电影' === $category || '电视' === $category || '音乐' === $category){})。 后来我琢磨了一下，确实是，这样做的话，一个方法里会有很多这种if语句，那我要对应某一个分类内容的时候，我就要看一堆的if了。还真不如写在一块呢或者重构代码了！
点击与我互换企鹅群.
2>autoload()方法。
类似下面的代码。
<?phpTest::getName(); function __autoload($className){ echo $className,"\n";exit();}
<?phpTest::getName(); function __autoload($className){ echo $className,"\n";exit();}
<?phpTest::getName(); function __autoload($className){ echo $className,"\n";exit();}
<table data-draft-node="block" data-draft-type="table" data-size="normal" data-row-style="normal">
<?phpTest::getName(); function __autoload($className){ echo $className,"\n";exit();}
运行结果:
我们都知道__autoload()方法性能并不是很好，一样平常不鼓励去利用这个方法。以是，我在调用类的时候，我就加了这么一句:
对话:
我:我以为__autoload方法性能不是很好，以是我在调用别的模块的时候，我就用了include方法。
老大:你这样做，一是全体代码看起来没那么规范，二是，如果将来要修正框架了，我们就要查看所有的这样的代码文件，由于比如，你的入口文件移动到别的文件夹下面，那么你的Test.class.php文件在什么位置，你知道吗？
如果我们调用__autoload()方法，我们只须要修正这个接口就可以了，由于所有的类调用都经由了这个方法，这样比较好管理。
3> 一个方法只管即便保持在一个屏幕内,一行不超过80个字符。
我:我以为我们的类里面的方法太长了，很多都超过几个屏幕，才能把当前的方法看完。我个人比较推崇"只管即便把方法放在一个屏幕内"和"让一个方法做一件事"。有的时候看到一个很长的方法的时候头大了！
老大:
一个方法便是做一件事啊，比如test()方法，就做test（）。以前php没有面向工具的时候，我们常常不是把代码都写在一个文件里吗？
我们不应该“为了拆方法，而把方法硬性拆分。而该当是由于业务须要而对方法拆分!”。而且函数调用我们知道，本身也是耗费性能和内存的。如果你这个方法体内的有些部分，其他方法也要调用，那么这时候你可以把这部分代码做成一个方法。
如果你的方法里有很多调用其他类里的方法，不也看着很麻烦吗？还不如写到一个方法里呢！
这样还比较直不雅观些。
4> 找回以前删除的代码。
我:如果某个功能产品哀求撤下来，但是过了很长一段韶光，产品又哀求再上这个功能。那么我原来的代码是删除呢？还是只做注释呢！
老大:删除掉！
我：那我怎么规复呢？要把原来代码做备份吗？
老大：你可以利用版本管理软件做规复。如svn。
例子演示:
(1)最初代码
svn提交代码:
(2)产品哀求下线代码
svn提交代码:
(3)隔了一段韶光，产品又哀求重新上线该模块。svn操作:先查询日志，然后针对日志进行合并
大厂2000道口试题（含答案）点击与我互换企鹅群.总结上面的问题，我估计你也碰着过，以是大家共勉下吧！
题外话:曾经我在离开一家事情一年的公司的时候！
项目经理就跟我说你如果频繁跳槽，会对你的将来的发展是不利的，但是没有见告我怎么不利？现在我有点明白了，由于我到过的公司很多技能过硬的人，都是在这个公司带过3年以上的人。我创造如果你在一家公司待很永劫光，对你的技能提升是很有帮助的。
1》 一直的重构代码，提升你的代码质量。
我们开始进入公司的时候，一样平常都是公司急需赶个项目人手缺少。等项目完成，一样平常都是1年旁边。如果你在公司待足够长的韶光，这个项目多多少少会跟你扯上边的，这时候，你会一直的翻看自己的代码，你也会不断的调度代码， 不断的重构你的代码——跟写文章一眼，你一直的看自己写过的文章，你会一直的做修正，越修正你的文章会越让你喜好。
2》业务熟习，能够更快更好的写出代码！
——我个人比较喜好“行云流水”似的觉得。
你如果在一个公司待了很长一段韶光，那么你对这个领域是非常熟习的。新需求上来，你会很快的知道怎么做代码架构，比如上面提到的，你就知道方法中，哪些代码部分可以抽出来，独立做成一个方法;你也会知道，将来什么地方会频繁修正的。——写代码，如行云流水般！
以上内容希望帮助到大家，很多PHPer在进阶的时候总会碰着一些问题和瓶颈，业务代码写多了没有方向感，不知道该从那里入手去提升，对此我整理了一些资料，包括但不限于：分布式架构、高可扩展、高性能、高并发、做事器性能调优、TP6，laravel，YII2，Redis，Swoole、Swoft、Kafka、Mysql优化、shell脚本、Docker、微做事、Nginx等多个知识点高等进阶干货须要的可以免费分享给大家，须要的可以查看详细资料
