php采集类 如何优雅地写PHP?
某移动互联网公司的开发人员小A写出来的代码经常被项目组的开发组长鄙视,组长会说“你这里这个条件写得太死了”,“这里的一个类方法太长了,要封装一下”,“你这个数组怎么来个
小故事: 某移动互联网公司的开发人员小A写出来的代码经常被项目组的开发组长鄙视,组长会说“你这里这个条件写得太死了”,“这里的一个类方法太长了,要封装一下”,“你这个数组怎么来个5维的,我表示看不懂啊?”等等之类表示看不起的话,接下来迎来的是小A的尴尬与表面上接受建议的搪塞,结果并没有多大的改观。其实小A跟猿哥说,其实他很不爽他们组长,也知道自己写的代码有时候跟面条似的,但是没办法,他接着说,这是因为他已经坚持这种code style几年了,在加上项目进度又很赶,想改但是根本没时间改。 猿哥评价: 你们组长说得有道理呢,但是我觉得既然你们选择了PHP作为项目开发语言,你们首先得订立一套开发规范,这一套规范应该由项目组长亲自输出,并在开发沟通会中跟其它项目组成员达到一致认可,另外开发规范是人定的,可以在适当的时候进行新规则的加入和旧规则的修改或摒弃。 (这是猿哥现在码字的状态!) 猿哥,说了这么多!我怎么感觉有点太理论(xu:太虚了!)呢,表示听不懂啊,能不能来点实操!好吧,下面是本猿给PHP开发小伙伴们的一些建议,权当是抛个砖,金玉良言的高手们,请不吝赐教,同时请针对自己的实际项目开发情景选择性地采用部分建议。 第一:数据输入(input ) 1)前后端(web或app)对输入数据的有效性检查 理由:避免无效的数据提交和混乱的字符输入,sql注入字符串等等多层级过滤,直接从源头扼杀 2)后端对数据输入频度控制(前端最好也能做一下) 理由:减轻服务器负载,例如某些无聊者利用一些灌水程序或者采集程序不停地想同一个接口发送请求,导致服务器过载等 3)前后端的权限检查(这个工作一般留在后端进行) 理由:这个地方一定要做好,不然就跟web程序后门一样,说不定哪一天一个离职很久的小伙伴因心情不爽,通过直接调用某个URL把一张核心表的几条数据给删掉了,结果你懂的 4)统一的入口行为方法(action),保证数据一致性 理由:生成数据的模板程序一定要统一,不管数据输入是来源于APP调用,还是PC端表单提交,还是H5 web端表单提交,甚至一些测试程序,这样就能保证修改若干生成数据的业务逻辑时候多个入口的统一(数据一致性,从源头避免脏数据),注意本猿在这里指的这个数据入口统一是指生成数据的model(logic)业务层面的逻辑统一,从而使得进入数据库的数据也可以保持绝对一致 第二:数据输出(output ) 1)输出view(json data)使用统一的输出行为方法 理由:数据的格式化都在controller层中控制,view层只做好自己显示数据的职责(猿哥,你是不是想说“单一职责原则”?嗯,是的),避免改了一处,错误两处,因为忘记了代码同步修改 2)跟第一的2,3条目保持一致 3)服务器404,500,502等故障时的兼容处理 理由:如果是app返回的数据最好还是json,h5或者pc web页,应该都是友好的自定义显示页面 4)错误日志,慢请求,慢查询日志等各种日志 理由:错误日志往往直接表示了代码层面的隐藏bug,慢请求或者慢查询日志直接表示了服务器的负载压力,会随时导致503,都应该定期检查,做好高可用可伸缩性检查 第三:代码组织 1)2层及以上的类继承结构,使用几种常用设计模式 理由:接口类->抽象类->实体类php采集类,这种继承风格已经在java中保持多年,其中蕴含了“生物进化论”的一些原理,十分周到。当然,几种常用的设计模式,例如单例,工厂方法等等,值得推荐 2)依赖注入,组件化组织代码 理由:DI(dependency injection)几乎成为每一个设计优良PHP框架的典型标记,可维护度很高,组件耦合度降低 3)写好接口文档与接口升级文档 理由:使用phpdocumentor给自己的代码写注释,便于输出风格优良的接口文档,因为总有一些你写的代码会让人摸不着头脑,如果没有同步的代码注释可以参考的话将会是极大的麻烦 关注“PHP技术大全”,phpgod,每天成长一点,成就大神就不远! (编辑:威海站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |