2016.05.19
这近一个月的关于两个产品的维护，真的是很辛苦。可是收获却并不多，大多都是一些小错误的修补，更多的是一些处理问题的方式希望可以在今后受益。其中，在修改一个功能点的时候，自己还是没有读懂需求，耗费了很多不必要的时间。需求其实只是让我增加一个提示，但我的想法是能够不额外的增加提示代码，通过调整保存数据的逻辑，让提示能够自动显示。但是最终自己陷入了数据保存的泥潭，因为涉及到流程的变更，改动的范围太大了，最终只能回退代码，老老实实添加一个if判断给出一条提示。一定要理解需求啊，3个工时事耗了30个工时，真心塞。另外，不要轻易改变业务流程，不要自作聪明！
2016.04.14
酱油。今天是科比的最后一场球，好久没摸篮球了，感觉是篮球抛弃了我，而不是我放弃了篮球。
2016.04.13
忙，现在维护两个产品。
2016.04.12
周二比周一还要忙啊。以后、任何时候在涉及到除法运算时，都要考虑除数是否为零的情况。很惨痛的经历，一没考虑到月绩效奖(￥600)就没有了(┬＿┬)
2016.04.11
周一忙成狗。
2016.04.06
酱油。有空研究一下Control.Refresh()，还蛮有意思的，程序还在等待，控件内容就刷新了，怎么感觉有点异步的意思。
2016.04.01
酱油。没事就研究了一下公司的报表项目源码，被以下代码震了一下，看来要熟悉一下位运算，以及消息机制了(⊙ｏ⊙)
2016.03.31
酱油。哼(ˉ(∞)ˉ)唧
2016.03.30
酱油。仔细想想倒是一篇博文挺有意思，传送门，博主通过经营外包公司过程中对比JAVA和.NET的接单率而发表了一些对.NET市场的看法。评论有时比博文精彩！
2016.03.29
今天主要解决的是业务上的问题。商锐9.5中，进行班次管理时，可以设定‘销售收银日期记班次日期’。这看上去是个小设置，开启后把原来收银日期的字段保存为班次日期即可。但实际业务中，收银员所在班次涉及到跨天时就遇到了不少麻烦。例如第1天晚上10点到第2天凌晨4作为晚班，实际业务中29号晚上10点后到30号凌晨4点前换班的收银员，他所在的班次号都为20160329。该收银员在29号所做的收银操作在软件中好处理，操作时间原封不动的存进去即可。但到了30号时，同时收银日期需要登记为班次日期，操作日期如何处理？考虑到收银对账对日期的要求，之前的设计是直接将操作日期保存为班次日期，结果导致第2天(30号)结算打印时，日期都变为了前一天(29号)，这样客户拿到小票后会很纳闷为什么日期提前了。同样，小票的重打印也会出现上述问题。设计当初，添加设置时，前人很可能对整个业务逻辑的影响并没有考虑清楚。另外，做软件的人还是要融入生活，多思考多设想。
