项目经验分享

感觉很少有人写这类东西，而我最近终于在大神的带领下完成了一个项目，所以特此记录下自己在本次项目中的收获。

项目简介

是使用thinkphp 3.2.3版本开发的一个报价网站，供应商可以在该网站注册，注册时需要上传营业执照之类的图片，在后台经过我们公司的相关人员审核后，就可以登录后台管理页面，上传自己的商品。然后在前台页面就会显示该商品。

难点１ 图片上传与删除

我们采用的阿里云的OSS服务来保存图片的，所以用户上传的图片都是上传到我们的阿里云服务器，之后再发送到OSS上。难点就是我们不想冗余很多多余的图片，而且还使用Ajax实现图片上传，具体的情况我在前面的博客里介绍例：

Ajax和OSS文件上传和删除

里面我讲解了如何使用临时bucket减少删除的操作，从而加快图片处理的速度，但是其实还存在问题，那就是当用户在编辑时，当用户上传新图片、删除该商品等间接性操作图片时，我们也需要将旧图片进行删除，否在当我们更新数据库信息后，我们就无法失去旧图片的object名称了。该图片就会作为冗余数据保存在OSS中。

结论：

• 图片上传类操作还需要优化

难题２ 商品属性录入方式

原来我们采用的方式是模拟ECSHOP的商品属性录入方式：ECSHOP属性录入方式，ECSHOP采用的方式是设置一个类型(Type)，当用户输入一个商品的属性时，就选择一个Type，然后填充该Type下的属性。当初觉得没有什么问题，但是在实际情况中，存在下面的问题：

1. Type不能由供应商来设置，否则会很乱，所以只能我们预先设置几个Type来供供应商选择。
2. 可是，这很难在现实情况中来实现，商品的属性很灵活，我们根本没有能力保证我们预先设置的属性能满足供应商的需求，所以只能在供应商需要额外的Type时，联系我们的后台管理人员进行添加，着实是既麻烦又耗费人力物力。
3. 曾经设想过，将Type添加的权限开给供应商，使供应商能自己添加自己所需的Type，然后由后台管理人员进行审核，但是由于项目第一次迭代已经到了末期，所以这个改进被取消了。

结论：

• ECSHOP采用Type的模式进行添加是因为ECSHOP面向的是小型个人电商系统，使用者自己能很方便的添加自己的Type属性，而且由于是小型，商品之间跨度不大，所以商品属性也不会很复杂
• 但是我们这次的项目目标就是面向多种供应商的，所以当初采用Type来进行商品属性进行添加时，没有考虑到这一点，多种供应商，商品属性的类型会很丰富多彩，所以属性的添加只能由供应商自己进行添加
• 如果下次有改进的机会，则将Type表删除，用户直接在商品添加页面添加属性名，以及该属性下的可选值，还有该属性的类型，这样自由灵活的方式才能满足众多供应商的情况。具体的表结构我后面再想想。

难题３ 排序

我们有一个页面是显示所有供应商的，但是当供应商比较多的时候，就需要进行分页，问题来了，越前面显示的供应商，广告效果越好，那么在后台怎么设置该排名，我采用的设计方式。

总结

• 用户体验之上！

你编写的程序是给别人用的，所以操作一定要简单，越白痴越好，越简单越好。不要期望用户能主动来适应你的软件，而是你的软件足够方便使用才能吸引到用户。

比如我上面说的几个难题，对于用户来说，很多功能对于他们来说是只会按照自己的习惯进行操作的，以图片上传为例，如果用户在上传图片之前主动删除旧图片，那么就可以减少我们图片的冗余，但是他们更加习惯的操作是直接上传新图片覆盖旧图片。我们能怎么办，只能说你们是大爷，你们高兴就好。这个时候就呵呵好了，然后挑战自己，超越自己，放心，一起超越的还有你的工资。

• 经验，经验，经验

比如上面的难题２，我们当初只是考虑了如何录入商品属性，却没有考虑到后续会面临的问题，实际上也真的是我们的经验不足，虽然有点推卸责任的味道，但是这是事实，我的经验确实不足，这不仅仅是表现在具体的编程知识上，更是社会经验上。好在我心态好，又肯认真去学，所以经验以后会越来越多的。

• 不仅限于过去也敢自己解决

还是以难题２为例子，当初一心想靠着ECSHOP的设计模式进行解决，但是也就是太拘泥于ECSHOP才让我们没有看到更好的解决方式。而其中的难题３排序的解决思路，则是我一边散步一边思考如何解决该类问题的时候，突然想到的。第二天上班的时候，我把我的思路跟一个拥有两年编程经验的大哥说了，他回答是他没有尝试过这种解决思路。而事实证明，我的解决方案暂时没有出现较大问题。所以勇敢一点，不要给自己的人生设置那么多的限制，也不要给自己找太多接口，人的潜力是巨大的！相信自己！