Разработка обслуживаемых программ на языке С#

Читать фрагмент

книга

Разработка обслуживаемых программ на языке С#

Данное практическое руководство познакомит вас с 10 простыми рекомендациями, помогающими писать программное обеспечение, которое легко поддерживать и адаптировать. Эти тезисы сформулированы на основании анализа сотен реальных систем.
Написанная консультантами компании Software Improvement Group книга содержит ясные и краткие советы по применению рекомендаций на практике. Примеры для этого издания написаны на языке C#, но существует аналогичная книга с примерами на языке Java.
Издание предназначено программистам на C#, желающим научиться писать качественный и хорошо поддерживаемый код.

Форматы: PDF

Издательство: ДМК Пресс

Год: 2017

Место издания: Москва

ISBN: 978-5-97060-446-5

Страниц: 192

Артикул: 95441

Возрастная маркировка: 16+

Электронная книга

359 ₽

Купить и скачать

Содержание

Содержание книги "Разработка обслуживаемых программ на языке С# "

Об авторах

Предисловие

Глава 1. Введение

1.1. Что такое обслуживаемость?

Четыре вида обслуживаемости программного обеспечения

1.2. Почему так важна обслуживаемость?

Обслуживаемость значительно влияет на деловую сторону вопроса

Обслуживаемость обеспечивает улучшение других качественных характеристик

1.3. Три принципа, на которых основаны рекомендации

Принцип 1: рекомендации должны быть простыми

Принцип 2: применение рекомендаций с самого начала и значимость вклада каждого разработчика

Принцип 3: не все отступления от рекомендаций дают одинаковый отрицательный эффект

1.4. Заблуждения относительно обслуживаемости

Заблуждение: обслуживаемость зависит от языка программирования

Заблуждение: обслуживаемость зависит от прикладной области

Заблуждение: обслуживаемость гарантирует отсутствие ошибок

Заблуждение: обслуживаемость оценивается одной из двух альтернатив

1.5. Рейтинг обслуживаемости

1.6. Обзор рекомендаций по улучшению обслуживаемости

Глава 2. Пишите короткие блоки кода

2.1. Мотивация

Короткие блоки кода проще тестировать

Короткие блоки кода проще анализировать

Короткие блоки кода проще повторно использовать

2.2. Как применять рекомендацию

При написании нового блока кода

При добавлении в блок новых функциональных возможностей

Два метода рефакторинга для приведения кода в соответствие с рекомендацией

2.3. Типичные возражения против коротких блоков кода

Возражение: увеличение количества блоков кода плохо сказывается на производительности

Возражение: разделение кода ухудшает читаемость

Рекомендация препятствует надлежащему форматированию кода

Этот блок кода невозможно разделить

Разделение блоков кода не дает заметных преимуществ

2.4. Дополнительные сведения

Глава 3. Пишите простые блоки кода

3.1. Мотивация

Простые блоки проще изменять

Простые блоки проще тестировать

3.2. Как применять рекомендацию

Цепочки условий

Вложенность

3.3. Типичные возражения против создания простых блоков кода

Возражение: высокая сложность неизбежна

Возражение: разделение методов не уменьшает сложности

3.4. Дополнительные сведения

Глава 4. Не повторяйте один и тот же код

Виды дублирования

4.1. Мотивация

Код с дубликатами сложнее анализировать

В дублированный код сложно вносить изменения

4.2. Как применять рекомендацию

Извлечение суперкласса

4.3. Типичные возражения против исключения дублирования

Копирование фрагментов из другой базы кода допустимо

При незначительных изменениях дублирование неизбежно

Этот код никогда не изменится

Дублирование всех файлов допустимо в целях создания их резервных копий

Модульные тесты защитят меня

Дублирование строковых литералов неизбежно и совершенно безвредно

4.4. Дополнительные сведения

Глава 5. Стремитесь к уменьшению размеров интерфейсов

5.1. Мотивация

Интерфейсы небольшого размера упрощают понимание и повторное использование кода

В методы с компактным интерфейсом проще вносить изменения

5.2. Как применять рекомендацию

5.3. Типичные возражения против сокращения размеров интерфейсов

Возражение: объекты параметров требуют определения конструкторов с большим количеством параметров

Преобразование интерфейсов большого размера не улучшает ситуацию

Фреймворки или библиотеки предоставляют интерфейсы с длинными списками параметров

5.4. Дополнительные сведения

Глава 6. Разделяйте задачи на модули

6.1. Мотивация

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

Небольшие слабо связанные модули упрощают навигацию по коду

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

6.2. Как применять рекомендацию

Разделение классов по решаемым задачам

Сокрытие подробностей реализации за интерфейсами

Замена пользовательского кода библиотеками или фреймворками от сторонних производителей

6.3. Типичные возражения против разделения задач

Возражение: слабые связи вступают в конфликт с возможностью повторного использования

Возражение: интерфейсы языка C# не предназначены для ослабления связей

Возражение: высокая нагрузка на служебные классы неизбежна

Возражение: не все слабо связанные решения улучшают обслуживаемость

Глава 7. Избегайте тесных связей между элементами архитектуры

7.1. Мотивация

Слабая зависимость между компонентами обеспечивает изолированность его обслуживания

Слабая зависимость компонентов способствует разделению ответственности за обслуживание

Слабая зависимость компонентов упрощает тестирование

7.2. Как применять рекомендацию

Абстрактная фабрика как шаблон проектирования

7.3. Типичные возражения против устранения тесных связей компонентов

Возражение: зависимости между компонентами невозможно смягчить из-за тесного переплетения компонентов

Возражение: нет времени на исправление

Возражение: транзитный код просто необходим

7.4. Дополнительные сведения

Глава 8. Стремитесь к сбалансированности архитектуры компонентов

8.1. Мотивация

Хороший баланс компонентов упрощает поиск и анализ кода

Хорошо сбалансированные компоненты улучшают изолированность обслуживания

Хорошо сбалансированные компоненты позволяют распределять ответственность при обслуживании

8.2. Как применять рекомендацию

Выбор правильного концептуального уровня при распределении функциональных возможностей по компонентам

Последовательное применение разделения системы на основе анализа предметной области

8.3. Типичные возражения против стремления к сбалансированности компонентов

Возражение: системы с дисбалансом компонентов отлично работают

Возражение: запутанность связей между компонентами не позволяет их сбалансировать

8.4. Дополнительные сведения

Глава 9. Следите за размером базы кода

9.1. Мотивация

Проект с большой базой кода, скорее всего, обречен на неудачу

Большие базы кода труднее обслуживать

Большие системы отличаются высокой плотностью дефектов

9.2. Как применять рекомендацию

Функциональные меры

Технические меры

9.3. Типичные возражения против уменьшения размеров базы кода

Возражение: сокращение размера базы кода снижает продуктивность разработки

Возражение: выбранный язык программирования препятствует уменьшению объема кода

Возражение: сложность системы заставляет дублировать код

Возражение: разделение базы кода невозможно из-за архитектуры платформы

Возражение: разделение кода приводит к дублированию

Возражение: разделение базы кода невозможно из-за тесной связанности

Глава 10. Автоматизируйте тестирование

10.1. Мотивация

Автоматизация делает тестирование повторяемым

Автоматизированное тестирование увеличивает эффективность разработки

Автоматизированное тестирование делает код предсказуемым

Тесты документируют тестируемый код

Разработка тестов улучшает качество кода

10.2. Как применять рекомендацию

Начало работы с NUnit

Общие принципы разработки хороших модульных тестов

Оценка охвата для определения достаточности количества тестов

10.3. Типичные возражения против автоматизации тестов

Возражение: нам нужно и ручное тестирование

Возражение: мне не разрешается писать модульные тесты

Возражение: зачем тратить время на модульные тесты при низком текущем охвате ими

10.4. Дополнительные сведения

Глава 11. Пишите чистый код

11.1. Не оставляйте следов

11.2. Как применять рекомендацию

Правило 1: не оставляйте после себя грязи на уровне блоков кода

Правило 2: не оставляйте после себя неудачных комментариев

Правило 3: не оставляйте после себя закомментированного кода

Правило 4: не оставляйте после себя неиспользуемого кода

Правило 5: не оставляйте после себя длинных идентификаторов

Правило 6: не оставляйте после себя таинственных констант

Правило 7: не оставляйте после себя плохую обработку исключений

11.3. Типичные возражения против написания чистого кода

Возражение: комментарии являются документацией

Возражение: обработка исключений увеличивает объем кода

Возражение: почему выбраны именно эти правила

Глава 12. Дальнейшие действия

12.1. Применение рекомендаций на практике

12.2. Низкоуровневые (блоки кода) рекомендации имеют более высокий приоритет, если они противоречат высокоуровневым (компоненты) рекомендациям

12.3. Помните, что учитывается каждое действие

12.4. Передовой опыт разработки будет рассмотрен в следующей книге

Приложение А. Как в компании SIG оценивается обслуживаемость

Предметный указатель

Внимание!
При обнаружении неточностей или ошибок в описании книги "Разработка обслуживаемых программ на языке С# (автор Джуст Виссер)", просим Вас отправить сообщение на почту help@directmedia.ru. Благодарим!

Разработка обслуживаемых программ на языке С#

Содержание

Виссер Д. другие книги автора

С книгой "Разработка обслуживаемых программ на языке С#" читают