7
从VBA到C＃的团队成员质疑
背景 去年，我被要求为大约10个用户创建一个用于业务计划的工具。这项工作是由另一个IT团队代表完成的，该团队将工作“分包”给我，并且由于项目期限在他们这边有些计划外，我不得不匆忙实施。 当时，我们决定最快的方法是使用VBA创建Excel工作簿，然后让用户从Intranet下载此VBA增强的工作簿以在其PC上使用。在这种情况下，Excel是一个约束，因为我们使用的计划系统（即数据库）只能通过Excel加载项进行交互，该加载项必须在打开计划工作簿的同时加载。但是，当时VBA并不是一个约束。 我创建了约4,000行VBA代码的工作簿，虽然我尝试分离数据层和表示层，但由于项目截止日期，所以在所有情况下都无法做到。老实说，虽然我为创建此工作簿感到自豪，但同时我感到有些失望，因为它在编码和部署到用户方面都可以做得更好。 今天 回到今天，IT团队再次来找我，要求提供类似的工作簿（这样我就可以重用上面其他工作簿的部分内容），但这一次它变得更加复杂，将被更多的用户使用（ 200左右）。 但是，这次的计划要好一些，我可以看到我们有更多的时间来计划事情。基于此，我考虑了该解决方案和基础架构，因为针对100个用户的编程比对10个用户的编程影响更大。因此，我向团队建议，也许我们应该考虑将现有代码迁移到C＃解决方案，以便我们可以以更精细的方式管理代码。我仍将其视为使用VSTO / Excel-DNA编写的加载项，然后可以将其部署到用户。 两周前，我与IT团队讨论了这一问题，一切似乎都很好，直到昨天，我收到一个团队（不了解VBA或C＃）的邮件，询问我们为什么应该在C＃中启动这个新项目，而不是使用与以前相同的方法。他们的一些担忧是： 这是一个非常重要的项目，因此它必须能够工作-C＃解决方案不能像现有的基于VBA的解决方案那样稳定或有效。 我们将不得不舍弃[I]在VBA解决方案中所做的事情，并在C＃中从头开始重新创建它。 有人必须支持两种单独的解决方案，一种在VBA中，一种在C＃中。[实际上，他们目前没有任何人支持，我通常会介入]。 现在，我可以在某种程度上理解他们的一些担忧，但是我需要决定下一步的工作以及如何处理这些问题。就个人而言，我想用C＃实施，因为我认为它更适合于构建这样的“企业”解决方案。此外，我想借此机会提高我的C＃技能，因为我目前不像VBA那样胜任C＃的能力，并且我希望通过这样的项目将我带入“下一个级别”。 我准备了一些要点，可以用来说服他们说C＃解决方案更适合该项目，这是我到目前为止的目标： 单元测试。 源代码控制。 代码文档-用于将知识转移给其他支持人员。 更好的编码约定-可以使用ReSharper之类的东西来加强更好的命名和结构。 更好的IDE-减少由于错误突出显示而导致的错误。 通过组件实现更高的模块化-可以促进将来工具的重用。 托管部署-可以控制使用此工具的人员。 问题：我还能说些什么来说服他们？还是我想尽全力去完成这个项目？我应该保持安静，还是在VBA中这样做吗？ 我知道，仅因为新语言的“较新”或被视为“较凉爽”而改用新语言就不应作为决策的基础，因此我拒绝将其作为决策要点-这是关于事实的。 另外，我不要求在C＃和VBA作为语言之间进行字面比较，因为在SO上有很多比较。