一个典型的 C++ 程序员成长经历:
1.
完整的学一遍 C++ 所有语言特性,典型书籍
"The C++ Programming Language" Part1, Part2, "C++ Primer"
感觉 C++ 像大杂烩(多编程范型),各种精妙的语法特性 (friend, virtual/RTTI, const/mutable, exception, template),太多精妙的东西容易导致记忆琐碎化,学了又忘了,尤其是那些很少用的部分
实践:编写一些带 class 和 virtual 字眼的所谓的 C++ 程序
2.
树立 C++ 的规则,明确在 C++ 世界“合法的并不一定是合理的”,典型书籍
Effective C++ 系列
有些东西可用 C++ 写,但一般情况下并不合理,如 protected 成员数据, 覆盖 non-virtual 成员
实践:发现 C++ 有强烈的语义约束,和次语言 (sub-language) 范畴,开始写一些规矩的代码
3.1 为了使上述的约束更加形式化,开始使用
设计模式,典型书籍
"The C++ Programming Language" Part4, "Design Patterns"
实践:教条的套模式,与人协作,编写真实规模的程序
开始想:有时传统的设计模式对 C++ 很难看 (OO),有没有一种原生化的 C++ 模式实现思路(以便利用 C++ 的高效性),开始对静态类型系统和模板推导着迷 (GP)
3.2 为了开发快捷,开始使用
标准库,典型书籍
"The C++ Programming Language" Part3, "The C++ Standard Library", "Effective STL"
光用标准库是不能满足真正的 C++ 程序员的好奇心:auto_ptr, iostream 这些精妙的东西是怎样实现的?string 的开销究竟有多大?functional/alogrithm, iterator, container 这三者是怎样分离的?
于是开始阅读某个标准库实现(典型的是 HP-SGI 的实现,但建议 Windows coder 读 MSVC 的),并尝试自己的等价实现,虽然可能只是标准库的一部分功能。这里一个很大的驱动力是重视 C++ 的高效性
至此,已经知道如何在 raw/smart pointer, char*/string, static/dynamic bind, array/STL container 之间抉择
实践:编写可稳定工作的程序,重视模块的复用性和扩展性,并理解将书本模式(学院派)实化为优质的 C++ 代码之间的鸿沟
4. 插曲:3.1 和 3.2 过程会交替重叠进行,并导致
重学 template C++ 这个次语言,典型书籍
"C++ Templates: The Complete Guide"
5.1
玩转 template C++ 和 GP,发现它是超强的代码生成器,和模式塑型器,典型书籍
"Modern C++ Design"
开始进入一种偏执狂式的 GP 和模式应用状态:
1. 把所有的实体都对象化, wrapper hell
2. 把所有的概念都抽象化, abstract class/factory
3. 把所有的行为都策略化, 动态的: strategy, 静态的: traits, policy
4. 把所有的实现都向标准库靠拢, Think in STL: every IO is iostream, every algorithm uses iterator, every container is type-safed and nonintrusive with specialization for optimization
成也萧何败萧何:炫技和实用只在一念之间
至此,几乎每个 C++ 程序员手上都有自己的一个 semi-STL 的私人库,那是多年的积累
实践:编写工业强度的 C++ 程序,你的一部分代码(库)可能以开源或闭源的形式供他人使用
5.2 开始使用
一个 Think in STL 的叫做 Boost 的东西,于是你对 Boost 做了和上面 STL 同样的事,典型书籍
"Beyond the C++ Standard Library", "Boost Docs", "Boost 程序库完全开发指南"
也许还对 C++11 感兴趣,现在可用即 TR1,典型书籍
"The C++ Standard Library Extensions"
实践:以较高的效率编写工业强度的 C++ 程序
5.1 和 5.2 过程会交替重叠进行
6. 过度的玩 template C++ 将会导致
元编程,典型书籍
"C++ Template Metaprogramming"
尽管它很炫耀,但生产环境中却很少用
补充:既然认为 TMP 是 turing-complete 的,并且秉持 handy coding 和 compiling is running 的理念,实际上你是需要一个动态语言(把 C++ 编译器当解释器用,而且还不能调试)。再将范围缩小:从目前 C++ 社区工作来看结合最成熟的 interop语言是 Python
实践:地球很危险,回火星去吧
7. 一个高质量的 C++ 程序所在的商业项目失败了,导致你
陷入沉思
考察失败的可能原因:
1. 商业决策,和 C++ 无关
2. 其实是部分高质量 C++ 程序,高质量的模块由优秀程序员编写,其它人的很烂
办法 1. 你很喜欢现在的团队:循循善诱那些新手,让他们经历你的至少 2-3 阶段,短时间领悟是不可能的,你很清楚
办法 2. 离开去找和你水平相当的人,记住:C++ 是真正懂它之人的利器,而是一知半解者的绞绳,还不如完全不会用 C++
3. 过度的个人炫技,导致代码复杂度过高
不易理解、难维护、开发时间长
4. 需要一个度
1. 实现复用性和扩展性的难度不宜超过团队的平均水平
2. 团队的平均水平不宜低于同类产品开发的市场竞争者的平均水平
5. 需要一个目标和态度
1. 以制作可交付使用,可工作的产品为终极目的
2. 做最好产品,而不一定用最好的技术
8.
返璞归真