0 bug：C/C++商用工程之道 (china-pub首发)
点击看大图基本信息
编辑推荐
多年的一线经验，无错化的开发之道.
产品与工程视角，系统化的开发之道..
商用与市场思维，务实化的开发之道...
内容简介回到顶部↑
本书主要针对c/c++语言在商用工程开发中的程序实战进行论述，从需求出发，从商用解决方案的角度来理解c和c++语言的程序设计技巧。首先讨论商用开发的原则，然后是基础知识、基本技巧，接着是无错化方法，最后提升到世界观层面论述并行开发的正确理念。商用程序员在实际工作中最为关注的无错化、并行、时间片、内存池、线程池、任务池、工程库和跨平台等相关问题，在本书中都有宝贵的经验总结和理念梳理。本书不是教科书，更多的是在开发技巧、测试调试、工程代码库等方面给出实例与总结。本书也可以说是教科书，作者试图通过实战技巧的训练，帮助读者升华出一种全新的程序设计理念。本书可以帮助你摆脱“training”式编程开发思维与方法，培养“商用”和“产品”标准的工程开发技能。.
本书适合作为c和c++的程序员进行“商用化开发”和“工程化开发”的参考。...
本书适合作为c和c++的程序员进行“商用化开发”和“工程化开发”的参考。...
作译者回到顶部↑
本书提供作译者介绍
肖舸：MCSE，商用程序员，CSDN学生大本营名师，现任普罗通信（西安）有限公司研发主任。拥有多年的软件研发和研发管理经验。精通C/C++，TCP/IP，擅长分布式数据库、服务器集群以及并行计算领域的研发。曾担任西南交大客座讲师，讲授《C/C++语言无错化程序设计》课程。曾在多家企业担任项目经理，负责过的项目有《http tunnel防火墙隧道穿越系统》、《freepp V1.5 服务器集群》、《电子白板子系统》、《水泥生产窑红外线监控系统》、游戏《隋唐演义》、《营区网络化视频监控》、《局域网IM即文档共享平台》、《核爆测试频谱分析.. << 查看详细
目录回到顶部↑
第1章 商用工程开发思路. 1
1.1 系统分析初步 2
1.1.1 需求理解和沟通 2
1.1.2 “上家”和“下家” 3
1.1.3 角色“定名” 3
1.1.4 初步的拓扑图 4
1.1.5 后续的模块级设计 4
1.1.6 商用设计思维 5
1.2 商用程序员对开发的理解 5
1.2.1 资源和成本 5
1.2.2 盈利导向 6
1.2.3 客观 7
1.2.4 平衡 9
1.2.5 服务 11
1.3 基本开发思路 15
1.3.1 边界 15
1.3.2 “细分”的分析方法 16
1.3.3 灵活，逆向思维 17
1.3.4 小内核，大外延，工程库思维 18
1.3.5 单笔交易失败不算失败 19
1.1 系统分析初步 2
1.1.1 需求理解和沟通 2
1.1.2 “上家”和“下家” 3
1.1.3 角色“定名” 3
1.1.4 初步的拓扑图 4
1.1.5 后续的模块级设计 4
1.1.6 商用设计思维 5
1.2 商用程序员对开发的理解 5
1.2.1 资源和成本 5
1.2.2 盈利导向 6
1.2.3 客观 7
1.2.4 平衡 9
1.2.5 服务 11
1.3 基本开发思路 15
1.3.1 边界 15
1.3.2 “细分”的分析方法 16
1.3.3 灵活，逆向思维 17
1.3.4 小内核，大外延，工程库思维 18
1.3.5 单笔交易失败不算失败 19
前言回到顶部↑
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+ +语言的程序设计技巧。
因此，本书更多的以一种实用主义的态度，从需求出发去挑选需要的技术，并针对需求做出相应的优化，最终形成合用的商用开发方案。
本书可以说是一本教科书，因为里面有大量的经验和技巧，更有笔者多年积累的解决方案思路。但本书也可以说不是教科书，如果出于一种系统全面学习知识的角度来看本书，可能会有一点点失望，因为本书的知识已经打乱，完全在为需求服务。
本书是一本C和C+ +语言的开发类书籍，里面讲述了大量开发的技巧，比如如何实现无错化的程序设计，使程序在写出来的时候就已经具有较高的鲁棒性，接近0 bug的地步。
在本书定名的时候，笔者做了很多思考。本书究竟想说什么？关注的重点在哪里？看起来，本书所讲述的知识、经验和技巧，在很多书上都有讲，那么，我们的差别在哪里呢？
笔者看到过无数的年轻学子，兴高采烈地从学校出来，走向职场，但是，通常立即会遇到两个问题：
（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+ +语言的程序设计技巧。
因此，本书更多的以一种实用主义的态度，从需求出发去挑选需要的技术，并针对需求做出相应的优化，最终形成合用的商用开发方案。
本书可以说是一本教科书，因为里面有大量的经验和技巧，更有笔者多年积累的解决方案思路。但本书也可以说不是教科书，如果出于一种系统全面学习知识的角度来看本书，可能会有一点点失望，因为本书的知识已经打乱，完全在为需求服务。
本书是一本C和C+ +语言的开发类书籍，里面讲述了大量开发的技巧，比如如何实现无错化的程序设计，使程序在写出来的时候就已经具有较高的鲁棒性，接近0 bug的地步。
相关资源回到顶部↑
· 【推荐】众多高校学子口口相传，他们共同的选择--华清远见嵌入式学院(嵌入式Linux就业课程、3G手机开发就业课程，通过入学测试即签100%就业协议，4个月集中实训，世界500强企业成功就业保障！！！)· 【亚嵌教育 嵌入式培训专家】(嵌入式培训，嵌入式Linux培训，ARM培训,Linux培训，3G培训，Android培训，WINCE培训，DSP培训，FPGA培训，嵌入式就业培训)
· 程序员的7种武器(正则表达式、编程语言、数据库、算法、软件调试、开发环境)
· C/C++ 经典著作(《C专家编程》《C++ Templates中文版》《C和指针 》《C陷阱与缺陷》《C++沉思录》)
评论交流
共有85人开贴评论 287人参与评论 10人参与打分 查看
评价等级：
发表于：2010-1-26 14:01:00
匆匆浏览了前几章，总体来说不错，如作者说的 本书不是按部就班的教材，是一本经验之谈。尽管有些地方写的和大师们的建议不一致（比如书中太多的宏定义，而c++里面是极力避免宏定义的，宏定义过时了也不安全），但书中提到的一些技巧和思路是我们这些普通的程序员值得学习和借鉴的。论坛里面有部分读者好像很偏激，感觉对作者不是很尊重。其实大家少点争论，若有心的话就如作者一样，把自己的在工作中的已经证明过的好的经验写出来，我想对我们这些普通的程序员来说 真是福音了，即使是需要花些银子去买的，也是值得的。
另外，近日在一个项目中，我采用了作者在P186上面所说的一个技巧。即
#define CON_PRINTF //printf
#endif
发现每次引用很多警告信息打印出来。说实在的我看见警告信息就有一种不安全的感觉。为此我做了一个小的demo.如下
#include <iostream>
#include <string.h>
using namespace std;
//#define DEBUG_TRACE
#ifdef DEBUG_TRACE
#define TEST_PRINTF printf
#else
#define TEST_PRINTF //printf
#endif
int main(void)
{
TEST_PRINTF("abcd");
return 0;
}
编译：
[root@localhost testCXX]# g++ -D_REENTRANT -Wall -g -D_DEBUG -DNDEBUG ex41.cpp
ex41.cpp:15:21: 警告：多行注释
ex41.cpp: In function ‘int main()’:
ex41.cpp:21: 警告：statement 不起作用
我想问 除了不在编译时去掉-Wall之外，怎么能不显示这些警告信息。
另外，近日在一个项目中，我采用了作者在P186上面所说的一个技巧。即
#define CON_PRINTF //printf
#endif
发现每次引用很多警告信息打印出来。说实在的我看见警告信息就有一种不安全的感觉。为此我做了一个小的demo.如下
#include <iostream>
#include <string.h>
using namespace std;
//#define DEBUG_TRACE
#ifdef DEBUG_TRACE
#define TEST_PRINTF printf
#else
#define TEST_PRINTF //printf
#endif
int main(void)
{
TEST_PRINTF("abcd");
return 0;
}
编译：
[root@localhost testCXX]# g++ -D_REENTRANT -Wall -g -D_DEBUG -DNDEBUG ex41.cpp
ex41.cpp:15:21: 警告：多行注释
ex41.cpp: In function ‘int main()’:
ex41.cpp:21: 警告：statement 不起作用
我想问 除了不在编译时去掉-Wall之外，怎么能不显示这些警告信息。
)
评价等级：
发表于：2010-3-14 16:33:00
在还没0bug门的时候，就购买了，也进入了作者组织的群，觉得作者比较自负，但是觉得书的内容还可以，我不懂c++，所以关于c++的错误我不懂，我也不在意，只是对于这些高性能，高并发在意，所以也没觉得什么问题。可是后面出了0bug门，让我对作者的人品很失望，虽然书籍和人品是两码事，可是还是给人不好的印象了，真是非常可惜了。也许作者技术非常牛b，但是接受大家的意见，也没什么问题吧？至于很多人说经验错的离谱，可是至少别人说出来了，你们的经验都敝帚自珍，完全不共享，那又有何用呢？虽然被误导了，但是至少知道一种错误的方法，也许后面才能领悟到正确的方法，可是完全连方法都不知道的话，连错误的机会都没有，又何来正确的思想呢？
加载中...| 我要写评论 |
| 查看所有评论交流(共85条) |
