Rails程序开发的最大问题是代码规范

这个跟我们team用的jira一样，jira里可以定制一个ticket的生存周期，我们的做法就是在ticket给QA之前加一个“Code Review”的流程，只有经过“Code Review”之后才会进入QA测试阶段

但是，Code Review又如何能保证Review者确实按规范认真去Review代码？
所以还是缺乏执行力和监督机制

冉翔同学的点子倒是不错，我记得以前有家公司在招聘新人时整个team的member都会面试一下应聘者，如果有一个team member觉得不行就否决掉，这样能保证新的应聘者能够让team每个成员满意，以后工作起来就不会有意见，貌似这家公司就是TW吧？

我以前所在的公司也是如此，这样招聘尽量会使得团队成员有效协同的工作。而且能够保证相同水准的人在一个团队工作.

既然你不缺乏工具，不缺乏技术，不缺乏能力，还是在人员上下功夫，把不合群的先隔离。

哈哈，没有这么大的权力

这个问题背后，是一个不争的事实：我们的经验积累还很有限。

我非常相信楼上几位都有非常丰富的rails项目经验，但我更相信绝大多数像我这样：用了几年java,但只有一年的ruby经验，有几个项目经验，但团队规模都在3人左右的级别。

rails如何拥抱“大规模项目”(30人月以上)

在享受着rails,ruby给予我们以强大的快速开发能力，与编程之美的同时，如何不滥用这些power?

或许我们以后可以分享一下自己的best practise,就像下面这个网站做的事情一样。
http://www.therailsway.com/

每隔一段时间，让每个人拿出自己认为写得比较好的代码，给大家讲一下。
认为自己没有好代码的，揍他。
拿出来的代码自己都没搞懂或者大家都看不懂，揍他。
一半觉得好一半觉得不好，分析分析原因。
都觉得好，推广起来。

 

如果能和小日本那样就好了。

 

那样不一定好，对于软件开发来说，这样只会限制创造性。gigix说的那个隔离，很难执行。大部分创业公司需要人手，像lz公司当年那样的，肯定找进来很多不会rails的，慢慢培养，这事没办法的办法。

时间、人员与代码质量的一场竞赛

世界不美好，所以在这种竞赛里必须有人付出更多的代价

区别在于是谁，什么时间而已

跟rails技术本身关系不太大,我们每个人在使用这个新技术的时候,都会在犯错或个人创新的基础上,不断改进.
这些东西会随着时间慢慢清晰起来,每个人的积累也不一样,如何让这些个人的经验随着产品的发展,迅速的传播给每个人,最有效的共享?
这些经验,不止是编码规范,也会包括其它方方面面的活动,比如如何沟通,如何设计,如何实现某个特定功能,如何处理某个通用问题,如何升级,如何测试,... 都是一个个或大或小的套路.

甄别出哪些需要共享,哪些需要通知给其它人,俺们wwei同学已经总结的很好了.

人的能力在某个时刻下就是那样,保持有效的制度和文化才会不断的自我改进.
至少,能让人尽情发泄比沉默要好.