典型的 C++ 程序员成长经历
一个典型的 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. 返璞归真
完
