日常工作反思(一)

最近公司和亚马逊合作，把产品放到亚马逊上销售，虽说只有4款产品，但是销量很好，起初是让业务人员在CRM里面录入，但是订单量一大了之后就发现这样效率太低，会造成发货不及时的问题。
所以，业务人员找到ERP这边希望我们可以帮忙实现亚马逊订单批量导入的问题，组长欣然答应，我这边来接手开发，大致实现的逻辑是这样的，我们在界面上提供一个入口让业务人员导入一个Excel，然后程序对数据进行处理，实现订单的逐条导入。
其实开发一个导入倒也算简单，但是订单导入之后还需要做其它一系列的操作，比如同步到易飞，做库存占用，写入日志文件，这些都是同事要做的事情。在辛辛苦苦做完这些之后发现其实还是有问题，就是在数据表里每一种订单类型都对应网店类型数据表里面的一条记录，所以在将功能上线的时候需要同时在界面上新建一种网店的类型叫Amazon，这样在写esale_obj.browse(cr,uid,6),只有这样业务员在使用的时候才不会出错。
但是写完了这些所有的代码，在实际使用的时候还是发现出现了不少的问题:
1.同一个客户的两条明细，只计算了其中一条明细的金额+运费（粗心）
2.客户的国家代码使用的简称（业务需求）
3.加入库存占用和日志（自己粗心，没考虑到）
**4.不应该发邮件的，但实际上给客户发了（思考局限，没考虑到后面流程）
5.亚马逊单调拨出现错误的问题(思考局限，没考虑到后面的流程)**
先说第一个问题，其实是我开发的时候粗心造成的，在导入的时候没有严格检查，因为大多数客户下的单都只有一条明细，所以没去深究不用两条明细的这种客户订单正确与否，这个算是二级bug吧。
第二个问题：这个不用多说，不过我自己除了code外也要反思，某些地方是否可以改进
第三个问题：开发的时候时间限制，但实际上还是开发习惯的问题，我再一次觉得开发之前认真思考如何开发，有哪些功能点是多么重要的事情，一味忙着开发或许只会适得其反。
第四个问题：实际上是亚马逊那边反馈给业务人员，我才发现的，这个地方其实我不知道是会发邮件通知客户的，所以也没在意，但是就像第五个问题一样，说明了开发时先过一下全局流程的重要性，订单的整个业务流程是有关联的，改了一个地方，其它地方是否受影响是值得思考的。
第五个地方：其实是WMS（仓库管理系统）的同事发现的，我起初不任务是资产这边的问题，后来发现其实是因为我这边没有在发货的代码里面相应的增加发货请求导致的，但是这个地方也反映了发货这一块代码设置的死板，如果以后再加一种订单来源，这个地方又要增加，如果忘了增加又会出现同样的问题，所以那个地方是不应该写死的。
结语：开发一个功能，其实做好一些前奏工作，这样才能把尽量所有的细节都考虑到位，才不会至于前面刚开发完，后面就出现问题，问题流到了别人那里才被发现。