难免扣除了印象分，今后共事会带有先入为主的看法。

公司缺人呗，想着有 x 年经验即使没什么出彩的也不会太差，没想到坑了。

Rails Guide 里有很清楚地讲到这两个用法的区别和使用场景。

然而提示了。

这个不方便讲，不过不算少。

本身多对多关系就是需要中间表，不论是否承载独立业务，不论是在哪个语言、哪个框架中。has_many_and_belongs_to只是框架上的封装，RDB 里该怎么样还要怎么样。我觉得这些也是 Web 后端开发者的常识吧，与框架无关。

同没用过。感觉这个函数是给新手用的，太过简单，不符合业务场景。

嗯，以后也得这么搞。

嗯是的。

我敢保证那天下午一定不是“人多的聚会”的场景，聚会的氛围和忙碌的 Office 的氛围完全不同。

另外，遇见这样的开发者也算是小概率事件吧。

这得是多脆弱。。。

就是因为有这么一个下午的时间，还有 error log 的提示，我才觉得无法理解/接受。

我也不敢保证自己能什么都不忘，但很基本的东西，又加上充足的时间和提示，再怎么忘也都该想起来了。

不排除，但小公司考证不来。

怎么讲？

兄弟我多问一句，这个价值观是怎么看出来的？

既然你能理解has_many_and_belongs_to，那么如果实体 A、B 之间存在多个“多对多”的关系，你这一个has_many_and_belongs_to就完全不够用了，这时候就该用has_many through了。

最简单的理解，就这样。

我上面所说的，是我对 PM 和研发的职责划分。我能在一定程度上做好自己职责之内的事，但 PM 那边做不到、又管不了，这是我这边的问题。

这套思路是我最近理清楚的，还没来得及推行。要让整个团队都认同这个观点，大概会比较难。

受教了。

我不觉得吧。

这事情你仔细想想，很不对劲的。

1. 这是开发者的常识
2. x 年里是做了多简单的业务，才能把多对多关系表给忘掉？
3. 有报错信息说 xx 表找不到，但不知道他是看不见还是看不懂。

评价他是我的事情。颁奖就不必了。

他的程序一直在报错，但是不知道问题在哪。

很简单：

• 业务主导的开发，PM 权重大于研发
• 技术主导的开发，研发权重大于 PM

两边的出发点不一样，区别还是非常大的。

第一个例子：

就像上周我司开会，要在 App 里集成运营的功能，老板是个聪明人，就一下子指出不光要有 App 运营内容展示的模块，还要有一个发布运营内容的地方。我直接把话接过来，讲到“App 上只是做到运营内容的展现，但运营是公司的业务之一，运营的闭环是产生、发布、展现、回馈，因此这里至少还需要一个用于发布运营内容的平台，才能把这部分做出一个最基本的可用的样子”。

第二个例子：

App 上要做一个 xx 综合指数的数值（姑且称为 INDEX），这个数值由几部分不同维度的数值综合而来（姑且称为 index_a、index_b、index_c...）。那么首先：

1. 这个数值是给谁看的？
2. 我们给受众展现这个数值，有什么直接作用？比如 360 产品的“电脑开机速度打败 95% 的用户”，比如“本周您的运动步数为 xx，在朋友圈中排名 xx%”，这完全不一样。
3. 我们给受众展示这个数值，有什么长期目的？是单纯的增加用户体验，还是为了增加用户活跃度，还是为了配合公司其他产品的活跃度/销售，还是为什么大功能铺路？
4. 因此这个数值应当（或理想中）达到怎样的表现？满分是多少，分几个层级，每个层级代表怎样的含义，如何引导用户加高（或减低）该数值，会引导用户进行怎样不同的操作，等等。
5. 所以，具体来说，INDEX 与不同维度综合指数的关系是怎样的：线性关系，指数关系，还是更复杂的非线性关系？不同维度所占权重是多少？
6. 用户查看这个指数的场景是什么：实时更新，按小时更新，亦或是日报/周报的形式？

以上六个问题，与业务密切相关，PM 本应深入理解业务，那么回答以上六个问题也就是分内的工作，但凡抛一个给工程师，只能说明 PM 失职或者能力不够。

再接下来，如何得到 index_a、index_b、index_c 这几个数值呢？这些参数是不同业务的综合指标，因此，平均值？方差？中位数？写过 abc 三个业务的程序员应该心里有数，PM 当然更应该对业务了如指掌，也应该心里有数。所以这个问题上，达成共识是双方共同的责任。

最后，如何根据场景（周期）计算所有用户的 INDEX、页面展示、小数处理、各个环节之间的依赖与异常处理等，这些都是工程师要做的东西，没话说。

第三个例子

数据产品、人工智能产品（如 Siri、Cortana、小冰）、框架级别的产品（墨刀、Matlab）乃至当年的 OS360，至少以现在的标准看，这些东西都应该自始至终由工程师主导。

以上，请楼主仔细思考。

我能感受到楼主的困惑，但我也觉得楼主把问题想简单了。

高度概括实现一个产品的流程，就三部分：业务设计，（基于业务的）工程设计，工程实现（包括测试）。这三个坑，不论是 PM 还是工程师，不论是怎样的 PM 或者怎样的工程师，敬请对号入座。

PS：我是一名工程师。

建议跳槽。

第一反应是：不存。因为不干净。

第二反应是：可以存。存了能节省查询时间，空间换时间。

第三反应是：可存可不存，各有优劣，如何选择还需要看具体需求/场景。

深圳，知名创业公司，三个英文字母：DJI？？？

但其实 Gitlab 不算小。 不过真要说大型项目，Github 绝对算一个。

看过 Discourse，比预想的要复杂得多。

rake stats

有 3 年经验的大厂程序员，遭遇技术瓶颈该怎么办？