另一条路子：独立开发，爱用啥用啥。

读书人的事，能算偷么？别在意这些细节。

根据本帖讨论的内容搜到一个帖子：http://129.226.226.195/post/24983.html 为什么将 Python 用于高性能/科学计算（而不是 Ruby）？

不过读着像是机翻。

这套方法似乎必须依赖 SCSS 来实现是吗

原来如此。

我之前拿 JSON:API (有点类似 GraphQL) 对比了一下传统 API. 我不知道自己有没有理解错，跟大家交流一下。我感觉这种方式几乎是直接把后端的模型暴露给了前端，前端在知道后端的模型之后，可以直接根据规范针对已知的模型进行种种操作，包括但不限于：按属性排序、按属性过滤、列表、分页、查看详情、删除、更新等。如果再定义了模型间的关系（比如 has many comments），还可以通过 side loading 和 side posting 的方式对模型及其相关联的模型同时进行查询和修改，可以自由控制数据的粒度，似乎也省掉了很多前后端沟通。这样基本上弱化了后端的功能，后端直接退化成了一个对象数据库。

跟传统 API 的区别在于，传统 API 返回的某些字段可能是后端计算之后返回的，JSON 结构也可能跟后端模型不完全一致。如果直接返回原始模型给前端，这样的计算工作会被放到前端，一些业务逻辑也都往前端移了，最终的结果是前端计算量和代码工程量都变大。而一个项目中，前端可能有很多种实现，比如 HTML, Android, iOS 等，这些前端的工作量都跟着变大的话，感觉不是很划算。我没有在项目中使用 JSON:API 和 GraphQL 的实战经验，这只是我在粗略了解 JSON:API 之后的一些推测，不知道实际情况是不是这样。

“确保后端返回的 json 和前端 ts 里的 json 是相同类型的”不是太理解。在我看来 API 是个契约，它一变动，前后端都得跟着作调整，你的意思是把这个前后端开发者协调的过程给省掉吗？不太明白是打算解决什么问题。

你说的这些 REST 的缺点，JSON:API 似乎都补上了。

大公司的人，是不一样。

类似这种帖子我总想问一句：然后呢

福州居然有用 Ruby 的

母语和英文还是两回事的。当然，也不排除你的英文达到母语水平。

如果 1 楼的方法能行，用浏览器能下载只是用命令行 curl 访问不了，说明你是翻过去的。

这样的话装个 proxychains 再配置一下，然后 proxychains curl -k -sSL https://get.rvm.io | bash -s stable

我觉得面向对象是一种比较好的管理复杂度的方法，贫血模型本身很反面向对象，没有对数据进行细致地分类，很容易出来一堆长参数列表的方法，那些 manager 也很容易被设计成单例或者干脆就是只含静态方法的类。而这些方法里边的逻辑本该可以被更好地组织起来。

哈哈，说白了我个人比较排斥贫血模型。

那难怪了 ~ 话说现在前端有没有类似的框架？我前段时间琢磨着拿 Backbone 配合独立的 virtual DOM lib（例如 maquette）用起来算了。

居然还有在用 Backbone 的。说真的我特别喜欢这类啥都没有的框架。

我会把 by_xxx 的参数 price 和 months 放到构造方法的参数列表里，再 new 出 4 个对象分别取 attributes。按照你目前的写法，其它方法会依赖 by_xxx 方法先执行，如果 by 方法不调用，其它方法会出错，这样的对象在使用上不太友好，别人不容易注意到这个约束。

剩余的部分我跟你差不多。另外我会照习惯把 SaleDetail#attributes 之外的方法全部声明为 private，并且不开放 attr_reader。

嗯… 然后我可能不会写那个 %w[month quarter semi_annual year].index_with

🙄🙄 我这也有你要不？

不是一本一本卖啊，我每次都是同时卖好几本，每一本书只要挨个条码扫一下，然后等着顺丰上门来收就好了，打包给你收走，对方会出运费。

可以试试多抓鱼。

看懂的人，都会明白，看不懂的人，都不明白，哈哈哈

rubymine 不贵么各位？

比如说 whenever, sidekiq 这样的工具，我倾向于选择第三方的代码。首先这两个东西跟业务基本上不会有冲突，只解决技术问题。其次它们解决自身领域的问题很专业，考虑得很全面，不需要我操心太多。当然，同时也能省下我不少的开发和维护的时间。

但像权限管理这样的逻辑，很多时候很依赖具体的业务细节，开源出来的第三方代码库如果解决得问题过于全面，适用性就必然低，很有可能与使用者本身的需求有冲突；如果做得很通用，又变得几乎没有什么存在的意义——基本上它本身就没做什么事情。

确实。这问题本身也没有标准答案。具体怎么选择，我觉得要看自己所拥有的时间资源、负责这件事情的人本身的代码能力、第三方代码库本身的质量以及该代码库本身是否包揽了太多我不希望它做的事情等等…

其实仔细想的话，“不自己造轮子”这种行为只降低了做一件事情起步的成本。在我看来，它对“把一件事做好”并没有太大帮助。

我会把 2 和 1 的顺序倒一下。然后如果代码质量可以，3 我觉得无所谓。

不过在这之前，我更倾向于自己写，其次才考虑引入第三方库。比如说我现在后台权限管理的逻辑是自己写的。有时候发现其实大家能共用的逻辑没那么多，为了图省事反而费事。

只针对 8 楼回复，与主帖不是太相关。

在我的理解当中，private 是用来限制人的，不是限制程序的，让别的程序员不要瞎调用。相当于是个声明或者约定：这个方法在不是必须的情况下请不要在该类的外部调用。

其次，private 的一个优点是，在重构的时候，如果要移除某个方法，或者要重命名某个方法，该方法是 private 的，那么你就能很清楚的知道，我只要在这个类内部做修改就行了，不需要整个项目全局搜索对该方法的调用。

在 Ruby 代码当中，编写所有方法的时候我首先考虑的是 private，尤其是“写入”（修改了该类的成员变量）的方法。只有在发现该类的外部真的需要调用的时候，才会修改为 protected 或者 public。没有必要的情况下绝不暴露接口。

一个方法一旦成为 public，就相当于开放了一个全局的约定，所有人都知道你有这个方法，所有人都可以调用，这时候如果你要修改它，相当于修改了之前公布出来的约定，那么所有使用过这个方法的人有可能都要修改自己的代码来重新调用这个方法。

另一方面，暴露越多的接口，对外部来说这个类越不简洁、越复杂，或者换句话说：越难用。本来一个类就是封装了对该类成员变量操作的所有逻辑，如果把细枝末节的 private 操作都暴露出来，那封装本身就变得没什么意义，本该封装起来的复杂性还是暴露给了外部。外部的调用者很容易受诱惑去调用这些 public 接口，复杂性就这样外泄了，系统逻辑就容易变得混乱。所以写一个方法，private 是首选，真的需要开放的时候再开放。同时这样首先考虑 private 的编写原则也完全避免了楼主所担忧的问题。

还有，父类的 private 方法对子类来说未必就是 private 的，子类本来就是父类的特例化，在一些情况下，外部需要调用子类的某个方法，而该方法在父类当中是 private 的这种情况并不少见。 回头看了一下，这句与主题无关。

结论就是，楼主可能思考的方向错了。

Refactor 和项目大小有什么关系？

看完描述，我第一个反应是：如果 var_a, var_b, var_c 都是临时变量，并且方法 a 和方法 b 只负责处理这 3 个临时变量。那么把方法 a 和 b 放在当前这个类里的意义是？

这种情况下我会把计算出 var_a 和 var_b 的那些变量拿出来放到一个新的类里，变成成员变量，然后在新的类里面组织这些成员变量的方法，把方法 a 和 b 移到这个类里面。

楼主的描述还是比较模糊，比如说计算出 var_a 的变量有哪些，我们根本没法知道。其实讨论这样的问题把真实代码拿出来最好。

说个题外话，有时候我蛮提倡过度设计的。

首先，“过度设计”好过“没有设计”，这两者相较起来，前者起码说明程序员在思考，说明这些代码是被管理着的。

其次，“完全没有设计”是一个极端，“过度设计”是另一个极端。程序员要两个极端都到过，似乎才更好把握“中间”在哪里，才能更好的权衡。和“过度设计”深入地打过交道，才能更清楚地知道它到底长什么样，好像不用一开始就拒绝它吧，你说呢？

其实我觉得“让表达更清晰”这一个理由就足够让我动手对代码进行封装了。而“能不能被重用”有时候更像是个结果：短小的代码更有机会被重用，也更容易被重用。