Избегайте или принимайте конструкции C #, которые нарушают принцип редактирования и продолжения?

Я разрабатываю и поддерживаю большое (500k + LOC) приложение WinForms, написанное на C # 2.0. Оно многопользовательское и в настоящее время развернуто примерно на 15 машинах. Разработка системы продолжается (можно рассматривать как вечную бета-версию), и вот ' Очень мало сделано для защиты пользователей от потенциальных новых ошибок, которые могут появиться в еженедельной сборке.

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

Я так высоко отношусь к редактированию и продолжению, что активно пишу код, чтобы полностью совместим с ним. Например, я избегаю:

  • Анонимные методы и встроенные делегаты (если полностью невозможно переписать)
  • Общие методы (за исключением стабильного неизменяемого служебного кода)
  • Ориентация на проекты на «Любой ЦП» (т.е. никогда не выполняется в 64-битном режиме)
  • Инициализация полей в точке объявления (инициализация перемещается в конструктор)
  • Запись блоков перечислителя, которые используют yield (кроме служебного кода)

Теперь я полностью осознаю, что новый языковые функции в C # 3 и 4 в значительной степени несовместимы с функцией редактирования и продолжения (лямбда-выражения, LINQ и т. д.). Это одна из причин, по которой я сопротивлялся переносу проекта на более новую версию Framework.

Мой вопрос заключается в том, стоит ли избегать использования этих более сложных конструкций в пользу кода, который очень, очень легко отлаживать? Есть ли законность в таком развитии событий, или это расточительно? Также, что важно, вызывают ли какие-либо из этих конструкций (лямбда-выражения, анонимные методы и т. Д.) Накладные расходы на производительность / память, которых можно было бы избежать при написании хорошо написанного, совместимого с редактированием и продолжением кода? ... или внутренняя работа компилятора C # заставляет такие сложные конструкции работать быстрее, чем написанный вручную "расширенный" код?

20
задан JaredPar 5 October 2010 в 16:16
поделиться