2.6 C语言入职例程三：函数指针和程序框架入门

2.6.1 勿在浮沙筑高台

前文介绍过，很多企业的培训体系是这样的：

1. 新人入职后，师傅会给一堆资料让看，然后新人硬着头皮看一些；
2. 哪天师傅不忙了，惦记起这个新人，然后交给其一个产品，让其折腾；
3. 可惜真实产品一般都涉及多个学科，面对一大堆疑问，新人会感觉腾云驾雾般难以前行；
4. 一段时间后部分新人迈过了入职时的绝望悬崖，有了自己的积累，开始慢慢的深入接触产品，但因各种文档资料奇缺，只能一边学习一边调整；
5. 数年后，新人成为了老手，同时新的产品体系也诞生了；
6. 然后重复以上死循环。

如果没有刻意的训练和设计，大多数产品都是以这样的模式做出来的。这类产品的代码，会呈现出强烈的堆砌感，所有的软件功能是简单粗暴堆砌在一起的。没有严格的分层，各模块之间耦合繁杂，修改一个功能需要涉及到很多代码模块，通用的功能很难移植扩展……，最终的结局就是很多企业面对的困局：老人脱不了身，新人上不了手。

代码模块不应该是简单的堆砌在一起，优秀的产品是需要优秀的架构设计的。什么是优秀的架构设计，工控产品种类繁多，差异很大，很难有统一的标准。但如果产品代码大部分是C语言构成的，应该会用到相当量的函数指针。换句话说，如果我们的产品中几乎没用到函数指针，就表明我们还有很大的进步空间。

◇◇◇

不仅传统的堆砌代码，新人难以入手，即使是基于优秀架构设计的产品，新人如不掌握方法，也会难以入手。

我上大二时，一个快参加工作的同学找我玩，告诉我只要学好了VC6.0，以后找工作就可以随便挑了。那是1999年的事情了，实际上即使今天，很多企业软件依然在使用VC6，哪怕面临N多版本兼容问题，可想而知当初VC6.0的重要性。

一听到这个消息，我当然两眼冒光了。然后就去图书馆找了一堆书籍，照书画猫，一路step后，一个漂亮的程序就诞生了。惊喜之余，困惑紧随其后，生成的代码看不懂啊，这是C++语言吗？一大堆宏啥玩意儿，main函数在哪儿，新增加模块在哪儿写代码，……。

一边是赚钱的希望，一边是实际的困惑，进退维谷。记得那个时候，很长一段时间，我都非常困惑。幸运的是，在我一筹莫展的时候，一本书救了我，几乎是柳暗花明的感觉，豁然开朗。

该书叫《MFC深入浅出》，台湾侯捷先生写的，后来这本书被大家称为MFC四大天王之一。这本书一开始先从一个最简单的windows程序讲起，然后用模仿的手段帮大家理解MFC中的各种宏定义和背后技术，最后才是一个简单的MFC示例程序。

记得我当时将这本书通读完后，再去看默认生成的代码，再也没有那种晦涩难懂的感觉，所有的东西都是如此的亲切舒服。后来再学习MFC编程时，几乎是一马平川了。

为何会出现这种情况呢，我们首先来了解一下基于MFC编程的默认学习曲线：

以MFC开发程序，一开始很快速，因为开发工具为你产生了一个骨干程序，各种界面一应俱全，但是MFC的学习曲线十分陡峭，程序员从默认架构出发，到有能力修改程序代码以符合真实产品的需要，是一段不易攀登的峭壁。

增加《MFC深入浅出》一书的学习后，学习曲线如下：

从windows程序的入口WinMain函数开始，然后是窗口类别，然后是构建窗口，然后取得消息，然后分发消息，然后决定如何处理消息。

该书通过一系列模仿手段，让我们理解了MFC类库是如何将这些基础动作整合起来的，虽然初看走了N多弯路，但学习曲线却是台阶式的，条例分明的，整个学习曲线会缓和很多。

虽然目前学习MFC框架的人已经很少了，我也不推荐大家去学习使用，但这一段学习经历对我的职场生涯影响颇大，在我内心中牢牢烙下了一句话：“勿在浮沙筑高台”。

◇◇◇

同MFC框架类似，多年的迭代之后，我们的产品也呈现出框架思维。新人初接触这一大团东东时，也容易迷糊。怎么才能帮助大家迈过这个坎呢？

谈及架构设计，不可能回避面向对象设计思想，我们的产品中大量的使用各种面向对象设计思想。那么，是否可以从该方面入手呢？

我自己特别喜欢“四人帮”写的《设计模式》那本书，这本书很便宜，很薄，全是干货。有段时间，我强烈给大家推荐这本书，甚至花费很大精力，将常用的设计模式整理出来，供团队内部集中讲解交流，但发现效果寥寥。大家都感觉很好，但一碰到真实代码就无从下手。

后来反思这段打脸经历，我终于理解了知识是需要分级的，和入门者谈设计模式会被认为装叉，如同在贫民窟中谈论品味生活找骂一般。

什么样的架构