Силлабус:
Избавляемся от зависимости от зависимостей
Сколько раз вы пытались удалить некоторую зависимость из проекта, но не были уверены, что сделали это успешно? Чтобы ваша кодовая база не зависела от чего-то конкретного? Или чтобы она "зависела от интерфейсов, а не от реализации"? Или старались следовать SOLID по инверсии зависимостей?
Избавляемся от зависимости от зависимостей - 2
Ключевой вопрос любой зависимости независимо от её типа, очевидно, такой: "Зависит ли А от B?".
Избавляемся от зависимости от зависимостей - 3
В первом материале по этой теме мы разобрали 9 видов зависимостей, а во втором материале изучили три характеристики любой зависимости, и как правильно о них думать. Теперь вернёмся к исходным 9 видам, и рассмотрим, как с ними разбираться. Но предварительно дадим точное и практическое определение зависимости.
Избавляемся от зависимости от зависимостей - 4
Итак, у нас есть универсальное определение зависимости. Рассмотрим теперь в его свете 9 типов зависимостей, причём в некоторых случаях мы получим ответ вида "это не зависимость, но часть зависимости".
Как извлечь пользу из сторонних зависимостей
Скорее всего, в вашем проекте имеется не одна зависимость от сторонних библиотек, на которые достаточно серьёзно опирается ваше приложение, но вы либо боитесь, либо по каким-то другим причинам не хотите (нету времени...) заглянуть под капот и изучить её исходный код.
Изоморфизмы и программирование
Чем больше вы тренируете свою способность формально рассуждать об изоморфизмах, тем больше расширяется ваша способность видеть вроде бы несвязанные вещи эквивалентными, и формировать интересные связи между ними.
Что такое баг?
Через некоторое время обнаруживается, что разработчики совершенно неправильно поняли интерфейс API...
Пишем безошибочный код с помощью Typestate-Oriented Programming
ООП позволяет достаточно хорошо моделировать мир, но основополагающим для качественного моделирования становится состояние объекта, которое, с другой стороны, частая причина ошибок и запутывания кода.
Логика бьёт порядок
Сценарии (прежде всего use cases и user stories) сегодня тотально доминируют в технических заданиях. Они опасны тем, что обманчиво хорошо смотрятся с точки зрения здравого смысла, однако не могут претендовать на универсальность прежде всего потому, что им не хватает абстракции, даже если мы предварительно тщательно формируем "проектную онтологию предметной области"...
Дополнительная сложность -- мать всех запашков кода
Я учу видеть такие недостатки в коде, которые большинство сочтёт безобидными, и программировать на более высоком уровне, чем многие вообще могут себе представить. Но, как ни странно, ещё труднее поднимать на такой уровень код.
44 правильных вопроса при разбирательстве с легаси-системой
Само по себе изучение кода проекта "в вакууме" довольно абстрактно и бессмысленно. Вместе с кодом у вас должна быть работающая система, сформированная из этого кода, с которой вы взаимодействуете через UI.
Как развивать хакерское мышление
Главная рекомендация, что тут как раз надо забыть/забить на классические принципы проектирования, и действовать от противного.
=
12 материалов,
130 кб чистого текста,
купить на бусти
+ этот 7-й гайд добавлен в бандл (кто уже покупал бандл, просто скачайте и этот гайд себе бесплатно, и так и дальше будет с новыми - доплачивать не надо),
=
Предыдущие материалы (в бандле все эти материалы с большой суммарной скидкой + новый данный):
1. БАЗА программной инженерии
2. Software Design с акцентом на Programming in Small
3. SOLID-26
4. Вайб-проектирование
5. Software Design с акцентом на Programming in Large
6. Programming in Large: продолжение
7. this :)