标签：
每年公司都会进行小范围的组织结构调整， 今年被规划做产品需求相关的工作，欣然接受了这个挑战 。 以前一直求之不得，万万没想到调岗之后却让我做了我最想做到事。
公司在员工的个人规划方面做得真的差强人意。如果你擅长做一件事， 然后能够稳定的输出成绩，他永远都不会考虑将你的级别进行调节。直到你开始蹦跶起来，甚至让他感觉到你可能要离开公司，公司将失去一个技术核心骨干的时候， 才会认真的思考和安排你的职业规划。 这是一种博弈。
好在自己足够的自信和有底气，一切都没有脱离自己的控制和规划。
在一个纯技术研究的部门里待了五个半月 ， 做了两个VC++的项目， 一个外挂文卷浏览服务器程序，一个基于现有平台技术的数据协同平台。 前者将PLM产品集成第三方设计软件图纸数据的浏览简化封装到了公司的平台上，然后基于公司平台的二次开发可以快速的针对浏览图纸进行集成开发 。 数据协同平台是对公司的现有平台进行了分布式的改造， 将单客户端的处理平台函数库增加了适用于服务端的平台函数库， 两套平台分别部署在客户端和服务端可以进行连接交互。 好处是摆脱了客户端对于ODBC等中间件的依赖，服务端对于IIS等部署较为复杂的服务端发布程序的依赖。 然后网络层传输的数据，传输的频次都变得可控。 对于控制网络传输数据的规模，安全性都有了配套的对应的优化解决方案。 特别是对于表缓存技术在客户端和分布式服务端上的使用， 大大的减轻了数据库的负载压力以及客户端的响应速度 。 另外倒逼了基于平台的客户端程序在设计代码时的优化改进。
用到了动态链接库技术，windows 服务程序， TCP/IP 网络协议， 多线程，数据库连接池，普通结构化查询语句的请求与表缓存的操作封装。 熟悉了大量的windows API , MFC框架。 在OOD 方面积累了宝贵的经验。 这五个月过得非常充实， 技术得到了比较明显的提升， 也提升了自己的自信。
在这五个月的空闲时间里研究了linux下开源的分布式文件系统， 主要对轻量级的分布式文件系统 FastDFS 有了比较深刻的认识和理解。 在前年使用C# 基于WCF也做过一个分布式文件系统， 作为公司产品的一个亮点已经发布运行了两年， 得到的反馈还不错， 产品功能也比较稳定。 但是IIS的部署，windows下的权限设置等操作给产品的实施人员带来了一些挑战， 顺带着让我也做了不少这个分布式文件系统的技术支持工作。 本来今年的安排是打算使用TCP/IP 自己封装一套分布式文件系统， 一方面是减小实施人员的部署难度， 另一方面国家对于国产软件的支持，对微软产品的不信赖政策上，放弃IIS , C#相关的方案也是客户的需求。
可是公司组织结构调整之后，对于这些替代性的解决方案公司反而不是很看重了， 分布式文件系统的改造工作优先级也降低了。 对我的安排是一半的时间做一个成熟产品的需求分析，将客户的需求规格化到概要设计这个阶段。 另一半的时间是维护前期做的分布式数据协同平台。
值得一提的是， 公司的平台已经维护了很多年，由两到三个在公司待了十几年的技术大牛维护， 平时代码量的改动比较小，属于精打细磨的那种维护， 产品很稳定 。 现在加入了我写的这一块分布式相关的代码之后，代码量改动比较大，虽然我已经做了比较好的边界处理， 在代码的结构上也单独的封装了核心类 ， 但是两个大牛明显不是很放心， 要自己逐行走查代码然后才会捡入到代码库中。 这个捡入到目前已经过去了一个月了， 还没有正式捡入。自从我提交了数据系统平台的代码，转手接了其它的任务之后， 在开发分布式数据系统平台时跟着我的一个小兄弟最近被这两三个技术大牛折腾的痛不欲生， 大牛们总是在提各种各样的需求与猜测，要求出各种各样的测试样例 ，还要求出测试数据， 而且想法比较跳跃，任务的安排比较随性， 进而导致工作效率不那么高。谨慎也是好事， 但我看到的是大牛们这些动作后的惊讶。 这个时代对于程序员的要求越来越少了， 不用熟背API , 不用写汇编就能很好的胜任编码工作， 还开发出来的东西比较快 。 大牛们明显有一种不怎么情愿接受现在的年轻人也很厉害的事实。 希望我成为大牛的那一天没有这种傲慢与偏见。
做需求的这方面有很深的学问， 已经接触到了不少非常厚的资料。 在掌握工作方法和提升工作技能方面是接下来的主要精力占比点。
标签：
原文地址：http://www.cnblogs.com/meaningful/p/5277103.html
