Основные принципы, по которым следует ехать домой:
- Инструменты Microsoft - хорошее место для начала, но можно написать лучшее программное обеспечение быстрее, используя другие сопутствующие продукты
- Изменение - это хорошо, поэтому всегда думайте о том, как быстро изменить код и проверить его
- Если это не проверено, это не качество продукции
Затем, после контроля версий (!), Я начну с непрерывной интеграции и покажу, как получение немедленной обратной связи о качестве сборки может помочь улучшить качество с первого момента. Первое выполнение CI не меняет кодовую базу.
Затем я бы представил автоматизированное сквозное тестирование приложения с помощью FitNesse, Watin или что-нибудь подобное. Это должно проиллюстрировать, как не стоит бояться рефакторинга кода, если у вас есть хорошие инструменты тестирования, которые проверят, что код все еще работает.
Тогда я бы сделал мягкий рефакторинг, чтобы отделить бизнес-логику и доменные объекты от пользовательского интерфейса (если их там уже нет) и ввести модульное тестирование. Это также показывает, насколько хорош рефакторинг.
Поскольку мы стремимся к определенному разделению проблем, шаблоны проектирования (такие как IoC), естественно, начнут становиться очевидными. Также будет очевидно, что мы можем заменить слой данных на ORM.
В процессе рефакторинга я бы также показал, как разработка на основе тестов может на самом деле ускорить создание лучшего кода. Это, вероятно, легче всего продемонстрировать впервые с новой разработкой, так как в противном случае это довольно культурный шок!