Почему программисты допускают ошибки?

[ezus]

Кажется "глупый" вопрос.

Но может быть он заинтересует кого-нибуть.
Может у кого-нибуть есть мысли на эту тему более серьезные чем "Все ошибаются, а мы что? Рыжие?"

Этот вопрос меня волнует уже давно.
Его анализ приводит к интересным выводам, проясняет историю программирования и сегодняшние ее проблемы. Но многое из того, что я собирал и делел возможно уже устарело, и я хотел бы освежить для себя эту тему, услышав мнение более молодых и продвинутых программистов.

Заранее благодарен тем, кто серьезно отнесется к такому "несерьезному" вопросу.

[RXL]

Человек - не машина. Ошибаться - его право и обязанность. Чтобы потом изучить и исправить свои ошибки и не повторять их.

ezus, а в чем суть исследования? Можно ознакомиться с деталями?

[x77]

зависит от того, что считать ошибкой в контексте программирования.

[Dimka]

ezus, программисты ли их допускают?

[x77]

Dimka, программист совершает только одну ошибку в своей жизни - когда решает заниматься программированием

[ezus]

Dimka, программист совершает только одну ошибку в своей жизни - когда решает заниматься программированием

Это кому как - я свою жизнь ошибкой не считаю. Более того - больше 30 лет я занимался в рабочее время своим хобби.

зависит от того, что считать ошибкой в контексте программирования.

Действительно, уровней ошибок много, но в данном контексте я имею ввиду ошибки именно программиста, т.е. у него получилось не то, что он хочет.

Человек - не машина. Ошибаться - его право и обязанность. Чтобы потом изучить и исправить свои ошибки и не повторять их.

И это правильно. Но все-таки лучше ошибок не совершать.

ezus, а в чем суть исследования? Можно ознакомиться с деталями?

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

Размышления на эту тему привели к созданию коллекции моделей "Что такое программирование".

Кратко:
3 группы моделей:

1. Общие модели, например,
       - мотивационная - почему люди занимаются программированием
       - психологическая - почему программисты допускают ошибки
       - структурно-аналитическая
       - целевая
       - инструментальная
       - языковая
       - и др.

2. Что такое программа
       - определение программы
       - соотношение статики и динамики в программе
       - типы модулей и их связей
       - и др.

3. Декомпозиционные модели
       - стратегии и тактики декомпозиции
       - системно-декомпозиционные модели
       - функционально-декомпозиционные модели
       - структурно-декомпозиционные модели

Я более 10 лет не имел возможности к ней возвращаться, естесственно она в ряде моделей устарела. Вот мне и захотелось обновить эту коллекцию с современных позиций.

[x77]

- психологическая - почему программисты допускают ошибки

- предполагается, что ошибка программиста можеть иметь только психологические причины?

[PooH]

Что значит - допустить ошибку? Значит составить неправильную программу.
А почему составляются неправильные программы? Потому что не хватает опыта или знаний.
Если программа составлена (и выполняется), то на она уже что-то делает. Необходимо определить условия "неправильности", если таковое определено, то необходимо искать причину и в разных случаях она будет разной: незнание предметной области, незнание инструмента (языка программирования), неверный алгоримт (опыт?) ну и лень =), возможно что-то еще.

[ezus]

- предполагается, что ошибка программиста можеть иметь только психологические причины?

Конечно, Нет.
В предыдущем посте очень хорошр перечислили другие причины ошибок. Но что показательно, психологических - там нет.

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

[ezus]

To PooH:
А разве программисты знающие предметную область, хорошо владеющие инструментом, реализующие известный проверенный алгоримт не допускают ошибок?
А если ДА, то причина только Лень?

[ezus]

Почему то никого не удивляет, что человек ограничен физически. Он не может поднять 500 килограмм, прыгнуть на 20 метров, бегать со скоростью звука.
Но интеллектуально он тоже ограничен, и именно эти ограничения меня интересуют в первую очередь.

[x77]

ezus, некоторые системы в результате многолетней доработки разными программистами в итоге выходят за грань человеческой понимания но это больше говорит о неправильном административном подходе к разработке, а не об интеллектуальных ограничениях человека. если человек может представить себе конечную систему - как правило, он сможет её написать.

[ezus]

x77:
Но этим Вы только подтверждаете мои подозрения\утверждения.
Разве эти доработанные системы не являются конечными?

И зачем этот "административный подход"?
Разве без него нельзя обойтись?

И если нельзя, то какими параметрами и свойствами он должен обладать? На какие идеи и платформы он должен опираться?

Что-то же должно лежать в основе этих "административных методов".
Вот это ЧТО-ТО меня и интересует.

[x77]

ezus, под административными методами я понимаю регламент разработки. чем больше людей участвует в проекте, тем более жёстким он должен быть. регалмнет описывает общую методику процесса разработки (постановку задачи, формирование требовний, составление ТЗ, требования к проектной документации, декомпозиция задачи, составление плана разработки и графика вввода в эксплуатацию). в зависимости от используемых методологий (экстремальное программирование, например) может быть очень и очень разным. в больших компаниях регламентируется всё, вплоть до правил наименования переменных, функций, объектов и пр.

в конечном итоге рождается некий документ, который можно дать в зубы студенту и посадить его за код. этот подход оправдан в больших коолективах, если регламента разработки нет - в большинстве случаев система сдыхает через 5-7 лет (в какой-то момент оказывается, что легче/быстрее/дешевле переписать её нах, чем разбираться в многолетних наслоениях чужого говнокода).

но это не ограничение ума, имхо. это именно неправильная методика разработки.

[ezus]

x77:
Зачем графики мне понятно - это борьба с ленью и разгельдяйством.
А вот зачем регламентировать имена?

Разве маленькую программу нельзя написать правильно без всяких этих ограничений?
Я думаю можно.
А большую систему? Тоже правильно - НЕЛЬЗЯ.

Вопрос 1 - ПОЧЕМУ?
Вопрос 2 - Где эта граница между маленьким и большим?

[Sla]

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

Неверное применение синтаксиса и  семантики языка. В основном эта ошибка проявляется на этапе проектирования.

Отсутствие плана. Ошибка проявляется от "недостатка времени", нехватки знаний, и т.д.

Ошибки в программном комплексе, допущенные при разработке и не обнаруженные при его тестировании

Ошибки, возникающие при вводе в компьютер неверных данных

Как бороться с ошибками?
ПО должно проходить тестирование как при вводе данных, так и при их обработке.

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

Это все так навскидку, без серьезного обоснования.



Или, например, и в шутку и всерьёз Законы Мерфи для программитсов

[Антон (LogRus)]

ezus, я не думаю, что комьюнити в паре постов, напишет трактат об управлении проектами и средствах защиты от ошибок.
почему вы не предлагаете своё виденье в полном объёме судя по всему на создание собственного мнения на этот счёт вы потратили много времени, мы его обсудили.

моё ИМХО

1. усталость
2. лень
3. отсутствие опыта
4. непонимание предметной области
5. не соблюдение технологий
6. не согласованность подразделений
7. много объясняет фраза "Нельзя объять баобаб."

ошибки проектирования мы не рассматриваем, т.к. формально эту ошибку совершил не программист

ошибки это побочный продукт программирования, когда программист пишет код, он кодирует ошибки, это естественно.

что же касается вашего, ЧТО-ТО
то обычно
1. это стремление, к максимально чёткому описанию процесса до кодирования.
2. стремление максимально сблизить во времени момент кодирования и момент обнаружения.

разные проекты и разные подходы, но обычно 1 или 2

http://feedproxy.google.com/~r/happy-pm/~3/VTiEPFqa7no/
http://ru.wikipedia.org/wiki/Agile

[ezus]

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

Уточню:
Зачем были придуманы функции? Без них прекрасно обходились на заре программирования.
Почему отказались от чудесного оператора GOTO? Ведь он лежит в основе фон Неймановской машины, принципы которой используются до сих пор?

Зачем было придумано ООП - известные и популярный термин?
Зачем еще до ООП придумали структурное программирование - термин, который уже неизвестен многим молодым программистам?

Ведь без всего этого обходились.
Значит были какие-то объективные причины создания всего этого и многого другого.

[ezus]

LogRus:

почему вы не предлагаете своё виденье в полном объёме судя по всему на создание собственного мнения на этот счёт вы потратили много времени, мы его обсудили.

Я не хотел вываливать свои размышления, чтобы не навязывать сразу свое мнение в надеждена то, что кто-нибуть задумывался над близкими вопросами. У меня не было цели публиковать свои мысли. Я больше хотел послушать других. Но похоже тема очень узкая и мне придется начать самому.

[ezus]

Кратко о Мотивационной модели.

Почему люди занимаются программированием?

Существует 3 группы:
1. Профессионалы - для которых программирование это хлеб
2. Пользователи - для которых программирование это инструмент
3. Любители - для них программирование это хобби.

В этой модели есть ряд интересных на мой взгляд выводов, но остановлюсь только на одном.

Почему программирование может быть хобби? Ведь не любая профессия обладает таким свойством.

Программирование может быть хобби, потому что на первом этапе его освоения оно кажется простым, напоминает детский конструктор, обладает восхитительным свойством "отсутствие существенных последствий допущеных ошибок". Потери - только личное время - ни деньги, ни материалы, ничего кроме личного времени.

И складывается впечатление, что я все могу. Могу написать программу, могу большую программу, а могу и любую систему. Т.е. если я знаю, как записать на языке то, что я хочу, значит я программист.

Это следствие Ложной Простоты Программирования.

Не каждый, кто умеет писать, - писатель.

Так в чем Сложность? Этому посвящена Психологическая модель.

[Алексей++]

Делаю ошибки (ммм, совершаю то есть) потому, что невнимательный Зная это, делаю всяческие на первый взгляд тупые проверки в дебаге, а иногда и в релизе (например, что переменная после цикла равна именно тому, чему должна быть равна)

[Oldy]

На мой взгляд в Мотивационную модель можно добавить четвертый пункт - студенты.

[ezus]

На мой взгляд в Мотивационную модель можно добавить четвертый пункт - студенты.

Спасибо принято.

Делаю ошибки (ммм, совершаю то есть) потому, что невнимательный Зная это, делаю всяческие на первый взгляд тупые проверки в дебаге, а иногда и в релизе (например, что переменная после цикла равна именно тому, чему должна быть равна)

Может быть невнимательность - это объективное свойство человеческого поведения, и его необходимо учитывать при разработке языков и методик программирования?
Спасибо, включим невнимательность в психологическую модель.

[Вахмурка]

Почему программирование может быть хобби? Ведь не любая профессия обладает таким свойством.

Программирование может быть хобби, потому что на первом этапе его освоения оно кажется простым, напоминает детский конструктор, обладает восхитительным свойством "отсутствие существенных последствий допущеных ошибок". Потери - только личное время - ни деньги, ни материалы, ничего кроме личного времени.

И складывается впечатление, что я все могу. Могу написать программу, могу большую программу, а могу и любую систему. Т.е. если я знаю, как записать на языке то, что я хочу, значит я программист.

Не каждый, кто умеет писать, - писатель.

Так в чем Сложность? Этому посвящена Психологическая модель.

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

Кратко о Мотивационной модели.



Это следствие Ложной Простоты Программирования.


Так может считать только тот кто "слышал" про программирование"  

[Dimka]

Dimka, программист совершает только одну ошибку в своей жизни - когда решает заниматься программированием

Когда он так решает, он ещё не программист Так что вопрос у меня правильный

у него получилось не то, что он хочет

Лень, невнимательность, дефицит времени, самоуверенность при недостатке опыта.

А почему составляются неправильные программы? Потому что не хватает опыта или знаний.

И не всегда это относится к программисту

Разве маленькую программу нельзя написать правильно без всяких этих ограничений?
Я думаю можно.
А большую систему? Тоже правильно - НЕЛЬЗЯ.

Вопрос 1 - ПОЧЕМУ?
Вопрос 2 - Где эта граница между маленьким и большим?

2) Нет такой границы.
1) А почему "нельзя" - это правильный ответ? Чисто эмпирически?

[ezus]

Кратко:
ПСИХОЛОГИЧЕСКАЯ МОДЕЛЬ
Все известен афоризм:
-   "не ошибается тот, кто ничего не делает"

У программистов свои афоризмы:
-   "в любой программе есть ошибки"
-   "невозможно написать программу без ошибок"
-   "любая последняя найденная в программе ошибка на самом деле является предпоследней"

Но если первый афоризм носит снисходительный, прощательный оттенок, то других - утвердительный, обосновательный и даже гордый.

 Почему? Чем можно объяснить этот феномен ошибки?
Существуют объективные причины, связанные с ограничениями возможностей человеческого мозга.

Например:
•   Святое Число 7. Установлено, что человек в состоянии контролировать не более 7 независимых процесса одновременно
•   Число 6. Человек может одним взглядом без подсчета определять количество предметов до 6. Если их больше, то он или пересчитывает их, или разбивает в уме на маленькие группы, а затем складывает.

Т.е. существует объективный предел возможностей человеческого мозга.

Интересно соотношение понятий трудно и сложно.

Борьба двух полушарий - конкретного и абстрактного

В рамках данной модели рассматриваются 3 фактора:
-   проблема сложности
-   проклятье одномерности
-   феномен тривиальности

1. Проблема сложности
1) С т.з. человека:
-   - интелектуальная сложность
-   эмоциональная сложность

2) С т.з. цели:
Сложность задачи определяется стоящей перед человеком целью, накладываемыми ограничениями и критериями.

3) С т.з. неопределенности
- чем > неопределенность поставленной цели, задачи, входных и выходных параметров окружения (среды)
тем > сложно достижение поставленной цели, решение задачи

4) С т.з. главной стороны сложности - размерности
Основной принцип борьбы с этой разновидностью сложности
- РАЗДЕЛЯЙ и ВЛАСТВУЙ
Здесь помогают  декомпозиция, понятие системы

Возникает новая проблема - КАК разбивать
Соотношение сложностей отдельных модулей и суммарной сложности связей.

  2. Проклятье одномерности
Противоречие между многоплановостью, многомерностью реального мира и одномерностью нашего мышления.
1. Структурная одномерность:
-   одномерность нашего сознания вступает в противоречие с многомерностью окружающего мира, объектов, задачю
-   мало того, что мы осознать не можем, так мы должны еще  проебразовывать все это в линейный текст программы   именно поэтому так тяжело даются нам эти циклы, условия - особенно goto
   
   Средства борьбы:
1) переход к глазам (планарность) => использование графических средств изображения

2) спрятать параллельность, перейти к более общим понятиям -инвариантам, которые скрывали все эти взаимосвязи, найти новые языковые конструкции, более простые  (физики - матрицы)
в программировании:
- не условный переход, а условный оператор
- не множество переменных, а массив,
- вложенные структуры - иерархия инвариантов

2. Динамическая дискретность
- свойство мозга фиксировать состояние объекта для осмысления, а объект уходит вперед, изменяется
- необходимо ввести динамические инварианты

3. Феномен тривиальности
Все знают: что - зеленый свет
         - здоровье
         - необходимо писать комментарии
         - необходимо разбивать на блоки, модули
Очевидно, это свойство человеческой психики - не воспринимать тривиальное, простое как руководство к действию


ГЛАВНЫЕ ВЫВОДЫ:
- программирование - это не просто
 - необходимы спец. средства борьбы с этой сложностью
а) декомпозиция
в) иерархия
г) упрощение
д) конкретизация
е) специальные изобразительные средства
и тд. и тп.

Прошу прошение за сумбур и краткость, если кого-нибудь заинтересует, то можно развить

[Dimka]

ezus, я думаю, что всё описанное проистекает из одного корня, нужно только этот корень явным образом обозначить. То, что я говорю - это метод управления сложностью, называемый абстрагированием; только это не "разделяй и властвуй", а как раз "объединяй и властвуй". В иных сферах на эту тему есть поговорка: "Если не можешь противиться процессу, возглавь его."

одномерность нашего сознания вступает в противоречие с многомерностью окружающего мира, объектов, задачю

Не согласен. Ты за одномерность сознания на самом деле выдаёшь последовательность (или длительность во времени) мышления. А это несколько разные вещи. Именно в качестве длительности во времени процесс мышления в мозгу и процесс вычисления на машине считаются подобными. Но проблема в том, что о мышлении мы многого не знаем, и протяжённость мысли во времени, возможно, лишь иллюзия или привычка, наиболее часто используемый приём, обусловленный речью (которая, в свою очередь, безусловно протяжённа во времени). А про внеречевое мышление: ассоциативная память, образное мышление и т.п. - такого сказать нельзя, они будто бы не имеют протяжённости, их работа описывается словечком insight (озарение).

спрятать параллельность, перейти к более общим понятиям -инвариантам

См. автоматное программирование. У нас в стране им занимается профессор Шалыто. Любая программа описывается как автомат, множество состояний и переходов. При этом процесса как такового нет, автомат концентрирует внимание лишь на узловых точках - там, где осуществляется управление процессом, а собственно процесс (последовательности действий) прячется в активностях внутри состояний и переходов. С этой точки зрения граф состояний и переходов как раз и является как бы взглядом "сверху" на весь процесс целиком, без отслеживания последовательных сценариев развития событий; ну а заодно (благодаря этому всеохватному взгляду) и прикладной инструмент проектирования процессов любой сложности (хотя и в этом случае возможны ситуации, когда требуется декомпозиция состояний на подсистемы).

свойство мозга фиксировать состояние объекта для осмысления, а объект уходит вперед, изменяется

Если объектом сделать процесс, то сам метод мышления через осмысление состояний оказывается инвариантным.

[ezus]

То, что я говорю - это метод управления сложностью, называемый абстрагированием; только это не "разделяй и властвуй", а как раз "объединяй и властвуй". В иных сферах на эту тему есть поговорка: "Если не можешь противиться процессу, возглавь его."

Ну, что же, спасибо, еще один метод.
Только не понятно, почему вы против "разделяй и властвуй". Все-таки именно этот тезис лежит в основе декомпозиции.
Просто получается, что "разделяй и властвуй" - это "методологическое" основание подходов сверху-вниз, а "объединяй и властвуй" - подходов снизу-вверх.
Красиво.

Не согласен. Ты за одномерность сознания на самом деле выдаёшь последовательность (или длительность во времени) мышления...

Тут много из проблемы лингвистики.
Давайте разделим сознание и подсознание. Подсознание - это интуиция, ассоциативное мышление, и оно действительно многомерно во времени. А сознание на вербальном уровне оно принципиально линейно, т.к. в его основе одномерный язык. Мы не можем сознательно (если не нравится термин, то предложите, пожалуйста, что-нибудь другое, с радостью приму) думать несколько мыслей сразу. Например оператор IF - было бы прекрасно, если бы мы могли одновременно рассматривать и блок THEN, и блок  ELSE. К сожалению мы делаем это последовательно, сначала одно - потом другое. И при больших размерах этих блоков мы теряем над ними контроль.
Именно борьба с этой одномерностью породила блок-схемы, они хотя бы двумерны. Без них, я думаю, вообще программирование в кода или потом на ассемблере было бы невозможно.
 
 

[ezus]

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

Вот эта сложность меня и интересует. В чем ее суть, какая она бывает, и как с ней бороться

[ezus]

Dimka:
Еще несколько слов.
Во второй группе моделей рассматривается соотношение статики и динамики в программировании, что имеет непосредственное отношение к динамической одномерности нашего мышления.
Статика проявляется в структуре программы и особенно данных, а динамика в алгоритме. Есть одно из золотых правил программирования - соотношение сложности структуры данных и сложности алгоритма: уменьшение одного приводит к увеличении сложности другого.
Так вот из осознания динамической одномерности нашего мышления вытекает совет: упрощай алгоритм путем усложнения структуры данных.