前言

Java/Go语言都内置了反射机制，支持在运行期获取类/方法/属性的信息。反射机制有很多的应用场景，如最常见数据的序列化，如果没有反射机制，要么是基于代码生成，如protobuf；要么是一行行的手写代码那是纯体力活。

C++并没有内置的一套反射机制，实现反射机制也是C++经常讨论的话题。考虑到C++有强大的元模板编码能力，准确的来说，C++在编译期间是有些自省能力，提供一些is_xxx函数集合以及模板萃取能力，只是不支持动态反射，因为它没有像Java/Go语言拥有运行时环境，且在编译期能力非常孱弱与难用。

C++有不少的开源第三方反射实现库，他们实现方式无外乎二种：

• 编译时反射：在编译时进行类/属性/方法的遍历 ，且遍历支持用户进行过滤，为类/属性/方法提供静态的附加元信息，并把他们保存起来提供运行时API
• 运行时反射：提供一套管理框架，在运行时对类/属性/方法信息进行注册管理，使用时再从框架获取对应的信息

前一段时间定位某一C++写的老产品（20年+）的问题，无意中发现代码中有运行时反射的影子，只是代码并没有把这个反射概念进行提炼，代码比较零散。

前言

在C++简单依赖注入一文中，利用C++类的static变量初始化特性实现了简单的依赖注入框架。你是否还有印象，其中还同时利用C++模板编程另一个特性CRTP：把派生类作为基类的模板参数。

template<typename T>
class ManagedObject {};

class A : public ManagedObject<A> {};

CRTP又是什么鬼？CRTP (Curiously Recurring Template Pattern)，翻译中文是奇特递归模板模式，它到底奇特在哪里？用法看起来有点奇怪，怎么能把一个对于基类未知的类型传给基类呢？在C++模板编程中，这一切皆有可能。

前言

前一段时间参与定位Tomcat某一问题，涉及到sendfile系统调用。忽然想到之前一些使用经验，知道Java领域中有不少开源软件，都应用了零拷贝来提升其性能，于是有了本文。看看我们这些耳熟能详的软件吧，你是否曾了解过他们背后应用的技术点：

• Tomcat: 使用sendfile把大文件写入Socket，提升静态文件数据传输性能
• Netty: 统一的ByteBuf机制，对DirectBuffer封装采用堆外内存进行Socket读写；也支持使用sendfile把文件缓冲区的数据发送到目标Channel
• RocketMQ：使用mmap内存映射文件方式对CommitLog文件读写，当客户端消费消息时把内容写到目标Socket

本文是对网上知识点的收集与整理而成，在此分享给大家。本文中【OS层】章节中介绍零拷贝技术的部分内容与图片来源于看过就懂的java零拷贝及实现方式详解，在此先致谢。

前言

前一段时间看某一老产品的代码，是C/C++混合编写的代码，代码中充满了全局变量，并采用extern引用外部全局变量。问题是由于类与类之间存在依赖关系，如果都通过构造方法传入依赖，会导致整个对象依赖图构造复杂。对于上了年头的老代码，采用全局变量+extern引用能够简单粗暴地插入要新增的调用关系，但也带来了代码上腐化。

在我司新的C++融合编程规范中提到：

禁止通过声明的方式引用外部函数接口与变量。

只能通过包含头文件方式使用其它模块或文件提供的接口。通过声明的方式使用外部函数接口变量，容易在外部接口改变时可能导致声明有定义不一致。同时这种隐式依赖，容易导致架构腐化。

避免使用全局变量(节选)。

使用全局变量会导致业务代码和全局变量之间产生数据耦合。在不同编译单元的全局变量以及全局常量的初始化顺序没有被严格定义，使用时需要注意他们的初始化是否有相互依赖。

一个完整的应用是由一组相互协作的对象组成，开发人员要关注如何使这些对象协作来完成所需功能，并且要低耦合、高聚合。如果有个框架出来帮我们来创建对象及管理这些对象之间的依赖关系，那我们只需要聚集于业务逻辑。作为同时写过Java代码的老兵，了解管理依赖是Spring的设计初衷之一。Java天然具有动态反射能力，为IoC框架实现提供了基础。但C++并没有反射能对类的自省，如何实现一个简单的IoC框架？

案例

在我司新的C++融合编程规范中，提到避免定义C风格的变参数函数：

为了避免类型错误，应当使用可变参数模板等其它的方式来代替va_arg可变参数。

规范中也给出了一个简单的示例，像我这种有使用过的经验感觉示例有点意犹未尽。去年年底我使用C++写一个小工具，其中就使用可变参数模板封装了一个日志接口，同时参考了Java slf4j日志用法，支持占位符。正好借这个代码的来温习与讲解一下可变参数模板，感受一下C++模板编程的魅力。

前言

追求软件产品竞争力的企业，都会追求研发效能极致。对研发效能提升的投资是非常有价值的，因为如果一个开发者每天节可以节省一小时，即使一个50人的开发团队，总体节省的数字是非常可观的。

研发效能提升不仅仅是要提供更好的编程规范，开发工具，快速获得的流水线等硬件，也要对开发者提供贴心的软服务。因为目前软件开发不再单体活动，是一群人协作完成。因而个体问题转变了成社会问题：大家如何高效地协同、沟通和互动，团队与环境如何对开发者的工作产生影响。

软件开发要以人为本，对软件开发者群体进行研究。比如开发者之间是如何建立关系，关系是如何的管理，如何让参与者都有意愿，聚集有价值的活动，产生更大的能量，最终开发出有竞争力的软件。

前言

在我的多篇博文中提到软件开发需要师傅带徒弟，如在谈到Commit活动中，师傅们应该积极利用Commit活动，通过对代码检视，发现问题，帮助软件能力提升，养成良好的工作习惯。再如在谈到软件传承时，提升明确建立了师徒关系，师傅在日常开发中，通过言传身教，传递对代码的价值取向，精益品质追求。

在敏捷软件开发方法中，也提到“结对编程”：两个程序员在一个计算机上共同工作。一个人输入代码，而另一个人审查他输入的每一行代码。输入代码的人称作驾驶员，审查代码的人称作观察员（或导航员）。两个程序员经常互换角色。

结对编程的目的一方面是对软件质量的看护手段，另一方面则是让参与的程序员能够提升自身能力。程序员结对工作的时候，水平较低的一方会潜移默化地受水平略高的程序员影响，学到新的东西。而水平高的一方同样因为不断地把自己的想法说出来，过程中会整理与完善自己的思路，是一个相互促进的过程。

师徒结对就是通过传、帮、带，通过互助、互信、合作来促进团队的软件开发专业能力的提升。

前言

我司很多的软件产品生命周期非常长，甚至还有20年前开发的软件产品还在网上发挥重要价值。前一段时间参与某一开源软件的自维护，分析其软件发展历史，发现它第一个版本开发于1999年，2002年重构发布2.0版本，到现在已历经了20+年。它的版权与主要作者也几经变化，最后成为Apache的顶级项目。无论是商业软件还是开源软件，越是基础性的软件，其生命周期越长，需要长期维护，软件也不可能由一个人或者一个团队自始至终开发、维护，软件需要传承。

软件产品生命周期的80%时间可能是维护阶段，在大规模开发阶段会留下很多"资产"。如开发过程文档，像我司基于DBOX的文档管理方式，侧重于权限控制，而未考虑使用体验。每个版本每个阶段的文档不同的目录管理，几年下来积累的各种文档散落在各个目录，文档间割裂缺少连续性，无法维护和使用。如几十上百篇的各个需求设计文档，在后期的维护阶段也没有人愿意去看，并且能看懂，原因是与现有代码实现严重脱钩了，文档起不到期望的软件传承。

我们耳熟能详的2G，3G，4G等，通讯技术似乎每5到10年有代际，不断地演进发展。那纯软件技术是不是也有代际？有。软件有继承才有发展，如我们部门某一软件产品从部署形态来讲，从早期的单板嵌入式，到X86虚拟化，再到现在全容器CloudNative化。从支持协议来看从传统的7号信令接入，再到全网IP化。软件一直在随着技术的发展在演进，包括其技术架构，交付形态，功能构成等都在变化中。软件传承相比软件维护并是不要发展，而是顺势而为，持续可交付与迭代。

今天趁着元旦有点时间，瞎聊糊侃一番软件传承，软件的传承有其特殊性。