标签：
今天早上一醒来，忽然想到一个可怕的事情：发现2016年的工作如果还在这个组里，我得担心是否KPI会给C（最差），得担心BOSS是否给穿小鞋。
虽然我知道以自己的能力应对工作是游刃有余的，但是这个想法还是吓坏外了我。然后我忽然又想到，一年里如果是浑浑噩噩的过完，和15年一样，还要继续花很多时间跟踪用户问题，那更是一件非常让人害怕的事情。
那理所当然的就在想，是否可以去做别的?我想了下，可以去另外一个组里做中间件开发，何必为难自己因为KPI什么的操碎了心？
所以我决定年后换组，可以在新的一年里既能学到新的东西又能有所产出，还能够对得起自己，做好这个决定后，我心里是非常开心的，感觉郁闷的一块忽然没了。也许新的工作里可能有一些不好的，但是总比现在要更好一些。
然后我就去找了CTO（那个组是他直接领导的），自然很轻松的做好了约定。过完年，就可以换了。
今天BOSS找我，让我帮助组内的其他成员把一个移植的程序调通，可以跑起来。嗯，我一想到自己都要换组了，心情非常好，嗯，就答应了。然后那个什么移植程序，分分钟就搞定了..
问题都是出在新集成的一个网络库，也是我司内部开发的，UDP部分做的比较粗糙，这个网络库的代码我也看过，但是对其不以为然。
针对遇到的问题，其中一个是udp_create后，需要调用一个udp_bind，这个函数是把一个SOCKET和IOCP的句柄绑定，然后发起WSARecvFrom，这是个非常蛋疼的设计和实现。
因为这样会让网络库用户把逻辑里认为的create之后就既然内部bind了IOCP，也自然的发起了WSARecvFrom，但是这个udp_bind硬生生的把这个行为逻辑给打破了。
除此之外，没有对udp_create返回的句柄提供设置SOCKET属性的API，比如用udp_create创建了对象，但是我需要往一个255.255.255.255上发送数据，但是也没有提供参数可以让我启用SO_BROADCAST属性。这也是个蛋疼的事情。
然后就是这个程序的通信协议也做了修改，这个修改是二进制不变，只是变更代码的形式。但是这个改变非常蛋疼，也是属于一个拙劣的设计。
我司的大部分产品都是自定义协议格式（产品已经十年了...）原有的代码形式虽然看上去很挫，但是工作良好。
原有的形式不好的地方是在于一些协议内部如果包含了类似可变数量的字段时，是没办法用c++11的range-for或者std::for_each遍历的。
原谅一个十年的产品代码吧，也别问我为什么那个时候没有使用std::vector。要知道在那个年代，很多人认为STL是低效的。
虽然现在这个移植程序做了协议形式的修改，支持了std::vector，但是我觉着它也没有变得更好用。因为还是老协议格式嘛。没太大意义。
然后下午又顺便去听了一个测试妹子分享的PYTHON在测试中的应用。嗯，当然听她讲了下，我觉着这个妹子非常适合做程序员，至少我觉着比今天上午辅导的那个毕业生小伙子强太多了。
然后看了下她写的代码，整体上至少逻辑是清晰的，虽然很多地方代码组织看起来不是很美观，但是比那毕业生小伙子要明白一个程序大概怎么写。
妹子还说她使用python时遇到了哪些问题，然后怎么解决的，我觉着也非常的棒，她知道怎么描述遇到的问题，知道去哪里找解决方法，或者知道去找什么人来帮她解决。
我以前对这个妹子是很烦的，整天跟个妇女似的，但是今天彻底让我亮瞎了眼。
嗯，今天总体来说还是非常开心的，所以晚上喝了杯岳母大人酿的米酒，好喝不上头！
以上.
标签：
原文地址：http://www.cnblogs.com/concurrency/p/5161637.html
