开发配置语法-最佳实践/规则/方法？

Question

我目前正在开发一个小应用程序，它检查提供的数据是否满足某些要求。需求实际上是一个很长的列表，并且可能会发生变化，所以我定义了一个语法，允许我在一个单独的文件中简短地陈述所有的需求。

现在，应用程序的总体需求发生了变化，我需要更改配置语法。这使我怀疑是否有方法或最好的实践来发展这样的语法。目前我所做的是

• 我考虑了需求并提出了一个初步的语法，
• 开始配置前几个项目，看看它是如何工作的。
• 如果我遇到一些不能很好地工作或与当前语法完全不兼容的东西，我会更改语法，如果可能的话，以向后兼容的方式进行。

这在某种程度上适用于我，但感觉有点像在混水摸鱼。而且，我觉得这并不能带来最简洁和易于理解/使用的语法。

所以我想知道其他人做什么，特别是如果有更好的方法来解决这个问题。

Answer 1

我的经验是，不值得花费太多的时间来完善表达需求的语法。

需求将再次发生变化，而且很可能是以您没有预料到的方式改变的，因此您不太可能在任何合理的时间框架内找到完美的解决方案。在处理遗留数据时，通常更容易保留旧的解析代码作为回调的后盾，如果有必要，甚至会出现一系列这样的回退。它看起来有点难看，但是向后兼容性很差，如果代码反映了这一点的话，我认为它是可以的，只要每种不同的解析策略都是相当好的。

Answer 2

大多数语言都有某种类型的验证库可供您使用。例如，在C#中，我使用了FluentValidation，它允许您使用fluent API指定业务规则。

public class Post
{
    public string Title;
    public string Body;
    public DateTime CreatedAt;
}

而验证者：

public class PostValidator : BaseValidator<Post>
{
    public PostValidator()
    {
        RuleFor(p => p.Title)
            .NotEmpty()
            .Length(1,50);

        RuleFor(p => p.Body)
            .NotEmpty();
    }
}

建议使用类似的方法，特别是因为这些验证库中有许多是单元可测试的。

Answer 3

这似乎是XML工作良好的一种情况。您可以从需要的基本标记开始，或者是给定的长度等；如果稍后您获得了需要新的约束类型的新需求，只需添加一个标记和代码来检查该标记。