部门的开优化与分析会，新人也被要求去听，谓之培训。内容是个C++项目，听上去技术不是很难，但是比较大，维护了有几年了。说了些代码规范、注释风格之类。涉及到一些工具函数时，比如String与int互相转换，竟然要自己重新封装。我很好奇为什么不直接调用C++现成的库函数。后来方知，这个大项目是一个重要的应用，有PC版，也有Android版。PC版是Visual Studio直接编译运行，有界面什么都有，Android里面也是。而所谓的Android版只是在Visual Studio把整个C++项目编译成一个以.so为后缀的库文件，然后引入到Android里面以供调用。所以他们必须最大限度保持这个C++项目与Android的兼容性，即在PC上可以运行，但是Android上也不能报错。我又好奇，如果这个项目是用Java编写的，会不会省很多事？答案是花费太大。公司里没有几个Java工程师，大都是C++程序员。即便请一个Java大牛过来，熟悉公司业务也要非常长一段时间，公司能不能请来和留不留得住这个人也是个问题。明显这是一个legacy system！当我学习System Re-engineering时，曾经以为只有银行、医院里的大系统才具有那种特性，那就是，用新技术开发的成本太大了，而且风险特别大，公司的整个business都在里面。老系统虽老，但是经过长时间的运行维护，不断测试和修改，能保证现有功能，企业已经在上面投入了大量人力物力财力。而新功能的加入、系统的升级变得简单，只需在现有架构上继续开发即可，有路可循，即便这个过程有时候很憋屈，系统的某些缺点老是被诟病，让你很有把整个系统重构一遍的冲动。但是老板告诉你，不允许！

　　为期一整天的培训，什么都没听懂，唯一的收获就是第一天听说了.so。曾经有人问我，你有没有搞过Android里的C语音开发，我连说没有，对Android开发只知道皮毛，没有搞过这么高深的东东。原来也不是那么高深的东西，只是将C/C++文件编译成.so文件，然后扔到Android调用即可。我开发的时候只用到过在Eclipse中把一个EMF工程打包成jar文件，然后导入到Netbeans中继续开发，加上一些界面元素。这样做的好处是project manager可以集中精力设计EMF类和接口，其他人可以在Netbeans中同时开发界面（据称，Netbeans比Eclipse开发界面更方便，以我之见，也没方便到哪去，界面代码和逻辑代码混成一坨），要用到EMF类时再调用。缺点是，在Netbeans开发的过程中，如果遇到需要修改类的结构时，得请project manager，到Eclipse里去修改，然后重新打包jar，重新导入到Netbeans中。公司的情况应该也是类似，Visual Studio中修改后编译，然后重新导入到Android开发环境中。

　　在网上搜.so，一些前辈说类似于DLL。但是为什么不直接打包成DLL，目前我也不得而知。大概因为DLL针对Windows，而.so针对Linux，而Android是基于Linux内核。以后慢慢学习吧。