发人深省 🤔

支持 🎉

终于知道 hoopo 的真名了 😳

现在趋势一般向纯拉走，更容易做算法排序的 abtest 之类

这个视频看了五遍 ( https://weibo.com/1283022704/FEPKyx8Ti

其实觉得 web 作为一个开发领域已经没落了，后端工程师要开发的将更多是 api 与三端对接，而非 web 而已。

这时语言的生产力差异相对会不那么明显一些，差异将更多 concern 在不同技术栈的成熟度和扩展能力上，其中扩展能力除了耳熟能详的性能、可用性方面的考虑，也包括团队的扩展空间。这两者都与社区的力量也深深关联着，比如公司快速成长时，能否通过社区内成熟的方案解决难题、或者引进社区内有经验的工程师顶住局面。

单表就行了，现在千万不算大表，做好索引就问题不大

都这么慢，不要相杀了....

靠 rpc 去推动服务化容易掉进服务分层的坑里，如果拆分不谨慎，后期会发现做需求调整时需要一调调三层，出问题要挨个去定位

感觉如果能把缓存覆盖率做高，gevent 这类并发机制就尽量可以不用了，我们这边有几个 python rpc 服务摘掉 gevent 也可以做到几 ms 的延时几 w qps，与打 gevent 占用的资源差别不大，都挺吃机器的... 这时异步带来的复杂性多于好处，接口的 P95 等延时指标容易躺着受其他请求的 cpu 操作干扰影响诊断问题，设不好协程池子会傻 accept 请求容易过载，数据库池子设大了会打爆连接数设小了又限制并发

最近在玩哪些呢 qwq

现在做项目挺担惊受怕的，后端怕 microservice，前端怕 SPA

#16 楼 @rei :plus1:

#43 楼 @kayakjiang

个人体会：

• 对测试代码本身的质量不需要要求太高，覆盖到好过没覆盖到
• 测试作为接口文档的功能很可疑，因为测试代码质量下降的很快
• 差的测试好过没有测试
• 测试只是质量保证的一个环节，有比没有好
• 有 CI 比没 CI 好
• 没测试真不敢重构
• 尽量靠接口的解藕，尽量克制使用 mock
• 测试代码中重复代码好过封装重复，上下文更明晰

@luikore 最近比较喜欢不在 Model 里放任何 validation 而把所有 validation 都弄在 form object 里倒是

@luikore 之前弄了这么一个 trick 把 model 的 errors 合并过来囧：

def save
  if [self.valid?, self.order.valid?] == [true, true]
    OrderForm.insert!(self.withraw)
    return self.order
  else
    self.order.errors.each do |field, message|
      self.errors[field] << message
    end
    return nil
  end
end

感觉“容错”容的只是网络超时这种通信的错误，而逻辑的错误一般都要速错。

比较喜欢把 Service Object 做成 Form Object 的形式，对参数加一些 validators，然后把逻辑放在 submit 方法里 Q.Q

• 加 validation
• 不够？加 concern
• 还不够？加 callback
• 最后就见鬼了……

这种比较喜欢抽一个 Form Object 出来，把 validation 和事务塞里面，尽量不用 callback

#5 楼 @lgn21st 目前我们的代码还有不少需要重构的地方，很想找个机会交流一下 :)

#2 楼 @lgn21st 短期没有开源计划，主要是仓库里放了一坨运营代码，自己运营监控会方便一些，不适合做成一套通用的交易所解决方案

报名

#56 楼 @jasl sorry 刚刚看到，他应该会给你发一封邮件 (

@jasl 现在还能否申请话题呢？mruby 社区的 Daniel 想要分享一个主题演讲 :D

是，十八摸之前还愿意养几个内核牛人，现在全球没剩下几个了

在用 daemontools，考虑换成 supervisord

报警用常规的监控工具就行。

挺看好 AVOS Cloud 这类 Backend as a Service 的

全明星团队！

#1 楼 @ginchenorlee 是我们的产品撒

@robertyu 这里有撒 http://fleurer-lee.com/slides/puma-notes/

报名！