:plus1:

#18 楼 @pengedy 其实文档本身并有错，但比较常见的问题是文档和代码没有同步更新。 我们把测试代码当做活文档，做重构的时候，只看测试代码和产品代码。而代码我们会做 Code Review 所以能保证一致性。

#16 楼 @pengedy 我们也有需求文档，只写：用户在什么场景下遇到什么问题，需要一个功能来解决用户的问题。产品经理会给一个大概的解决方案，细节需要工程师在开发前以及开发中跟产品经理当面沟通。 通过这种方法，得到了很多超过产品经理预期的方案。

1 减少手工测试时间 通常写了一段代码，如果手工测试的话，得启动应用、登录、制造测试数据、人工验证结果。这时如果写一个单元测试，就省事多了。

2 有效避免引入 Bug 在开发新功能时，针对新功能，其实很难引入 Bug，因为开发人员会手工测试，可能还有会专门的 QA 进行测试；但却非常容易破坏原来的功能，QA 通常会问 Dev，你告诉我重点要测试哪些功能，Dev 通常会说，你还是全部测一遍吧。而如果有测试代码，就可以在编码过程中频繁地运行，在引入 Bug 的第一时间察觉到，从而将修复 Bug 的成本降到最低。

3 可以运行的活文档 看产品代码时一般很难看出业务规则，如果有测试代码，test case 的名称也比较好的话，就可以当文档来读了，并且如果对某段代码有疑问的话，可以很容易地修改或增加测试来验证自己的想法。

4 提前搞清需求细节 如果进行 TDD 的话，需要在开始编写产品代码前就要分析需求，设计测试用例，可以帮助开发人员提前搞清楚需求细节，而不是写一会儿发现一个问题又去问产品经理（这样对开发的效率影响是很大的）。

想写这么多，想到再补充。

#13 楼 @martin91 今天飞不飞？

#11 楼 @prajnamas 并没有说文档没有价值，只是更喜欢当面沟通而已。每个团队有自己喜欢的做事方式罢了。

#5 楼 @tumayun 谢谢哥们！

#3 楼 @zoker 谢谢，已提 Trello。

#1 楼 @martin91 谢谢！现在团队所有人都是从社区来的。

#4 楼 @littlell 没问题，等回顾文章吧 : )

#7 楼 @yanglei_ruby 你直接去就好了，因为你能进去的嘛。社区成员就要先提流程，所以昨天截止报名了。

#11 楼 @kgen 不要被楼主误导了，是 gulp，不是 glup。

怎么可以没有深圳软件匠艺小组？

#1 楼 @tony612 谢谢，完全是最近敲太多 githug 了。

#6 楼 @xiaozi0lei Magic Move 和另一个小技巧。

#1 楼 @xlgwr 组织个 Emacs 训练营怎么样？

定向投“彩程设计”啊！

有意思，情不自禁 star 一下。

正好前两天在简书上看到过此文，不知作者是不是楼主？http://www.jianshu.com/p/b588d62daaa0

#9 楼 @gene_wu 我只是分享目前个人的读书情况，以后可能会像您说的一样。

#7 楼 @oppih28 是说欣赏文学作品吗？

#3 楼 @tuliang 我还没读哦，公司内有学习小组，应该比一个人学要容易。

#8 楼 @chairy11 Trello Golden

#37 楼 @simlegate 你理解错了，是我的手机和电脑在同一 Wifi 下，我才能用我的电脑给任何手机打电话。

#11 楼 @insraq 多谢补充！

#9 楼 @Ryan 我用的蓝牙键盘，在之前 Beta 版的时候很不稳定，正式版已经稳定了。可以试一下删除 plist 文件：

rm ~/Library/Preferences/ByHost/com.apple.Bluetooth.*.plist
sudo rm /Library/Preferences/com.apple.Bluetooth.plist

重新启动系统。

Ruby Motion 吧，用 Ruby 做 Android 开发。

ThoughtWorks 欢迎你，北京上海成都西安武汉深圳随你选。

#45 楼 @mr_zou123 很多人一上来不问 what 和 why，直接进入 how 的阶段，就容易陷入细节，走弯路，浪费时间。

这和 pow 功能一样啊，pow 还有 powder 呢 https://github.com/Rodreegez/powder