或许要放弃jruby了

ruby 被团队所喜爱，但是真正把ruby做到系统里面的时候，却引发了一连串的问题，包括性能／内存等，服务器当机也应此而起

回想起这个技术决策的起源，其实是来自于当前业界的ruby风盛行，然后影响了团队的爱好，最终向团队妥协造成的结果，在我个人而言，我对脚本语言本身的一些特性，是能够想象到其中的一些好处的，但是在做技术决策的时候，我却没有在认真了解jruby技术实现原理时，就拍板同意了这一决定

这到底是谁的错？业界？团队？我？还是头？在整个过程中，每个人都在犯错，最终导致了这样的结果。

要引以为鉴，不可在将来再犯类似的错误了。其实应该感到幸运，毕竟引入脚本这样的决策，并不是对整个产品产生巨大冲击的决策。

技术团队年轻，敢打敢拼，但是在作判断的时候，容易忽略潜在的危险，这个在未来还会出现的，所以我更要提高警惕。

今天跟大家对比过去，我们的开发效率提高了3～4倍，并且在质量上有所跃进，其实究其原因，无非是以下几点：

1. 砍掉了没有用的项目，节省了成本 (100%，一些华而不实的项目被砍掉了)
2. 把人员调整到合适的位置 (100%，调整网站业务人员和c++人员到核心产品中)
3. 合理的团队架构和成员组成 (50%，从单兵作战到多人协助，分摊了压力，提升了个体能力)
4. 基于成熟技术编写的合理架构 (50%，源代码量缩减了33%左右，并且有助于理解和开发)
5. 有效的测试技术，项目管理制度和质量保证（版本控制和上线）制度 (50%，让个人工作压力得到合理分摊，提高工作安排效率，省下大量的测试时间，提高了项目质量，降低了维护工作量，根据统计，项目维护时间从40%～50％降低到目前的20％)
6. 有效的策划案实施流程 (50%，很多沟通时间和重复代码工作量不用浪费了，下一个阶段会在有效性上提升，将会有进一步的飞跃)

这些都不是因为赶技术潮流而得到的提高，而是实实在在通过管理获得的提升，我在运营管理上面所学习到的技能，更多是超越了具体技术的科学论，而这些才是真正能拿上战场和竞争对手比拼的家伙。下一个阶段，

从提升水平而言，我更建议团队成员去研究一下OOP概念／设计模式／算法和基础数学等方面的内容，这些才是长久的立足之本

对技术还是要保守一些，涉猎一下新技术就好，不要忘记了根本。其实javaeye上面 的新技术风很盛，虽然我知道作为程序员，对新知识的好奇心是必须的，但不是每 个人都需要学那么多的新玩意，精通就足够了，为啥？这个想想应该就明白了