我所热衷的编程生涯 连载(5)

    上篇文章说到解决UDP通讯丢包和乱序所采取的滑动窗口协议, 而我则更进一步将其改良成了并行滑动窗口协议, 精髓也无非在于解决发送等待的空耗问题, 具体细节可能后续还会因为涉及到整个平台的稳定性而提及. 这里就不啰嗦了.

    大家知道散打评书吧, 其特点就是说主题的时候会散出去说些相关的话题, 然后再散回来. 有点像游戏里做主线任务的时候顺道去做做支线任务, 然后还是会回来继续做主线任务. 并且主线任务才是大头. 我现在也发挥下这个功能吧, 从UDP通讯这块散出去吧, 虽然上回说数据库的时候已经想散了...

    其实细心的看客应该已经发现了, 我提及的技术细节并没有深入进行剖析, 为什么呢? 原因很简单, 开发的时候是不会有太多问题的, 真正的问题是出现在应用上的, 哪怕是封闭测试. 所以还是一步一步慢慢的将产品呈现出来的时候, 很多解决过问题的方案也会逐渐浮出水面的.

    这里我散出来要说的是关于自主创新这个问题, 我在有一个创新构思的同时, 有些朋友会告诉我, "网上有很多现成的", "同样功能的有很多产品啊", "费神费力做的研发其实已经有人在弄了" 诸如此类的话, 其实要表达的意思就是"算了吧,麻烦,吃力不讨好". 是的, 朋友的这些建议我是真的很认真的思考过, 可以用现成的, 可以用开源的, 可以用第三方的, 甚至可以买商业化的组件, 那么你作为一个研发人员的底气在哪里呢?

    有些事情其实并不一定需要用最简单的办法来实现, 然后再后悔简单的方法给自己未来带来多么大麻烦. 也许很多人都有这样的经历吧, 然而面对选择, 他又会选择简单的办法解决了, 省时省心, 结果有可能留下很多的隐患和不方便在后期. 比如我用现成的商业化第三方组件来完成我产品的某个功能, 效果很好, 但是后来出现不适应客户环境的问题, 联系第三方组件开发商进行解决, 然后翻来覆去的折腾...那么如果这个问题涉及到产品的核心机密呢? 你还希望用现成的吗?

    其实这也是搬运工的码农和专研技术的研发人员的区别, 码农首先想到的实现功能, 用简单的方法, 最好是现成的, 省事. 而研发人员则不同, 他会考虑的更深入, 更长远, 不被短期的"快速解决"所诱惑. 正所谓站得更高, 尿的更远, 你愿意别人怀疑你前列腺有问题吗? 如果真是潜心下来研发的话, 我想考虑的很多事情都会有一定的高度的, 也会变得更加细致. 也许你会花很长的时间去调试一段核心的代码, 调试完了再测试功能, 功能测完再测试性能, 稍有问题就进行深入研究. 其实我也蛮喜欢这种状态的, 当遇到瓶颈时, 你会显得很不安, 但反而不会烦躁, 会静下心来细细的琢磨. 当遇到技术点成功突破时, 这种喜悦是难以言表的. 也许真正的研发人员就喜欢这种爱恨交织的感觉吧.

   不过我觉得这种完全专注于技术的研发人员还是有所缺陷的, 他可能会因为太专注于技术反而忽略了研发的核心目标和终极使命了. 那就是产品...

    对于我来说, 没有什么技术会比产品更重要的, 但是产品又依赖于技术的构建. 所以我奉劝各位热衷于技术, 或者说沉醉在技术里的研发人员们, 别太深入变得无法自拔了, 你会迷失方向的. 高级的研发人员醉心的不是技术, 而是产品. 只有做产品才能让你的技术得到质的提升, 为什么呢? 一个专注于技术的人, 说白了他关注的是技术点, 技术面, 相对于整个产品来说只是某些部分, 并没有一个整个的把握. 而专注于产品则不同了, 你会想方设法的用各种技术手段来完善产品, 而又不去过多的纠缠这些技术细节, 但是对于产品至关重要的技术细节你又了然于胸, 那么高度是不是比码农要高那么一点点呢?

    有时候我会因为一张程序界面需要的图片, 去学习PS技术, 然后自己花大半天的时间画一幅还算不错的图片出来美化界面. 有时候又会因为想有更好的客户体验, 嵌入Flash在程序了, 而又去花时间精力学习Flash. 我的专注点在哪? 对, 是产品, 不是技术, 更不是代码. 真正一个强大的软件产品, 除了强大的执行代码, 还需要强大的周边设施, 文档, 界面, 解决方案什么都算. 所以别仅仅醉心于技术, 醉心于代码, 你会失去很多提高自己的机会去做一个真正的研发人员.

    今天散的够多了, 话又说回来, 我为什么会在描述UDP通讯开发过程的时候散到产品上呢, 下个帖子你就会明白, 因为每遇到一个实际的应用问题, 说不定都是产品得到提高的机会, 残酷繁琐却又那么的激动人心~

    未完待续....