Гарантируется ли результат задания. Когда все заказы гарантированы?

Question

Из следующего теста мы видим, что текущая версия фреймворка гарантирует, что порядок вывода совпадает с порядком ввода.

async Task<string> GetString1()
{
    await Task.Delay(2000);
    return "1";
}

async Task<string> GetString2()
{
    await Task.Delay(1000);
    return "2";
}

var results = await Task.WhenAll(GetString1(), GetString2());
//now we have results[0] == "1" results[1] == "2"

Однако из документации я не могу найти ничего об этом поведении, что означает, что документ не гарантирован. Из мнений ответов на этот вопрос

Q1: мне нужно поставить "флаги порядка" на выходе? Измените пример кода следующим образом:

class OrderTaskResult<T>
{
    public OrderTaskResult(int order, T value)
    {
        this.Order = order;
        this.Value = value;
    }
    public int Order { get; private set; }
    public T Value { get; private set; }
}

async Task<OrderTaskResult<string>> GetString1()
{
    await Task.Delay(2000);
    return new OrderTaskResult<string>(1, "1");
}

Q2: (возможно, основанное на первичном мнении). Действительно ли плохая практика - кодировать в зависимости от недокументированного поведения, даже если некоторые виды поведения практически не могут быть изменены? Иногда вам нужно добавить много кодов, чтобы избежать недокументированного поведения.

Answer 1

Вы просматриваете документацию для неправильной перегрузки.

Если вы посмотрите на перегрузку, которая фактически возвращает результаты, вы увидите:

Task<TResult>.Result свойство возвращаемой задачи будет установлено в массив, содержащий все результаты поставленных задач в том порядке, в котором они были предоставлены

Answer 2

Отвечая на ваш второй вопрос, хотя и признавая, что в данном конкретном случае это спорно -

Q2: (возможно, основанный на первичном мнении) Действительно ли плохая практика - кодировать в зависимости от недокументированного поведения, особенно когда некоторые виды поведения имеют мало возможностей для изменения? Иногда вам нужно добавить много кода, чтобы избежать недокументированного поведения.

Собираюсь дать канонический инженерный ответ - это зависит от обстоятельств. Вам нужно взвесить преимущества более простого кода, работающего в настоящее время, с риском того, что коврик вырвется у вас из-под ног в будущем.

С одной стороны, « технический долг » - это то, что вам может быть полезно прочитать, чтобы развить здесь свою интуицию -

Технический долг (также известный как проектный долг или долг кода, но также может быть связан с другими техническими усилиями) - это концепция в разработке программного обеспечения, которая отражает подразумеваемую стоимость дополнительных доработок, вызванных выбором простого (ограниченного) решения сейчас вместо использования лучший подход, который займет больше времени.

С другой стороны, вы, возможно, сможете снизить риск до приемлемой степени, спроектировав свою кодовую базу таким образом, чтобы она была модульной и слабо связанной - то, что, если вы будете следовать указаниям принципов проектирования SOLID, вы сможете вероятно, все равно будет делать. Или, если вы более функциональный путь, вы можете попробовать откусить от Марка выбираетеСиманна Impureimсэндвича , который также имеет большое значение для того, чтобы ваша основная логика домена была отделена от деталей приложения, которые могут измениться в результате следующей шумихи или осуждения приложения. особая технология прохождения.