服务器开发的环境

最近由于项目原因，从原有的windows开发平台 转移到 linux下面开发， 虽然工作内容没有发生太大的改变，但原本熟悉的开发工具和调试环境通通都没有了，换来的是单调的黑屏字符一屏。 可能老早就有人说过开发服务器端的代码 终究linux才是正统。 这句话浅含的立脚点在于 服务器的程序 极少数是在 windows环境下运行的 ，所以开发理应在运行环境下做， 这样再维护代码的时候能更自然些。 道理听上去是没错，但其实这仅仅是对过往开发经验的一种妥协。

之所以这么认为 ，是因为最近接触了不少linux下面的开发工具，和新同事聊过其实他们对于开发过程中也有不少无奈之举，而此种无奈在于习惯于windows开发的人看来完全无意义。目前的项目是对一个已有的老项目进行资料片的开发和维护，而手里的工具除了vi 和 gdb 没有其他工具。听说过是有不少人用vi 顺手但这和在win下面用edit编辑代码又有什么差别。  项目的代码主要是靠充足的人手来保证，即每个人都维护一部分，且需要对该部分异常的熟悉。什么叫异常的熟悉？举个例子就是你得知道一个调用函数的定义具体在 哪个目录下的哪个文件的哪一行 下，事实上因为vi没有太多能够支持跳转的功能，如果开发人员不清楚这个函数到先前提到的程度，就得回到目录下用 find grep 命令搜索了，可想如果所有代码你想看一下定义都得先退出vi 执行一下shell 再进入vi去看代码 这么一个流程下来效率多么低下。虽然vi也有ctags cscope 的工具，但和va比还是差得较远，且周围的同事也被要求尽可能的少用这些辅助手段，因为在调试过程中没有这么多的插件，gdb一样要求你 通过 path+file+line 的方式来放断点。windows下编写代码和调试代码在一个IDE 环境里进行是一个很自然的选择，而且围绕这个IDE有各种丰富的调试测试插件来 对性能 健壮性 进行测试 。 而目前在linux下面的可选依旧很少，我了解到同事们的 手段还是集中在 vi里编辑， shell 下make ，然后 scp到 远端服务器上 进行 gdb调试， 而且因为有多线程的原因 往往都 无法 利用调试 来排除 编写期间产生的问题， 所以还是得靠 编写 和 log 输出来 进行修正。 往往一个功能在最终交付使用 需要花上几周或是更长的时间进行测试修改，而且也正因为此种原因 在目前的开发中 根本不敢进行 太多结构性的 设计， 因为所有功能关系 都是通过 会话式的 结构化开发 进行设计和交付，以隔离每个人的工作交叠。 在这种环境中 要求人人都是一个不允许出错的高级程序，显然这对人员和开发环境的净室期许都过高。

抱怨了这么多，也提出一下我的看法和解决方案。 其实上一个项目的开发已经充分证明了 靠移植 代码的方式 来换取 开发过程中的高效和易维护性 是可行的。通过ace提供的网络跨平台的便宜，简单一组配置就能让 netio 库在 linux下编译通过， 而上层的logic 工程 只需要对 .proj -> makefile 的一种格式化转化就能 轻松应对 gcc 编译。 这样一来只需要中途对性能充分测试以后， 就可以一直在windows下开发 直到 封版本测试前。 这样开发效率会极大提高，而且对新人的培养也相对容易。 

其实系统平台应该只是限制软件的 而不是限制 软件开发者的 门槛， 工作时应该更可能的选择适合开发者开发的环境