09年底写的小文,记录一下。回想起来，别有一番滋味。再描述一下，项目小组共5人,3个写代码1个整理需求1个迁移数据，除了我还有2个女孩是写代码。 老系统大约20w行c sharp,改造后1w行不到的ruby。这么少的代码主要得益于ruby的简洁和rails高开发效率。现在认为，在数据库方面没有做大多努力， 有些sql效率需要改进(不过一般的表就也不是百万级的)，有信心可以让整体性能提升一个级别。后来，我对oracle印象有改观(我本不愿意使用oracle)， 另一同事对ruby印象也大为改观(他认为ruby只能小打小闹)，总的来说，这次项目收获很多。

虽然我们还在忙乎着这个系统的升级工作，还在为客户没完没了的需求做努力，我们真是又累又烦了。真是因为这样，我们大多数人（我想应该说团队所有人）都希望逃离这个泥塘。 项目现状虽然是这样，但是咱们也要摆脱这些东西，来说说技术方面的东西。

有幸在项目中担任小小架构师的角色，应该说，我们在这次升级过程中技术上遇到了许多问题，但最终都算解决了，应该不会有什么不满吧？ 其实对这样的项目，一开始也是徘徊在所谓强大的j2ee技术和所谓前卫的ruby on rails之间，也不知道最后是哪个领导拍板上ruby on rails了。 对于这种升级性系统(从.net到xx),需求方面还是比较稳定的，用所谓j2ee貌似也是可行的，至少我在前期也的确看不到ruby on rails有太明显的优势。 可是我还是对选择ruby on rails没什么意见，也正好是可以证明一下并非架构只此一家，这也算一个不错的机会吧。

再说到具体的点上，假如你见过原来系统数据库设计的蜘蛛网，就会明白我们在数据迁移方面的工作有多么艰难。 还有其他一些原因，我们没有选择耳熟能详的mysql，而是选择了oracle。也正因为数据方面的原因，我们不得不在程序方面做出让步（即使这样，ruby还算比较优雅）。 至少，我们让程序兼容了数据。ruby on rails+oracle的探索也是比较漫长的，前前后后也修改了几次适配器(如数据类型识别，一些数据库选项)， 增加了一些插件来增加特性(如存储过程)。逆其道而行，真是吃力不讨好。虽然相对java来说，这些做法就像无聊的笑话一样，但是至少我们顺利的解决问题了。

随着项目深入带来的多如雨点的细节方面的调整，ruby on rails的优势才逐渐凸显出来。至少从我这个javaer来，区别是很明显的(俺也做过java项目维护,知道那是怎样一种体力活动)。 你不要好奇为什么细如牛毛的调整会这么多，可是事实就是这样了，咱也不解释了。在语言层面的强大真的可以节省不少精力，算起来也有n多功能，也才1w行代码。 按照我的经验，如果不幸用的是java，在这样战乱纷纷，弹尽粮绝的情况下，我们肯定会给java这门大炮压垮了。 在需求变更处理方面，动态语言的优势是相当明显呀，感谢MATZ，感谢DHH,感谢C-C-A-V。

现在项目逐渐稳定下来，我们考虑更多的是如果让我们的系统高效稳定的运行，能够及时处理bug。 关于性能方面，我们的项目是基于流行的lighttpd+fastcgi部署的，也算一个LAMP架构(最大的区别就是oracle代替mysql了)， 而作为业务系统，流量到现在最多也是20w动态pv那样子。我们也没有使用什么特别的缓存策略，运行还是相当流畅的(这还是在内存从原来16g减少一半的情况下做到的)。 基本繁忙的时候，都是oracle在那忙活着，这也是普遍情况，瓶颈大多首先出现在数据库IO。 所以，这样的架构性能方面也是没有什么问题，稳定性也很好。还有一次好处，我们的更新非常频繁，而每次更新只用短短3s左右，几乎是无痛更新。 得益于Linux平台，我们在监控，流量分析方面也是游刃有余(不得不赞叹一下shell)，另外得益于ruby on rails架构的灵活性， 可以做些调整方便我们监视运行状况（例如在top中查看真实URL，在单独的log中记录exception），这些都大大提高我们的效率。 这方面，大体上是windows和linux之间在服务器端的比较优势了。

现在回过头来看，在一开始打造的时候，我还是有些担心的,担心oracle和ruby的兼容，担心性能，担心处理ms格式(还好，excel和sqlserver至少是没什么大问题的)。 这也是一步步走过来的，现在就淡定多了。在项目前期，任何东西都不会有太大优势，只有到了中后期，才会有强烈的感觉。 另外，也杂七杂八的把以前自学的东西用上了一些，算是厚积薄发了一下，学以致用吧，感觉还是不错的。呵呵，感谢xy，感谢hnjk，感谢C-C-A-V :）