978-5-4461-0772-8, 9780134494166
ISBN :Возрастное ограничение : 16
Дата обновления : 14.06.2023
В ходе исследований Дейкстра обнаружил, что в некоторых случаях использование инструкции goto мешает рекурсивному разложению модулей на все меньшие и меньшие единицы и тем самым препятствует применению принципа «разделяй и властвуй», что является необходимым условием для обоснованных доказательств.
Однако в других случаях инструкция goto не вызывала этой проблемы. Дейкстра заметил, что эти случаи «доброкачественного» использования goto соответствуют простым структурам выбора и управления итерациями, таким как if/then/else и do/while. Модули, использующие только такие управляющие структуры, можно было рекурсивно разложить на доказуемые единицы.
Дейкстра знал, что эти управляющие структуры в сочетании с последовательным выполнением занимают особое положение. Они были идентифицированы за два года до этого Бёмом и Якопини, доказавшими, что любую программу можно написать, используя всего три структуры: последовательность, выбор и итерации.
Это было важное открытие: управляющие структуры, делающие доказуемой правильность модуля, в точности совпадали с набором структур, минимально необходимым для написания любой программы. Так родилось структурное программирование.
Дейкстра показал, что доказать правильность последовательности инструкций можно простым перечислением. Методика заключалась в прослеживании последовательности математическим способом от входа до выхода. Она ничем не отличалась от обычного математического доказательства.
Правильность конструкций выбора Дейкстра доказывал через повторяющееся применение приема перечисления, когда прослеживанию подвергался каждый путь. Если оба пути в конечном итоге давали соответствующие математические результаты, их правильность считалась доказанной.
Итерации – несколько иной случай. Чтобы доказать правильность итерации, Дейкстре пришлось использовать индукцию. Он доказал методом перечисления правильность случая с единственной итерацией. Затем, опять же методом перечисления, доказал, что если случай для N итераций правильный, значит, правильным будет случай для N + 1 итераций. Используя тот же метод перечисления, он доказал правильность критериев начала и окончания итераций.
Такие доказательства были сложными и трудоемкими, но они были доказательствами. С их развитием идея создания евклидовой иерархии теорем выглядела достижимой в реальности.
Объявление вредным
В 1968 году Дейкстра написал редактору журнала CACM письмо под заголовком Go To Statement Considered Harmful («О вреде оператора Go To»)[10 - На самом деле Дейкстра озаглавил свое письмо A Case Against the Goto Statement («Дело против оператора goto»), но редактор CACM Никлаус Вирт изменил заголовок. – Примеч. пер.], которое было опубликовано в мартовском выпуске. В статье он обосновал свою позицию в отношении трех управляющих структур[11 - Перевод статьи на русский язык можно найти по адресу http://hosting.vspu.ac.ru/~chul/dijkstra/goto/goto.htm. – Примеч. пер.].
И мир программирования запылал. Тогда у нас не было Интернета, поэтому люди не могли публиковать злобные мемы на Дейкстру и затопить его недружественными сообщениями. Но они могли писать – и писали – письма редакторам многих популярных журналов.
Не все письма были корректными. Некоторые из них были резко отрицательными; другие выражали решительную поддержку. И эта битва продолжалась почти десять лет.
В конце концов спор утих по одной простой причине: Дейкстра победил. По мере развития языков программирования инструкция goto все больше сдавала свои позиции, пока, наконец, не исчезла. Большинство современных языков программирования не имеют инструкции goto, а некоторые, такие как LISP, никогда ее не имели.
В настоящее время все программисты используют парадигму структурного программирования, хотя и не всегда осознанно. Просто современные языки не дают возможности неограниченной прямой передачи управления.
Некоторые отмечают сходство инструкции break с меткой и исключений в Java с инструкцией goto
Конец ознакомительного фрагмента.
Текст предоставлен ООО «ЛитРес».
Прочитайте эту книгу целиком, купив полную легальную версию (https://www.litres.ru/robert-s-martin/chistaya-arhitektura-iskusstvo-razrabotki-program-39113892/?lfrom=174836202) на ЛитРес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.
notes
Примечания
1
Перевод Т. Гнедич. – Примеч. ред.
2
Фильм, вышедший в США в 1970 году, в нашей стране известный под названием «Колосс: Проект Форбина». – Примеч. пер.
3
«Луна жестко стелет», роман Роберта Хайнлайна. – Примеч. пер.
4
Фильм, вышедший в 1968 году, в нашей стране известный под названием «2001 год: Космическая одиссея». – Примеч. пер.
5
Именно «ее», потому что в те годы программистами были в основном женщины.
6
Роберт Мартин. Идеальный программист. Как стать профессионалом разработки ПО. СПб.: Питер, 2016. – Примеч. пер.
7
Роберт Мартин. Чистый код: создание, анализ и рефакторинг. СПб.: Питер, 2013. – Примеч. пер.
8
Роберт Мартин. Быстрая разработка программ. Принципы, примеры, практика. М.: Вильямс, 2004. – Примеч. пер.
9
Из речи, произнесенной в Северо-Западном университете в 1954 году.
10
На самом деле Дейкстра озаглавил свое письмо A Case Against the Goto Statement («Дело против оператора goto»), но редактор CACM Никлаус Вирт изменил заголовок. – Примеч. пер.
11
Перевод статьи на русский язык можно найти по адресу http://hosting.vspu.ac.ru/~chul/dijkstra/goto/goto.htm. – Примеч. пер.
Книга от профессионала своего дела, умудренного опытом, следующему поколению разработчиков.Если ты пишешь код, то прочтение книги однозначно сделает тебя лучше.Огорчает правда корявый стиль перевода - иногда читалось туговато именно из-за него.
Эта книга, как и большинство информации об архитектуры в программировании страдает от одних и тех же вещей. Книга похожа на подборку различных вещей связанных с архитектурой, есть главы про функциональное программирование, есть какой-то задел на DDD, ну и конечно же любимый всеми SOLID. Но, информация по всем темам подается очень куцо, без примеров кода и все основные мысли подаются лозунгами, создаётся ощущение что читаешь не цельную книгу, а какое-то краткое резюме на все эти темы. Если вы ещё не знакомы с литературой по архитектуре, то можете прочитать эту книгу, возможно узнаете про какие-то базовые концепции, но если вы ищете что-то продвинутое, с конкретными советами, то эта книга вам ничем не поможет
Главный недостаток книги — чрезмерная абстрактность и теоритизация. Большинство глав вообще без примеров, общими словами. А значит каждый поймет как захочет => прикладная ценность существенно снижается.И конечно фирменный отвратный перевод на русский. Вместо устоявшихся терминов "фича", "юзкейс" — особенность и случай использования. И т. п.Но есть и ряд положительных инсайтов:1. Хорошо показана идея направления зависимостей и изоляции между компонентами (всегда от низкоуровневых к высокоуровневым)
2. Показана роль архитектора, который должен найти этот баланс между идеальной изоляцией компонентов и простотой реализации. Для каждого конкретного случая.
3. Хорошо показано почему архитектурные границы системы не должны совпадать с инфраструктурными (отдельный микросервис != отдельный…
Книга мне "зашла" ( хотя поначалу она не совсем мне понравилась), и заставила пересмотреть некоторые подходы к текущим проектам. Главные мысль книги, по моему мнению:
- Отделяйте вашу бизнес-логику от технологий и деталей реализации.
- Архитектура должна представлять собой "чистые сущности", готовые к имплементации на любом языке, любом фреймворке,
- Проводите осознанные границы между компонентами системы.
- Помните, что архитектура пронизывает всю систему - начиная с конвенций по оформлению CSS стилей и заканчивая стратегиями облачного развертывания в мультизональном режиме. Низкоуровневые решения поддерживают высокоуровневые и наоборот.Наверное, эта книга в основном предназначена для архитекторов и тимлидов, но для обычных разработчиков она тоже будет полезна, ибо "Плох тот солдат,…
Это хорошая и мудрая книга. Про принципы SOLID, про уровни абстракции, про направление зависимостей. Слишком много ооп, впрочем чего еще ждать от книги, в которой столько java (на самом деле куда меньше java-кода, чем в "чистом коде"). Я ещё не строила большие приложения, но когда начну, перечитаю.
Отличная книга о проектировании архитектуры ПО. Автор не привязывается к какому-то конкретному подходу, а дает общие принципы, лежащие в основе успешной архитектуры. Обязательно к прочтению.
Лично для меня книга открыла глаза на то, как надо организовывать код, как не надо и почему. Теперь, когда я смотрю на свои проекты, я понимаю, почему код через некоторое время становится клубком, который все сложнее поддерживать, хотя всегда стараешься делать проще и понятнее. Просто удивительно, как часто нарушаются принципы проектирования даже опытными программистами, ведь эти принципы давно известны и доступны.По содержанию, кроме последней, автобиографической главы можно ставить 10. Но к изданию и переводу есть вопросы, например, понятие служба и сервис в книге используются как синонимы и порой странно видеть их одновременно в одном предложении. Возможно, стоит читать в оригинале.
Довольно очевидные вещи для опытных архитекторов, но всё так четко структурировано и разложено по полочкам, что прочитать было в удовольствие.
Отдельное спасибо автору за последнюю главу "Архитектурная археология" - полувековой срез архитектур программного обеспечения.
на мой взгляд уникальность книги в максимально общем ответе на вопрос “как должна выглядеть идеальная программная архитектура и какими характеристиками обладать?“. в принципе автор не даёт никаких новых прорывных истин по проектированию программных моделей, но умело компилирует общие принципы и старается показать общий, системный путь, то к чему нужно стремится, формулирует своеобразное универсальное шаблонное правило. мне не хватало этой системности и книга навела определённый порядок в куче общих представлений и принципов.
Все книги на сайте предоставены для ознакомления и защищены авторским правом