最近我们做了一个GIS和RS系统，客户端使用C#+ArcEngine，服务器端使用C++，使用C++的目的是为了主要就是为了提高计算速度，服务器端并能够跨平台。作为一个以后要维护和复用的平台系统，服务器端选择可以跨平台的标准C++绝对是一个正确的选择。而客户端就是为了针对特殊的应用而开发的，而且对于客户端，客户在实际操作的时候会提出大量的问题以及需求，所以我们选择了C#。我们的目的也是只要客户端能够在windows下运行即可，毕竟作为客户端，绝大部分客户还是使用的Windows操作系统。
在客户端和服务器交互选择了ACE，选择ACE当初的初衷是为了能够让客户端直接操作服务器端上的对象，而且操作方式和客户端本地的对象一样简单，即远程对象技术。但在实际操作的过程中发现这种技术的难度比较大，但鉴于系统的开发进度已经完成的情况，不可能再去替换别的技术，所以就只能接着使用者这种技术。这种技术带来的另一个十分严重的问题就是一旦负责ACE的同事离职，那么这一技术需要一个新人花费很长的时间才能接受，因为这种技术不想其他的比较常用的技术，会的人很少。要是选择普通的类似Web Service服务的技术就可以。但当时我也是支持选择ACE技术的人之一，现在想想挺后悔的。
所以劝一些设计和开发人员在选择技术的时候，判断的标准不是该技术是否够新，够酷，而是只要满足系统需求就可以，技术要成熟，用的人比较多才是最重要的。
我主要负责客户端的设计以及服务器端基础平台的设计，服务器端业务部分以及通信部分参与的比较少。所以等我过了一段时间之后，当系统进行到后期的时候，服务器端业务部分以及通信部分老是拖项目的后腿，有个原因是服务端的业务部分在项目时间紧的情况下完全进行了面向过程的开发，在思考了设计时也都是按照面向过程的方式进行的。这个系统本身就是一个不小的系统，业务的复杂程度可想而知，而且还需要和其他的系统进行交互。所以在项目的需求不断添加时，服务器端的响应速度越来越慢，并且其稳定性越来越差，开发人员不得不花费很多时间来修复系统的bug，而不是增加新的功能。
后来我仔细看了一下服务器端通信和业务部分的代码，很混乱，代码注释很少，里面有很多注释掉的临时代码，也不知道被注释掉的原因。而且业务部分的代码组织方式面向过程的成分很多，没有分层，和外部系统的交互以及对数据库的访问被和业务模型搀和到一起，没有分层而言。每当我问起服务器端怎么会做成这样子的时候，服务器段主要设计开发人员给我的答复主要有下面几点:C++不像你们C#，需要那么多设计，我们主要是为了实现功能，提高效率；任务那么紧，这两天就要出功能，就是写临时代码也得把演示的功能实现啊；C++本来就很难，能把功能实现就已经很不错了。
每当听到上面的回到，我的窝了一肚子火。而且有些功能我认为在服务器端应该很好实现，但这服务器端却说实现很麻烦，需要很长的时间。有时候说C++和C#不一样，要实现一个功能没有C#那么简单。我觉得有些可能是以上的原因，但绝对不是大部分。这也让我有了学C++想法，因为每当上面的情况，我都没实质性的答案来反驳。我知道作为一个项目的管理人员，可以不负责具体技术的，主要把设计的思路和目标告诉主要的设计和开发人员就可以了，但有了这样的设计和开发人员，让你没有办法放心。
最终，由于多方面的原因，那个负责服务器端的主要的设计人员离职，这导致了整个项目严重的滞后，更要命的是整个服务器端的通信问题没有人负责了，这个本身就是一个技术难点，就需要专门有一个人来熟悉服务器端通信的原理和代码。而这将花费很长时间。
难道C++只是为了做底层开发，和硬件打交道或是做嵌入式系统用的吗？C++也可以做业务系统，也可以对现实世界进行模拟建模，而且这些东西在本质上和C#以及其他语言是没有什么区别的。并且现实中，太多用C++做的业务系统了。像ESRI的ArcEngine库，我觉得那个库是我现在使用的库中组织最好的。
只是C++学习起来比较困难，使用起来比较麻烦，所以在应对需求不明确，容易发生变化，对效率要求不高的系统来说，确实有些大材小用，所以C#和Java等语言等较为简单易用的语言就成了做一般业务系统的首选。但要做一个产品或是平台的核心还是需要C++的。而有些C++开发人员拿C++的难来和C#开发人员来说事，觉得使用C++就高C#一等，甚至有些看不起使用C#的人，认为那些都是一些花哨的东西，但大部分人也没有学到C++的精髓。估计很多人都有这种心态吧。
一个学到C++精髓的人，肯定会明白C++和C#以及Java等并存的原因，在合适的时候选择正确的语言和平台开发。而且面向对象和一些方案在大部分语言和平台上都是可以使用的。
虽然整个系统已经进入了后期阶段，但还是比较被动，幸好好友几个兄弟坚持着。这也和公司的一些政策有关。