我认同在能提升可读性和维护性的情况下用方法代替临时变量; 但软件工程没有银弹，我认为这是一个最多只有 73, 甚至可能 64 的设计。

可读性

在方法数量合理 (这个是我个人感觉) 和取名合理的情况下，我觉得大部分方法都可以增加可读性; 但是注意是取名合理的前提下，如果对这点有些感受的人都知道，程序员几乎 50% 的时间都在思考如何取名，如果只是像例子中那样简单的把临时变量名改成方法名，我觉得对可读性是毫无帮助的，如果需要自己归纳总结，好坏不说，成本可能不会比后期重用重构的成本低。

可维护性

但是谁能保证以后一定没有复用需求呢？

我觉得这句话的出发点是错的，没有可预见的复用需求的的前提下我认为这么思考是过度设计。不说有没有价值，最简单的一点，我觉得存在被滥用的可能性。

关于整理代码的意识，很多时候——就像你说的——人们习惯于总结出一些非此即彼的“百分之百”的标准，更不愿意在具体的场景下具体分析

像你说的这句话一样，人都有惰性，很多人喜欢下意识的重用之前留下的东西，无论语义是否一致，只要代码逻辑有可复用的地方就会果断的修改和重用。这种语义放大的设计对后期的修改和维护是极不友好的，但是却很容易出现。所以针对这点，我会在最开始就考虑不过度设计这些东西。临时变量就好好的当你的临时变量，不要给别人复用的可能，最开始就不给别人想法，, 其实可以预防很多的问题

关于 临时变量 bad_smell 这个确实不太理解; 如果可以的话请详细解释一下好吗; 因为就我个人而言，是比较反对把不影响可读性，又没有复用需求的代码抽成方法的

基本全部赞同。但对最后一句话不完全认同。我认为像这个例子所在的情况可能没有重用需求，并且不会影响可读性 param[:type_id] = params[:thirdCategory].presence || params[:secondCategory].presence || params[:topCategory].presence

1. 这个是在 api 内部对参数做处理，这种 case 写法合理的情况下很少有重用的可能;
2. 看到 param[:type_id] =这里必然就会清楚后面值指代的意思是 type_id, 抽个名为 type_id 的方法对可读性不会有影响
3. 在这种情况下抽个方法，代码结构怎么组织，会不会有滥用风险等也是值得考虑的。
4. 所以我觉得一切写法还是要参考业务和需求; 任何百分百的东西都是伪命题

不确定你想要的是不是 at_exit

str.gsub(/(?!<a[^>]*?>)ruby(?![^<]*?<\/a>)/, "<a href='https://ruby-lang.org'>ruby</a>")

(?!<a[^>]*?>) 这里应该是 ?<!, 不过一般的正则库 look behind assertions 都不支持不明确长度的表达式。所以这种写法会有问题。

参考链接：https://stackoverflow.com/questions/9030305/regular-expression-lookbehind-doesnt-work-with-quantifiers-or

username: <%= ENV["APPNAME_DATABASE_USER"] %>
只要理解里面 ENV 方法的定义，你应该就能明白是那个环节你的理解出了偏差

可以看下是不是 ruby 版本的问题，2.0 之后才支持这种语法

就是因为 IN 要求加 () 啊，另外推荐用第三种

Customer.where('id in ?', [1,2]).to_sql
=> "SELECT `customers`.* FROM `customers` WHERE (id in 1,2)"

Customer.where('id in (?)', [1,2]).to_sql
=> "SELECT `customers`.* FROM `customers` WHERE (id in (1,2))"

Customer.where(id: [1,2]).to_sql
=> "SELECT `customers`.* FROM `customers` WHERE `customers`.`id` IN (1, 2)"

因为 rack 没有 0.8.7 这个版本啊...
https://rubygems.org/gems/rack/versions

不推荐把 gemset 混用; 但是如果真的要做，将两个 gemset 的文件夹做个软连接应该可以搞定吧。

因为之前的 rails 装在了 2.4.0@global 这个 gemset 里，切换 ruby 版本后，gemset 变成了 2.1.10@global

%w(cat dog wombat).map.with_index { |iterm, index| [iterm, index] }.to_h

#work = Work.new
#attrs.each do |key, value|
#  work.send("#{key.to_s}=", value)
#end
work = Work.find_or_initialize_by id: attrs['id']
work.update(attrs)

当你对 id 为 1 的 work 有缓存的时候，会新建一个 id 为 1 的 work 对象，然后 save.这是一个 CREATE 操作不是 UPDATE, 所以 uniq index 冲突了。

跟空格无关，你报错是因为 Time.new -t1中负号被语法解析成了-@,你可以用 Time.new <=>t1这种不会引起歧义的方法去测试，顺便说一句，这种报错一般给出的报错信息应该说的很详细了

send(:age=, 3) # 3
p send(:age=, 3) # 3 6

D3.js

https://docs.mongodb.org/ecosystem/tutorial/mongoid-documents/