Программист постоянно делает баги. Это считается нормальным.
Причем не только баги-описки, но баги в самой логике работы программы.
Зачастую оказывается, что используемая модель некорректна даже в теории, при этом на практике она может даже более-менее успешно работать за счет каких-нибудь хакерских методов.
А что если предположить, что баг не должно быть вообще? Почему человек не может думать без ошибок? В чем причина ошибок?
Мне кажется, основная причина в том, что разработка происходит стихийно, каждый пишет, что ему придет в голову.
1) Не формулируется математическая модель предметной области, не доказываются необходимые теоремы. Возможно не везде это требуется, но в нетривиальных случаях без этого не обойтись.
2) Не учитываются свойства системы, о которых надо помнить при проектировании каждой операции (например, это могут быть такие свойства, как безопасность, одновременный доступ к ресурсам, блокировки, какие-то инварианты предметной области)
3) Не осуществляется полный анализ всех возможных вариантов. Такой анализ вообще возможен только в случае, когда у нас есть нечто хотя бы напоминающее абстрактную* математическую модель, в противном случае количество вариантов будет слишком большим для такого анализа. Например, нужен анализ всех вариантов одновременных операций при доступе нескольких пользователей к иерархии ресурсов.
Есть ли какой-то способ проектирования, который бы позволил если не избавиться от ошибок, то хотя бы минимизировать их число?
Может ли существовать какой-то паттерн мышления, которому надо следовать, чтобы добиться этого?
Программирование — еще молодая область, возможно лет через сто появится нормальная методология разработки, которая позволит человеку не совершать ошибок...
HH> Программист постоянно делает баги. Это считается нормальным. HH> Причем не только баги-описки, но баги в самой логике работы программы. HH> Зачастую оказывается, что используемая модель некорректна даже в теории, при этом на практике она может даже более-менее успешно работать за счет каких-нибудь хакерских методов.
HH> А что если предположить, что баг не должно быть вообще? Почему человек не может думать без ошибок? В чем причина ошибок?
HH> Мне кажется, основная причина в том, что разработка происходит стихийно, каждый пишет, что ему придет в голову.
HH> 1) Не формулируется математическая модель предметной области, не доказываются необходимые теоремы. Возможно не везде это требуется, но в нетривиальных случаях без этого не обойтись. HH> 2) Не учитываются свойства системы, о которых надо помнить при проектировании каждой операции (например, это могут быть такие свойства, как безопасность, одновременный доступ к ресурсам, блокировки, какие-то инварианты предметной области) HH> 3) Не осуществляется полный анализ всех возможных вариантов. Такой анализ вообще возможен только в случае, когда у нас есть нечто хотя бы напоминающее абстрактную* математическую модель, в противном случае количество вариантов будет слишком большим для такого анализа. Например, нужен анализ всех вариантов одновременных операций при доступе нескольких пользователей к иерархии ресурсов.
HH> Есть ли какой-то способ проектирования, который бы позволил если не избавиться от ошибок, то хотя бы минимизировать их число? HH> Может ли существовать какой-то паттерн мышления, которому надо следовать, чтобы добиться этого?
HH> Программирование — еще молодая область, возможно лет через сто появится нормальная методология разработки, которая позволит человеку не совершать ошибок...
HH>*Под абстракцией понимается выделение существенного.
Солнца клонилось к закату, а старушки все падали, и падали из окон... а математики, все искали и искали серебряннную пулю...
Здравствуйте, HrorH, Вы писали:
HH> А что если предположить, что баг не должно быть вообще? Почему человек не может думать без ошибок? В чем причина ошибок?
HH> Мне кажется, основная причина в том, что разработка происходит стихийно, каждый пишет, что ему придет в голову.
Золотые слова. Работа программиста сравнима с работой инженера проектирующего самолет, но при этом обладает таким вреднейшим качеством, как кажущаяся легкость модификации уже сделанного. Вторая проблема программирования: обычно человек видит сразу решения каких-то частных областей, зависящих от его собственного склада ума. Кто-то сразу видит общую архитектуру, придавая крайне малое значение деталям реализации; кто-то видит реализацию отдельных частей алгоритма, упуская общую архитектуру. Начиная работать с программой, человек начинает с именно с областей наиболее близких ему, генерируя заплатки в тех местах, которые кажутся ему не столь важными. Во что это все выливается — все вы прекрасно знаете.
Сравните это с работой инженера, который вынужден прорабатывать все изначально, перед тем как готовые чертежи уйдут на заводы. Цена ошибки тут велика и может вылиться в миллионы рублей/долларов. По сути инженер в чертежах, схемах, диаграммах как раз строит этакую полную модель будущего изделия, которой так не хватает программистам.
Ошибка работы программиста тоже очень велика и тоже очень часто выливается в огромные убытки. Но из-за некой "виртуальности" или "несерьезности" его работы, кажущейся ему самому и его начальству, мало кто удосуживается достаточным проектированием будущей программы. Движимые принципом "лучше быстрее, чем качественнее" мы роняем наши "самолеты", пускаем под откос "поезда", но все это сходит нам с рук. А ведь программирование — это в меньшей мере искусство, и в большей — наука. Тенденций к исправлению тоже не видно. Печально.
HH> А что если предположить, что баг не должно быть вообще? Почему человек не может думать без ошибок? В чем причина ошибок?
В самом устройстве человека?
HH> Мне кажется, основная причина в том, что разработка происходит стихийно, каждый пишет, что ему придет в голову.
HH> 1) Не формулируется математическая модель предметной области, не доказываются необходимые теоремы. Возможно не везде это требуется, но в нетривиальных случаях без этого не обойтись. HH> 2) Не учитываются свойства системы, о которых надо помнить при проектировании каждой операции (например, это могут быть такие свойства, как безопасность, одновременный доступ к ресурсам, блокировки, какие-то инварианты предметной области) HH> 3) Не осуществляется полный анализ всех возможных вариантов. Такой анализ вообще возможен только в случае, когда у нас есть нечто хотя бы напоминающее абстрактную* математическую модель, в противном случае количество вариантов будет слишком большим для такого анализа. Например, нужен анализ всех вариантов одновременных операций при доступе нескольких пользователей к иерархии ресурсов.
Бюджет и сроки любого проекта ограничены, поэтому перебрать все варианты зачастую просто невозможно. Поэтому берется модель которая устраивает всех(почти) и реализуется
HH> Есть ли какой-то способ проектирования, который бы позволил если не избавиться от ошибок, то хотя бы минимизировать их число? HH> Может ли существовать какой-то паттерн мышления, которому надо следовать, чтобы добиться этого?
HH> Программирование — еще молодая область, возможно лет через сто появится нормальная методология разработки, которая позволит человеку не совершать ошибок...
Нет ни одной области человеческой деятельности где бы не было ошибок. Похоже это невозможно.
Над этой задачей работает много исследователей, и успехи тоже есть. Есть я зыки которые позволяют верифицировать определенные контракты.
К сожалению , очень часто на практике, трудностью является создание формального описания для решения задачи. Т.е. уже на этапе построения спецификации мы не можем избавиться от человеческих ошибок и плохой эфективности.
Зато в областях где каждая ошибка стоит очень дорого, применяются соответствующие интсрументы. Например верификация микросхем и т.п.
Спасибо за тему. Вопрос конечно стар как мир, что как бы намекает, но всё же.
Первое. Человеку свойственно ошибаться — смеритесь. Иногда какой-нибудь Фобос-Грунт будет падать и вывод здесь только один — то, что ошибка может случиться должно быть предусмотренно заранее. Где-то помнится проскальзывала история о том, как код на каком-то марсоходе дебажили удалённо, тобишь с Земли. Гениально! Так и надо.
Второе. Сложность задачи, которую может охватить человек, ограничена. Проше и дешевле (хотя, вследствии неграммотного руководства, невсегда) написать программу и посмотреть, что будет. Помните как Эдисон изобрёл лампочку — просто тупо пробовал все варианты. И знаете что — это сработало. Программировать — это не здание строить. Пробовать разные варианты здесь дёшево.
Третье. Мы всё ещё используем слишком низкоуровневые языки программирования. Чтобы вместить сложные задачи в голову человека, надо поднимать уровень абстракции. (Xотя сначало надо долго и нудно впихивать эти абстракции в голову самого человека. Начиная с "у меня было два яблока, одно отдал, сколько осталось?". А это я о чём? Правильно — об образовании). Иными словами надо улучшать инструменты, точнее использовать другие языки программирования. Будущее проблескивает где-то за декларативными языками программирования. Точнее к сожалению выразиться не могу. Так мне подсказывает моя программистская интуиция. Пока мои собственные попытки как-то собрать свои разрозненные мысли по субжекту терпят неудачу. Нахожусь в постоянной погоне за идеальной программой. Жду просветления.
Здравствуйте, HrorH, Вы писали:
HH> Есть ли какой-то способ проектирования, который бы позволил если не избавиться от ошибок, то хотя бы минимизировать их число? HH> Может ли существовать какой-то паттерн мышления, которому надо следовать, чтобы добиться этого?
Прочитайте Дисциплину программирования Эдсгера Дейкстры.
А после нее — Наука программирования Дэвида Гриса.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, HrorH, Вы писали:
HH> Программирование — еще молодая область, возможно лет через сто появится нормальная методология разработки, которая позволит человеку не совершать ошибок...
Дома строят уже сотни тысяч лет, а ошибки всё совершают и совершают.
Программы без ошибок появятся, когда появится искусственный интеллект.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, HrorH, Вы писали:
HH>> Программирование — еще молодая область, возможно лет через сто появится нормальная методология разработки, которая позволит человеку не совершать ошибок...
vsb>Дома строят уже сотни тысяч лет, а ошибки всё совершают и совершают.
vsb>Программы без ошибок появятся, когда появится искусственный интеллект.
ИИ не "появится", его создадут. И тоже с ошибками...
Здравствуйте, Artifact, Вы писали:
A>Здравствуйте, HrorH, Вы писали:
A>Спасибо за тему. Вопрос конечно стар как мир, что как бы намекает, но всё же.
Вам спасибо, что это кому-то интересно.
A>Первое. Человеку свойственно ошибаться — смеритесь. Иногда какой-нибудь Фобос-Грунт будет падать и вывод здесь только один — то, что ошибка может случиться должно быть предусмотренно заранее. Где-то помнится проскальзывала история о том, как код на каком-то марсоходе дебажили удалённо, тобишь с Земли. Гениально! Так и надо.
Попробуете доказать, что человеку свойственно ошибаться?
Если серьезно, то каждая ошибка всегда имеет конкретную причину, я попытался выявить список таких причин в первом посте.
A>Второе. Сложность задачи, которую может охватить человек, ограничена. Проше и дешевле (хотя, вследствии неграммотного руководства, невсегда) написать программу и посмотреть, что будет. Помните как Эдисон изобрёл лампочку — просто тупо пробовал все варианты. И знаете что — это сработало. Программировать — это не здание строить. Пробовать разные варианты здесь дёшево.
То, что сложность задачи, которую может охватить человек, ограничена, почему-то не так мешает в других областях. Тут уже писали про инженера.
Пробовать разные варианты, это хорошо в случае, когда надо, чтобы работал хотя бы один вариант. Программа должна работать для всех возможных вариантов использования.
A>Третье. Мы всё ещё используем слишком низкоуровневые языки программирования. Чтобы вместить сложные задачи в голову человека, надо поднимать уровень абстракции. (Xотя сначало надо долго и нудно впихивать эти абстракции в голову самого человека. Начиная с "у меня было два яблока, одно отдал, сколько осталось?". А это я о чём? Правильно — об образовании). Иными словами надо улучшать инструменты, точнее использовать другие языки программирования. Будущее проблескивает где-то за декларативными языками программирования. Точнее к сожалению выразиться не могу. Так мне подсказывает моя программистская интуиция. Пока мои собственные попытки как-то собрать свои разрозненные мысли по субжекту терпят неудачу. Нахожусь в постоянной погоне за идеальной программой. Жду просветления.
HH> Причем не только баги-описки, но баги в самой логике работы программы. HH> Зачастую оказывается, что используемая модель некорректна даже в теории, при этом на практике она может даже более-менее успешно работать за счет каких-нибудь хакерских методов.
Вообще-то как раз описки — дело пустяковое. А вот отсутствие самой теории, скорей закономерность.
HH> 1) Не формулируется математическая модель предметной области, не доказываются необходимые теоремы. Возможно не везде это требуется, но в нетривиальных случаях без этого не обойтись.
Сформулируйте математически предметную область бухгалтерского учета, управления бизнес-процессами, работы с клиентами.
Чтобы доказать теоремы.
HH> 2) Не учитываются свойства системы, о которых надо помнить при проектировании каждой операции (например, это могут быть такие свойства, как безопасность, одновременный доступ к ресурсам, блокировки, какие-то инварианты предметной области)
Сложно учесть то, что появляется ПОСЛЕ ввода системы в эксплуатацию.
Но даже до ввода — покажите затраты применимости проектирования каждой операции в обычном таком опердене.
HH> 3) Не осуществляется полный анализ всех возможных вариантов.
Как бы да. Математики наплодили всяких разговоров о P и NP. Нет чтобы на парочке A4 проанализировать все варианты.
HH>Такой анализ вообще возможен только в случае, когда у нас есть нечто хотя бы напоминающее абстрактную* математическую модель,
К ответу на п1:
А математики уже решили уравнения Навье-Стокса? Или задачу о трех(всего лишь!) телах?
HH> Есть ли какой-то способ проектирования, который бы позволил если не избавиться от ошибок, то хотя бы минимизировать их число?
У математиков точно нет. Математики вообще не занимаются проектированием.
Инженеры да, весьма часто прибегают к математике при проектировании. Но вот странно — почему-то есть хорошо спроектированные самолеты и мосты, а почему-то плохо. Может потому что в проектировании чего-либо немало от шаманства?
Чего уж говорить о выражении своих мыслей на формализованном языке программирования. Да, работающая программа обладает рядом свойств которые можно зафиксировать и количественно и качественно. Вот только тут как в китайской присказке — "На ковре с утками не найдешь иглы ее вышивавшей"
HH> Может ли существовать какой-то паттерн мышления, которому надо следовать, чтобы добиться этого?
Может.
Осталась малость — заставить программистов=людей мыслить по этому паттерну.
А вот тут проблемы озвучены уже наверное с 3 лет.
1. почему человек рассудив что правильно — поступает неправильно.
2. И почему человек не хозяин собственным мыслям.
HH> Программирование — еще молодая область, возможно лет через сто появится нормальная методология разработки, которая позволит человеку не совершать ошибок...
Программирование — в первую очередь прикладная область. А значит все в этой области:
1. отражение неразрешенных (а может и неразрешимых) проблем в чисто абстрактных дисциплинах — в первую очередь математике
2. влияние действительно мира, закономерности которого могут быть изучены неверно, или неизвестны.
HH>*Под абстракцией понимается выделение существенного.
... за счет отбрасывания несущественных деталей.
Покажите только безошибочную методику отделения существенного от несущественного и сразу счастья всем прибавится.
Здравствуйте, HrorH, Вы писали:
HH>То, что сложность задачи, которую может охватить человек, ограничена, почему-то не так мешает в других областях. Тут уже писали про инженера.
С чего Вы взяли, что не мешает? Те же инженеры, проектирующие самолеты, регулярно ошибаются. Причем эти ошибки бывают что доходят до производства и иногда приводят к гибели людей. А бывает, что становятся просто особенностями, слабостями самолета, с которыми обслуживающий персонал просто живет.
Здравствуйте, HrorH, Вы писали:
HH>Программа должна работать для всех возможных вариантов использования.
Позвольте не согласиться. Я считаю, что правильнее и надёжнее для каждого варианта писать отдельную программу.
Здравствуйте, HrorH, Вы писали:
A>>Первое. Человеку свойственно ошибаться — смеритесь. Иногда какой-нибудь Фобос-Грунт будет падать и вывод здесь только один — то, что ошибка может случиться должно быть предусмотренно заранее. Где-то помнится проскальзывала история о том, как код на каком-то марсоходе дебажили удалённо, тобишь с Земли. Гениально! Так и надо.
HH>Попробуете доказать, что человеку свойственно ошибаться?
Человеку свойственно переводить явления природы в систему символов (слова, цифры, команды языка программирования). Поскольку система символов — это лишь аппроксимация явлений окружающего мира, эта аппроксимация всегда выполняется с некоторыми неточностями. Отсюда вывод, что ошибки в рассуждениях, в моделировании, в процессе разработки — явление неизбежное, как следствие самой аппроксимации.
Когда программист пишет программу, он (как и любой другой специалист) проводит двойное преобразование: задание превращается в мыслительную модель, а эта модель уже воплощается в коде. И то и другое — суть преобразование из одних символов в другие, при этом на обоих этапах возможны ошибки.
HH>Если серьезно, то каждая ошибка всегда имеет конкретную причину, я попытался выявить список таких причин в первом посте.
Да, только эта причина устанавливается после проявления ошибки. Ошибки могут быть и в матмоделях, и в инвариантах, и во всём остальном. Притом больше того, у каждой ошибки есть не только причина, но ещё и имя с фамилией, и зачастую — не одно.
A>>Второе. Сложность задачи, которую может охватить человек, ограничена. Проше и дешевле (хотя, вследствии неграммотного руководства, невсегда) написать программу и посмотреть, что будет. Помните как Эдисон изобрёл лампочку — просто тупо пробовал все варианты. И знаете что — это сработало. Программировать — это не здание строить. Пробовать разные варианты здесь дёшево.
HH>То, что сложность задачи, которую может охватить человек, ограничена, почему-то не так мешает в других областях. Тут уже писали про инженера.
Мешает. Только в других областях перед "серийным производством" принято выписывать требования, тщательно верифицировать конструкторские решения и вообще всяко проверять друг друга. Это только в программировании принято уповать на "паттерны" чего бы то ни было — то на паттерны архитектур. то на паттерны мышления
HH>Пробовать разные варианты, это хорошо в случае, когда надо, чтобы работал хотя бы один вариант. Программа должна работать для всех возможных вариантов использования.
Программа и так всегда работает во всех вариантах использования. Просто в некоторых случаях её работа считается отклоняющейся от спецификации. А некоторые случаи считаются недопустимыми. Эту проблему, в принципе, могут помочь решить языки с автоматической проверкой корректности программы по отношению к формальной спецификации, Но ни один такой язык не защитит от ошибок в самой спецификации.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Skynin, Вы писали:
HH>> Причем не только баги-описки, но баги в самой логике работы программы. HH>> Зачастую оказывается, что используемая модель некорректна даже в теории, при этом на практике она может даже более-менее успешно работать за счет каких-нибудь хакерских методов. S>Вообще-то как раз описки — дело пустяковое. А вот отсутствие самой теории, скорей закономерность.
Согласен, причем закономерность печальная.
HH>> 1) Не формулируется математическая модель предметной области, не доказываются необходимые теоремы. Возможно не везде это требуется, но в нетривиальных случаях без этого не обойтись. S>Сформулируйте математически предметную область бухгалтерского учета, управления бизнес-процессами, работы с клиентами. S>Чтобы доказать теоремы.
При такой общей постановке технического задания не то что математическую модель, а даже самую кривую программу не написать.
Если же поставить конкретные задачи, то некоторые умные люди уже сейчас для многих из них смогут подобрать полезные модели.
HH>> 2) Не учитываются свойства системы, о которых надо помнить при проектировании каждой операции (например, это могут быть такие свойства, как безопасность, одновременный доступ к ресурсам, блокировки, какие-то инварианты предметной области) S>Сложно учесть то, что появляется ПОСЛЕ ввода системы в эксплуатацию. S>Но даже до ввода — покажите затраты применимости проектирования каждой операции в обычном таком опердене.
Наверно не покажу. Хотя бы потому, что не очень понимаю, что есть опердень. И что есть затраты применимости проектирования.
HH>> 3) Не осуществляется полный анализ всех возможных вариантов. S>Как бы да. Математики наплодили всяких разговоров о P и NP. Нет чтобы на парочке A4 проанализировать все варианты.
Я так понимаю, что эти разговоры не мешают рассмативать задачи с конечным числом вариантов, которые очень часто встречаются на практике.
В этом топике приводили ссылку на доказательтство корректности ядра операционной системы или чего-то такого.
HH>>Такой анализ вообще возможен только в случае, когда у нас есть нечто хотя бы напоминающее абстрактную* математическую модель, S>К ответу на п1: S>А математики уже решили уравнения Навье-Стокса? Или задачу о трех(всего лишь!) телах?
И что из этого следует? Что нельзя решить никакую задачу?
HH>> Есть ли какой-то способ проектирования, который бы позволил если не избавиться от ошибок, то хотя бы минимизировать их число? S>У математиков точно нет. Математики вообще не занимаются проектированием. S>Инженеры да, весьма часто прибегают к математике при проектировании. Но вот странно — почему-то есть хорошо спроектированные самолеты и мосты, а почему-то плохо. Может потому что в проектировании чего-либо немало от шаманства? S>Чего уж говорить о выражении своих мыслей на формализованном языке программирования. Да, работающая программа обладает рядом свойств которые можно зафиксировать и количественно и качественно. Вот только тут как в китайской присказке — "На ковре с утками не найдешь иглы ее вышивавшей"
HH>> Может ли существовать какой-то паттерн мышления, которому надо следовать, чтобы добиться этого? S>Может. S>Осталась малость — заставить программистов=людей мыслить по этому паттерну. S>А вот тут проблемы озвучены уже наверное с 3 лет. S>1. почему человек рассудив что правильно — поступает неправильно. S>2. И почему человек не хозяин собственным мыслям.
Философия — это хорошо, когда она на своем месте. "Доктор, я буду жить?" — "А смысл?"
HH>> Программирование — еще молодая область, возможно лет через сто появится нормальная методология разработки, которая позволит человеку не совершать ошибок... S>Программирование — в первую очередь прикладная область. А значит все в этой области: S>1. отражение неразрешенных (а может и неразрешимых) проблем в чисто абстрактных дисциплинах — в первую очередь математике S>2. влияние действительно мира, закономерности которого могут быть изучены неверно, или неизвестны.
Да, да. Программирование непознаваемо, закономерности действительного мира изучены неверно, все проблемы неразрешимы.
Может быть вернемся к практике, где вполне возможно просчитать и предусмотреть очень многие проблемы, и для этого не хватает только знаний и возможно, желания?
HH>>*Под абстракцией понимается выделение существенного. S>... за счет отбрасывания несущественных деталей. S>Покажите только безошибочную методику отделения существенного от несущественного и сразу счастья всем прибавится.
Не надо философии, в каждом случае требуется математическая модель, которая решает данные конкретные проблемы, а не все проблемы мира.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, HrorH, Вы писали:
HH>>Попробуете доказать, что человеку свойственно ошибаться?
ГВ>Человеку свойственно переводить явления природы в систему символов (слова, цифры, команды языка программирования). Поскольку система символов — это лишь аппроксимация явлений окружающего мира, эта аппроксимация всегда выполняется с некоторыми неточностями. Отсюда вывод, что ошибки в рассуждениях, в моделировании, в процессе разработки — явление неизбежное, как следствие самой аппроксимации.
ГВ>Когда программист пишет программу, он (как и любой другой специалист) проводит двойное преобразование: задание превращается в мыслительную модель, а эта модель уже воплощается в коде. И то и другое — суть преобразование из одних символов в другие, при этом на обоих этапах возможны ошибки.
Хорошо, давайте говорить только о том классе ошибок, которые можно отловить, создав математическую модель и т.д. Ошибки, которые для своего разрешения требуют йогических практик, впадения в нирвану, и непосредственного созерцания Божественной Истины, рассматривать не будем.
HH>>Если серьезно, то каждая ошибка всегда имеет конкретную причину, я попытался выявить список таких причин в первом посте.
ГВ>Да, только эта причина устанавливается после проявления ошибки. Ошибки могут быть и в матмоделях, и в инвариантах, и во всём остальном. Притом больше того, у каждой ошибки есть не только причина, но ещё и имя с фамилией, и зачастую — не одно.
Устанавливается причина после проявления ошибки, но поняв ее, можно попытаться больше не совершать таких ошибок. И ошибка не в фамилии, а в неверном алгоритме мышления.
HH>>То, что сложность задачи, которую может охватить человек, ограничена, почему-то не так мешает в других областях. Тут уже писали про инженера.
ГВ>Мешает. Только в других областях перед "серийным производством" принято выписывать требования, тщательно верифицировать конструкторские решения и вообще всяко проверять друг друга. Это только в программировании принято уповать на "паттерны" чего бы то ни было — то на паттерны архитектур. то на паттерны мышления
Блин, никто не умеет читать. Я написал "не так мешает". Все почему-то прочли "не мешает". Кстати об ошибках
Понятно, что паттерны мышления не всемогущи, но они могли бы помочь совершать меньше ошибок.
HH>>Пробовать разные варианты, это хорошо в случае, когда надо, чтобы работал хотя бы один вариант. Программа должна работать для всех возможных вариантов использования.
ГВ>Программа и так всегда работает во всех вариантах использования. Просто в некоторых случаях её работа считается отклоняющейся от спецификации. А некоторые случаи считаются недопустимыми. Эту проблему, в принципе, могут помочь решить языки с автоматической проверкой корректности программы по отношению к формальной спецификации, Но ни один такой язык не защитит от ошибок в самой спецификации.
Да, зато от этих ошибок, по-крайней мере от многих из них можно попытаться защититься другими способами (о которых я попытался написать в первом посте).
Здравствуйте, Artifact, Вы писали:
HH>>Программа должна работать для всех возможных вариантов использования. A>Позвольте не согласиться. Я считаю, что правильнее и надёжнее для каждого варианта писать отдельную программу.
А как же повторное использование кода?
Или это была шутка?
HH> Есть ли какой-то способ проектирования, который бы позволил если не избавиться от ошибок, то хотя бы минимизировать их число? HH> Может ли существовать какой-то паттерн мышления, которому надо следовать, чтобы добиться этого?
Ошибки появляются в следствии следующих причин:
1. "а это вообще должно было работать?"
2. неверная модель
3. забыты или нерассмотренны какие-то варианты поведения кода
4. опечатка
Ошибки первого рода возникают, когда программист даже не пытается обосновать и доказать правильность работы свое кода.
Ошибки второго рода провоцирует наше незнание, например, незнание — что требования к многопоточному коду отличаются от требований к однопоточному коду.
"Темные углы", они же вырожденные и частные случаи, и их нерасмотрение приводит к ошибкам третьего рода.
Опечатки заложены в природе человека, и даже так и называются — "человеческий фактор". Опечатки уменьшаются при концентрации всего внимания на одной задаче, но полностью от них избавиться не получается.
Для борьбы с этими ошибками есть стандартные рекомендации: пишите правильный код, много знайте, ничего не забывайте, и не теряйте концентрацию когда пишите код. Проблема этих рекомендаций: что они не говорят — а как это сделать?, и не говорят — а как убедиться: что правильности кода уже достаточно? что знаний о ситуации уже достаточно? что достаточно всего вспомнено? и что концентрации внимания тоже достаточно?
Стандартные рекомендации стоит подкрепить следующими привычками:
Предсказание. Основная привычка для защиты от ошибок: это привычка предсказывать поведение своего и чужого кода до запуска кода.
Всегда сначала пытаемся предсказать, как должен себя вести данный код: за сколько времени отработает, что выведет на экран, в каком порядке будут вызываться строки кода, какие будут промежуточные данные и т.д. (чем больше всяких предсказаний, тем лучше).
Потом код запускаем и проверяем свои предсказания, и если предсказанное не совпало с ожидаемым, то разбираемся почему наше представление не совпало с реальностью.
Полнота. Вторая привычка: предсказывать и рассматривать поведение на всем множестве внешних факторов, включая самые худшие сценарии (например, если читается файл определенный структуры, то каким будет поведение кода, если какие-то байты будут случайно изменены, или вообще, если файл сформирован "злоумышленником", который хочет наш код "завалить"?)
Здесь главное не надо бросаться в избыточность: явно фиксировать и обрабатывать в коде все возможные ошибки. достаточно, чтобы код вел себя адекватно: не портит данные, на ошибочную ситуацию формирует ошибку, не скрывает информацию по ошибке.
Разнообразие перепроверок. В большинстве случаев, нет гарантированного способа определить: достаточное или недостаточное кол-во предсказаний уже сделано, чтобы обеспечить правильность нашего представления?. Достаточно (или недостаточно) рассмотрено вариантов? Достаточно или недостаточно написано тестов? есть в коде опечатки или нет? и т.д. Здесь можно лишь рассчитывать на корреляцию, что чем больше разнообразных вариантов перепроверено, и не выявлено проблем, то тем больше вероятность, что наше представление и код правильный. Большинство действий по перепроверке рутинные и их можно переложить на компьютер: статическая типизация, регрессионное тестирование, проверка покрытие кода тестами, проверка, что у кода "хороший запах" и т.д.
Однородность кода. Если придерживаться предыдущих трех правил, то кол-во рассматриваемых вариантов растет лавинообразно по экспонециальному закону. Лавину можно минимизировать, если стараться писать однородный код.
возьмем два кода
for (uint i = items.Length - 1; i >= 0; --i)
{
var item = items[i];
//что-то делаем с item
}
и
foreach (var item in items.Reverse())
{
//что-то делаем с item
}
второй код более однородный, чем первый. в первом коде, для полноты необходимо рассматривать поведение i на границах: что надо написать, чтобы перебрать концевые элементы и при этом не выйти за границу массива: items.Length или items.Length — 1, и i >= 0 или i > 0; также необходимо проверить как себя ведет i "по ту сторону границы", и только вот здесь обнаружится ошибка..
второй код этого всего не имеет, потому что оно уже "спрятано" внутрь функции Reverse, и все эти варианты были рассмотрены при написании функции Reverse.
Привычки предсказывать и перепроверять предсказания уменьшает вероятность появление ошибок первого и второго рода. Привычка к однородному коду с перепроверкой уменьшает кол-во невыявленных опечаток. Привычка к полноте с перепроверкой уменьшает ошибки второго и третьего рода.
