次の方法で共有

Typescript –TFS里现实世界故事的采用

  • [アーティクル]

[原文发表地址]  Typescript - a real world story of adoption in TFS

[原文发表时间] 2012-10-24 6:49

正如您可能知道的，我们为TFS有一个Web UI已经相当长一段时间了。在我们的TFS 2012发布中，为了让WEB UI更加现代化，我们对它做了一个相当重大的改革-无论是外观和感觉还是架构。我们移到了REST/Json, 更多嵌在浏览器内的Javascript，少了一些Ajax的调用。结果是一个更快、更具响应性、更加愉悦的体验。结果是更多的Javascipt。我们现在有大约8万行Javascript(实际代码，不包含空白行，注释等- 如果计算在内的话，大约15万)。这是一个相当大的数据块Javascript。

几个月以前（在Typescript发布之前），我们决定转换所有的Javascript为Typescript。我们最终在几周以前开始做这个, 本周我试图评估我们这样做可衡量的好处。我首先查看有多少个 bug 我们并未在代码中发现，而转换后通过Typescript编译器错误发现了。如果大型的 Javascript 程序很难达到准确，很难验证的话，那么Typescript是用于帮助编写更"准确"的 Javascript的不错工具，您可以期望在您迁移的大型代码库中找到一些 bug。并确保找到足够的，我们做到了......

我们对Javascript进行了很大程度的测试-包括单元测试和功能测试。我们认为我们已尽了一切合理的方面来确保最高质量的代码。转换帮助找到了 13个我们不知道的bug。因此您能借助Typescript帮助查找，这里是 bug 的列表：

  • Bug 987091:TFS.TestManagement.Controls.debug.js 不正确调用RegExp导致没有匹配
  • Bug 986991:调用 baseConstructor 在多个位置缺少"this"参数
  • Bug 986997: 引用到 ActionManager 的未定义属性，将此操作的worker放在开始而不是结束-TFS.Agile.debug.js
  • Bug 987103：TFS.WorkItemTracking.debug.js中，引用到未定义的位置属性应该为path()
  • Bug 987016： TFS. TestManagement.Controls.debug.js中当前不存在的函数的解除绑定。-重构工作出错了吗？
  • Bug 987071:RichContentTooltip _setPosition 调用一个不存在的函数-看起来就像大小写错字
  • Bug 987080：TFS.UI.Controls.Grids.debug.js _onToggle调用此._addSelection 具有不匹配的参数
  • Bug 987086: TFS.UI.Controls.Grids.debug.js中的_beginCopySelection引用了当前不存在的属性以确定是否选择
  • Bug 986993： 在TFS.Agile.Boards.debug.js中，在调用基类构造函数时，缺少 'this'参数。
  • Bug 987104:调用Diag.assert* ，当需要两个参数时，只传递一个
  • Bug 986987：在Area Iterations（区域迭代）对话框中缺少资源字符串值
  • Bug 987054： TFS .Build.debug.js中不正确的资源引用。
  • Bug 987101：在TFS.WorkItemTracking.Controls.Query.debug.js中资源引用的拼写错误。

随着我们努力着手如何迁移我们的代码，我们与微软的其他几个团队交谈过了，他们在我们之前就采用了Typescript。一个是 Erich Gamma 的团队。Erich 估计手动转换，若是要获取完整注释的Typescript，每个类/ 函数/行每小时一次可以做 300 行左右。当然，所有有效的 Javascript 都是有效的Typescript，因此您可以只更改文件扩展名，然后编译它，但如果您想要获取所有的优势，您将想要充分利用类型批注的优势，这是手动的部分。80,000 行，每小时 300 行是一件令人生畏的事情。所以我们决定投资一种工具来帮助处理。值得庆幸的是，我们已做到了相当严密。我们相当一致地使用 Javadoc 来描述我们的 API。我们为我们的类和模块等使用一致的模式。

总而言之，它花了我们 (1个 dev） 不到一个星期来编写一种工具 （当然是以Typescript编写的:))，它将识别 Javadoc 和我们的模式的其余部分，然后将它们转换为相应的TypeScript构造。这用了大约一个星期来运行该工具，调整我们的 Javadoc 注释 （比如填写一些遗漏掉的），更新我们的生成过程，测试转换等。当然还有更多我们可以为Typescript做的事情。例如，我们为接口的合同没有任何之前可识别的模式— — 所以此工具没有什么东西来生成Typescript构造。随着时间的推移，我们将着手这一点，因为我们有理由重新访问模块和进一步加强Typescript。我期望我们会发现更多我们现在还不知道的问题。

总体来说，对于这个结果我们超级开心。我们想未来随着像Intellisense的更好的工具体验, 我们将会更高效，代码将会有更好的结构，更强的可维护性以及最终的高质量。这是一个非常好的体验，我鼓励您试一试。如果您花了很大精力确信没有bug时，您将会惊异于您在代码中所发现的bug。

Brian