#25 楼 @iBachue 你们 QA 环境是谁维护呢？自己维护就可以用 migration

#23 楼 @iBachue 不知道是否可以开发者本地用 migration，正式环境更新的时候再给 DBA“翻译”成 SQL

#20 楼 @iBachue 可以考虑把某一时间的数据库结构用 rake db:schema:dump 导出，之后新的修改再用 migration 维护

#19 楼 @huobazi 这个建议不错，多谢！

#14 楼 @hz_qiuyuanxin 上万次的 commit 记录查看起来不太容易，所以我会尽量把代码留在当前分支

#12 楼 @leozwa 我经常做 code review，所以有这种情况

#2 楼 @leozwa #4 楼 @rainchen #5 楼 @billy #8 楼 @hz_qiuyuanxin

保留 migration 的记录不是更好么，可以追溯一个 model 的变动情况，保留每位工程师贡献的代码

#5 楼 @billy

这个 gem 已经经过测试，并且在我们项目的正式环境里使用了数月时间，没有出现问题，反馈不错

#1 楼 @ugoa https://github.com/swordray/modular_migration 如文档所说，只需要在 Gemfile 里引用即可，不用额外操作

iOS 应该以减少网络请求大小为优先

以前不小心用 order 做字段名，Rails 可以正常处理也就没注意，没经验的运维工程师看到哭了

#4 楼 @lgn21st debugger gem 好像还不兼容

“有车有房”也详细说说好吗

只有 Ruby 1.9 需要加，果断跳过了这个版本

Swift 是编译型语言，跟动态语言千差万别

按 Ruby 的理念去写，不难做到“代码即文档”（self-documenting code）

redirect_to :back

个人站长不需要用 Capistrano，没改 asset 就直接 git pull && thin restart，改了就加一句 RAILS_ENV=production rake assets:precompile

我习惯先尽量写成一行，在保持一句话的情况下适当换行，比如

records = model
  .where(params[:where].permit(...))
  .order(params[:order].permit(...))
  .paginate(page: params[:page], per_page: params[:per_page])

真是不好意思，让您失望了

Test::Unit 和 RSpec 各有支持者，让我想起豆腐脑的甜咸党之争

需要先把网站做到百万级，然后再看瓶颈在哪儿

我们的项目已经使用了 400 多个 Slim 文件，目前 Ruby、CSS、JavaScript 开发均感觉良好。跟 @allenfantasy 一样是 ERB / Haml / Slim 逐渐升上来的，切换毫无压力。

#4 楼 @zgm 谢谢指正！

Slim 的优点：

• 优雅的语法
  • 简短的写法，去掉结束标签而用缩进表示
  • 用 CSS 风格简写标签，例如 # 对应 ，. 对应
  • 安全
    • 默认对 HTML 自动转义，以防止 XSS
    • 支持 Rails 的 html_safe?
  • 高性能
    • 速度与 ERB / Erubis 相当
    • 与 Rails 无缝支持
  • 支持几乎所有主流框架，例如 Rails、Sinatra
  • 支持嵌入其它引擎，例如 Markdown、Textile 或其它语言，例如 Haml、Sass、CoffeeScript

  https://github.com/ihaveu/wiki/wiki/Slim

[keys, [default_value] * keys.size].transpose.to_h

可以去外包网站问问 http://www.csto.com/

Rails 4 的默认 database.yml 已经可以满足一般性的开发，使用的 SQLite 数据库文件也会自动创建，可以跳过这两步了