Технология устранения ошибок в программе

← →
Grol © (2006-02-26 00:52) [0]

Мне необходимо знать как можно устранить ошибку в прогамме, т.е. наверняка есть какая-то схема(правила) устранения ошибок. Потом с помощью чего лучше отслеживать ошибку? Что делать, если не знаешь ассемблер, потому что как я понимаю надо будет работать с регистрами процессора? Ну и вообще, если есть ошибка в программе, с чего надо начинать ее устранение? Спасибо заранее за ответы...

← →
Eraser © (2006-02-26 01:03) [1]

http://delphimaster.net/view/1-1140902492/
см. 5 пост.

← →
Desdechado © (2006-02-26 16:44) [2]

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

← →
Сергей М. © (2006-02-26 16:50) [3]

> есть какая-то схема(правила) устранения ошибо

Нет такой схемы.

> с помощью чего лучше отслеживать ошибку?

С помощью встроенного в Делфи-среду отладчика.

> Что делать, если не знаешь ассемблер

"Выучить" его.

> если есть ошибка в программе, с чего надо начинать ее устранение?

С детального анализа тек, извещающего тебя об оной.

← →
Anatoly Podgoretsky © (2006-02-26 19:08) [4]

Глаза и то, на чем они находятся.

← →
Grol © (2006-02-26 19:24) [5]

Все понятно...буду читать книжки :)

← →
Джо © (2006-02-26 19:28) [6]

> [4] Anatoly Podgoretsky © (26.02.06 19:08)
> Глаза и то, на чем они находятся.

Тут скорее "в", чем "на". Иначе паталогия или членовредительство :)
---

> Grol © (26.02.06 00:52)
> Мне необходимо знать как можно устранить ошибку в прогамме,
> т.е. наверняка есть какая-то схема(правила) устранения
> ошибок.

Есть различные методики, сводятся, в большинстве, к тому, чтобы изначально писать код, содержащий минимальное количество ошибок. Также, при написании предусматривать постоянное тестирование. Ведение протоколов работы (логов). Ну, а если уже ничего этого заранее предусмотрено не было — то тогда уж по старинке. Головой, глазами и клавишами F7/F8 в комбинации с контрольными точками (break points) :^)

← →
Anatoly Podgoretsky © (2006-02-26 19:35) [7]

Джо © (26.02.06 19:28) [6]
Правильная - не писать код с ошибка (речь не про очепятки). Ну нет времени на поиск и устранение ошибок.

← →
Джо © (2006-02-26 19:43) [8]

> [7] Anatoly Podgoretsky © (26.02.06 19:35)

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

← →
Anatoly Podgoretsky © (2006-02-26 19:50) [9]

Джо © (26.02.06 19:43) [8]
Мне известна - ГОЛОВА
Не сто процентно, некачественный инструмент однако, но можно свести почти к нулю.

← →
Anatoly Podgoretsky © (2006-02-26 19:50) [10]

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

← →
Джо © (2006-02-26 19:53) [11]

> [9] Anatoly Podgoretsky © (26.02.06 19:50)
> Джо © (26.02.06 19:43) [8]
> Мне известна - ГОЛОВА
> Не сто процентно, некачественный инструмент однако, но можно
> свести почти к нулю.

Ну, вот я и о том же. Стопроцентной гарантии нет (и не может быть, ибо человеку СВОЙСТВЕННО ошибаться, с этим ничего не поделаешь). А вот добиться минимизации ошибок вполне реально. Разумеется, при отсутствии головы ничего не поделаешь, но речь, надеюсь, не об этом? ;)

← →
Anatoly Podgoretsky © (2006-02-26 19:57) [12]

Адназначна не об этом

← →
Джо © (2006-02-26 20:04) [13]

> [10] Anatoly Podgoretsky © (26.02.06 19:50)
> Ошибки проектирования к программистам не относятся, я говорил
> только про программирование.

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

Некоторые программисты могут заявить, что проектирование не связано с конструированием, но при работе над небольшими проектами конструирование часто включает другие процессы, в том числе проектирование. В некоторых более крупных проектах формальная архитектура может давать ответы только на вопросы системного уровня, при этом значительная часть проектирования может быть намеренно оставлена на этап конструирования. В других крупных проектах проектирование может быть проведено в таком объеме, что кодирование становится почти механическим, однако это случается редко — официально или нет, программисты обычно сами проектируют некоторые фрагменты программ.
С. Макконнелл. Совершенный код. (из главы Проектирование при конструировании).

← →
Anatoly Podgoretsky © (2006-02-26 20:08) [14]

Джо © (26.02.06 20:04) [13]
Недостатки конкретных проектировщиков ситуации не меняют. Я видел хороших проектировщиков, где даже имена струтурур и полей были в проекте, оставалось только посадить индуса и получить программу. Не зря же программирование является иммигрантской профессией, наряду с таксистами.

← →
GEN++ © (2006-02-26 20:11) [15]

Есть "золотые правила" написания программ:

1: выигрываем в объме памяти - проигрываем в быстородействии
и наоборот

2: каждая последняя ошибка в программе, на самом деле -
предпоследняя.

Наверное есть и еще.

← →
Marser © (2006-02-26 20:16) [16]

> Наверное есть и еще.

3. Програама, в которой совсем нет ошибок, никому не нужна.

← →
homm © (2006-02-26 20:18) [17]

> 1: выигрываем в объме памяти - проигрываем в быстородействии
> и наоборот
В ощем случа чуш полная. Гдето конкретно, иногда - да.

← →
Marser © (2006-02-26 20:23) [18]

> [17] homm © (26.02.06 20:18)
>
> > 1: выигрываем в объме памяти - проигрываем в быстородействии
> > и наоборот
> В ощем случа чуш полная. Гдето конкретно, иногда - да.

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

З.Ы. Слово "чуш" пишется с мягким знаком - "чушь", а "гдето" - через дефис, "где-то". Стыдно должно быть, носитель "великого и могучего", я ведь иностранец и даже инородец :-)

← →
homm © (2006-02-26 20:29) [19]

> выигрывая по одному критерию, мы наверняка проигрываем с
> другим
А потом находим *верный* алгоритм, и выигрываем по обоим показателям на порядок. Очень часто так и получается.

> Стыдно должно быть, носитель "великого и могучего", я ведь
> иностранец и даже инородец :-)
Слово "инородец" меня поставило в тупик. Что это? Это не заразно? :)

← →
Marser © (2006-02-26 20:41) [20]

> [19] homm © (26.02.06 20:29)
>
> > выигрывая по одному критерию, мы наверняка проигрываем
> с
> > другим
> А потом находим *верный* алгоритм, и выигрываем по обоим
> показателям на порядок. Очень часто так и получается.

В практике нет понятия "верного" алгоритма, есть понятие оптимального. И вот эти оптимальные алгоритмы дают выигрыш или в скорости или в памяти. Совместить эффективность быстрых и ресурсоэкономных алгоритмов получается очень редко.
К примеру, тебе вряд ли удастся подсчитть натуральный логарифм числа быстрее, чем другой алгоритм выберет его из имеющейся в памяти таблицы. Эта таблица занимает много места в памяти, но если скорость критична(а это далеко не всегда гигагерцы, например, в однокристальных МП), то лучше использовать именно её. Опять-таки, если критичны требования к памяти, то лучше вычислять.
По этому критерию нередко отказываются от микропроцессоров в пользу ПЛИС или микросхем ПЗУ - они работают намного быстрее с рядом сохраненных значений, чем МП.

← →
Sergey Masloff (2006-02-26 20:56) [21]

Marser © (26.02.06 20:41) [20]
>В практике нет понятия "верного" алгоритма,
Есть. Другое назвыание "корректный". Сейчас лень смотреть но кажется в переводе Кнута термин встречается.

Одним словом алгоритм который за конечное число шагов позволяет вычислить правильный результат. А то ведь алгоритм может быть очень эффективным а ответы давать неверные ;-)

← →
Marser © (2006-02-26 21:01) [22]

> [21] Sergey Masloff (26.02.06 20:56)

Корректный, согласен. Но корректный опять-таки может не соответствовать части критериев. То самое количество шагов может стремиться к бесконечности, даже при верной работе алгоритма.
Тонкая это штука, инженерное дело :-)

← →
Knight © (2006-02-26 21:09) [23]

Есть такая небольшая книжечка... называется
"Программное обеспечение без ошибок" автор Роберт Лоренс Бейбер.
Приёмы и секреты создания правильных программ.

← →
SKIPtr (2006-02-26 21:14) [24]

А мне отладчик Делфи не нравиться в паскале все было проще. Я ставлю Tlabel и записываю туда результаты очередного действия

> [21] Sergey Masloff (26.02.06 20:56)
> Одним словом алгоритм который за конечное число шагов позволяет
> вычислить правильный результат. А то ведь алгоритм может
> быть очень эффективным а ответы давать неверные ;-)

Это мне напомнило историю, вычитанную у Макконнелла:

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

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

Далее он должен был убедить в этом участников проекта. Они выслушали его, и когда он закончил, создатель старой системы спросил:
— И как быстро выполняется ваша программа?
— Ну, в среднем она обрабатывает каждый набор введенных данных примерно за 10 секунд.
— Ага! Но моей программе для этого требуется только 1 секунда.

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

:)

Механизм перехвата ошибок в принципе показан в JCL (http://jvcl.sourceforge.net/daily/) модифицируй его под вывод логов - будет тебе инструмент...

Marser © (26.02.06 20:23) [18]
Обычно где-то есть минимум памяти+процессора. Вопрос в том, что где-то лучше пожертвовать или одним во имя другого, от задачи зависит.

ЗЫ. Я б украинский тоже не смог исковеркать, не родной язык, правил коверканья не знаю :)))))

> [27] Petr V. Abramov © (26.02.06 21:33)

Я о том же.

> ЗЫ. Я б украинский тоже не смог исковеркать, не родной язык,
> правил коверканья не знаю :)))))

Гы, ты думаешь, я русский - свой второй родной язык, не смогу исковеркать?

> [29] Petr V. Abramov © (26.02.06 21:44)
> Marser © (26.02.06 21:36) [28]
> вот на такой значек внимание обрати: :)))))

Я тоже забыл - :-))

> Джо © (26.02.06 19:28) [6]

> Anatoly Podgoretsky © (26.02.06 19:50) [9]
>
> Джо © (26.02.06 19:43) [8]
> Мне известна - ГОЛОВА

Очень интересная дискуссия! Но никто не обратил свой юмор на то, что "голова" = "череп" = кость! :)))

Grol © (26.02.06 19:24) [5]
> Все понятно...буду читать книжки :)

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

Исспользуй Dunit для автоматизации тестирования твоего кода. Очень помогает минимизировать ошибки особенно при каких либо изменинеиях в уже отлаженном коде :) А так же при расширении функциональности программы.

Технология устранения ошибок в программе Найти похожие ветки