Современные разработчики занимаются построением кроссплатформенных приложений, их сопровождением и развертыванием. Чтобы облегчить им тяжкий труд, был создан новый фреймворк компании Microsoft — ASP.NET Core. Теперь в вашем распоряжении множество разнообразных библиотек с открытым кодом, более того, сам фреймворк является продуктом с открытым кодом.
Как же освоить все новые возможности, предоставляемые ASP.NET Core? Авторы объясняют решение конкретных задач на примере вымышленной компании Alpine Ski House. Каждую главу предваряет краткий рассказ о проблеме, с которой сталкивается команда разработчиков, и о том, как они эту проблему преодолевают. Вам предстоит познакомиться с архитектурой приложений, средствами развертывания и проектирования приложений для работы в облаке и многим другим.
В этой книге рассматриваются первые спринты разработки приложения в вымышленной компании Alpine Ski House. Каждую главу предваряет краткий рассказ о проблеме, с которой сталкивается команда разработчиков, и о том, как они собираются ее преодолевать. Несмотря на присутствие элемента вымысла, в книге достаточно глубоко освещена не только функциональность ASP.NET Core MVC, но и инструментарий, используемый разработчиками для построения, сопровождения и развертывания приложений.
Кроме историй и технической информации об ASP.NET Core MVC, в книге рассматривается новая версия Entity Framework, системы управления пакетами и периферийные технологии, используемые современными веб-разработчиками. Помимо теоретического учебного материала, к книге также прилагается сопроводительный проект — тот самый, который разрабатывают программисты из Alpine Ski House.
Для кого написана эта книга
Книга проведет программиста по всем этапам создания нового приложения на базе ASP.NET Core и обеспечения доступа к нему через интернет. Многие программисты все еще далеки от мира веб-разработки или лишь незначительно соприкоснулись с ним посредством WebForms, несмотря на широкий спектр доступных в настоящее время программных инструментов. Книга поможет читателю овладеть навыками, необходимыми для проектирования современных приложений на активно развивающемся фреймворке. Вы изучите архитектуру приложений, средства развертывания и проектирования приложений для работы в облаке.
Эта книга вам не подойдет, если…
Эта книга может вам не подойти, если вы — опытный разработчик ASP.NET MVC, внимательно следивший за ходом разработки ASP.NET Core MVC или принимавший в нем непосредственное участие.
Структура книги
В книге используется необычный подход: она проводит разработчиков по отдельным спринтам в ходе разработки приложения. Рассматривается не только технология, но также процесс восстановления после ошибок и реакция разработчиков на обратную связь от пользователей. Мы начнем с пустого листа и закончим полноценным работоспособным продуктом.
Книга поделена на четыре части:
• Часть I «Спринт первый: Приложение Alpine Ski House» вводит читателя в суть ситуации: в ней описывается приложение, используемое в книге, и вымышленные персонажи истории.
• Часть II «Спринт второй: Путешествие длиной в 1000 шагов» посвящена основным функциональным аспектам приложения и настройке конвейера, с помощью которого развертывание станет происходить «на лету», а процесс будет понятным для всей команды разработки.
• Часть III «Спринт третий: В пасти у зверя», уделяет основное внимание базовой функциональности, необходимой для того, чтобы начать использовать тестовое приложение в реальных бизнес-процессах. В частности, здесь рассматривается работа с данными посредством Entity Framework Core, созданиепредставлений на базе Razor, настройка конфигурации и журналирование, безопасность и управление правами, и наконец, внедрение зависимостей.
• Часть IV «Спринт четвертый: Финишная прямая» описывает JavaScript и управление зависимостями, а также развивает некоторые предыдущие темы.
В конце книги рассматриваются такие важные темы, как тестирование, рефакторинг и добавление расширений.
Отрывок. Рефакторинг и повышение качества кода
Мало кто из разработчиков доволен кодом, который они написали год назад. Расхожая шутка на многих семинарах по программированию: программист восклицает «Кто написал этот мусор?», заглядывает в историю и выясняет, что это был он. На самом деле это замечательная возможность. Приступая к написанию кода, часто вы только пытаетесь разобраться в предметной области, задаче программирования и структуре приложения, которое вам предстоит написать. Объем информации, которую разум может усвоить за один раз, ограничен, а большое количество «подвижных частей» часто приводит к ошибкам в структуре или функциональности кода. Вернуться и исправить старый код спустя несколько месяцев, когда ваше понимание приложения улучшилось, — величайшая роскошь.
В этой главе рассматривается идея рефакторинга и возможности усовершенствований функциональности приложения без нарушения его работоспособности.
Что такое рефакторинг?
Термин «рефакторинг» был предложен в начале 1990-х годов Уильямом Опдайком (William Opdyke) и Ральфом Джонсоном (Ralph Johnson). Да, есть книга, написанная «Бандой четырех»1. Под рефакторингом понимается изменение внутренней структуры блока кода, в результате которого код становится более понятным, удобным в тестировании, лучше адаптируется к изменениям, причем его внешняя функциональность не изменяется. Если представить себе функцию в виде «черного ящика», который получает входные данные и выдает выходные данные, изменение внутренней структуры «черного ящика» особой роли не играет, если ввод и вывод остаются неизменными (рис. 23.1).
Это наблюдение позволяет вам заменять код в приложении с сохранением функциональности и повышением общего качества приложения. И хотя мы используем термин «функция» как обозначение блока кода, его область действия не обязана ограничиваться внутренним строением функции. Вся суть объектно-ориентированного программирования — широкое введение абстракций для защиты от раскрытия подробностей реализации. Есть много конструкций, которые могут рассматриваться как «черный ящик» для целей рефакторинга. Первым кандидатом становятся классы. Реализация класса несущественна, если входные и выходные данные остаются неизменными, поэтому мы можем изменять его внутренние механизмы так, как считаем нужным. Пространства имен не обеспечивают тот же уровень защиты, что и классы, но также могут рассматриваться как кандидаты на замену. Наконец, в мире микросервисов все приложение может быть заменено другим приложением, и такая замена тоже станет частью рефакторинга.
Рассмотрим сервис, обязанностью которого является отправка электронной почты по списку рассылки. Вводом может быть список получателей и отправляемое сообщение. Место вывода как такового здесь занимает результат: получение сообщения всеми адресатами из списка получателей (рис. 23.2).
Неважно, как именно микросервис рассылает сообщения: с помощью Sendgrid или с собственного сервера. В любом случае результат остается одним и тем же. В данном случае замена микросервиса может считаться рефакторингом.
Программисты обычно называют рефакторингом все, что способствует улучшению кода. Исключили лишний параметр метода? Добавили запись в журнал в коварном методе, чтобы обеспечить улучшенную поддержку DevOps? Хотя качество кода или качество приложения в обоих случаях повышается, ни один из них формально не может рассматриваться как рефакторинг, потому что они изменяют функциональность приложения. Полное следование определению рефакторинга требует, чтобы неизменным оставался как ввод (в том числе и состав параметров), так и вывод (включая сообщения в журнале).
Оценка качества кода
Если разработчик занимается рефакторингом для повышения качества кода, безусловно, должен существовать некоторый критерий оценки качества кода. Было бы замечательно иметь инструмент для оценки качества кода — безукоризненную метрику, способную представить все аспекты качества кода одним числом. К сожалению, такой метрики не существует. За прошедшие годы предлагалось бесчисленное множество метрик качества, от центробежного и центростремительного сцепления до оценки количества ошибок в строке кода и степени тестового покрытия кода. Выбор набора метрик качества кода — тема, которая сама по себе заслужила бы целой книги.
Впрочем, будет полезно выделить несколько простых метрик для оценки качества кода:
• Делает ли код то, что ему положено делать? На первый взгляд очевидно, но об этой метрике часто забывают. Ее можно оценить по количеству заявленных ошибок на тысячу строк кода или по количеству ошибок на класс. Некоторые разработчики используют эту метрику глобально, сравнивая относительное качество двух проектов по количеству обнаруженных дефектов. Впрочем, такой подход непродуктивен, потому что два проекта никогда не решают одну проблему. Можно ли ожидать, что система создания и доставки электронных поздравительных открыток будет иметь такую же степень сложности или количество ошибок, что и система управления дозатором инсулина? Нет, конечно. Эта метрика, как и большинство других, просто помогает узнать, совершенствуется ли группа и продукт со временем.
• Удовлетворяет ли код своим нефункциональным требованиям? Речь идет о требованиях, не связанных с вводом или выводом функции (как, например, производительность фрагмента кода или его защищенность).
• Насколько понятен код? Идеального кода вообще не бывает, и кому-то рано или поздно понадобится обновить его из-за обнаруженной ошибки или изменившихся требований. Этим «кем-то» может стать даже автор кода, то есть вы! Взгляните на следующий фрагмент:
for (var i = 1; i < parts.length; i++) {
root[parts[i]] = root[parts[i]] || (root[parts[i]] = {});
root = root[parts[i]];
}Возможно, это эффективный и умный код, но разобраться в нем почти невозможно. Найти объективную метрику понятности или удобочитаемости достаточно сложно. Эта метрика — не столько число, сколько воплощение согласованного мнения разработчиков относительно удобства сопровождения. В группах нормальных людей, не отягощенных амбициями, редко возникают серьезные расхождения по поводу того, насколько хорошо читается код. Рецензирование кода — прекрасный инструмент для обнаружения непонятных участков кода.
Другая простая, но практичная метрика — цикломатическая сложность — оценивает сложность функций по количеству ветвей кода в методе. Метод с одной командой if содержит две возможные ветви кода, а значит, его цикломатическая сложность равна 2 (рис. 23.3).
• Способен ли код легко реагировать на изменения в требованиях? И снова эта метрика не может быть выражена простым числом. Скорее это ощущение, возникающее в группе опытных разработчиков. По кислому выражению на лице разработчика, когда в его коде предполагаются серьезные изменения, можно с уверенностью определить, достигнута ли эта цель.
Эти четыре простые метрики станут хорошей отправной точкой для принятия решения о том, каким частям приложения может понадобиться рефакторинг. Вероятно, в процессе роста и развития приложения вам удастся обнаружить и добавить новые метрики.
Когда в вашем распоряжении оказывается несколько метрик, важно убедиться в том, что приложение не оптимизируется по ошибочной метрике. Люди склонны обманывать систему, сознательно или нет. Если выбрать метрику производительности, обеспечивающую максимально быстрый возврат из функции, но при этом не добавить метрику, устанавливающую разумное ограничение затрат памяти, появляется искушение оптимизировать функцию так, чтобы она расходовала память в обмен на вычислительные ресурсы. Подумайте, действительно ли это именно то, что вам нужно, или на самом деле конечной целью является баланс. Проанализируйте метрики и убедитесь в том, что оптимизация не идет в неверном направлении, а если все же идет — обновите набор метрик.
Об авторах
Джеймс Чамберс, пятикратный обладатель статуса Microsoft MVP в области технологий разработки, в настоящее время занимается разработкой с использованием ASP.NET Core и MVC Framework на платформе Azure и AWS. Он является независимым консультантом, преподавателем и активным блоггером, а также участником ряда проектов с открытым кодом.
Дэвид Пэкетт, четырехкратный обладатель статуса Microsoft MVP — разработчик ПО и независимый консультант. Он обладает обширным опытом использования .NET для построения приложений Windows и веб-приложений, глубокими техническими познаниями и страстью к качественным пользовательским интерфейсам.
Саймон Тиммс, обладатель статуса Microsoft MVP на протяжении многих лет — организатор сообществ, блоггер, разработчик и независимый консультант. Его технологические интересы весьма разнообразны, он увлекается всем — от распределенных систем до новомодных фреймворков JavaScript. Обладая хорошей подготовкой как в области разработки, так и в организации текущей работы, он нередко сводит с ума свои группы, участвуя во всех этапах, от построения и разработки до обслуживания серверов.
» Более подробно с книгой можно ознакомиться на сайте издательства
» Оглавление
» Отрывок
Для Хаброжителей скидка 20% по купону — ASP.NET Core
Автор: ph_piter
