最近php项目总结

1.需求整理

   我是长久的依靠产品经理了。现在没产品经理基本干不了活。这个以后得想法改改,估计以后再小公司混的可能性高点。

   这个项目产品经理只把前台的流程说了一遍。就开始了,后台基本没说。导致一些设计完全没考虑到这些问题。

   所以,一个明确的需求很重要。同时程序员要去不断的问产品,去发掘可能隐藏的需求,这个很重要。好多需求是在问产品的时候时候才发觉的。


2.数据库设计

  数据库设计很悲催的开始只设计了前台的,后来才不断的在加上后台的东西。这些导致了些问题。

  常用的一些经验:小字段,等

  索引一般在最后加上,同时发现实践中,并不是跟从一般说法。

  例如查询订单:我们肯定多半是查异常的订单,所以其实对于状态字段是可以建立索引的。因为我们不会常去查这些成功的。同时一般是和时间联合查的,所以建立时间和状态的联合索引是可以的,时间放在前面。


3.程序设计

      首先,面向对象绝对坑爹!

     其次,完全按照书本的面向对象更坑爹

     再次,php用面向对象还tm的坑爹。

     互联网项目,不知道领导给你们多长时间,领导说2星期搞定。其实我用了2个月(此次是重写以前的代码,其实以前这个项目他们2人用了1.5个月)多出来的时间,

第一是增加了以前的需求,比以前增加了流程。

 

第二我按照经典的三层架构mvc虽然是有框架。但是我又sb的一定得用有数据访问层,业务层,还好没用业务接口层,数据访问接口层。这样代码至少增加了50%。同时维护性并不一定增加了很多。反而在排查错误的时候,得一层层去追。多个文件中来回切换。反而耽误了时间。面向对象应用于底层简单可分离的工具类倒是十分的好。例如网络工具类,日志工具类等。同时复杂的逻辑,不同状态转换条件,这个如果按照金典的面向对象来分析,我不是面向对象高手,分析起来真的是很耗时间。不知道高手是什么样的!

   php的面向对象,鸡肋的感觉。首先调用方式 :: -》 这个得多打多少字母。偏偏字符其实是键盘操作不是特别熟悉的字母。其次,起实现方式跟数组差不多,反而调用方法和对象还比用数组多次hash查找。其实返回数组比返回对象反而更简单直接。再者,没有方法重载。这个让我很抓狂。同时又是弱类型的语言。两个加起来,不伦不类。最后,总是觉得有点浪费资源,有时候你明明只需要几个属性的值,但是对象返回,到数据库所有属性都返回了。关联查询的时候尤其觉得别扭。本来可以一个sql解决。但是为了所谓的对象,你得去三个对象中找。然后了你就查了三次数据库。

 

一些小经验:

    1.以前说了不用gbk了,这次一时头热说gbk可以减少存储空间。好,我就采用gbk了。结果坑爹啊。gbk有些字符是不认得的。偏偏我的系统中极其有可能出一些变态字符。后来一看我们后台调用的别人的接口也是gbk的。好吧反正他们也不支持,那就算了。同时js ajax是utf的还得转码。还有json也得转码。xml解析的时候也得弄成utf8再转回来。擦点点磁盘,现在都白菜价啊。即使说让索引少占空间,但是一般建立索引的字段都是数字型的啦。

         ok 坚决用utf8编码!坚定不移的一直用utf8吧。

 2.数字计算得注意

   能不用浮点型,坚决不用浮点型。对于有钱的计算,都采用分做单位。防止进行加减的时候精度丢失。一笔查1分貌似不多,次数多了就是大数字了。

  excel靠不住,兑账时候财务用excel的小数加减结果我们的账就差1分了。这里尤其注意,兑账时候有时候程序和财务对不上可能就是这个原因。

   php对比两个字符 最好用=== 防止我上个博文说的 “  12345” 和“12345” 相等的问题。


3.接口双方通讯

  记录所有的原始日志,以备查。

 再稳定的通讯,也有不通的时候,一定得考虑到对方收不到你的请求的情况。



评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值