感觉不同人学习能力有差异

同意解决问题比代码本身重要

提供一种可能的思路，把编程问题和熟悉的事务建立关联

支持，道理上是如此，但我认为这些内容都是对有经验的人来说的，但有经验的人往往有自己的方法了，总结的意义不大了...

对于新手或者刚入行的人来说，个人对各种经验总结都持悲观态度，试着逐一举反例

1. 抓住主干，而非细节。 那么，什么是主干？什么是细节？你可以知道，但新手怎么能够知道，我们也可以告诉新手什么是主干什么是细节，但要做不同的事情主干和细节是不同的，前辈们真的有那么多精力么？比方说学写 Rails 可能很长一段时间都不需要自己亲自动手完成一个类，或者也几乎不需要操作各种 IO，但我想写一个统计代码行数的小脚本则反之了。

2. 尽量不折腾 和 1 类似，什么叫折腾？对于新手，本身就是白纸一张，做任何事情都是“折腾”。而且相对来讲，做网站 NodeJs+MongoDB 组合对一个完全新手来说可能是最不折腾的了，因为只需要学习 JS 一门语言足矣。而且在基本 CRUD 上，是不可能遇到坑的，碰到“坑”完全是因为用错了。

3. 尽量学习经典原理而不是浪费时间在细节上 原理、思想很重要，但是，一个实践不足的人能够理解他们么？此外，编程是极重实践的工作，任何思想最终都要化为一行行实实在在的编程语言的代码，思想和模式是提供思路的，语言的语法、特性、类库是解答问题的，两者分工不同

4. 尽量学习形而下的系统而不过多上升到形而上的思想上 学习 C 语言就要随着 OS 学习，学习 OS 本身就是一个巨大的范畴了，数据结构、算法、汇编等等，而 C 只是因为历史原因采用其实现而已。 学习 Lisp 就随着编译器或分析器一起学习，抱歉不好举例，但个人认为编译器和分析器与 LISP 或者 HASKELL 之类函数式语言也无直接关系 学习 Ruby 或 Python 就跟着 web 开发来学习，至少 Python 在科学计算领域也有着很大的市场，Ruby 也在测试领域还有 PAAS 领域有着很重要的地位 上边每一个选择都是巨大的坑，彼此之间完全不相干 此外，通过某一类系统架构理解语言的优劣，优劣是通过对比得来的，也就是说，你要用 LISP 和 C 写操作系统，用 LISP、C 或者 Py、Rb 对比写编译器，用多种语言写 Web 对比后，才能说出优劣，这完全是实践出来的总结

我认为成长只有实践，走弯路很正常、感觉困惑也很正常，遇到了，停下来，反思、交流，我觉得这是个穷则思变的事情，各种经典书籍里记载的也不是真理，思考的原料、实践的方向而已，在瓶颈之前，不要想太多

#66 楼 @tangzhan_ 感谢！ 过段时间会发布消息的

#64 楼 @fredwu 下届地点暂时保密恩... 这次还是要熟悉下组织活动的流程

#60 楼 @stargwq 控制在 200 左右，争取以内

已经入手，等纸质版，再买一本留念

这种情况 mongodb 更容易解决，我们的流程是这样的

1. 保留旧的字段，加上新的字段，如果涉及到数据迁移，则编写兼容代码，添加修改的时候再写入旧字段的同时也写入新字段 2.上线模型，并且在后台对老数据做数据迁移 3.上线新功能 4.删除兼容代码，清理废弃代码

下一届办在哪里 保密 恩。。。

蹭饭！

恩 会去

#65 楼 @simlegate 至于怎么找到方法，原因则很复杂，运气、个人经历、知识积累、经验等等都有可能

另外就是，人是会随项目成长的。面对问题来解决问题，然后总结，什么样的问题是常见问题，什么是跟场景有关，Rails 其实就是前者常见问题解决方案的集合。

#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 就行了