关于test-Infra后续的一些想法

好的产品应该是能拿出来卖的

• 要抱着这个产品能够呈现给客户的这个标准，而不是只是满足于“这个产品只是内部大概能用“。 内部用户说到底也只是一个用户，如果只是为这个客户做点对点的深度定制开发，那这个产品的质量也难以上去。
• 如果我们要把test-infra呈现给外部，最主要是减少各组件的耦合，增加可组合性。分几步

简单使用

• 用户能快速部署一个最简化环境，把case跑起来，一眼就能看到效果
• 用户能写个case 这个阶段最简化的场景就是让社区用户（包括客户）也能写case，让他们搭一套tcms-tps … 注册账户，还依赖于pingcap账号… 显然是不合适的。这儿的最小化安装指的是 rms+sdk/sdkserver。用户起一个rms，就可以把case跑起来了，也可以照着case。这就要求 rms不应该对tcms有依赖。比如tcms和rms的交互方式上应该是基于pull的（rms暴露信息，tcms拉取)。 这点在设计认证授权方案的时候就没做好。

企业接入

这点对test-infra的可组合性有更高要求，各个组件不能耦合在一起，否则无法接入他们内部系统。

• 企业已有自己的工作流，case管理等平台，不需要tcms，这种情况与简单使用相似，只是让test-infra准备环境
• 企业有账号，各种元数据管理。用户只需要tps+rms的功能，提交符合我们格式的case/suit，test-infra能跑起来。
• 企业需要完整部署test-infra的全部组件
• 企业需要k8s native?

对于软件开发的一些想法

• unix哲学，边界清晰，权责分明，可组合
• 不能总是头痛医头脚痛医脚，而是利用一套机制能解决这类问题，当我们发现写代码很难，难以预测这个代码的后果，总是疲于奔命，就是要通过机制来解决的时候了。由经过证明的机制解决复杂问题，不要在业务代码里面解决。
• 大部分的代码都应该是纯函数，结果完全可预测，输入输出非常明确。 我们写的业务代码都应该是给定明确的输入（就是参数），有一个明确的输出（就是返回值），坚决避免副作用（IO），甚至最好连日志都不要打，日志只在输入输出的时候打, 如果发现打log有业务含义，那么你需要reporter。由机制提供IO，业务逻辑只做计算。特别小心业务代码引入依赖。
• 最小惊讶原则： hack一时爽
• rest is for human, rpc is for machine， 所以REST一定要做到符合直觉，类似于简单的文件服务器,比如我put了一个东东，然后就能把这个东东（近乎）原样get下来。

为什么总是要想着这些

• 想着这些，就有了一个质量标准。有一个bar在这儿，我们就会对自己有些要求，提交贴膏药的代码也会感到不安，而不是，我又解决了一个bug（可能引入了更多的bug）的沾沾自喜中。
• 不要拿到内部需求就急切的动工，加几行代码草草解决掉，这样的解决代码甚至于只能解决内部这个特例场景，导致内部依赖太深，以后都卖不出去。往往这些需求或者问题都有更加通用，更加根本的解决方案。内部的这些需求或者提出的bug都是财富，而不是负担，不要草草地写代码把它们浪费掉。 当然，紧急和重要，短期目标和长期目标是存在矛盾的，我们可以快速地把这个问题简单处理，但是只要有时间就应该深入处理。就像运动员受伤了又要上场，就需要打止痛药，但我们不能总是打止痛药，只要有时间，就要想着系统的解决方案，使用更先进的防具彻底避免这种受伤。

test-infra的一些改进意见

• client 先于 dashboard，每个功能都要先有命令行工具(或者sdk)的入口，再做出dashboard。 命令行工具不是说要给多少人用，而是可以鞭策我们设计良好的API。可以用命令行快速解决的api， dashboard写起来也很容易， 不要让dashboard 调用一堆api，在前端搞出很重的逻辑，这样前端会很辛苦（况且我们还没有多少前端人力，容易出bug），继续容忍后端不合理的API。当然，命令行工具在自动化的过程中也很有用。
• 我们的服务可能会上k8s native, 减少耦合。部署tcms肯定是比k8s api server要轻量级的，但是，如果客户是k8s native的，我们能不能方便的把tcms那些resource转成CRD, 就能快速迁移？