XML反序列化
摘要：
短信平台和支付中心在与某些第三方接口通信时，涉及到xml格式的报文。这时会用到xml反序列化成相应实体对象。 阅读全文
posted @ 2017-07-12 15:55 buguge 阅读(795) 评论(0) 推荐(0) 编辑
2017年7月12日 #
2017年7月7日 #
巧用CurrentThread.Name来唯一标记一次请求的所有日志（完结篇）
摘要：
设计软件，面向业务来设计，例如用一个自定义的变量来保存参数。这样不管这问题中不同的过程被调用时在同一个线程还是不同线程，变量的值都是一致的。
如果“高大上”到过分技术层面，由于我们不了解技术底层和问题，所以反而弄巧成拙。 阅读全文
posted @ 2017-07-07 19:37 buguge 阅读(305) 评论(0) 推荐(0) 编辑
2017年7月6日 #
巧用CurrentThread.Name来唯一标记一次请求的所有日志（续）
摘要：
一个ashx文件，在其构造器里给当前线程的name赋值。通过post方式流请求，测试发现，在给HttpWebRequest传参和不传参的两种情况下，传参时ashx的ProcessRequest方法里获取不到线程name，而不传参可以正常获取到。
由此，问题来了，Http流请求传参和不传参这两种情况有什么区别呢？ 阅读全文
posted @ 2017-07-06 12:01 buguge 阅读(577) 评论(1) 推荐(0) 编辑
2017年6月29日 #
巧用CurrentThread.Name来唯一标记一次请求的所有日志
摘要：
即，应用程序对每一次请求的处理过程所记录的日志统一打了一个标识。 这样，在系统运维过程中进行排障时，尤其在并发请求的情况下，即使日志记录得你中有我我中有你，也很容易就可以查到处理某次请求的来龙去脉，进而帮助我们快速定位原因。我对这种日志记录实现方式屡试不爽。 阅读全文
posted @ 2017-06-29 21:58 buguge 阅读(636) 评论(0) 推荐(0) 编辑
2017年6月23日 #
多类继承情况下适应变化设计一例
摘要：
8个派生都这么改还是挺麻烦的，也违背了OCP原则。另外，从领域的角度来说，logFlag参数与整个功能并无关系，只是为了完善记录日志才“生硬地”加这么一个参数。所以，上面的实现方案不妥。改为封装一个LogFlag属性。这样，只需修改基类，派生类无需任何改动。调用方在实例化对象后，可以为LogFlag属性赋值（if possible） 阅读全文
posted @ 2017-06-23 21:46 buguge 阅读(450) 评论(0) 推荐(0) 编辑
2017年6月16日 #
溢+渠道对接之北京农商订单结算需求产品方案
摘要：
溢+支付是公司刚投产不久的项目，还有很多的事情要尝试、摸索、探索，项目内缺乏专业的支付人才包括结算、运营、产品和技术，对于创业公司的这种项目，而不是总是想着大而全。那样只会耗费人力和时间成本。单就支付渠道对接来说，我们对接的渠道也有十几家了，但是，目前在商用的也就是中信、易宝的支付和代付，更多的对接工作变成了无用功。这其中，大家免不了相互吐槽，带来负能量。所以，小步稳跑或许才是比较好的节奏。 阅读全文
posted @ 2017-06-16 22:51 buguge 阅读(307) 评论(0) 推荐(0) 编辑
分享一种系统事故&问题处理反馈方式（COE）
摘要：
COE（Correction Of Error）是我们在JD研发部时使用的一种事故&问题处理反馈方式。 阅读全文
posted @ 2017-06-16 17:24 buguge 阅读(3967) 评论(1) 推荐(0) 编辑
2017年6月10日 #
支付中心接口设计之参数命名
摘要：
产品设计上有一条重要的原则：Don't Make Me Think，同样适用于软件设计 阅读全文
posted @ 2017-06-10 21:07 buguge 阅读(908) 评论(1) 推荐(0) 编辑
2017年6月1日 #
2017年5月22日 #
“技术诚可贵，领域价格高”
摘要：
之前的一些重构，由于缺乏聚合支付方面的领域知识，是有些欠火候，一些解耦和封装，连自己都认可不了。也就在近期，将支付中心做了一次系统性的重构升级。 阅读全文
posted @ 2017-05-22 20:16 buguge 阅读(289) 评论(0) 推荐(0) 编辑