开发Linux服务程序的工作环境配置

看看一下的问答，然后思考这样一个问题,想在linux平台下开发服务程序的工作环境配置是哪些呢？

问：
老师，可以写一篇文章介绍一下如何使用vim搭建好用的linux开发环境吗？（比如vim如何设置快捷键可以做到一键编译和运行，常用的插件如何安装等）
答：
我不会用vim，也从不用。
问：
听说实际工程中，可以在windows下写代码然后放到linux下编译，但是每改一个文件就要上传到linux，好像很麻烦，肖老师可以写一篇文章介绍一下如何在windows写linux下软件的代码的文章吗？主要是如何管理文件。谢谢。
答：
嗯，好吧，我把我自己的工作习惯写篇文章给大家看看。

我的回答：

和平同学你好，嗯，看了你的问题，感觉你很细心，因为很少有朋友会就开发环境，单独提出问题，不过呢，不可否认，我们开发软件，首先碰到的就是开发环境，这个搞不顺，后面的开发工作往往会受到很大影响，甚至，直接影响自己的工作效率和效果，因此，这也确实是一个需要仔细探讨的话题。

那这里，我就写篇文章来讲讲我的开发习惯，先声明啊：我的开发习惯有很多背景在里面，是长期形成的一套开发习惯，自己觉得好用就行，我相信很多朋友都有自己的开发习惯，我呢，没说我这个是圣旨，不能改的，大家完全可以结合自己的工作实际，总结自己的习惯。一句话：“合用就好！”

我呢，最开始学习C是用的TurboC2.0，那是DOS下的事情，90年吧，大家知道，TurboC2.0是有集成开发环境的，因此，初期我做C程序，基本上还是习惯在IDE的辅助下工作，包括编译和调试。

不过呢，95年开始，我使用6502宏汇编语言开发，这就完蛋了，我找不到一个好用的开发环境，没有IDE，而且，由于是交叉汇编，在5x86机器上写代码，利用交叉编译器，编译成6502的二进制代码，然后传到仿真器上，仿真器上有块卡，可以插在真实的任天堂游戏机上，其实就是仿真了游戏机的ROM卡部分，然后，游戏机Reset，就开始工作，就能看到输出结果。

这就带来一个问题，我没有好用的编辑器啊，96年整整一年，我都在打烂仗，这个用点，那个用点，嗯，用NotePad最多，当时都想哭了，呵呵。

还好，到了97年，微软公司那会把MSC7.0生了级，升级到VC++4.2，这个可是一代经典，无论是MFC，Win32的支持，还是IDE本身的特性，给我们的感觉都无与伦比，漂亮。我一下就爱上它了，呵呵。立即转到这上面做开发工作。嗯，顺便说一句，我正式转到Windows95上工作，是96年底。以前的 Windows3.1不好用，主要还是在DOS下使用。

VC4.2的IDE环境有几个优点，非常突出：
1、工程管理，甭管什么语言的源代码文件，可以直接建立一个工程来管理，这很方便，我一个游戏十几万行，分属在上百个asm文件里面，如果不管理，会死人的。
2、自定义关键字高亮度显示，这个很重要，我使用的是6502宏汇编，VC肯定是没有这个关键字的，不过，我写了个自定义的文件，导入进去，就ok了，看起来很漂亮和醒目，关键是，自己不容易看错。嗯，有个细节，我当时主要还在用BASIC语言，就是VB啦，对于BASIC语法很熟，我以前讲过，我利用宏，做了一整套BASIC语言的宏，方便书写汇编语言，搞得我6502汇编语言里面，全是FOR、NEXT、PRINT什么的，我把这些Basic的关键字也做了高亮，很好看。
3、外部编译工具，VC肯定是没有办法做这个6502交叉编译的，不过，它提供了自定义工具，允许一键调用外部的“bat”批处理，实现编译，这个很方便，嗯，我当时把它的快捷键都拦截成“Alt-F7”了，确实很舒服。
4、支持矩形块拷贝，一般的编辑器，都是行拷贝，即只能选择一行或者几行拷贝，但是，很多时候，我们在复制结构体的时候，或者很多有规律排列的文字的时候，比如，《0bug-C/C++商用工程之道》，里面的任务池的任务，由于采用程序三段论，一般定义 TaskInit,TaskLoop,TaskExit，一般一排列就是如下模式：
static bool TravelTaskInitCallback(void* pCallParam,int& nStatus);
static bool TravelTaskLoopCallback(void* pCallParam,int& nStatus);
static bool TravelTaskExitCallback(void* pCallParam,int& nStatus);
大家看整齐不整齐？不过，问题来了，如果我们只拷贝TravelTaskxxxxCallback这部分内容，矩形块拷贝就很方便了，这在VC中一直没有变过，就是按住Alt键拉块，然后Ctrl-C拷贝就好了，而不需要拷贝3行，再来挑着删除，这也是一个很常用的功能，很方便。
5、最重要的来了，VC4.2允许录制和回播键盘宏，这个功能很重要，很多时候，我们输入大量的内容，需要用复制、粘贴命令，但是，如果这大量的资料，每笔之间只差一小点，但是又符合规律，怎么办？这就需要键盘宏。

这里举个例子吧，可能有点复杂，大家仔细看：
比如我在数组中输入Item000、Item001、、、Item999，共计1000个这种内容，拷贝肯定不行。我的做法如下：
 

大家觉得累不累？呵呵，其实这已经很轻松了，当然，这里再次声明一句：作为程序员，我们还有一个办法，自己写段程序，不管是什么语言的程序，或者是编辑器的脚本程序，来生成上述内容，这自然可以，不过，这里论述使用纯粹的输入技巧，来完成大量相似数据的输入工作，所以我故意没有用程序办法，而是讲纯粹的键盘宏。这算个程序输入的技巧吧，大家学学，我觉得有好处。

因为我觉得，一个好的程序员，首先要做个好的打字员。毕竟，我没听说过哪个公司为每个程序员配置一个秘书兼打字员的，呵呵。什么东东都得自己敲进去。

上面的方法很重要，我做《隋唐演义》，里面几百个武将文官的属性值，差不多接近60k的数据，我都是用上述方法输入的，一个上午搞定。

这直接导致了，我以后评价程序编辑器，首先就看有没有键盘宏功能，没有就不用，很奇怪，VC6.0以后，引入了多个键盘宏录制的概念，这导致录制键盘宏不方便，没法做到一键录制，一键回播。所以，我又找了第二个工具，UltraEdit32，这个工具的键盘录制宏和播放允许自定义热键，我一般习惯于定义Ctrl-Q为录制，Ctrl-W 为结束录制，Ctrl-A为回播1次，嗯，它还有个很大的好处，Ctrl-L，可以指定回播次数，这样，上面的实验，我可以直接写个100，就回播100 次，就省事多了。

因此，这么多年，我写程序，一直是VSIDE+UltraEdit32模式，基本就够了。

嗯，说到用 VSxxxxIDE，比如我现在用的是VS2008IDE，这里面有个工具不能不提，Visual Assist这个工具必不可少，这个我原来没用，是来西安后，这边的同事推荐的，这是个好东东，几乎能把所有命名空间相关的信息，如类中的方法，成员变量，都自动在输入中弹出来，供你选择，编写基于类的C++程序就变得很方便。

嗯，这几个，就算我的基本开发环境吧，这么多年基本没变过。

到了西安以后，由于主要开发Linux程序，这个时候问题就来了，我不会vim咋办哦？呵呵。

后来我看了一下，gcc要编译的还是.h和.cpp文件嘛，这个文件我是在哪个系统编写的，有什么关系？我啊，接着用VSIDE来组织工程，编写文件。

然后呢，我在Linux服务器上开个ftp服务，以及一个ssh服务，每次编写好了，就ftp上传到Linux服务器的我的home下，然后makefile好了，《0bug-C/C++商用工程之道》里面讲了个如何写Makefile的故事，就是这么来的，呵呵。

当然，文件都上去了，我putty，登录ssh，然后转到我的home目录下，make，不就ok啦？

至于ftp工具，我其实没用业界常用的汤姆猫什么的，我自己一直习惯使用NortonCommand这个工具，从DOS就开始用，到了Widnows下，现在是TotalCommand，这个工具用来看文件（F3），编辑文件（F4），拷贝（F5）和转移/改名（F6）很方便，一直就用着，嗯，从开始到现在，差不多也二十多年了。

这个TotalCommand从4.x版本就开始支持ftp了，虽然不是很完美，但是，作为传输一点程序代码文件是够了，我一直就用这个工具。

其实我开发就这么简单，上述几个简单工具，再加上点技巧，就ok了。这里面我就养成一个习惯，每次敲完程序，一般在VC下就是一个F7，先编译一下看看，再上传Linux做二次gcc的make，这样久而久之，我写的代码总是先用VC编译运行检查，再用gcc编译运行检查，所以，《0bug-C/C++商用工程之道》说我的工程库是跨平台的，不是开玩笑的，真的都是两个平台都run过。

其实是3个平台啦，我买过一个arm9试验板，它也是交叉编译，就是得在Linux环境下，使用arm-linux-gcc编译，再传送过去运行，我是这么做的：
 

就是这么简单，由于我始终用我熟悉的几个工具，到哪个平台都没有变过，因此，我程序代码的敲入速度始终比较恒定，算比较快的。

这不像有些朋友，一说到Linux下，就必须得用vim什么的，偏偏vim比较老，对于现代程序编辑器的一些功能，比如键盘宏什么的支持不好，很多需要配置，编程序，很麻烦，我是程序员，写程序是第一要务，没有那么多时间跑去学工具，所以就没有学啦，呵呵。

嗯，但是，我以前的项目组，有几个同事，就是坚持用vim，我没说啥，毕竟，用啥工具是自己的自由，看他们编程序的时候，十个指头像蝴蝶一样在键盘上飞，也煞是好看。不过，就是效率太低，出错率高，很多时候，项目进度都受影响，后来我劝他们，没必要耍酷，还是用VC吧，好用得多，他们也慢慢都调整成我上面的习惯了，现在效率好多了。

就这么简单，呵呵。

这里面还有个需要提醒大家的地方，在VC 下，我们有很方便的调试工具，什么单步追踪什么的，但是，gcc下除非用gdb，否则基本没戏。这就麻烦了，arm9机器支不支持gdb我还不知道呢，事实上，gdb我一直就没有学，为啥？我觉得不好用。

其实程序调试这件事，抽象来看，我认为一个取决与设计，一个取决与检查中间值，没多复杂。
1、所谓设计，表示程序员需要精确控制自己的程序思想，走到哪一步，一个变量应该是什么值，要心中有数，这样才能确定程序运行时正确与否。
2、所谓检查，表示程序员要有手段“看到”变量的中间值，以便比较对错。
大家去想，程序调试是不是这么回事？

设计这个不好说，取决与程序员本身的能力，但“看到”，这个方法就太多了，没有哪个法律规定，一定要依赖IDE开发环境才能“看到”变量中间值，我和同事一般都使用“print-大-法”，呵呵，这个《0bug- C/C++商用工程之道》书上有讲的，大家以为我在书中专门花了两个章节，做了个Debug类和一个Syslog类，是做什么，其实就是自己做调试工具，随时可以把感兴趣的变量中间值打印到屏幕上或者磁盘上，方便回过头来比较，检查bug。
这个Debug类甚至是整个工程库的基础，它是最底层的类，它的对象，在进程一起动就实例化，在所有其它模块退出完成后析构，其重要性，不言而喻。
跟大家说句老实话吧，这么多年，其实我虽然一直用VCIDE在开发，但真没怎么去依赖F9、F10什么调试功能，基本上都是依赖自己的Debug类实现的调试。

原因很简单，我做的是高速服务器，高性能数据内核，并行系统，系统运行时，网络上几百上千个报文随时在跑着，几十上百条线程，进程，甚至服务在工作，很多时候，bug都是这么多因子互相影响的结果，而不是某个单独程序的bug，我跑去单步跟踪，这边一句话没有跑完，那边几百个信令都过去了，可以说，一个现场在被我看到的时候，已经被宣告无效了，我一直说单步跟踪在并行环境调试中无效，就是这个道理。

那怎么办？“print-大-法”呗，运行时不去影响程序的工作，不中断，不阻塞，所有的变量全部打印到日志文件里面，事后来分析，可以说，我最近几年的 debug，都是这么分析解决的，肯定不能用单步跟踪。这就是为什么我从来不学习gdb的原因，因为没用。

嗯，当我自己有一套很完善的程序输入习惯环境，同时自己的工程库也提供很完善的自校验机制，大家觉得我跨平台开发还难吗？呵呵。

喏，上面就是我自己的一点心得，包括我自己做开发，嗯，现在我计算机上正在做的一个HashCache，就是以上面讲的工作模式开发，习惯了，速度也很快。