如何避免陷入困境...

引言

多年来（很多年！），我参与过一些项目，有些项目取得了巨大的成功，有些项目一败涂地，还有些项目磕磕绊绊，压力和一帆风顺交织。我发现，总的来说，当我们项目结束时进行“经验教训总结”，并将这些经验应用到新开发中时，我们的成功率会提高，压力水平和熬夜加班解决问题的次数会减少。因此，本文内容轻松易读，是对开始一个项目时需要记住和思考的事情的集合——这些事情可能看似显而易见，但值得放在您的脑海中或项目清单中。这些是如果未被提出，可能会在项目投入生产后（或者因为您没有充分预见而无法投入生产……）在技术或运营方面将您逼入绝境的问题。这仅仅是冰山一角，是一个起点。我会根据需要添加更多主题。我也期待大家添加评论，我们可以将这些评论纳入文章中！

平台和操作系统

这一点可能非常显而易见，但其中有一些棘手的问题。您可能以Windows平台为目标，但您支持哪些版本？……您支持的版本可能会限制您使用的技术。例如，在本篇文章的撰写日期，微软对Windows XP的支持已基本停止（或者至少正在缓慢死亡），但其用户基数仍然很高。如果您选择支持在XP上运行您的代码，请注意，例如，它将无法运行需要.NET 4.5版本的任何技术。除了运行在特定平台外，您还需要考虑访问您系统的平台，因为它们可能无法“和谐相处”，并带来一些不必要的麻烦。

用户和他们的数据

啊，用户！那些消耗我们劳动成果的可怕生物……我几年前进行了一些研究，得出的结论是，大多数应用程序都会受益于首先为边缘用户（例如视力不佳者）设计。除了确保您符合可访问性法律外，研究表明，为残障人士进行设计所需的基本原理有助于集中设计，使其更易于所有用户使用。

当我们谈论用户时，您预计用户数量有多少？刚开始时有多少，12个月后有多少，48个月后有多少？这个问题应该对您系统的任何需要快速响应的领域，以及涉及存储数据或快速数据吞吐量的方面产生深远影响。

小心隐藏用户

(此部分由读者 Jalapeno Bob 提供 - 一个很好的观点，需要提出 - 谢谢！)
在任何流程中，经常有一些我称之为“隐藏用户”。他们工作的一部分是获取系统输出的一小部分，进行处理，然后将其发送到别处。他们的工具可能是纸和笔，例如复制几个值，在一周内取平均值，将它们复制到状态表中，然后每周或每月邮寄出去。因为这些用户不是日常的“主要路径”用户，所以管理层经常忘记将他们列入系统开发人员的用户和用途列表中。

当管理层向您展示一个样本输出，并划掉一列说“我们不再需要这一列”时，要特别警惕。在以前的系统中，那一列的设置是有原因的。虽然这一列可能确实不再被使用，但很可能某些遗留流程仍在依赖它。关于您的全新产品中“过时”数据的删除，请多提问。如果您确实删除了某个数据输出，请准备好在隐藏用户开始抗议时迅速将其加回来。

数据引入

如今很少有系统不需要与其他系统交互，在“业务线”应用程序中，将数据从一个应用程序迁移到另一个应用程序是很常见的。因此，在计划让用户上线时，我们需要询问历史数据需要在何时/何点迁移到系统中，以及如何迁移。这不仅影响总体数据存储，还影响数据引入系统本身的效率。当您引入数据时，是否存在数据所期望的依赖项？……如果不存在默认的预期数据，查询是否会失败而无法返回数据？关于数据引入的另一个问题是频率。您引入的数据是一次性工作，还是需要定期进行？……如果需要定期进行，那么您需要考虑如何收集流入的数据，例如，您是否需要制定一个仅引入增量数据的程序……问题，问题，问题……

数据量

在设计系统时，通常只对体系结构的扩展性和负载测试给予初步的关注。如果您预期有任何数量上的问题，您必须制定一个适当的策略来进行负载测试——不仅是数据本身，还有数据的查询。您可能会发现，您引以为傲的美丽的超规范化数据库，由于过多的连接和内部选择，其速度慢如在山上流淌的糖浆。您需要提前计划，并在必要时进行反规范化或预先分阶段处理数据。虽然遇到扩展性问题对企业来说是一种赞誉，但如果您一开始就设计和测试得当，那对您来说是更大的赞誉。

数据输入/输出

引入数据固然好，但我们有多少人会考虑导出数据呢？（不，它不是指在暴风雪中进行的活动……）。根据数据保护和隐私法规（在欧盟和许多其他地区），您必须以可读的格式方便地导出与用户相关的任何数据。如果您不知道您拥有用户哪些数据，那么导出它们就很困难。因此，我们应该从一开始就计划，当编写获取数据进入系统的方法时，我们也要有相应的数据导出功能。请记住，在设计时完成这些事情比在系统失控、最初设计者和能够回答问题的人早已不在之后再添加它们要容易得多。

测试

当开发人员测试自己的工作时，他们的测试是基于他们自己的知识以及他们对事物工作方式的默会理解。出于这些原因以及其他原因，让非开发人员测试工作非常重要。当然，开发人员在进行基本合理性检查之前不应该发布任何内容进行测试，但除非您是面向开发社区销售，否则让没有先入为主观念的人与您一起走查设计和原型是至关重要的。

用户界面固然极其重要，但数据及其验证同样重要。在构建样本数据时，您需要问一些问题：数据是否相关？……如果您发布的应用程序仅在英国，而英国的邮政编码格式与美国不同，那么测试美国邮政编码格式的验证是没有意义的。数据是否与日期相关？……例如，如果您的主页显示一个包含过去三十天销售数据汇总的仪表板，但您的样本数据是六个月前收集的，您可能会纳闷为什么仪表板小部件是空的。当您将业务逻辑链接在一起，并将数据与历史数据依赖项进行比较时，这一点就更加重要了。在这些情况下，最好创建一个样本数据生成器，它可以根据给定的中央枢纽日期生成准确的样本数据。

再说一次数据量，这里有一个简单的经验法则。如果数据检索需要超过两秒钟，那么它就太长了，不能作为实时数据检索过程使用，您需要重新设计。

技术

当决定在解决方案中使用什么技术时，假设您已经评估了其适用性，您还需要考虑技术的质量、成熟度以及提供技术的组织。如果技术是开源的，那么您可以自己检查内部机制，确保其稳固。在开源的情况下，核心开发团队和周围的社区就是组织。了解组织存在的年限、他们对技术的长期计划、技术有哪些依赖项，以及它是否与其他技术或您拥有的约束条件冲突。这可能是技术方面的，例如需要Twitter Bootstrap 2.x版本，或者可能是目标用户组织的约束，例如“不允许Java Applet……”。

重复造轮子

很多时候，我们可能会倾向于重复造轮子，仅仅因为现有的东西不能*完全*满足我们的需求。如果您时间紧迫（谁不是呢！），或者预算有限，您可能最好改进别人的轮子。在Web示例中，这可能意味着借用别人的CSS，将其作为基础，并对其进行调整以满足您的特定需求。在更偏向编程的意义上（什么是代码？！……有时会变得相当模糊！），这可能意味着注意到一种技术中的模式或做事方式，并利用它来构建其他东西。很多时候，我曾将多种不同的技术组合在一起以获得特定结果——始终在重用、重塑，而不是重复造轮子。另一方面，如果确实有需要一个更好的“捕鼠器”，那么如果业务/用例合理，就去构建它！

摘要

虽然这仅仅是冰山一角，但信息很明确——在不深入思考技术影响、用户需求、系统和数据可扩展性等方面之前，不要贸然行动。汲取团队的智慧和客户的领域知识。从错误中学习，并将经验教训带到您所接触的每一个新项目中。

历史

• 2013/12/25 - 发布第 1 版
• 2016/12/06 - 更新了 Jalapeno Bob 的精彩补充