选择技术栈时要考虑的非技术因素
4.71/5 (6投票s)
由于其挑战性，许多开发人员专注于选择技术栈的技术方面，而忽略了开发人员本身。如果您是项目的技术总监，您不能在不考虑重要的非技术方面的情况下宣布“这就是我们将要使用的技术栈”。
有关如何选择 ASP.NET 技术栈的一些指导，请观看此点播网络研讨会 “选择合适的技术栈”。
全新的项目通常很有趣。它是全新而令人兴奋的！没有遗留代码可以拖累或不必要地惹恼团队。*这次我们终于可以以正确的方式做事了。*
然而，这种兴奋也有其另一面。新项目的乐趣和灵活性也伴随着制定艰难、前期技术决策的无与伦比的责任。
问任何一个长期项目开发人员，他们都会告诉你，有些事情你不能在项目开发中期随意更改。至少不能在不付出数百人时的工作量来弥补的情况下进行更改。是使用 ORM 还是手动编写 ADO.NET？ASP.NET Core 1.0 还是采用久经考验的 ASP.NET 4.6？MVC 还是 WebForms？项目初期做出的艰难技术决策可能会回响多年！
有关如何选择 ASP.NET 技术栈的一些指导，请观看此点播网络研讨会 “选择合适的技术栈”。
由于其挑战性，许多开发人员将完全专注于选择技术栈的技术方面，而完全忽略开发人员本身。如果您是项目的技术总监，您不能在没有充分了解团队将如何接受它，甚至仅仅是了解项目需求的情况下，就宣布“这就是我们将要使用的技术栈”。
走在技术前沿
罗伯特·弗罗斯特有一首诗，美国每个高中生都必须背诵。黄色的树林里分出两条路，抱歉我无法两条都走。* 您的技术栈也一样。有两条路：一条是铺好的路，一条是布满灌木丛的路。
您选择哪条路？
首先，我们可以看看铺好的路。ASP.NET WebForms 已经存在了十五年多了。有无数关于 WebForms 各个方面的博客文章。随着它多年的成熟，大多数文档仍然保持相关性。尝试搜索“（某事）webforms”，您将获得数千个结果。所有这些可能仍然值得研究和使用！
ASP.NET MVC 5 是久经考验和前沿之间的中间选择。随着 ASP.NET Core 1.0 的出现，在 ASP.NET 4.6 上使用 MVC 5 就像在新车上市下周发货时购买老款车型一样。但是，与汽车一样，文档和开创性的工作已经完成。您将受益于早期采用者付出的所有辛勤劳动。
ASP.NET Core 1.0 是长满灌木丛的路。如果您看下去，您会看到摔倒的开发人员。有些人可能陷入了困境。路的尽头是一个谜，因为从您所在的位置看不到它。问问自己，“我有多么冒险？”
预算和截止日期严格的项目不适合使用前沿技术。这样的对话不好进行。
“下周的发布一切都准备好了吗？”
“还没有。事实证明 ASP.NET Core 尚不支持 SmtpClient，所以我们必须推迟几周。”
就我个人而言，我喜欢走中间路线，偏向技术前沿。我的工作决定了我必须解决业务问题，而不需要特定的技术栈。对于当前的客户项目，我正在冒险尝试 ASP.NET Core，并且遇到了比我预期的更多的障碍。
开辟道路的人需要警惕并花时间。通过他们的努力，未来的开发人员走的路将更清晰。
开发人员快速学习的能力
当我以前招聘开发人员时，我们的指标不太关注一个人知道什么，而是他/她能多快地学会它。
在选择技术栈时，重要的是要衡量负责实现技术栈的团队。一个执着于开发 WebForms 的开发人员，在转向 ASP.NET MVC 或 WebAPI 所暴露的更复杂的模式时可能会遇到困难。
我的一位同事讲述了他的一位老老板的故事，这位老板在软件开发方面有陈旧的背景。在这个故事中，老板花了几个月的时间试图学习 C# 的工作原理，并试图根据他从书籍和在线教程中复制的知识拼凑一个 WinForms 应用程序。一天，老板叫我的同事到他的办公室，让他解释什么是类。
我们的目标不是疏远开发人员。每个人学习的方式和速度都不同。在选择技术栈时，我们需要意识到谁将实现解决方案，以及他们心理上是否能够承受处于技术前沿的压力。
什么更好？用旧技术完成的完整解决方案，还是未完成的、走在技术前沿的解决方案。
项目需要什么？
所有项目都是独一无二的。客户的需求从“我只需要比这个 Excel 电子表格更好的东西”到“我想要类似 Facebook 的东西”。
简单的“数据之上表单”应用程序不需要使用 Angular 2 或 React 构建的单页应用程序。一个复杂到需要一小队开发人员花几周时间才能实现的解决方案，用 WebForms 很容易就可以由一名开发人员在几个小时内完成。
大型单体 Web 应用程序有不同的需求。您期望这些项目以最少的功能启动，但最终会变得越来越庞大和复杂。在更前沿的方法上投入的时间将在未来获得回报。
您作为决策者的目标是权衡项目的需求和可用的工具——甚至在某些情况下，还要考虑即将出现的工具。如果您的项目只是数据之上表单，也许可以坚持使用 ASP.NET WebForms 这样的简单技术。如果您预计项目会随着时间的推移而变得越来越复杂，那么也许可以从 ASP.NET MVC 和 WebAPI 技术栈开始，以后可以集成 Angular 或 React 等前端框架。
团队规模和可扩展性
在追求完美技术栈的过程中，另一个需要考虑的重要因素是构建项目的团队规模。
我有幸在小型（一到两人）团队和跨越全球多个人的大型团队中工作过。
作为一家初创公司的 CTO，我们的团队接触了我们能接触到的最前沿的技术。一天之内，我们向生产环境部署了十几次。团队对项目有共同的理解和尊重，团队的凝聚力使我们能够灵活地快速做出未经仔细计算的关于工具、库或框架的决策。如果工具不起作用，没关系——丢掉它，尝试另一个。
如果我再次走创业之路，我会指导我的团队采用 ASP.NET Core。即使在其早期阶段，该平台也有可能比以前的 ASP.NET 版本提供更大的灵活性。
我大学毕业后与第一个主要开发团队一起，为一家大型安全公司开发防病毒软件的组件。这个团队的进展要慢得多。我们的要求是每季度部署一次，我们的软件支持十几种操作系统。我们使用的工具和框架的更改会影响全球数十名开发人员。
如果实施了更改，我们的团队也需要准备好应对反响。如果您没有考虑所有角度，会发生什么？如果遇到障碍，B 计划是什么？谁来决定如何克服障碍？
请不要误解；有些大型团队完全有能力快速部署并在项目需要时迅速改变方向。我的论点是，我所经历的大多数大型团队绝对无法以这种能力工作。如果您有一个 30 人的团队，并且告诉他们使用 ASP.NET Core 1.0（这是 ASP.NET 开发人员可以使用最前沿的技术），那么您需要期望他们每几周适应一次 API 破坏性更改。很少有大型团队能够做到这一点而不发疯或最终推迟计划。
结论
有时我们希望决策仅仅是位和字节的问题，但有许多人为因素需要考虑。
可以给出的最好建议是，在您的团队中讨论所有可用选择的优缺点。如果团队完全参与技术决策过程，产品成果将会因此更好。
那么 ASP.NET 技术栈中有哪些工具可用呢？Jeremy Likness 有一篇 精彩文章 介绍了 ASP.NET 开发工具的现状。使用 Jeremy 文章中讨论的工具与您的团队展开对话。
一个伟大的团队，在获得灵活性时，总是会产生一个稳固的产品。
有关如何选择 ASP.NET 技术栈的一些指导，请观看此点播网络研讨会 “选择合适的技术栈”。