作者：CppExplore 网址：http://www.cppblog.com/CppExplore/
在这个blog上写了几篇技术文章，一是记录下自己对技术的一点浅显的看法，二是在自己的认知范围内揭示系统级别的核心技术，希望能对后来人能有一点帮助。从系统角度而言，技术本身只是实现业务的载体，业务才是系统的灵魂。因此除技术外，也准备写点其它方面的东西，大抵也就是写下面几个系列的文章，技术系列、业务系列、系统系列、测试系列、团队管理系列。以前本blog上起名为系统设计系列的文章，现已全部改名为技术系列了。
技术系列，在本人的认知范围内，探讨系统级别的核心技术，文章描述的都是技术本身，最终目的是建立公用的模块库，比如含消息队列的线程模块、状态机模块、定时器模块、对象池模块、log模块、网络层模块、管理接口模块等等。
从个人的角度考虑，开发公用模块，可以加深对系统整体的了解，能有更多的时间去了解新的技术、去认识业务的重要性、去考虑系统划分的合理性，不要陷入技术繁琐细节的泥潭，技术仅仅是工具而已，它们背后的原理都很简单。
从团队的角度考虑，开发公有模块，可以增加系统的可维护性、减少对新员工的培训成本、使具有不同业务的系统在技术细节上呈现一致性，形成开发的可持续性，减少对个人技术的依赖，不会因为某个核心人员的离职而造成后续开发的戛然而止。
公有模块开发导致的后果是减少对个人的依赖，因此有的技术人员可能对开发这些模块产生抵触心理。个人认为，技术是没有边际的，单个人是永远也不会掌握所有技术，单纯的技术也不是正确的职业规划，固步自封只能导致自己技术水平的落后。以开放的心态、职业化的心态去做实际的开发、去交流沟通，最终受益的是自己。
业务系列的文章写点本人接触过的业务，以公有协议为主线，mgcp、sip、rtsp、rtp、rtcp、加密框架等，协议本身、应用场景等，想想可写的东西也不多，和技术一样，都是很少很简单的东西。
系统系列，则从业务的角度出发，描述一些通用系统，也就是纯公有协议业务系统。比如说个媒体负载子系统，该子系统可以独立于信令协议，一个信令系统下可以挂载n个媒体子系统，可协同信令系统完成nat穿透、负载均衡、媒体流加解密等功能，使用私有协议和信令系统通讯，可定时比如60秒发一次负载个数信令到信令系统，一是作为心跳，二是作为负载均衡的依据。再比如一些顶层协议无关的proxy系统设计等。
从团队、公司的角度来考虑，开发公用系统的重要性不言而喻。开发公用系统也即开发工作由项目驱动转化为产品驱动、根据所做一系列项目的固有特点，找出事物的内在规律，合理划分子系统。
开发公用系统，可以降低开发的成本开销，便于公司去开发更多的业务，涉足更多的业务市场，从而形成不断扩大的业务市场，而不是以防守者的姿态，维护自己已有的甚至是逐渐萎缩的业务市场份额。
测试系列。测试团队的开发还是集中于业务层面的测试，白盒测试、稳定性测试还是要研发自己来做。写点自己的测试心得。虽然本blog上的技术文章远多于测试，但个人认为测试的重要性大于技术，不重视测试的研发不是一个好研发，也不会成为一个好研发，顶多是一个夸夸其谈的华而不实者。
团队管理系列，也或许不会写。但从职业发展的角度看，还是应当总结点，在不同的公司感受不同的管理，看看各个公司的相同点不同点，管理的初衷等。团队管理部分，个人看呈现下面几个部分:公司福利/公司制度、项目管理、技术培训、对员工的人文关怀、个人管理等。