0 bug:C/C++商用工程之道
| 商家名称 |
信用等级 |
购买信息 |
订购本书 |
|
|
 |
0 bug:C/C++商用工程之道 |
 |
|
|
0 bug:C/C++商用工程之道 |
|
基本信息·出版社：电子工业出版社
·页码：561 页
·出版日期：2010年01月
·ISBN：9787121098482
·条形码：9787121098482
·版本：第1版
·装帧：平装
·开本：16
·正文语种：中文
内容简介 《0 bug:C/C++商用工程之道》共分12个章节，主要针对C/C++语言在商用工程开发中的程序实战进行论述，从商用解决方案的角度来理解C和C++语言的程序设计技巧。具体内容包括商用工程开发思路、C/C++无错化程序设计、设计自己的工程库、Log日志管理系统等。该书可供各大专院校作为教材使用，也可供从事相关工作的人员作为参考用书使用。《0 bug:C/C++商用工程之道》主要针对C/C++语言在商用工程开发中的程序实战进行论述，从需求出发，从商用解决方案的角度来理解C和C++语言的程序设计技巧。商用程序员在实际工作中最为关注的无错化、并行、时间片、内存池、线程池、任务池、工程库和跨平台等相关问题，在《0 bug:C/C++商用工程之道》中都有宝贵的经验总结和理念梳理。《0 bug:C/C++商用工程之道》不是教科书，更多的是在开发技巧、测试调试、工程代码库等方面给出实例与总结。《0 bug:C/C++商用工程之道》也可以说是教科书，作者试图通过实战技巧的训练，帮助读者升华出一种全新的程序设计理念。《0 bug:C/C++商用工程之道》可以帮助你摆脱“Training”式编程开发思维与方法，培养“商用”和“产品”标准的工程开发技能。
《0 bug:C/C++商用工程之道》适合作为C和C++的程序员进行“商用化开发”和“工程化开发”的参考。
编辑推荐 《0 bug:C/C++商用工程之道》：多年的一线经验，无错化的开发之道
产品与工程视角，系统化的开发之道
商用与市场思维，务实化的开发之道
如果你是一名初次进入职场的软件专业学生，《0 bug:C/C++商用工程之道》可以助你迅速掌握企业商业化开发的思路和技巧。
如果你是一名C和C++的学习者和爱好者，《0 bug:C/C++商用工程之道》可以助你掌握很多实际的技巧，并获得一个现成可用的工程库。
如果你是一名商业公司的程序员，已经掌握了很多商用开发的思维和技巧，《0 bug:C/C++商用工程之道》能给你一点新的、意想不到的提示。
如果你是一名网络游戏公司的开发人员，《0 bug:C/C++商用工程之道》的多任务工程库可能会对你很有帮助。
如果你是一名商用服务器的开发人员，《0 bug:C/C++商用工程之道》可以助你掌握如何利用C和C++实现7×24小时稳定性的服务器的技巧。
如果你是一名嵌入式开发人员，《0 bug:C/C++商用工程之道》中严格的代码规范和数据边界意识，对嵌入式之类资源较少且有长期运行要求的设备开发很有帮助。
如果你是一名使用其他语言的程序员，《0 bug:C/C++商用工程之道》中很多基本模块的突现，如内存池、线程池等，对Java等程序员理解自己平台的相同模块，很有帮助，并且，《0 bug:C/C++商用工程之道》提出的商用开发思想，是跨语言跨平台的，也很有参考价值。
如果你是一名产品经理、项目经理或者架构师，《0 bug:C/C++商用工程之道》中提出的很多商用系统工程的设计理念，是作者多年开发的经验结晶，对于系统的设计、商用项目的风险管控，有很好的参考作用。
时间片
内存池
无错化
任务池
跨平台
并行
线程池
目录 第1章 商用工程开发思路
1.1 系统分析初步
1.1.1 需求理解和沟通
1.1.2 “上家”和“下家”
1.1.3 角色“定名
1.1.4 初步的拓扑图
1.1.5 后续的模块级设计
1.1.6 商用设计思维
1.2 商用程序员对开发的理解
1.2.1 资源和成本
1.2.2 盈利导向
1.2.3 客观
1.2.4 平衡
1.2.5 服务
1.3 基本开发思路
1.3.1 边界
1.3.2 “细分”的分析方法
1.3.3 灵活，逆向思维
1.3.4 小内核，大外延，工程库思维
1.3.5 单笔交易失败不算失败
1.4 数据传输各个角色的开发思路
1.4.1 服务器的设计原则
1.4.2 PC客户端的开发思路
1.4.3 嵌入式设备的开发思路
1.4.4 跨平台软件模块的开发思路
第2章 基础知识
2.1 内存的理解
2.1.1 32位操作系统的内存分配
2.1.2 C/C++语言对内存的使用
2.1.3 内存——bug之源
2.2 并行运算
2.2.1 时间片
2.2.2 进程和线程
2.2.3 同步和异步
2.2.4 礼貌地释放时间片资源
2.2.5 跨线程通信
2.2.6 跨进程通信
2.2.7 网络，并行运算的世界
2.3 “锁”的使用
2.3.1 为什么要使用锁
2.3.2 使用锁容易犯什么错误
2.3.3 “行为锁”和“资源锁”
2.3.4 单写多读锁
2.3.5 不可重入锁
2.3.6 用锁的最高境界——不用
2.4 “池”的深刻含义
2.4.1 “池”的由来
2.4.2 “池”的使用
2.5 跨平台、跨语言开发基础
2.5.1 C/C++跨平台开发基础
2.5.2 dll和so
2.5.3 API和NPI
2.5.4 服务无处不在
2.6 debug的重要性
2.6.1 在数据传输领域，你亲眼看到的都不是真的
2.6.2 如何看到——万事从debug开始
2.6.3 debug的原则
2.6.4 如何分析数据
2.7 性能统计的重要性
2.7.1 需要统计哪些信息
2.7.2 基本的统计方法
2.7.3 随机数的产生
2.8 队列无处不在
2.8.1 数据结构在数据传输中的应用分析
2.8.2 需要哪几种队列形式
2.9 不要求全责备
第3章 C/C++无错化程序设计
3.1 “无错化程序设计”简介
3.1.1 无错化程序设计思路
3.1.2 C/C++无错化设计的解决方案
3.1.3 使用后的效果
3.2 计算机程序的真谛
3.2.1 程序就是“搬数”
3.2.2 程序就是“写文章”
3.2.3 程序就是“复制”
3.2.4 笔者看程序设计
3.3 定名
3.3.1 匈牙利命名法
3.3.2 函数命名原则
3.3.3 变量命名原则
3.3.4 其他命名规则
3.3.5 定名的折中
3.4 无错化程序的基本书写原则
3.4.1 写简单易懂的程序
3.4.2 严禁变量转义
3.4.3 严禁一语多义
3.4.4 函数只能有一个出口
3.4.5 变量如不使用，保持初值
3.4.6 常量必须定名
3.4.7 太大数组不要用静态方式
3.4.8 尽量避免使用递归
3.4.9 解决方案一套就够
3.5 基本程序设计原则
3.5.1 函数的设计
3.5.2 类的设计
3.5.3 其他要点
3.6 基本语句的约定
3.6.1 判断语句，常量永远在左边
3.6.2 for（i=0;i
3.6.3 while（1）
3.6.4 不要使用do...while（）
3.6.5 i++和++i问题
3.6.6 请不要使用“?（...）:（...）”结构
3.6.7 善用大括号{}缩小作用域
3.7 请使用goto语句
3.7.1 函数只有一个出口的原则需要goto
3.7.2 谁分配、谁释放的原则需要goto
3.7.3 商用工程要求goto
3.7.4 程序的易读性要求goto
3.7.5 break为什么不能乱用
3.7.6 goto的常规使用手法
3.8 指针的使用原则
3.8.1 商用数据传输常见的指针类型
3.8.2 不要使用两个以上的*号
3.8.3 指针不能参与四则运算
3.9 使用结构体的技巧
3.9.1 结构体传参的必要性
3.9.2 预防多重指针的隐患
3.9.3 32位到64位移植
3.9.4 弹性内存使用需要结构体传参
3.9.5 网络传输协议，需要结构体传参
3.10 使用宏的建议
3.10.1 宏的几大作用
3.10.2 C++的建议
3.10.3 编译宏——跨平台开发
3.11 回调函数设计方法
3.11.1 回调模型设计者
3.11.2 回调模型使用者
3.11.3 参数传递的常规手法
3.11.4 事件模型和回调模型
3.12 C语言字符串的深入研究
3.12.1 字符串拷贝
3.12.2 字符串构造
3.12.3 关于字符串处理的结论
3.13 C/C++语言无错化程序设计小结
第4章 设计自己的工程库
4.1 数据传输库中到底需要哪些模块
4.1.1 跨平台定义
4.1.2 锁与安全模块
4.1.3 内存池
4.1.4 资源管理池
4.1.5 线程池与任务池
4.1.6 队列管理
4.1.7 其他工具
4.2 工程库基础——跨平台定义
4.2.1 锁定义
4.2.2 线程控制相关定义
4.2.3 Socket传输相关定义
4.2.4 include系统头文件
第5章 debug工具
5.1 变参函数的设计
5.2 文本输出
5.2.1 获得时间戳
5.2.2 同时输出到文件和屏幕
5.2.3 文本输出的原则
5.3 二进制输出的debug函数
5.4 核心debug和日志系统的区别
5.5 统计模块
5.5.1 累加器
5.5.2 ?计算模块
5.5.3 平均值计算
5.5.4 统计平均值计算
5.5.5 辅助功能函数
5.6 CLowDebug工具类
5.6.1 需求分析
5.6.2 数据边界声明
5.6.3 类声明
5.6.4 类工具函数
5.6.5 业务函数
5.7 基本debug工具小结
第6章 锁
6.1 二元动作理论
6.1.1 二元动作在C语言中的书写特性
6.1.2 面向对象和面向过程的本质差异
6.1.3 二元动作在C++语言中的特殊要求
6.1.4 二元动作开发关注要点
6.2 锁对象
6.3 多线程安全的变量
6.3.1 CMint和CMbool试验
6.3.2 多线程安全的变量模板
6.4 单写多读锁
6.4.1 单写多读锁的来源
6.4.2 单写多读锁C语言实
……
第7章 内存与资源管理
第8章 队列
第10章 Log日志管理系统
第11章 聚合工具类
第12章 细节决定成败（代结束语）
……
序言 0.1 为什么要写本书
在本书定名的时候，笔者做了很多思考。本书究竟想说什么？关注的重点在哪里？看起来，本书所讲述的知识、经验和技巧，在很多书上都有讲，那么，我们的差别在哪里呢？
笔者看到过无数的年轻学子，兴高采烈地从学校出来，走向职场，但是，通常立即会遇到两个问题：
（1）他们虽然在学校中学到了很好的知识，但是到了企业中，却没有办法投入实用，甚至找不到工作。是他们学习的书不对？还是他们的老师没有教对？很多人陷入迷茫之中。
（2）另外即使一个学子，顺利进入了企业，成为一名程序员，但无穷无尽的加班和做不完的项目任务，使生活充满了压力，也充满了苦闷。即使能赚取高薪，但生活毫无乐趣可言。这又是为什么呢？
笔者在IT研发领域工作了十几年，在这里有一点心得。
首先，笔者认为，学生即使学会了基本的程序开发技能，但还不能算作一个标准的商用程序员，其工作习惯、做事的思路和方法，特别是在具体程序工作中所秉持的设计思想，系统性思维，与企业需求相差甚远，这导致了就业上的困难，因此需要学习和调整。
其次，笔者认为程序员生活压力大，很多时候并不是任务量的压力，做过一些程序设计工作的朋友大概都有印象，“程序好写，bug难追”。真正导致我们大量加班的，往往不是程序的设计和书写过程，更多的，是debug。而企业中开发商用程序，由于对bug有着几乎为0的容忍度，这导致了商用程序员压力很大。
笔者一直在企业中做事，自己也深有体会，笔者曾经在2000年左右做过一个统计，发现工作中对bug的查找，占据了自己60％～80％的工作量。当时笔者就思考，如果能有一种方法，使程序一写出来就没有bug，那该是多么美妙的一件事情。
由于笔者一直从事C和C+ +语言方面的开发工作，于是笔者就着这个熟悉的领域，开始了一点探索和研究工作，其间也参考了很多大师写的书籍。慢慢地，自己形成了一套程序书写原则和方式，笔者将其定名为“C/C+ +无错化程序设计方法”。经过实际工程试用，发现效果不错，很多程序出来之后bug很少，成熟度很高，得到了一些好评。
但是，随之发现了另外一个问题：商用工程，是为客户需求服务的，一段程序，如果不能满足客户需求，即使写得再正确也毫无意义；同时，一个系统的设计，如果脱离了需求分析，即使采用再精妙的算法，再优秀的设计，也是毫无意义的。
这使笔者不得不思考一个更深层次的问题，商用软件工程，其实已经不仅仅涵盖程序设计的领域，仅仅就程序谈程序，其实并无意义。一名商用程序员，不仅仅要是程序设计的专家，也必须是商务沟通的专家、客户需求理解的专家。这大大扩展了“程序员”这个职业的内涵和外延。
笔者发现目前市面上有很多关于程序设计的书籍，也有很多职业训练方面的书籍，但是，却从来没有人（也许是笔者孤陋寡闻），以程序开发的角度，讲述程序员进入企业后应该学习的商业开发思维和设计思想。
因此，笔者希望能根据自己的经验，写一本书，帮助大家快速掌握一些工程化的开发技巧，并和自己过去所学的相结合，快速成长为企业合用的人才。
0.2 本书包括哪些内容
本书主要针对C/C+ +语言在商用工程开发中的程序实战进行论述。
本书无意重复无数书籍已经写过的一些C和C+ +语言的基础知识，而是试图从另外一个角度，从需求出发，从商用解决方案的角度，去理解C和C+ +语言的程序设计技巧。
因此，本书更多的以一种实用主义的态度，从需求出发去挑选需要的技术，并针对需求做出相应的优化，最终形成合用的商用开发方案。
本书可以说是一本教科书，因为里面有大量的经验和技巧，更有笔者多年积累的解决方案思路。但本书也可以说不是教科书，如果出于一种系统全面学习知识的角度来看本书，可能会有一点点失望，因为本书的知识已经打乱，完全在为需求服务。
文摘 插图：
第1章 商用工程开发思路
1.1系统分析初步
有关系统分析的内容，在很多教科书上都有较为详细的描述。系统分析几乎是所有程序开发行为的第一步。但是，商用工程程序员对系统分析应该有一些独特的理解，很多时候，商用系统分析与技术其实没有太多关系，更多的与沟通和合作有关。
1.1.1需求理解和沟通
以笔者通常面临的商用数据传输工程来说，这类系统，一般都是指借助网络（局域网或互联网），通过多台计算机的协同工作、共同提供资源、共同分摊loading，最终为客户实现一个或多个服务需求的商用工程项目。
因此，商用工程的程序员在接到用户需求的时候，最忌讳的就是马上从编程的角度开始思考，这个功能如何实现、那个模块如何编写。那只会把事情越弄越糟，最后导致不可收拾。
笔者一般秉持的习惯是，系统分析期间不涉及细节，先相信所有的细节是能实现的，以后再考虑风险点细节。
提示：程序界很多年以前就在争论，一个程序，自上而下编写（即先搭框架，逐步细化）和自下而上（先解决所有技术难点，做出底层模块，再来拼接）哪个好的问题。在商用工程中，笔者的经验，一定是自上而下。试想，连用什么平台和语言开发都没有确定，如何自下而上？
接到需求，程序员要做的第一件事情应该是理解需求。大家不要以为笔者在说笑话，在实际工作中，笔者就遇到程序员把需求完全理解反了的例子，还有的程序员干脆挑着看，对于自己熟悉的需求实现得很好，但不熟悉的干脆什么也没做。
因此，即使程序员接到的是一个小小的模块，也应该认真对待，在理解需求的时候，建议首先仔细看产品相关文档，如需求分析报告、系统设计书之类的文档，然后和自己的上级，可能是组长，可能是部门经理，也可能是项目经理，做一次面对面的直接沟通，讨论一下自己的模块在未来产品中究竟处于什么地位，它的优化方向是空间优先还是时间优先，有没有特定的算法需求等。
