kak se debugva c VC++ 6.0

Kak moga da napravja debugging na programa, kojato kompilirah s MS VC++ 6.0, primerno da sledja kakvo tochno pravi v opredelen moment, dali izprasta email i t.n.

Изпращането на e-mail можеш да го следиш с Ethereal или друг мрежов монитор . А иначе дебъгването на програмите обикновено става с дебъгер, и то с този, дето е вграден във VC++. Пробвал съм с Raid /дето уж трепе всички бъгове/, но не помага, а и оставя гадни петна по компютъра ...

"Всички науки са или физика, или колекциониране на пощенски марки." (Е. Ръдърфорд)

Debugvaneto se pravi s 3 klavi6a. F10, F11, a sas F9 slaga6 Break point.

Stom si ia piasl zasto prosto ne dobavish logging i ste znaesh koga kakvo e pravila. Debugger-a ne vinagi e nai dobroto reshenie.

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

AntiPattern-а е описан тук.

само аз ли тук мисля, че логването е приемливо само ако трябва да се пази информация/статистика като част от изискванията за програмата? има по-добри начини за елиминиране на дефекти!

Юнит тестовете могат да хванат само бъгове, за които си се сетил вече :-)
Те са полезни, за да не правиш глупости от невнимание.
Но в сложни системи, които си взаимодействат по непредсказуеми начини, напълно е възможно юнит тестове на отделните "юнити" да не засекат нищо лошо, а цялата галиматия да не работи.

Наскоро имахме проблем, който двама колеги хванаха с дълго четене (и мислене) на многомегабайтови логове - и не мога да си представя никакви разумни юнит тестове, които да биха го хванали.

Изобщо, извън учебникарските примери, които обикновено третират юнит тестове на "библиотечен" код, т.е. код който прави ЕДНО просто нещо, май не съм виждал нещо което да ме убеди в практичността им. Ти за какво и какви юнит тестове пишеш?

за какво служат логовете при дебъгването? за мен служат за начин за проверяване на хипотеза, която сме формулирали преди това. защо да не формулираме хипотезата и чрез тестове?

и аз не бях убеден в практичността на такива тестове... докато не видях обратното. каква печалба виждам от такива тестове:
1) по-добър дизайн - почти винаги, за да елиминирам дупликация или, за да направя нещо тестваемо променям дизайна. резултата е по-добър код с по-малко зависимости ( аргх как е coupling на български? )
2) някаква гаранция за безопасност при промяна на кода.
3) по-голяма сигурност за мен, че кода работи - все пак опитвам се да го ползвам така както го ползват тестовете.

>напълно е възможно юнит тестове на отделните "юнити" да
>не засекат нищо лошо, а цялата галиматия да не работи.
възможно е - тогава караме по стандартния начин - формулираме хипотеза, пишем тест, който да я докаже или да се провали ако е невалидна - повтаряме отначало. открития дефект бива демонстриран с тест и после оправен, което гарантира, че този дефект няма да се появи отново.

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

за библиотечните примери и невниманието - употребявам пхп и една от многото библиотеки дето се казват phpUnit. имам около 10ина класа, чиито обекти трябва да се записват в базата данни. да сложим грубо по 4 операции на клас - вкарване, четене, запис, изтриване -- прави 40 операции. не знам за теб, но аз не съм свръхчовек всеки път да внимавам за 40 неща и всеки път след промяна в базата да се разхождам из екраните от уебсайта и да гледам дали работят. не тествам уи-то ( хтмл и хттп ) опитвам се да го направя максимално тънко и просто...

не твърдя, че съм някакъв голям ТДД разбирач. опитвам се и още има много да уча. учудващо е, че дори и малкото, което правя се изплаща.

любопитен съм за проблема с мегабайтите логове - разкажи повече.

--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck

>код който прави ЕДНО просто нещо

сега ми мина през акъла -- ами горното е един от критериите за добър обектен дизайн. Single Responsibility Principle. прочее защо да имам клас, който прави 2 неща и не може да бъде тестван, като мога да имам 2 класа които да мога да тествам поотделно? дори и да мога да тествам само единия от тях - пак е по-добре

--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck

Ситуацията, която мегабайтите логове спасиха, беше следната:

Софтуерът представлява някаква симулация, която трябва да върви възможно максимално синхронно на много машини, които комуникират всяка с всяка, с възможно минимален трафик. Симулацията е квантувана на "тик"-ове, командите от всеки тик се насъбират, изпращат в края на тика, получават се по някое време командите от другите машини и едва тогава се изпълняват. Има няколко усложнения в тази иначе проста система: ситуации, в които се губят пакети, искат се повторения и се препращат наново, и един алгоритъм който се опитва така да дефазира тиковете на различните машини, че пакетите да пристигат точно когато са необходими и да не се губи време за изчакването им.

Е, тая симулация вървеше горе-долу добре, освен понякога, когато цялата работа се сриваше и машините почваха да се чакат, да пращат NACK-ове на поразия и т.н.

Изпринтихме кода, седнахме, прочетохме го внимателно, видяхме и оправихме някакви дреболии. Ефектът беше минимален. Сложихме тогава пълно печатане на пакетите на всички машини, барабар с timestamp-ове, станаха едни 10-12 МБ логове, седнаха двама души на една машина, отвориха логовете от всичките машини и четоха един ден пакети и стана ясна работата.

(От рубриката "при нас е весело" покрай тая случка: подробните логове показаха че на моята машина софтуера веднъж на две минути се успива за по 5-10 секунди. Добре че не потрошихме много време да го дебъгваме и да дирим какво в него се случва точно на 2 минути, преди да се сетя че Outlook-а ми на толкова тегли пощата, а тогава тръгва един спам-филтър който смята векторите на всички частици по времето на Големия взрив... Поука: не само профилиране, ами и най-нормално дебъгване се прави на чиста машина. Те затова в Microsoft програмистите имат отделна машина за email :-)

Ех, ако ти се случва да работиш само върху код, който отгоре додолу е изграден на основата на добър дизайн, бил той обектен или някакъв друг, значи си по-голям късметлия от мен.

Сега ще кажеш, че като не е добър дизайна, трябва първо да се рефакторне, и тогава да се дебъгва... ама нерядко клиента иска най-най-първо да му се достави софтуера.

>Сега ще кажеш, че като не е добър дизайна, трябва първо да се
>рефакторне, и тогава да се дебъгва... ама нерядко клиента иска
>най-най-първо да му се достави софтуера.

в някои ситуации да. а клиента ти запознат ли е с тази идея и това как тя може да застраши проекта му?

>Ех, ако ти се случва да работиш само върху код, който отгоре додолу е
> изграден на основата на добър дизайн, бил той обектен или някакъв
> друг, значи си по-голям късметлия от мен.
чак пък късметлия - просто допуснах, че кода е писан от теб... за наследените - ясно, бара се с повишено внимание. чувам хората го вкарват в тестове и оправят ама още не съм добър като Michael Feathers - модератора на WELC ( working effectively with legacy code ) групата на яху.

--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck

Клиентите слабо се интересуват от авангардни софтуерни методологии. Всъщност, ако клиентите изобщо разбираха нещо, вероятно щяха строго да забраняват всякакви авантюри като рефакторинг, нови компилатори и т.н. - клиентите винаги си мислят, че те искат само "малки промени".

Аз по код, "писан от мен", работя вкъщи, вечер, веднъж месечно :-) Истинската ми работа е върху код, писан от мен и още 8-10 души в продължение на последните 3 години (а има парчета, дето годините им почват с 199.), и е натрупал към 250 хиляди реда. Ако си работил с такъв codebase, ти е ясно какво става с неща като "дизайн" и "архитектура".

какво му е авангардното на техническия дълг? сигурно всеки ще се съгласи, че колиба от картон и сезал се прави по-лесно и по-бързо от нормална къща. естествено и се руши по-бързо, пък и трудно и се добавят гараж и втори етаж . не мисля, че рефакторинга е авантюра. всъщност това май е единственото средство, което може да се прилага, за да се избегнат ужасиите като тези, които описваш. всеки в виждал legacy код и на никого не е приятно да работи с него. защо тогава продължаваме да създаваме още и още?

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

о, музо, възпей оня гибелен гняв на Ахила пелеев... дотук с лирическите отклонения

--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck

I kakvo da kaza na klient kato mu krashne programata? Prati mi kakvo si napisal i ste ti kaza kakvo e stanalo? Da ama sistemata mu vkluchva vrazka s CICS, Sibel i edna kamara drugi vanshni moduli i ne moga izobsto da ia pusna na moiata mashina da ne govorim che bug-a se proiaviava edin pat na niakolko dena. Da go nakaram da si kupi debug-er i da si debugne bug-a? Da pisha test za nesto koeto dori ne znaia v kakva situacia gurmi? Izobsto kakvo da pravia?

Kazvam mu smeni trace level-a na 0 pusni go i kato se izadani mi prati log file-ovete.

Klienta go interesuva da pusne sistemata v production kolkoto se moze po-barzo, zastoto inache gubi pari. Ne mu puka kolko krasiv e koda koito lezi otdolu. Interesa klati fesa nali znaesh? :)

ти май немаш и хабер от правене на софтуер - само плещиш глупости и стандартни фрази, както Гуру и 80% от експертите тука.

Ха когато с рефакторинг ми разплетеш бозите и ги направиш 'Ултра яко обектно ориентирано дизайнато и построено чудо", тогава ми се похвали.

S tebe ne govorime edin ezik mai :)
Tova koeto kazah e che logvaneto moze da bade dobro za otkrivane na problemi koito ne mogat da se nameriat s debuger-a. Primer: multithreaded programi. Debug versiata moze izobsto da ne zavisva a releas-a da uvisva i da ne raboti. Kato debug-vash takava programa shansa da uvisne e nistozen. Sledovatelno debuger-a ne moze da ti pomogne. Spored tebe triabva da napisheme unit test. I taka kak ste napishesh unit test, sled kato ne znaesh daze kade se motka programata v momenta? Edinstvennoto reshenie koeto az znaia v tozi sluchai e release versia s logging i rovichkane iz log-a da vidish kakvo e stanalo. Sled kato imash hipoteza kakvo se e sluchilo se pishe test case za da ia proverish i ako vsichko e kakto triabva(programata ne raboti) opraviash bug-a i dobaviash test-a v regresshion testovete.

дораснах ли до Гуру-то а?

имам 2 предложения за теб:

1) регистрирай си ника и почни да даваш конструктивни коментари. тва за моя хабер му се вика argumentum ad hominem. опитай да прекараш фразата през гугъл ако не знаеш какво значи.

2) вместо да търсиш кой да ти разплете бозите - опитай да престанеш да произвеждаш бози в бъдещето. опитай и да образоваш колегите си, така че и те да не го правят

много ще се радвам ако направиш първото и с удоволствие ще помогна за второто!

--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck

>Da ama sistemata mu vkluchva vrazka s CICS, Sibel i edna kamara
>drugi vanshni moduli i ne moga izobsto da ia pusna na moiata mashina

обърнахме го пак на леките процеси - твоята обстановка изобщо не е гъвкава. в такава враждебна територия бих оправдал логването бих го използвал ако наследя подобна система... докато я направя по-гъвкава.

когато говорех за тестовете имах предвид разработка преди програмата да е стигнала до клиента. иначе това, за което ми говориш мирише на изисквания за статистики по време на изпълнение на програмата. щом клиента иска такова нещо и си плаща - добре. по-скоро ми е интересно, ако не иска и не знае, че плаща за Хикс време, в което се прави логването - как ще реагира. възможно ли е да има клиент, който да се примири с минимален дефект, но по-ниска цена?

--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck

а възможно ли е краткосрочното избързване за сметка на инженерен дълг да забави проекта и да загубим повече пари? клиента знае ли го това? знае ли, че ако произвеждам калпав код, за да наваксам на функционалност и работя по 60 часа на седмица ще му доставя само дефекти?

кода долу не е красив по естетически причини! не случайно Бек не му вика красив ами "прост". ето и неговите 4 критерия за простота:

1) всички тестове минават
2) няма дупликация
3) ясно се вижда какво иска да направи кода - намерението на програмиста
4) системата съдържа минимален брой класове и методи

--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck