学 4 的问题 会有不支持的情况（比如某个 gem），资料要少很多。rails4 本身可能就有 bug。 据说 rails4 相对难度大。觉得 rails 本身就很大，很难学。

当然也有好处，比如，一步到位。但问题是，你有多打的可能用的是 rails？又有多大可能你用的是 4？？？更可能的情况是，你大部分时间在写 JavaScript 或者是 Django。

#1 楼 @liprais :thumbsup:

#2 楼 @wangping #3 楼 @lex 我就是胡扯下。。。

#4 楼 @sufish 有理！！！:thumbsup:

#5 楼 @zhouchongzxc :thumbsup:

#33 楼 @Martin91 没做啊。。。我太懒了。。。

没有 Julia 不好玩！

#1 楼 @chenge :thumbsup:

#2 楼 @lihuazhang 觉得有些基本的东西需要了解，比如 stub，mock，比如单元测试的原则什么的。

#3 楼 @chankaward 又换头像了。。。

#12 楼 @sufish https://github.com/cloudwu/ejoy2d 这个似乎没有测试。。。

#9 楼 @ruby_sky 重点是大神好吗！！！sorry... 误会了 :)

我其实，就是找个机会，说下自己对测试的看法。。。楼主忽略我吧！

如果你写一段代码，会想着试一试你的代码（应该每个人都这么写代码吧？）。把这个代码写下来，觉得就是最简单的测试。好处显而易见，DRY。

有些没必要写，有的用不好 stub。这些情况，都会拖慢开发。但，代码个人觉得，代码质量的问题，才是最大的问题。

个人而言，半年来，写测试的时候，比我不写测试的时候要快，当然这也有可能是因为项目的特性以及记忆的不准确产生的偏差。但，我测试其实是覆盖不足那种。。。

TDD 其实前面还有 BDD，没 BDD 确定你做的是正确的事，既，你没有用葫萝卜钓鱼。那么有些代码会被直接丢掉。。。你写不写代码，都意义不大。

再者 TDD 不是说你写了测试，你就是 TDD，TDD 的流程，是 Red,Green,Refactor。你不重构，tdd 也没什么意思。

TDD，1 是分析问题的方法，明确目的，具体化问题。就好比接数学题的时候，如果你能问自己问题是什么，和举一些具体的例子，有助于你解题，见《怎样解题》。 2，分解问题。问题被分解为，有什么样的结果，和怎样去实现，是比较合理的。但同时也增加了相当大的复杂度。和学习成本，看如何取舍了。 3，代码的正确性，由代码自身保证。人脑不喜欢做重复的事情，所以，将重复的事情，交给电脑，也应该是合理的。大脑也不擅长逻辑思维，和抽象的事物（见《Your Brain At Work》），而测试刚好代替了大脑的这部分工作。 4, debug 时间和写测试时间，哪个多哪个少，也是看个人了。我 debug 能力跟屎一样，我也懒得学，所以用测试弥补。

释迦摩尼说过，不要相信任何人只凭听说的一切，当真正实践过，并且和自己的“原则”相符的时候，才去相信。

如果真的在乎这个，去读读相关的书，《Test-Driven JavaScript Development》，比如《重构》。了解不同人的不同看法，反对的，支持的。 亲身实践。写测试也分人。写测试也需要经验积累。

不写测试的，一样有牛人，比如云风似乎就不写，一样很牛，再比如 @ruby_sky 。写的，当然也有很烂的。

测试是手段，不是目的。

one more 如果，你写测试，不开心，不写测试，可能会更好。如果你 debug 不开心，不妨试试写测试。

见过 python 的 doctest，感觉不算是单元测试，没 stub 什么的。但又是测试一个 function 的。。。也可能是写测试的人出于某种考虑，没有用到 stub 什么的吧？ 没研究过 python 的 doctest，不知道第三方依赖是否是个问题？比如 respec 是不是每个文件都要引入？再比如 factory，觉得需要有单独的文件。

从 emacs 换成 sublime 又换回了 emacs。。。

#1 楼 @karmue 觉得覆盖要分哪种覆盖。如果是语句覆盖，90 是应该还是合理的。边界之类的，不在语句覆盖之内的，过早的考虑就是累赘。而且感觉这也不在 TDD 考虑范围内，TDD 有的观点只有，就是问题没有出现的时候，就不去考虑。

#4 楼 @chairy11 Master Boot Record 如果我记得没错的话（很可能是有错的。。但这个不是重点，真不是重点），想要加载系统先要“找到”系统所在的地方，所谓找，其实就是按照“门牌”找，而所有的门牌号都存在了 MBR 里，而 bios 启动的时候，会先找这个 MBR，然后通过 MBR 找到别的。。。

而 bios 是，在此省略若干字。。。

其实，我想说，我不知道如何解决你的问题。。。要是我的话就去找装电脑的了（羞。。。）。。。

好像 fitter 和 goto 有点关系。。。

推荐Engineering Long-Lasting Software 的第八章。 简单来说，就是先把项目跑起来，使用一下，有 user stroy 的看下 user story，没有的话看看 git commit 什么的也不错，最好能使用者交流下什么的，问问开发者什么的。之后注意下 models 的结构，有个 railroady 可以生成 ulm 图片。然后分离出具体问题，既你想要改或者要理解的部分。

当然这个过程比较复杂繁琐，楼主不喜欢，就可以无视他。多试试，找到自己方法。

先熟悉项目，了解需求，了解框架，找到相关部分，然后就是尝试着更改了。

个人经验是，不其实我没啥经验（我看的源码少的可怜，不是必须的就不看。。。） 1，带着问题看，或者有很明确的目的。 2，越晚接触细节越好。 3，分解问题，解决问题。

觉得我看代码的时候，一般都会看不懂。。。被逼着一定要看（一般是项目需要），才有可能看懂。。。

#15 楼 @ruby_sky ???

#10 楼 @ruby_sky #11 楼 @allenfantasy 我觉得叫涛哥也不错！霸气！

我觉得我很大程度上是在远程。因为和我做东西有关的，就一个人，在美国，但我我的工作地点是在公司。 个人感觉。 交流 交流是最大问题。 你做的事情可能是没必要的。。。或者一些细节搞错。 1，是多问问题吧？有的时候把对方的话重新组织下，问问对不对（本人英文比较渣）。 2，大局优先，先画大框，而且怎么 simple 怎么来（有出现过，把问题搞复杂的情况，比如我昨天还做了一小部分不必要的事情。。。）。 3，如果必要资源没给出或者事情没确定，建议先协商好，可以直接 pending 住。我始终相信，在任何软件开中，时间最大的浪费是在做的不是别人想要的这块。而且，真心觉得做不需要的事情是浪费时间，浪费生命。 4，测试可以非常好的降低交流成本！ 1），明确目的或者需求。 说的话不明确，语言比来就比较模糊。写成测试，就具体化了。觉得具体的东西都是好东西，哈哈。 大家应该都有感觉，写东西比说话难多了。书写，可以很好的帮助人思考。 2），动态文档（文档往往没办法跟着代码走）。 测试写的 ok 的话，大家也习惯测试的话，直接看测试，可以不需要跟你交流（当然这是理想的情况）。 3），代码最少化。 5，团队 DRY 如果有些坑，你踩过了，别人就没必要再踩一遍了。比如某个插件，我用的时候比较二逼，直接掉坑里了，如果别人也用这个插件，几句话就可以避免再踩这个坑。这个在远程比较不好搞。。。 如果遇到坑，第一时间在群里吼一声，没准就有人遇到过。如果团队有时差。。。自己解决吧。。。 一些配置。比如 emacs。。。如果公司别人也有用的，你配置起来会舒服很多。

（未完）

#12 楼 @chairy11 如果达成预期的话，人脑会释放多巴胺，而多巴胺促进大脑细胞之间每秒链接的数量，会看要到更多的可能性。 而没有达到预期的话，多巴胺会下降，而这会产生和疼痛很像的感觉，并且想要以逃跑来回应这种感觉（不想做了），影响你的逻辑思维和创造性思维。

帮你顶下吧。

话说至少半年前就看到楼主招在人了。。。

觉得后半部分似乎可以这么写 post && post.title

#12 楼 @chankaward ...

没法直接回答，但是我记得在 卡斯帕罗夫（陪深蓝玩那位）的 棋与人生 说有举行过人 + 电脑（深蓝有的时候也需要人来调整策略）辅助的国际象棋比赛，比较牛的，不是国际象棋大师，也不是很懂计算机的，而是两者都懂的人。但我记不清具体的规则是什么了。。。

只知道最简单的方法是对所有可能尽可能的穷举，然后给每一种可能的情况一个评分（是否更有利），下一步是分数最多的那个。

跑下题，卡斯帕罗夫有一次推算了 20 步 +（可能是 36 步吧。。。），但他自己也说忽略了大量的可能情况。

再跑一下 还有某个大师，下着棋，大脑中有歌谣想起，于是收到了启发。。。于是赢了。。。人在想出很难的问题的答案的前一刻的大脑是非常平静，然后突然爆发。good idea 也许不是“想”出来的，而是“不想“出来的。

随便一提，现在国际象棋方面，难点不是如何让计算机更厉害（据说的推算能力是 200 步），而是如何让计算机笨成不同等级。

#13 楼 @Rei #15 楼 @lidashuang 非常赞同！rails 提供了非常多的便利！觉得写 sinatra 是上手容易，但真正写好了，很困难，对程序员的要求很高！

但如果只从学的角度考虑呢？觉得 web 开发，还要学习 html，css。这些相对简单，也容易上手，入门什么的应该也说的过去。php 的好处是直观（不框架什么的），php 直接嵌在 html 内，比较容易理解，再比如 url 也和文件有个简单的对应关系。而 rails 有很的封装和约定的东西，觉得对于新人理解起来并不容易。

觉得学习来讲，循序渐进比较重要，当然这个也和人有关。当然，如果考虑到楼主需求的特殊性，学习 rails 也是不错的选择！

#2 楼 @Rei 我只知道 Sinatra 比 rails 简单。。。你的意思是说，资料什么的不全吗？我想我对 Sinatra 的看法是错误的。。。

#6 楼 @lidashuang 能具体说明吗？

为啥非要学 rails 啊？ 如果楼主认准 rails 了，就忽略我下面的话吧 可以简单了解下比较小的框架，比如 Sinatra，比如 web.py。python 本来就比 ruby 精简很多。rails 又具大无比。 觉得还可以考虑下 head first 的 html 和 php。也是不错的选择。 觉得学习这东西始终挑最容易的学比较好。。。

觉得数据库是 base