Отзыв Принципы, паттерны и методики гибкой разработки на языке C# Роберт Мартин, Мика Мартин

Манифест гибкой разработки программ 

Мы открываем лучшие способы разработки программного обеспечения, применяя их на практике и помогая в этом другим. В ходе своей работы мы научились ценить: 

Людей и их взаимоотношения больше, чем процессы и инструменты. 

Работающую программу больше, чем исчерпывающую документацию. 

 Плодотворное сотрудничество с заказчиком больше, чем формальные договоренности по контракту. 

Оперативное реагирование на изменения больше, чем следование плану. 

Иначе говоря, не отрицая значимость факторов, перечисленных в правой части предложений, мы больше ценим те, что слева.

Методики экстремального программирования 

1. Единая команда
2. Пользовательские истории
3. Короткие циклы
4. Приемочные тесты
5. Парное программирование
6. Разработка через тестирование
7. Коллективное владение
8. Непрерывная интеграция
9. Умеренный темп
10. Открытое рабочее пространство
11. Игра в планирование
12. Простота
13. Рефакторинг

S
Принцип единственной обязанности/ответственности (single responsibility principle) обозначает, что каждый объект должен иметь одну обязанность и эта обязанность должна быть полностью инкапсулирована в класс. Все его сервисы должны быть направлены исключительно на обеспечение этой обязанности.
O
Принцип открытости / закрытости декларирует, что программные сущности (классы, модули, функции и т. п.) должны быть открыты для расширения, но закрыты для изменения. Это означает, что эти сущности могут менять свое поведение без изменения их исходного кода.
L
Принцип подстановки Барбары Лисков (Liskov substitution) в формулировке Роберта Мартина: «функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа не зная об этом». (Метод Summ(int x, int y) должен возвращать x+y в любом подклассе. Ещё пример: квадрат и прямоугольник).
I
Принцип разделения интерфейса (interface segregation) в формулировке Роберта Мартина: «клиенты не должны зависеть от методов, которые они не используют». (Много специализированных интерфейсов лучше, чем один универсальный). Принцип разделения интерфейсов говорит о том, что слишком «толстые» интерфейсы необходимо разделять на более маленькие и специфические, чтобы клиенты маленьких интерфейсов знали только о методах, которые необходимы им в работе. В итоге, при изменении метода интерфейса не должны меняться клиенты, которые этот метод не используют. (discount - скидка)
D
Принцип инверсии зависимостей (dependency inversion) — модули верхних уровней не должны зависеть от модулей нижних уровней, а оба типа модулей должны зависеть от абстракций; сами абстракции не должны зависеть от деталей, а вот детали должны зависеть от абстракций.

Паттерны

Команда и Активный объект
Шаблонный метод и Стратегия
Одиночка и моностстояние
Фабрика
Компановщик
Наблюдатель
Абстрактный сервер, адаптер и мост
Заместитель и Шлюз
Посетитель
Состояние Конечные автоматы

Мартин ненавидит .net-разработчиков!

1. Хотя мне доводилось раньше писать на C#, лучше всего я владел языками Java и C++. (26)
2. И буду откровенен: мой опыт показывает, что программисты .NET зачастую слабее тех, что пишут на Java или C++. (27)
3. Программисты .NET обычно хуже разбираются в методах разработки ПО, паттернах и принципах проектирования и т. п. (27)
4. Я надеюсь, что это издание, ориентированное на .NET, перекинет мост между разработчиками .NET и остальным сообществом.(27) 
5. Я надеюсь, что программисты .NET завоюют новый статус в сообществе разработчиков.(27)
6. Работая над этой книгой, я не раз сомневался, ставить ли свое имя на обложке книги, посвященной .NET. Я спрашивал себя, хочу ли я, чтобы меня ассоциировали с .NET и со всеми негативными представлениями, связанными с этой платформой. Но что толку отрицать? Я программист .NET. Нет! Я гибкий программист .NET. И горжусь этим. (27)

Первое издание этой книги, «Agile Software Development: Principles, Patterns, and Practices», написанной моим отцом, Робертом К. Мартином, вышло в 2002 году (27)

Перевод! 

1. "А теперь предположим, что заказчик выставил новое требование. Некоторые модемы, называемые выделенными, не поддерживают набор номера, а устанавливаются на обоих концах выделенного соединения. Несколько новых приложений уже используют такие модемы и никаких номеров не набирают. Будем называть их DedUsers." (Кого будем называть?)(544) 
2. Очень часто диаграммы отличаются от текста и кода.
1. Где связь до Ded Users?(547)
2.  Сам автор пишет, что диаграммы старше текста. "Представленные в этой главе диаграммы построены на базе диаграмм. Буча в соответствующей главе издания этой книги 1995 года.1 Эти диаграммы созданы в 1994 году. По мере их создания я писал реализующий код, дабы убедиться, что диаграммы осмысленны. Однако по своему объему он даже не приближается к тому, что представлен здесь. По тому те диаграммы не были так же тщательно поверены(ОШИБКА!) кодом и тестами. И это заметно."

757 страниц

35 - обложка, издательство, оглавление/алфавитный указатель, пустые страницы.
7 - манифесты,  предисловие и об авторах
10 - введение

11 - гибкая разработка (Принципы.)
10 - Обзор экстремального программирования
В обоих главах КРАТКО описываются принципы экстремального программирования и гибкой разработки.
7 - Планирование.
9 - Тестирование. Рассказ про TDD (Кент Бек лучше)
14 - Рефакторинг
47 - Игра в боулинг.
13 - Гибкое проектирование введение
60 - SOLID
118 - UML. Пропускать нельзя. Потом все объяснения будут построены на UML. Так же в этой главе затрагиваются и другие методики разработки (прецеденты, пользовательские истории и тд.)
139 (333-337) (388-454) (647 - 716)Расчёт заработной платы. Можно сказать самая полезная часть книги. Тут мы начинаем разработку программы для расчёта и начисления заработной платы. Ведётся реальная разработка(без ролей, пьес и заламывания рук). Так же иногда автор даёт самостоятельные задания по реализации тех или иных частей кода. Здесь объясняется и показывается зачем и почему используются принципы SOLID и паттерны проектирования. Так же показаны методики гибкой разработки (истории, прецеденты, Agile в целом). Тема разбита на две части. В первой мы разрабатываем бизнес логику, а во второй начинаем работать с базами данных, проектированием пакетов\решений и пр.
192 (338 - 387) (480 - 488) (511 - 646) - Паттерны
45 (455 - 479) (489 - 510) - Принципы проектирования и анализа пакетов и компонентов

16 (717 - 733) - Сказ о двух компаниях
13 (734 - 747) - Что такое проектирование программного обеспечения. Статья.

Итого:
309 страниц обязательно к прочтению
139 рекомендуем.

Игра в боулинг. Тут мы в первый раз встречаемся с UML диаграммами

1. (93).БМ: Не поможешь мне написать программульку для подсчета очков
   в боулинге?
   БК: (размышляя про себя: этика парного программирования в XP
   говорит, что нельзя отказывать, когда тебя просят о помощи.
   Полагаю, что это особенно относится к случаю, когда просит
   начальник) Конечно, Боб, с удовольствием.
2. (94).БМ: Да, этого парня не назовешь образцом стабильности.
   БК: Или выпил малек. Зато какой отличный приемочный тест получится.
3. (94).БМ: (принимая позу великого объектного проектировщика) Ну так,
   понятно, что игра состоит из десяти фреймов. В каждом объектефрейме
   может быть один, два или три броска
4. (95).БК: Ну, раз у него нет поведения, то для чего он нужен? Пока не знаю,
   должен он существовать или нет. Мне кажется, было бы полезнее
   поработать над объектом, у которого есть что-то помимо методов
   чтения и записи. Но если ты хочешь постучать… (пододвигает
   клавиатуру к БМ).
   БМ: Ладно, давай сместимся по цепочке зависимостей к Frame и посмотрим,
   нет ли каких-нибудь тестов, которые позволили бы нам покончить
   с Throw (двигает клавиатуру обратно к БК).
   БК: (недоумевая, что задумал БМ: то ли хочет завести меня в тупик,
   чтобы чему-то научить, то ли вправду согласен со мной)
   Поехали, новый файл, новый тест.
5. (103).БМ: (строго грозит пальцем) Пока что я не знаю, где какие функции
   обретаются, сейчас я хочу, чтобы счет заработал.
6. (106).БМ: (хватая клавиатуру) Так-то оно так, но мне кажется, что инкремента
   ball в ветке frameScore==10 быть не должно
7. (117).БМ: (со счастливой улыбкой глядя на зеленую полосу) И это работает.
   Больше ничего не приходит в голову. А тебе?
8. (118).БМ: Ага, и заодно это поможет реализовать твою идею о выделении отдельного
   объекта-обсчитывателя. Ладно, давай попробуем.
   БК: (завладевает клавиатурой)!!!!!!!
9. (124).БМ: (в глазах отражается зеленая полоса)...
   БК: (тянется за клавиатурой).
10. (125).БК: (выпучив глаза) Проектирование сверху вниз?!!
11. (126).БК: (тянет к себе клавиатуру и мелкими шагами вносит изменения,
    прерывая их прогоном тестов)