对Robbin《ruby on rails为什么暂时无法成为企业应用开发的主流？》的一些思考

对Rails开发方式我也在思考，对动态类型和meta programming已有的一些实践需要调整，也许需要引入一些新的做法。不得不说目前的大部分Rails项目都是少数几个人搞出来，即使那些访问量较大的成功站点不代表其代码量就大到需要很多人编程。所以对大规模的项目如何管理开发没有什么典型的例子。Getting Real涉及一些，不过更多是讲商业上的而不是软工上的实践。

动态语言不使用强制的interface而是用duck type，也就是隐性的接口。这种对象界面间的隐性接口在Rails里被进一步扩大，也就是robbin说的mvc之间的各种约定。显然在这种情况下测试被放在一个更重要的地位上，但是麻烦在于有些约定是不是那么容易测试的（何况Robbin赶时间没写测试。。。）。没有测试就不敢动别人的代码，不小心破坏了某些约定也无知无觉。但是我感觉即使Rails内置了多达三个层次上的测试手段（基本对应MVC三层），面对那些鬼斧神工般的class_eval和monkey patch还是有些力不从心，需要更智能的覆盖测试工具。我一直很喜欢Matz说过的Ruby设计哲学：A sharp knife may cut your fingers, but it's better than a dull one. 想少受伤怎么办呢？长远的办法是磨练使用技术，而直接的就是加强防护带手套咯。至于那些说Ruby过于灵活的就好比说要把刀磨钝点才更安全一样 如何磨练技术和加强防护这是值得长期研究的。

Robbin说的纵向分割困难我也有体会，比如validation和权限系统几乎要贯穿mvc三层，有些情况下MVC要清晰切分确实不如理论上那么容易。从实践角度讲无需追求那种纯洁性，但是软工角度上确实不容易分工。至于横向分割还好吧，对复杂的逻辑我也见过用命名域分割的，虽然这种做法会需要调整route和一些helper，甚至一些plugin。至于一个controller的action太多我认为是设计问题，scaffold给人的一个不好的错觉是误以为一个controller得对应一个model。其实一个controller对应的是一个function,它可以对应一个model或几个model， 一个model也可以被几个controller对应。如果一个controller太臃肿，function可以重新划分一下。

最后Java界积累的那些模式和工具（AOP, IoC之类）哪些能套用哪些不能或哪些需要修改才能适用到Rails上不是简单能分析出来的，估计需要比较长的时间才能融合。这个过程可能非常慢，因为大部分用Rails的人主要关心get job done并且符合自然和美感，大家喜欢谈论是那些美妙的hack而不是书本上的UML。C++/Java的设计模式其实很早在Python和Ruby社团都有人研究，但是始终很少有人刻意强调。Why? 我们不要忘记设计模式是怎么出来的，是人们经过长年累月的使用OO语言（主要是C++）总结出来的那些反复出现的好的设计思路。所以对那些非C++类的语言，一是需要时间积累，二是出现的新模式可能和现在的不同, 三是需要足够大的项目才会促使人思考这些问题，否则就不值得花这个力气。