5-й сериал Programming in Large: продолжение
(на основе СильныхИдей для ментатов)
Предыдущие сериалы:
1. БАЗА программной инженерии
2. Software Design с акцентом на Programming in Small
3. SOLID-26
4. Software Design с акцентом на Programming in Large
Кто хочет взять все пять, подождите, сделаю бандл со скидкой.
17 материалов, 79 файлов, 170 тыс. знаков чистого текста.
Цена
=>
Проектные требования или проектная онтология?
Прежде всего, всегда исходите из того, что "требования заказчика" всегда надо воспринимать как "фантастические представления заказчика о требованиях" :)
О пользе формальных спецификаций
Когда здесь остановиться? Как вообще правильно думать о соотношении абстрактной спецификации Abstract с нашей реализацией Impl?
Можно ли генерировать код из спецификаций?
Особенно с учётом последних достижений LLM? Нет, вы не можете это делать... Но есть и хорошие новости.
И снова про тесты и TDD
Какой бы алгоритм ни был скрыт внутри функции Foo, он полностью непрозрачен, поэтому тест не справляется со своей базовой ролью спецификации и документации...
Функциональная архитектура - что это?
Максимально простое определение функционального программирования, из которого естественно вытекает и понятие функционального проектирования...
Наилучший способ разрабатывать большие программы
Задача ФП -- не устранять "побочные" эффекты, а наоборот, делать их явными и полностью управляемыми...
Инварианты и качественный код
Понятие инварианта (некоего логического утверждения, истинного всегда в процессе работы программы, например, "скорость объекта Кот не может превышать 100 км/ч") неотделимо от качественного кода.
Идея в том, что инвариант может быть нарушен только в том случае, если в вашей программе есть ошибка.
Формальный подход к рефакторингу
Подсказка: новая версия Foo должна быть инвариантна старой по своему интерфейсу...
ООП как средство повторного использования кода
Мечта многих поколений программистов -- создание реально многократно используемого кода. Однако можно однозначно сказать, что мы не то что до сих пор не разобрались с этим, а только ещё больше запутались.
Состояние -- это время
Абстракции -- это (почти) всегда про (виртуальное) время! А мы его эксплицитно учитываем крайне редко.
Не путаем DI и ADT
В любом случае всегда надо стремиться снижать coupling, а с DI получается, что вроде как зависимости явно описываются и внедряются в классы. Но так как с помощью DI мы можем легко заменять реализации зависимостей, получается, что внедрение зависимостей через интерфейсы способствует инкапсуляции, поскольку делается акцент на использовании интерфейсов вместо конкретных реализаций...
Анти-Visitor
В предыдущих выпусках мы разбирали, насколько хорош паттерн Visitor ("Всё, что вы знаете об ООП, неверно", "Ключевой паттерн Visitor в ООП и ФП"), но и у него конечно имеется своя тёмная сторона, о которой необходимо знать...
Глобальные ошибки эмерджентности
Интеграционные и сквозные тесты дорогие и медленные, и "покрыть" ими обычно удаётся лишь малую часть пространства состояний программы. Но глобальная корректность вообще никак не следует из локальной корректности...
Три типа программных ошибок
Любая система может сломаться: пользователь введёт неверные сведения, данные в базе окажутся некорректными, откажет сеть или интернет, проявятся обычные баги, в параллельных процессах возникнет клинч или гонка, космические лучи инвертируют бит, и т.д.
Как правильно работать с исключениями
Поспрашивайте знакомых программистов, и большинство пожмёт плечами и скажет: просто не вызывайте функцию с пустой коллекцией. Кто-то более продвинутый уточнит, что для этой конкретной функции надо задать соответствующее предусловие (например, в виде комментария). То есть ответственность перекладывается на вызывающего эту функцию...
Как и зачем разграничивать рабочие процессы
Agile называет это гибкостью, однако в реальной работе спринты не особо помогают избавиться от бардака...
Техническая вишенка в заключение :)
Микросервисы должны умереть
=> Programming in Large: продолжение <=