发现Discourse每天都有更新，可以随时享受更新的乐趣，这一点太棒了，开发团队牛逼。
而且，我发现discourse的细节做得很好，每次更新都在优化细节，官方能做到这么好，真的非常佩服。
Discourse 的理论是最新的版本就是最好的版本。
所以他们会把仓库内容分支内容直接进行推送，这个需要很大的勇气呀，搞不好就会搞瘫一堆系统。
微软蓝屏不就是一个推送干翻了全世界。
从另外一个层面来说 Discourse 对自己的代码还是非常自信的，同时这种模式需要有非常快速的响应。
如果是发送 bug 这样的东西在 meta 社区上，基本上在 3 到 5 分钟会有人回复，并且首先确定是不是 bug 还是安装的问题。
很多时候都是插件的问题，不一定会涉及到 Discourse。
基本上 Discourse 每天都会有提交。
2 Likes
不是main的，它们有一个自动测试和部署系统，将测试通过的提交自动部署到 tests-passed 分支，如果测试不通过就会在工作群发出警告。
这套系统几乎能防止所有的类似微软蓝屏的事情（）
Discource的这个技术还是很牛逼，反正国内我没见过这种的更新方式。
其实大部分软件开发我们都会用 CI 来做。
我们公司的测试和集成都在 Jenkins 里面完成的，但是还是没有办法保证所有的问题都能被发现。
主要原因还是测试用例的覆盖不够，有些东西没有办法写在测试用例里面。
还有就是项目一直开始赶进度，基本上测试部分也就是测下大流程，没有到后面函数级别的。
也不太敢像 Discourse 这样弄，到时候出问题很难说清楚是 DevOps 那边的还是测试这边的，还是开发本身代码就有问题。
上一个项目还因为测试覆盖率的问题在吵架，上面要求要 90%，下面这些 teams
都疯了，测试覆盖到 90%，就目前的 Java 项目来说还真没有那个项目真正做到了。
个人觉得 Discourse 团队对代码质量的管控上是做得非常好，相信就因为这种要求他们也非常自信，这么多社区都在用他们的产品，一个错误的推送会影响很多的。
同时，也相信他们在后端集成上面也做了非常多的工作，能做到这样的快速迭代是很不容易的。
1 Like
谢谢纠正。
针对纠正我也修改了下我回复中的内容。
1 Like
我觉得还是 discourse 的氛围很好，我用discourse这几年下来，遇到的小bug也不少，但是反馈上去以后一般都会很快修复。
而且实习了就会发现，它几乎所有的修复都会要求写一个测试去cover这个情况，这样日子久了，老功能就几乎不会出任何bug，因为有问题的容易出问题的几乎都被测试覆盖了。什么敏捷开发理论
测试覆盖到90%我觉得就算discourse也做不到啊，这谁做的到啊。感觉有些公司就喜欢乱下指标。
这个是真实的，后来发现可能公司希望用这个指标来裁员吧。
把 KPI 设置到一个达不到的指标，然后控制 PR 合并，降低整个项目组的 KPI 水平，以 KPI 达标或者整个项目需要 PIP，最后整个项目组都被裁掉了。
这是我见过吃相最难看的项目，你说裁员就裁员嘛，简直侮辱大家的智商。
我们组当年提出个问题：就算现在 Java 的 Apache 核心库也无法保证这么高的测试覆盖率，我们怎么保证？
再说了，有很多包我们会引用 Apache 的库，这根本没办法弄呀。
提出 KPI 的人的说法是，这种情况可以做例外处理，并且 Apache 的库因为大家都在用，没有达到这么高的覆盖率是正常的。
我怎么感觉是鸡同鸭讲，完全碾压你的智商。
1 Like
看了会犯厌蠢症的程度
实际情况是我们项目组在 3 个月后被裁掉。
整个公司裁撤技术人员超过 60%，余下的都是听话的人吧。
好在是我们组被裁掉的经过一段时间后都还不错，大部分人都能妥善解决了后续的问题。
这种公司和这种项目不做也罢。
PS：
项目原来的整个架构是 PHP 的，我们这边负责 PHP 转 Java 的 API 工作。
应该是公司整个是没钱了，PHP 也能凑合用，这个工作就不打算继续了。
见过一个 PHP 文件 4 万行吗？打开这个文件 IDEA 都得死机。
整个调用，跳转函数嵌套已经到了令人发指的程度了。
一说到这事，感觉是经历过最愚蠢的公司和项目，好在没有和他们耗多久就跑路了，再混下去我怕是自己都得蠢哭了。
每天都在给自己做心理建设。
1 Like