小型系统的开发方法。什么是权宜之计？

Question

我正在开发一个内部自动化的小系统。我使用asp.net webforms并面临一个选择：

1. 以面向对象的方式开发系统架构(开发变得更加困难和耗时)或
2. 只需在窗体上添加控件，并在控件处理程序中写入sql查询(高速开发，测试的复杂性)

С经常使用第一种方法，但开始怀疑我的选择是否正确。怎样才是权宜之计？

Answer 1

灵活性与形式主义

不需要质量的项目(例如原型)和需要尽可能高质量的项目(例如生命关键系统)之间是连续的。

在左边，原型有一个唯一的目标:为了展示一些东西而快速开发，然后扔掉。在这里，编写质量代码或遵循标准并不是重点。代码只写一次，从来不读。高比例的错误是可以接受的。

在正确的方面，生命关键系统在可靠性方面需要非常谨慎，这意味着应该使用一些特别昂贵的技术，如形式证明。在这里，一只虫子可能导致飞机坠毁或核电站熔毁，这使得尽可能接近完美是极其重要的。

当从原型系统转移到生命关键系统时，需要越来越多的技术来减少中期/长期费用，或者确保权威机构所需的某种遵从性。这些技术是有代价的:它们增加了产品的即期成本。这些技术包括但不限于：

• 软件测试，
• 非正式和正式的守则审查，
• 编码惯例，
• 遵守标准，
• 正式文件，
• 静态代码分析，
• 等。

定位项目

你在这个连续体上的项目在哪里？如果这是一个短期的丢弃项目，只需在表单上设置控件，提前发货，然后忘记它。如果这个项目具有多年来由几个开发人员维护的潜力，那么就把它清理干净:您的继任者(或几个月后)会感谢您的。

有许多因素可能有助于确定项目的地位：

• 有很多开发人员在做一个项目，还是只有一个？
• 是否需要遵守精确的规范(例如，考虑与会计有关的软件)？
• 该项目是要维持多年，还是很快被另一个系统所取代？请注意，人们倾向于使用较短的时间:一些项目被认为最多活了2到3年，二三十年后，它们仍然很活跃。
• 是否需要可靠性？一个供你个人使用的网络应用程序可能经常崩溃，没有人会在意。一个处理每个客户的每一项事务的业务系统，如果不时崩溃，将会带来更多的麻烦。
• 有多少人会使用这种产品？
• 等。

如果你不知道该把你的产品放在什么地方连续，问你的客户。确保它是在一份合同中写的(我有客户要求尽快交付一个原型，尽管从一开始就收到了电子邮件通知，但如果不重写它就无法维护它，我真的很惊讶)。如果没有人知道，那么应用YAGNI:按它是一个原型来做，但是如果这个项目看起来是一个很好的候选项目，那么就必须从零开始。

范式和过程

如果您经常无法提前交付产品，您可能需要考虑更改：

• 或者你使用的范例。例如，从静态编程语言转向动态编程语言，这通常为web应用程序提供更好的灵活性和开发速度，而不影响代码质量。
• 或者是过程。例如，敏捷使您能够尽早发布工作产品，然后不断改进它们，这意味着您可以同时拥有高速开发和高质量代码。

回答问题…

最后要回答的问题是：

1. 你说的是“内部自动化的小系统”。看来你不需要极端的品质。但是，还是要小心，你不想运送坏东西，然后保持多年。如果它真的很小，那么花几天时间制作一个原型怎么样?如果它成功了，那就创建一个真正的应用程序吧？
2. ASP.NET？为什么不使用动态语言，比如Python呢？使用Django，它是web应用程序的优秀候选程序，应该快速完成，并且可能比使用表单中的ASP.NET查询要干净得多。

Answer 2

如果你开始编写代码，把东西到处放置，那么你的项目就会变得一团糟！按照方法1，正如您现在所做的，它将在稍后支付。

考虑到一个自动化系统，因为它可以是多么小，必须保证一个可靠和负担得起的服务在中至长期。

如果你不使用一个好的结构，然后你必须在2-3年内进行维护，如果你以一种更好、有组织和一致的方式来构建设计/实现，你将对自己心存感激。

如果您继续使用方法1，并且如果组件设计良好，您还可以为其他项目回收一些代码，即使更新系统也会更容易。

Answer 3

如果我们不了解贵组织的几乎所有情况，这个问题是无法真正回答的，但无论如何，这里有几点建议。

不要盲目地听你写的每一行代码都必须完全抽象和分层的建议，特别是对于新系统。如果你把最初的需求，并创建一个完美的分层，抽象的应用，当用户回来说：“哦，你知道，我们真正需要的不是'x'，它的‘y’在部署后6周你会做什么。”您会抱怨和呻吟，一些程序员实际上将试图说服用户，他们对新的需求是错误的。这一切都是因为你有一个伟大的架构，你是投资的，而你不想把它全部撕掉。

有时，在部署之后返回的更改很小，或者您对域的了解足以在您的设计阶段预见到它，但这并不总是发生。这一变化可能会影响到一些你没有经验的新领域。在这种情况下，要将现有的模型添加到其中几乎是不可能的，您将不得不撕毁、更改和转换大量代码。

我的建议是，对于新软件(“嘿，你能给销售人员一个联系人数据库吗？”)，你应该尽可能快地、容易地创建一个工作原型。标记中有SQL数据源的Webforms对于这个原型阶段来说是非常好的。你确定你需要一个真正的数据库吗？现在，您可以在磁盘上使用NoSQL或普通序列化对象做很多事情，开发速度比编写代码填充SQL表要快得多。使用像Twitter引导程序这样的UI框架来减少你的UI时间。如果您确实需要从第一天开始写入关系数据库，请查看实体框架以加快数据访问速度。

只需确保你的沟通“已完成和部署”意味着“我仍然需要在2个月内回来，并优化它”。将这些数据放入您的估计中，当这些部署后的更改返回时，只需添加所需的额外时间即可。

根据第一次部署后返回的更改级别，您必须决定在什么时候才能“真正”知道系统是稳定的，然后花时间将其分解成适当的层。过早优化是许多问题的根源，在我看来，过早的抽象和分层属于“优化”。祝你好运！