之前没注意这篇 blog，感谢 @hpyhacking 在 http://ruby-china.org/topics/10381 写了这么一段让我注意到
所以我认为脚本语言是一个祸害，它几乎永远是错误的决定。
我们应该尽一切可能避免使用脚本语言。在没有办法的情况下（比如老板要求），也应该在脚本里面尽可能的使用通常的程序设计原则。
摘自 http://www.yinwang.org/blog-cn/2013/03/29/scripting-language/
我基本上赞同王垠博客里的观点，事实上这也是我一直以来比较注意的一个事情，除了 rails/sinatra 这样“手把手”的框架外，很多人（包括我）写的 ruby 代码基本上就是脚本堆砌，我见过公司的另外一个同事写的运维脚本，除了使用 ruby 语言，我找不到和（新手写的）bash shell 有什么不同——同样无结构、缺设计，而这是难以维护和不能长久的。
举个例子吧，类似的现象常出现在对 AR 的使用上，我们知道，在 M.F.的企业应用架构模式中，与领域模型做对比，还有一个业务脚本（也翻译成事务脚本）模式，后者的困难在于难以迎接业务的演化，所以结合 ORM 技术，我们 rails 中使用了充血模型，但是 AR 本身并不能保证你不写出“业务脚本”，比如：
Product.where("created_at > ?", Time.now).where(:owner => user).order(:id).limit(5)
这句话并不比
select * from products where created_at > now() and owner_id = #user.id order by id limit 5
更加结构化和易复用
当然，有经验的人都知道，正确的做法是使用 relation 技术复用各种 scope。但是，如果没有 AR 或者 Rails，有多少人能够意识到什么才是正确的做法呢？而王垠这篇博客的观点其实正好提醒我们——虽然 ruby 号称是脚本语言，但是作为一个程序员，你必须知道在必要的时候用严谨的方式使用通常的程序设计原则，避免“脚本面条”
BTW：之前很多同学都在讨论面试时怎样体现“深入”，我想，能充分理解这些做法的来龙去脉，利用工具而不是受到工具的支配算是一个方向吧。
不同意王垠这个观点 他根本没有开发大型项目的经验 根本看不到脚本语言在开发速度上的优势。 我不否认运维脚本存在代码堆砌的现象，这只是因为这个脚本通常完成一些很简单的任务或是只运行一次，用完即删。因此心理上没有足够的重视，如果换一种更严谨的语言也未必解决这个问题。如果是标准的项目，肯定会基于一套已有的框架或是自行设计，因为心理上已经足够的重视并且可以预见到这个项目未来的规模，肯定会足够谨慎，不会再出现堆砌代码的现象了。
用 shell 或 ruby 这类语言的脚本只要用 vi 或 nano 改一下就能立刻跑起来。用静态语言，比如 Java。我会先打开 eclipse，然后改，编译，打包 jar，上传....
[Build Awesome Command-Line Applications in Ruby] 推荐这本书，一步一步把脚本变的 awesome
说说我个人的感觉吧，其实很多时候，我自己都会陷入一个泥潭，就是如果我用 RUBY 开发，如果有个人指出了 RUBY 的某些问题的时候，有一瞬间，我是很难接受的，我觉得要反驳他，不然有种被冒犯的感觉，但是自己想想，我觉得任何事情都要分开看，楼主所说的完全正确，当我们写脚本的时候，确实容易写出很多所谓的脚本面条，所以下次写的时候，如果这脚本不是一次性的话，注意抽象和设计，让它维护起来简单，我觉得这并不代表 RUBY 不如 Java 或者说脚本语言不如所谓的正规语言，每种语言都有自己擅长处理的事情，没有一门可以搞定所有事情，所以我觉得还是要辩证的看问题，在用脚本语言的时候，让我自己写的代码更具维护性，在用所谓的正规语言的时候，尽量让自己的架构部要太臃肿，不管使用什么语言，警惕它可能引入的问题，最终让自己写出的代码结构清晰，易于维护。
rails 确实是强大的工具，很多人对自己也没那么高的要求，如果只是用来写一些简单站点的话，rails 还是很不错的。 如果说想提高的话，ruby/rails 中也有很多不错的思想。 如果说写脚本害怕面条的话，写的时候注意就好了，一切都要看使用的人，脚本所拥有的开发速度是很多静态预言所不能达到的。rails 有些人看着笨重，有些人看着敏捷，就是因为他们从不同的角度观察的，使用起来自然也有所不同的。 而且语言和使用习惯也是因人而异的，事务都是存在既合理的，更不用提语言了。
还有例子里说那个 ORM 模型，我是能看到笨重和效率损失的，但是我同样看到了可移植性和结构化，这两个语句是无法比的，一个也许是可以注入的，另一个则不能。
不设计和过份设计，这个还是只能看程序员自己。gnu grep 的源码里 main 函数也有 400 行，都是 if else，switch case，一样在用。
如果只是简单的脚本，我倾向于最简单的设计，甚至于没啥设计。 如果是个工具包，gem，web app，那适当做设计。
lz 举得的例子不太能看出效果，抛开 rails，orm 还是解决很多问题的，比如 escape，sql 注入等。 而且如果例子里的 where 和 order 没有被复用，这样的代码不觉得有太大问题。如果真的被用到很多次，再改成 scope 也没啥问题。
赞同@fsword 说的，ruby/rails 是很强大的工具，但代码的重点并不在于他们。特别像我这种新手，的确会有用了 ruby 就和其他人不同的错觉。关注各种奇淫巧计，殊不知程序设计思想才是最重要的。我们总会无意识的写出脚本面条式代码，很难写出拿得出手的东西。我们需要抛开工具，深入学习，或者至少可以了解工具的来龙去脉。这个过程肯定会有点枯燥，没有永远好远有趣的东西，除非你要当一辈子新手，我不要啦。。
