Дебъгване: Разлика между версии
Изтрито е съдържание Добавено е съдържание
форматиране |
Редакция без резюме |
||
Ред 5:
== Произход ==
Има някои противоречия относно произходът на термина „дебъгване“. Полулярността на термините „бъг“ и „дебъгване“ се дължи на адмирал [[Грейс Хопър]] (1940-те), докато тя работи по Mark II Computer в [[Харвардския университет]], нейните сътрудници открили молец (''bug'' - „бъг“) забит в реле и по този начин, възпрепятстващ операция, и след отстраняването му тя отбелязва, че те са „де-бъгнали“ (махнали грешката) от системата. Въпреки това терминът „бъг“ в смисъла на техническа грешка датира най-малко от 1878 г. и Томас Едисън, и „дебъгване“, е бил термин използван в аеронавтиката, преди да влезе в света на компютрите. Всъщност, в интервю Грейс Хопър отбелязва, че тя не е създателка на термина. „Бъг“ се оказва подходящ за вече съществуващата терминология, така че бива запазен. Писмо от Дж. Роберт Опенхеймер (директор на проекта на [[атомна бомба|атомната бомба]] „[[Манхатън (проект)|Манхатън]]“ от [[Втората световна война]] в [[Лос Аламос]], [[Ню Мексико]]) използва термина в писмо до д-р Ърнест Лорънс в [[Калифорнийския университет]] в [[Бъркли]], с дата 27 октомври 1944 г., по отношение на наемане на допълнителен технически персонал.
Обхват
Откакто софтуерните и електронни системи започнаха да стават по-сложни, различните техники за дебъгване са се разширили с повече методи за откриване на аномалии, оценка на въздействието, и частично софтуерно коригиране или пълно обновление на системата. Думите "аномалия" и "несъответствие" могат да бъдат използвани, тъй като са по-неутрални термини, за да се избегнат думите "error" (грешка), "defect" (дефект) или "bug" (бъг), където трябва да се разбира, че всички т.нар грешки, дефекти или бъгове трябва да бъдат фиксирани (на всяка цена). Вместо това може да се направи оценка на въздействието, за да определи дали промени за премахване на една аномалия (или несъответствие) биха били рентабилни за системата, или може би да се планира нова версия с нужните промяна(и). Не всички проблеми са жизнено-критични или критични в една система. Също така е важно да се избегне ситуация, в която промяната може да се окаже по-притеснителна за потребителите в дългосрочен план, отколкото временното примиряване с известен проблем(и) (където "излекуване ще бъде по-лошо от болестта"). Базирайки се на решения на приемливостта на някои аномалии може да се отрече съществуването на проблем и в резултатът периода да се отчете като мандат с нулев дефект. Имайки предвид въпроса с обезпечението, като например оценката на въздействието на разходите спрямо ползите, следват по-широки техники за дебъгване, за определяне честотата на аномалиите (колко често се срещат едни и същи "бъгове"), за оценка на тяхното въздействие на цялостната система.
[[Категория:Програмиране]]
| |||