#65 楼 @simlegate 努力没什么事儿做不成，我不赞同，更重要的是方法要找对，然后才是努力

测试为什么不能解决问题我已经叙述过了，回头看我帖子，另外别忘了，RSpec 升级之后过去的用例集也要重构的，这工程可真不比升级系统小

#60 楼 @simlegate 少年，脑洞不要开太大，升级之前我早在半年前就用几个项目预演过了，唯一遇到棘手问题还是 Mongoid 当时处于 alpha 版有 bug，正好赚个 PR

难度多大、花费时间多少、无不无聊 看人，你能力够强、经验够丰富 没什么做不到的 世界上毕竟还是有 Linus 这种代码一次成型的大神的

#57 楼 @psvr rake routes 就可以完成 提高效率的有效方式就是少走弯路，业务代码首先无聊其次没营养，这样学习不浪费精力，何况代码数万行后了解整个系统运作几乎不可能。这里也是 Rails 的优势，通过 Convention 降低学习成本，构建好代码地图遇到问题就能够做到快速定位问题即可。

至于#58 没有证据表明测试和减少潜在问题有正相关性，例如 Rails 的 CounterCache 的测试用例就是错误的，实现也就只能是表面上正确。所以能够降低这个观点不成立。 至于你说不会 100%，我得承认具体问题具体分析，因为我不是反对测试，而是认为很多项目因为业务和工程上的特性可以变通的方式避免编写测试并且减少重构时发生问题。如果一个项目完全可以这么做，我认为写测试的必要是 0，肉测即可

#36 楼 @xdite 啊...好吧...

#34 楼 @yangjie6020 其实 Rails 内部很多实现并不足够好，但是因为 Rails 和 Ruby 的设计很好，所以其实并不需要精通他才能去贡献的，所以其实门槛挺低的... Mongoid 的话...我得承认很复杂，当初解决一个 Bug，追了一宿都没有搞明白那块的工作流程，代码质量感觉整体很差...

#47 楼 @lilu 话说新来的实习没有任务的时候我给过他一个工作：把网站每个页面每个链接都点开一遍，构建一张网站地图，把每个业务，比如购物、发布评测的业务流程整理进去，因为了解 Rails 的 convention，再把对应 Controller 的 Action 映射到这张地图上去

这样我认为有一个好处：1.完全了解各项业务了 2.从用户的视角去体验，对于哪里好用，哪里不好用也有了感性的认识 3.知道每个业务每个步骤对应了哪块代码，如果接到有关任务，可以快速定位

这种情况下，理想情况下，扩展、变动或者新功能与已有系统交互时，应当会有牵扯到到哪些代码的认识，也就知道要注意什么、测试什么了

当然，最终会不会出问题，还是看人

#47 楼 @lilu 我写那个是没看文章的时候回复的 首先，我在贡献代码的时候一定会写测试 但是在业务系统上测试什么、怎么测试，我个人的认识或者说功力是无法给自己满意解答的

例如，主要业务并不复杂的系统，人脑是可以穷举出各种情况并加以肉测的，何况我作为设计和实现者 此时编写测试我认为我们可以从中获益两点：1、接手系统的开发者可以通过测试了解业务 2、对模块进行改动的时候可以保证功能的正确性

但这里同时引入了一个问题，我们是不是会去追求 100% 的覆盖率？我认为不会，但如果不做到 100% 的覆盖的话，通过测试了解业务其实是个坑，因为测试不完全，为了驾驭代码最终还是要去阅读理解代码，流程其实在网站上体验一次就可以了解了，开发者不会用自己的系统本身就很失败，通过测试了解业务其实并不一定是最明智的方式，至于了解函数的作用，应该是通过编写 rdoc 这样的文档。至于第二个优点，由于测试不会覆盖完全，其实并不能通过测试说明功能的正确性的。例如之前遇到一个需求，我的方案需要重构所有页面的路由从_path 改为_url，这时候很容易出问题，测试的好处凸显，但是，我们除非为每个页面都编写测试，否则仍然可能出现问题。

而各种异常情况和边界值，我认为是很稳定的，不会因为模块变动而变动，在重构过程中只要保证接口不变还有接口的设计目标不变就可以保证最终行为的不变，所以只要保证最初版本各种情况的正确，今后升级问题不大。并且，这种巨大升级并不常见。

综上，所以我目前在业务为主、变化频率较快的系统上推崇肉测

当然，我对任何东西的看法从来都是动态的，所谓穷则思变，如果肉测解决不了问题，那么拥抱自动化测试甚至是 CI 都是自然的

#31 楼 @fredwu 感谢！

赞！支持给 cap 正名哈哈

#10 楼 @camel 感谢！去年麻烦你们来做志愿者了，今年一定会想办法招待好大家！

#12 楼 @winnie 因为我在北京，就像往届吕国宁在上海办，所有组织者都有工作的，并且目前看来都在创业...办会还是需要消耗很大精力的

#5 楼 @vman 没准下届，我其实一直在深圳工作的呀

#2 楼 @cassiuschen 邮件沟通

#15 楼 @iBachue 其实感觉有点像边界法，去年因为错过最佳的会场预定期不得不选择在市中心（那会场主要是给 gov 办会用的 - -），这届我想试试压低成本

#4 楼 @Victor 不知道是遇到什么情况...其实可以拿出来讨论下的

#35 楼 @simlegate 一边做主线功能一遍升级，慢慢悠悠花了一个月，没啥代价呀

另外就是 mina 的优点是部署好脚本然后扔过去执行吧 感觉不差这点时间 另外 cap 你在部署过程中可以中断，cap 会帮你做 revert 这不知道 mina 支持否

cap 的优点是 recipe 完善 像 lz 的那个 unicorn 部分其实根本不用自己写 用 cappistrano-unicorn 就行了

写 erb 和 slim 没感觉到差别... 项目里也是 slim 和 erb 混写，但个人坚持认为强迫缩进的语法就是反人类

怎么感觉最近的一些言论一直在向测试开炮。。。

肉测的胜利！！！ @lgn21st @hpyhacking 好吧文章我只看完第一段。。。。

TDD 目前只在写 lib 还有修 bug 时候用，因为目标十分明确，而且通过用例来描述问题比用文字简单、清楚多了... 业务方面，在允许错误的场景下，还是倾向肉测，首先写代码的时候可以保证业务逻辑的正确，业务变动相对频繁，而且刷新页面明显比修改代码然后重新跑的效率要高，并且业务变动频繁的话，维护测试用例也是额外成本

话说 KnewOne 在 0 测试的情况下，也顺利从 rails 3.2 升级到 4 了，最近又升级到 4.1

对了 专业回答得 @hooopo

#17 楼 @cassiuschen token_authencatable 么...devise 3.x 已经移除掉了 4.1 的那个内置 hmac 能解决一些问题了

#15 楼 @cassiuschen 解协议很无聊....

#13 楼 @billy 我就是看不下去了才贡献代码呀，本身我们也在用，但是首先，那个项目的现在维护者能力一般，那厮当初拒绝接受 orm 的兼容 pr，号称自己可以搞抽象层解耦 orm，事实上也有人提交了方案，但因为年代久远不好 merge 自己鼓捣几个月又没鼓捣出来。。。。复杂的重构他也不会接受，其次，这个 gem 的主要开发者是波兰团队，据说那边的开发风格就是以狂野著称，代码里有这样的注释# this is so wrong 但还是上了，恰好工作而已，甚至有硬编码的部分... 我是想接手这个 gem，但可以 KnewOne 实在是缺人手，所以没有精力做这些，你看我 ruby-china 都是潜水姿态了....

作为 doorkeeper 排名前十的贡献者，我想说...这 gem 太烂了...唯一的解决办法就是，彻底重写 - -