软件工程

C语言嵌入式系统编程修炼之二:软件架构篇

本文是专题:程序员修炼之路中的第4篇,共5篇

作者:宋宝华 来源:天极网

朱文昊按语: 最近读到的一篇文章,收藏并作为一篇程序员修炼之路专辑中的一篇文章.

模块划分

模块划分的”划”是规划的意思,意指怎样合理的将一个很大的软件划分为一系列功能独立的部分合作完成系统的需求。C语言作为一种结构化的程序设计语言,在模块的划分上主要依据功能(依功能进行划分在面向对象设计中成为一个错误,牛顿定律遇到了相对论),C语言模块化程序设计需理解如下概念:

(1) 模块即是一个.c文件和一个.h文件的结合,头文件(.h)中是对于该模块接口的声明;

(2) 某模块提供给其它模块调用的外部函数及数据需在.h中文件中冠以extern关键字声明;

(3) 模块内的函数和全局变量需在.c文件开头冠以static关键字声明;

(4) 永远不要在.h文件中定义变量!定义变量和声明变量的区别在于定义会产生内存分配的操作,是汇编阶段的概念;而声明则只是告诉包含该声明的模块在连接阶段从其它模块寻找外部函数和变量。如:

/*module1.h*/
int a = 5; /* 在模块1的.h文件中定义int a */

/*module1 .c*/
#include “module1.h” /* 在模块1中包含模块1的.h文件 */

/*module2 .c*/
#include “module1.h” /* 在模块2中包含模块1的.h文件 */

/*module3 .c*/
#include “module1.h” /* 在模块3中包含模块1的.h文件 */

以上程序的结果是在模块1、2、3中都定义了整型变量a,a在不同的模块中对应不同的地址单元,这个世界上从来不需要这样的程序。正确的做法是:

/*module1.h*/
extern int a; /* 在模块1的.h文件中声明int a */

/*module1 .c*/
#include “module1.h” /* 在模块1中包含模块1的.h文件 */
int a = 5; /* 在模块1的.c文件中定义int a */

/*module2 .c*/
#include “module1.h” /* 在模块2中包含模块1的.h文件 */

/*module3 .c*/
#include “module1.h” /* 在模块3中包含模块1的.h文件 */

这样如果模块1、2、3操作a的话,对应的是同一片内存单元。

一个嵌入式系统通常包括两类模块:

(1)硬件驱动模块,一种特定硬件对应一个模块;

(2)软件功能模块,其模块的划分应满足低偶合、高内聚的要求。

多任务还是单任务

所谓”单任务系统”是指该系统不能支持多任务并发操作,宏观串行地执行一个任务。而多任务系统则可以宏观并行(微观上可能串行)地”同时”执行多个任务。

多任务的并发执行通常依赖于一个多任务操作系统(OS),多任务OS的核心是系统调度器,它使用任务控制块(TCB)来管理任务调度功能。TCB包括任务的当前状态、优先级、要等待的事件或资源、任务程序码的起始地址、初始堆栈指针等信息。调度器在任务被激活时,要用到这些信息。此外,TCB还被用来存放任务的”上下文”(context)。任务的上下文就是当一个执行中的任务被停止时,所要保存的所有信息。通常,上下文就是计算机当前的状态,也即各个寄存器的内容。当发生任务切换时,当前运行的任务的上下文被存入TCB,并将要被执行的任务的上下文从它的TCB中取出,放入各个寄存器中。

嵌入式多任务OS的典型例子有Vxworks、ucLinux等。嵌入式OS并非遥不可及的神坛之物,我们可以用不到1000行代码实现一个针对80186处理器的功能最简单的OS内核,作者正准备进行此项工作,希望能将心得贡献给大家。

究竟选择多任务还是单任务方式,依赖于软件的体系是否庞大。例如,绝大多数手机程序都是多任务的,但也有一些小灵通的协议栈是单任务的,没有操作系统,它们的主程序轮流调用各个软件模块的处理程序,模拟多任务环境。

更多 >

程序员修炼之路-C语言

本文是专题:程序员修炼之路中的第3篇,共5篇

在程序员修炼之路这个系列里面,转载过几篇他人的文章。最近有同学问我如何深入学习C语言和职业规划的问题,让我决心自己动手总结一些观点,和朋友共勉。于是就有了这篇同名文章。

要想成为一名合格的C语言程序员,读什么样的书是一个首先碰到的基本问题。我的品位是,读计算机方面的著作,一定要读国外人写的经典级别的书。回忆我的往事,在中学时候看了一点BASIC基础,学会了盲打,会用了Windows 3X和95,这些就是我在读大学前全部的计算机基础知识。在大学第一年的寒假,回家的火车上,我没有买到座位票,于是只好站着回家。在这十八个小时的旅途中,我阅读了大约1/2的《C程序设计语言》,对,就是那本Kernighan和Richie合著的薄薄的书。不过惭愧的是,我当时的英语很差,读的当然是东南大学徐宝文翻译的第一版。徐先生的翻译很好,所以我才能顺利读下来。有人可能觉得奇怪,没有什么基础的情况下,如何能读完这么一本书?我的感受是,当要学习一种全新的东西,读书不能奢望全理解,勇敢的看下去,看完它,和作者的第一次沟通才能完成。

这第一次沟通,奠定了我的C语言基础知识,也决定了我今后在C语言程序员、系统软件设计、嵌入式系统设计等方面的职业脉络。读了第一本C语言经典之后,应该就可以编写一些和书中例程差不多的小程序了。接下来需要阅读的经典有:《C专家编程》(Expert C Programming — Deep C Secrets)、《C陷阱与缺陷》(C Traps and Pitfalls)、《C和指针》(Pointers on C)、《C语言核心技术》(C in a Nutshell)、《代码大全》(Code Complete)。读完了这些书,基本上就可以号称是C语言程序员了。

其中《C和指针》我接触的比较晚,非常的遗憾。当我读了《C和指针》,那种相见恨晚的感觉,难于言表。《C专家编程》《C陷阱与缺陷》这两本书,作者处的时代很久远了。如果在现代PC程序设计领域,相关问题可能很少遇到。但是对C语言程序员而言,还是要继续列为必读书目,因为那些晦涩的问题,还是会不停的重现在嵌入式系统的硬件和编译环境里。《代码大全》结合一定的工作经验来读,会有更深的感触。

学习C语言的路还没有结束,真的要理解C语言,你就要了解“语言”,读一读《程学设计语言》(Programming Language-Michael L. Scott)吧。这本研究生和本科课程通用的教材,会让你对C语言的了解上升一个层次,不,一个数量级。

过了这个界线,C语言的学习就该依据职业规划来细分道路了。我只能根据自己的经验谈谈。

首先,学会用Linux操作体系或者其他类似的*nix系统,因为这些系统是面向程序员的操作系统,如果你真的是一个程序员,在*nix你会感到更舒服。会用Gcc也是必须的。

其次,读一下Intel出版的《多核程序设计》。

(本文未完成,请期待更新)

程序员的十层楼

本文是专题:程序员修炼之路中的第2篇,共5篇

第1层  菜鸟第1层楼属于地板层,迈进这层楼的门槛是很低的。基本上懂计算机的基本操作,了解计算机专业的一些基础知识,掌握一门基本的编程语言如C/C++,或者Java,或者JavaScript,…,均可入门迈进这层。
在这层上,中国有着绝对的优势,除了从计算机专业毕业的众多人数外,还有大量的通信、自动化、数学等相关专业的人士进入这一行,此外还有众多的其他专业转行的人士,人数绝对比西方多出甚多。并且还有一个优势就是我们这层人员的平均智商比西方肯定高。
没有多少人愿意一辈子做菜鸟,因为做”菜鸟”的滋味实在是不咋的,整天被老大们吆喝着去装装机器,搭建一下测试环境,或者对照着别人写好的测试用例做一些黑盒测试,好一点的可以被安排去写一点测试代码。当然如果运气”好”的话,碰到了国内的一些作坊式的公司,也有机会去写一些正式的代码。
所以,菜鸟们总是在努力学习,希望爬更高的一层楼去。

第2层 大虾从第1层爬到第2层相对容易一些,以C/C++程序员为例,只要熟练掌握C/C++编程语言,掌握C标准库和常用的各种数据结构算法,掌握STL的基本实现和使用方法,掌握多线程编程基础知识,掌握一种开发环境,再对各种操作系统的API都去使用一下,搞网络编程的当然对socket编程要好好掌握一下,然后再学习一些面向对象的设计知识和设计模式等,学习一些测试、软件工程和质量控制的基本知识,大部分人经过2~3年的努力,都可以爬到第2层,晋升为”大虾”。
中国的”大虾”数量和”菜鸟”数量估计不会少多少,所以这层上仍然远领先于西方。
大虾们通常还是有些自知之明,知道自己只能实现一些简单的功能,做不了大的东西,有时候还会遇到一些疑难问题给卡住,所以他们对那些大牛级的人物通常是非常崇拜的,国外的如Robert C. Martin、Linus Torvalds,国内的如求伯君、王志东等通常是他们崇拜的对象。其中的有些人希望有一天也能达到这些大牛级人物的水平,所以他们继续往楼上爬去。

第3层 牛人由于”大虾”们经常被一些疑难问题给卡住,所以有了”大虾”们只好继续学习,他们需要将原来所学的知识进一步熟练掌握,比如以熟练掌握C++编程语言为例,除了学一些基础性的C++书籍如《C++ Primer》,《Effective C++》,《Think in C++》,《Exception C++》等之外,更重要的是需要了解C++编译器的原理和实现机制,了解操作系统中的内部机制如内存管理、进程和线程的管理机制,了解处理器的基础知识和代码优化的方法,此外还需要更深入地学习更多的数据结构与算法,掌握更深入的测试和调试知识以及质量管理和控制方法,对各种设计方法有更好的理解等。
学习上面说的这些知识不是一挥而就的,不看个三五十本书并掌握它是做不到的。以数据结构算法来说,至少要看个5~10本这方面的著作;以软件设计来说,光懂结构化设计、面向对象设计和一些设计模式是不够的,还要了解软件架构设计、交互设计、面向方面的设计、面向使用的设计、面向数据结构算法的设计、情感化设计等,否则是很难进到这个楼层的。
当然除了上面说的知识外,大虾们还需要去学习各种经验和技巧。当然这点难不倒他们,现在出版的书籍众多,网络上的技术文章更是不胜数,然后再去各种专业论坛里泡一泡,把这些书籍和文章中的各种经验、技能、技巧掌握下来,再去学习一些知名的开源项目如Apache或Linux操作系统的源代码实现等。此时对付一般的疑难问题通常都不在话下,菜鸟和大虾们会觉得你很”牛”,你也就爬到了第3层,晋升为”牛人”了。
看了上面所讲的要求,可能有些大虾要晕过去了,成为牛人要学这么多东西啊!要求是不是太高了?其实要求一点也不高,这么点东西都掌握不了的话,怎么能让别人觉得你”牛”呢?
需要提一下的是,进入多核时代后,从第2层爬到第3层增加了一道多核编程的门槛。当然要迈过这道门槛并不难,已经有很多前辈高人迈进了这道门槛,只要循着他们的足迹前进就可以了。想迈进这道门槛者不妨去学习一下TBB开源项目的源代码(链接:http://www.threadingbuildingblocks.org/),然后上Intel的博客(http://software.intel.com/zh-cn/blogs/)和多核论坛(http://forum.csdn.net/Intel/IntelMulti-core/)去看看相关文章,再买上几本相关的书籍学习一下。
在国内, 一旦成为”牛人”,通常可以到许多知名的公司里去,运气好者可以挂上一个架构师的头衔,甚至挂上一个”首席架构师”或者”首席xx学家”的头衔也不足为奇。有不少爬到这层的人就以为到了楼顶了,可以眼睛往天上看了,开始目空一切起来,以为自己什么都可以做了,什么都懂了,经常在网络上乱砸板砖是这个群体的最好写照。由此也看出,国内的牛人数量仍然众多,远多于西方的牛人数量,在这层上仍然是领先的。
也有不少谦虚的”牛人”,知道自己现在还不到半桶水阶段。他们深知爬楼的游戏就像猴子上树一样,往下看是笑脸,往上看是屁股。为了多看笑脸,少看屁股,他们并没有在此停步不前,而是继续寻找到更上一层的楼梯,以便继续往上爬。

第4层 大牛从第3层爬到第4层可不像上面说过的那几层一样容易,要成为大牛的话,你必须要能做牛人们做不了的事情,解决牛人们解决不了问题。比如牛人们通常都不懂写操作系统,不会写编译器,不懂得TCP/IP协议的底层实现,如果你有能力将其中的任何一个实现得象模象样的话,那么你就从牛人升级为”大牛”了。
当然,由于各个专业领域的差别,这里举操作系统、编译器、TCP/IP协议只是作为例子,并不代表成为”大牛”一定需要掌握这些知识,以时下热门的多核编程来说,如果你能比牛人们更深入地掌握其中的各种思想原理,能更加自如的运用,并有能力去实现一个象开源项目TBB库一样的东西,也可以成为”大牛”,又或者你能写出一个类似Apache一样的服务器,或者写出一个数据库,都可以成为”大牛”。
要成为”大牛”并不是一件简单的事情,需要付出比牛人们多得多的努力,一般来说,至少要看过200~400本左右的专业书籍并好好掌握它,除此之外,还得经常关注网络和期刊杂志上的各种最新信息。
当”牛人”晋升为”大牛”,让”牛人们”发现有比他们更牛的人时,对”牛人”们的心灵的震撼是可想而知的。由于牛人们的数量庞大,并且牛人对大虾和菜鸟阶层有言传身教的影响,所以大牛们通常能获得非常高的社会知名度,几乎可以用”引无数菜鸟、大虾、牛人竞折腰”来形容,看看前面提过的Linus Torvalds等大牛,应该知道此言不虚。
虽然成为”大牛”的条件看起来似乎很高似的,但是这层楼并不是很难爬的一层,只要通过一定的努力,素质不是很差,还是有许多”牛人”可以爬到这一层的。由此可知,”大牛”这个楼层的人数其实并不像想像的那么少,例如比尔·盖茨之类的人好像也是属于这一层的。
由于”大牛”这层的人数不少,所以也很难统计除到底是中国的”大牛”数量多还是西方的大牛数量多?我估计应该是个旗鼓相当的数量,或者中国的”大牛”们会更多一些。
看到这里,可能会有很多人会以为我在这里说瞎话,Linus Torvalds写出了著名的Linux操作系统,我国并没有人写出过类似的东西啊,我国的”大牛”怎么能和西方的比呢? 不知大家注意到没有,Linus Torvalds只是写出了一个”象模象样”的操作系统雏形,Linux后来真正发展成闻名全球的开源操作系统期间,完全是因为许多支持开源的商业公司如IBM等,派出了许多比Linus Torvalds更高楼层的幕后英雄在里面把它开发出来的。
可能有些菜鸟认为Linus Torvalds是程序员中的上帝,不妨说个小故事:
Linus,Richard Stallman和Don Knuth(高德纳)一同参加一个会议。
Linus 说:”上帝说我创造了世界上最优秀的操作系统。”
Richard Stallman自然不甘示弱地说:”上帝说我创造了世界上最好用的编译器。”
Don Knuth一脸疑惑的说:”等等,等等,我什么时候说过这些话?”
由此可以看出,Linus Torvalds的技术水平并不像想像中那么高,只是”牛人”和”大虾”觉得”大牛”比他们更牛吧了。在我国,有一些当时还处于”大虾”层的人物,也能写出介绍如何写操作系统的书,并且书写得非常出色,而且写出了一个有那么一点点象模象样的操作系统来。我想中国的”大牛”们是不会比西方差的,之所以没有人写出类似的商业产品来,完全是社会环境的原因,并不是技术能力达不到的原因。
“大牛”们之所以成为大牛,主要的原因是因为把”牛人”给盖了下去,并不是他们自己觉得如何牛。也许有很多菜鸟、大虾甚至牛人觉得”大牛”这层已经到顶了,但大多数”大牛”估计应该是有自知之明的,他们知道自己现在还没有爬到半山腰,也就勉强能算个半桶水的水平,其中有些爬到这层没有累趴下,仍然能量充沛,并且又有志者,还是会继续往更上一层楼爬的。
看到这里,也许有些菜鸟、大虾、牛人想不明白了,还有比”大牛”们更高的楼层,那会是什么样的楼层?下面就来看看第5层楼的奥妙。
更多 >

程序员晋升架构师的十项必备技能

本文是专题:程序员修炼之路中的第1篇,共5篇

    不是每一个程序员都能够成为一个架构师——这是开发界广为流传的一个论调。架构师群体往往对这个言论表示默许,这不得不令广大入门不久的程序员们怀疑架构师们是不是隐藏了什么武林秘籍。程序员要修炼什么武功才能晋升为一个架构师?

    1、卓越的程序员

    Fred George先生说:“不编程的架构师的职业生涯是短暂的”。他说这句话的背景主要是针对有些架构师的设计与实现有断层的问题而言的,因为如果架构师不去实践,只是想当然的认为“没问题,这个想法能实现”,那么对于项目的落实而言是个很大的隐患。支付宝架构师冯大辉也表示过,架构师是一个比较“虚”的岗位,主要的问题都在“落地”的过程中。

    2、抽象思维

    很多优秀的架构师们都一致的表示,逻辑思维和抽象思维能力是一个架构师最重要的素质。eBay的Randy Shoup先生称拥有条理清晰的逻辑思维能力的人“就像稀有动物那样难找”。Fred George则表示“驾驭概念的技能,在我看来是每一个人最高的潜力”,并表示自己不太介意这样一个苗子在其他方面的技能和经验的匮乏,因为在他看来除了思维之外的其他因素都是可以培养的。

    3、技术前瞻性

    有人谈到技术高手与架构师的区别就在于,架构师不光是着眼于现在,不仅仅局限于开发细节,比如如何调用,如何并发等等。而是跳出三界外,考虑一下面向未来问题和潜在风险的应对之道。

    4、问题解决大师

    只是,架构师之所以为架构师,是在于他们在面对庞大系统之时,仍然能够敏锐的发现其底层之真实。这不仅需要此哲学层面的“内功”,还需要架构师具有多领域知识和经验的积淀。

    5、多领域知识

    架构师身为一名技术领袖,需要通过发散知识的光芒来统御开发团队的。如果只是对本行业知识做到烂熟于心,那还仅仅是一名熟练工的水平。要想晋升更高的层次,还需要跳出“只缘身在此山中”的困惑。

    6、沟通能力

    做到人性化的沟通,需要我们在平时就进行培养。写出大部头的架构书,有的时候并没有用VISIO画出的简单架构图好理解。人对图形理解远远大于对文字的理解,直观简单的UML图可以极大的方便程序员理解架构师的意图。

    7、内力

    很多人理解的内力就是开发技术,包括语言的掌握、对框架的掌握、数据库管理能力、安全管理能力等等。但是我们看到,架构更多的内力体现在对技术的综合运用上,光会编程的程序员,最多就能做到高级程序员,也就是技术实现上的高手。

    8、权衡取舍

    Fred George先生提出了“短期滥用”的说法,即在系统能够承受的范围内做出一些妥协。在ATAM方法中,分析的思路是基于“情景”的:你需要提出各种可能的情景,然后来证明在每一个用户使用场景中,系统的哪一些内容是必要的、不可丢弃的——从而确定哪些部分是暂时可以不予考虑的。

    9、管控能力

    架构师在管理和控制的能力上,需要有自己独到的见解,而不是简单的认为这是项目经理或者财务部门的事情。身为技术专家的架构师,随不需要处理那些烦杂的日常管理。奇虎架构师李钊在一次接受采访时道出过架构师们的心声,技术人才转向管理就是莫大的浪费。对,如果架构师只是一味的去进行项目管理,那就和其他市场人员没有任何区别了。在这里架构师所需要的管理与控制,其实是从技术的角度,对一些问题的控制,特别是开发过程中的监控,而不是普通意义上的纯粹管理。

    10、艺术气质

    一个优美的系统则是可以像有机的生命一样成长的,这是因为从系统开始架构的那一刻起,架构师就考虑到这个系统以后将会面临的挑战,为系统的成长预留好空间。项目经理经常会对这位架构师提出的看似理想化的要求不置可否——项目经理只想着能够尽快以比较低的成本实现客户的需求,然而这些充满艺术美感的想法其实是打造健康——因而优美——的系统的根本因素。(完)