Share via


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