IT & Bike

morlok · **Добавлено:** 23.07.2007 16:04

я не совсем понял почему это IT специалистов прямо таки отождествили с программистами :-)

Я аналитик компьютерных систем, тоже IT специалист, но совсем не программист :-)

Ну раз под программистами в опросе таки айтишники понимаются, если я все правильно понял, знач тож за программера проголосую :-)

mosh · **Добавлено:** 23.07.2007 16:50

Mike Chaliy писал(а):

Представляю себе ваши методы. Наверное полсотни ассертов на входе, еще пол сотни на выходе. Трейс через каждую строчку. Кейсы на пол класса для обработки кодов возврата. Вобщемто 90% кода для потдержки 10%.

Ну де Вы видели методы с 25 параметрами на входе и таким же числов выходных данных. Обычно 2-4 на входе, выход проверяется в вызывающем контексте. Ну а процентовка такая, как Вы написали, только наоборот, ну инода 20-80. Я уточнил сразу - грамотно написанный отладочный фреймвёрк.

Mike Chaliy писал(а):

Есть ТДД которое позволяет убедиться в работоспособности кода с внешней стороны. И не имеет смысла засорять код ассертами внутри. А дебаг тайм ассерты так это вообще дырка в безопасности...

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

Mike Chaliy писал(а):

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

).

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

Mike Chaliy писал(а):

Коды возврата вообще устрашающая фишка. Я когда ревьювлю код, методы которые могут нулл возаращать отношу к потенцеально небезопасным. И только потому что они могут возаращать два пути, либо нул либо информацию. А тут коды возарата, количестов путей = количество кодов возарата + безконечное количество неизвесных путей возврата.

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

Резюмируя , мона сказать, что отладочный фреймвёк - это набор формализованных и реализованных в коде процедур отладки. Можно сделать конечно выполнять их каждый раз руками или макросами в отладчики, но согласитесь, что подобная практика сама является источником ошибок, так как зависит от личностного фактора:) Кроме того, есть масса областей, где отладчики просто по аппаратным реалиям сливают - например при отладке через COM

ЗЫ в целом можно куда-нибудь перепозти с этой интересной темой в более подходящее место

Mike Chaliy · **Добавлено:** 23.07.2007 17:09

mosh писал(а):

Mike Chaliy писал(а):

Представляю себе ваши методы. Наверное полсотни ассертов на входе, еще пол сотни на выходе. Трейс через каждую строчку. Кейсы на пол класса для обработки кодов возврата. Вобщемто 90% кода для потдержки 10%.

Ну де Вы видели методы с 25 параметрами на входе и таким же числов выходных данных. Обычно 2-4 на входе, выход проверяется в вызывающем контексте. Ну а процентовка такая, как Вы написали, только наоборот, ну инода 20-80. Я уточнил сразу - грамотно написанный отладочный фреймвёрк.

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

mosh писал(а):

Mike Chaliy писал(а):

Есть ТДД которое позволяет убедиться в работоспособности кода с внешней стороны. И не имеет смысла засорять код ассертами внутри. А дебаг тайм ассерты так это вообще дырка в безопасности...

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

ТДД - Тест Драйвен Девелопмент - бузверд - Юнит Тесты. Упрощенно это специальные классы которые вызвают ваш код. Есть специальные фреимворки для упрощения тестирования. Кроме того что проверяют что метод работает правильно с правильными данными, так же проверяют и работу с неправильными данными.

mosh писал(а):

Mike Chaliy писал(а):

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

).

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

Аха, вы про СтекТерйс, сорри есть еще просто МануалТрейс, я имел ввиду его. Если же говорить про СтекТрейс, то дебаггер еще и его должен уметь визуализировать. А еще уметь интелектуально останавливаться на исключительных ситуация.

mosh писал(а):

Mike Chaliy писал(а):

Коды возврата вообще устрашающая фишка. Я когда ревьювлю код, методы которые могут нулл возаращать отношу к потенцеально небезопасным. И только потому что они могут возаращать два пути, либо нул либо информацию. А тут коды возарата, количестов путей = количество кодов возарата + безконечное количество неизвесных путей возврата.

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

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

mosh писал(а):

Резюмируя , мона сказать, что отладочный фреймвёк - это набор формализованных и реализованных в коде процедур отладки. Можно сделать конечно выполнять их каждый раз руками или макросами в отладчики, но согласитесь, что подобная практика сама является источником ошибок, так как зависит от личностного фактора:) Кроме того, есть масса областей, где отладчики просто по аппаратным реалиям сливают - например при отладке через COM

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

mosh писал(а):

ЗЫ в целом можно куда-нибудь перепозти с этой интересной темой в более подходящее место

Если вас устраивает что я буду разговаривть исключительно на украинском можете запостить тему на http://dev.net.ua/.

mosh · **Добавлено:** 23.07.2007 17:40

Mike Chaliy писал(а):

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

Ну я не знаю про инварианты, но указатели проверяются на ненулёвость, значения на диапазон или равенство, а перечисляемые типы на множество. Последний случай конечно несколько тяжеловат, но по практике полчается от 1 до максимум 8 ассертов.

Mike Chaliy писал(а):

ТДД - Тест Драйвен Девелопмент - бузверд - Юнит Тесты. Упрощенно это специальные классы которые вызвают ваш код. Есть специальные фреимворки для упрощения тестирования. Кроме того что проверяют что метод работает правильно с правильными данными, так же проверяют и работу с неправильными данными.

Правильно, это фреймвёк для тестирования типа cpp-unit или там java-unit. Мы ж говорим про фрейвёки для отладки. С помощью тестового фрейвёка Вы определяет факт того, что модуль не работает, а с помощью отладочного локализуете место, которое не работает.

mosh писал(а):

Аха, вы про СтекТерйс, сорри есть еще просто МануалТрейс, я имел ввиду его. Если же говорить про СтекТрейс, то дебаггер еще и его должен уметь визуализировать. А еще уметь интелектуально останавливаться на исключительных ситуация.

Мы ж говорим про фреймвёрк, который позволяет не использовать дебаггеры. Мануал трейсом легко делается СтэкТрейс, досточно писать в префиксе сообщения класс::метод:)

Mike Chaliy писал(а):

Коды возврата вообще устрашающая фишка. Я когда ревьювлю код, методы которые могут нулл возаращать отношу к потенцеально небезопасным. И только потому что они могут возаращать два пути, либо нул либо информацию. А тут коды возарата, количестов путей = количество кодов возарата + безконечное количество неизвесных путей возврата.

Mike Chaliy писал(а):

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

Если говорить о c++, то всё зависит от реализации языка (стандарт стандартом, но реализации бывают разные). Но в целом коды возврата и исключительные ситуации весьма схожи по функции локализации, хотя исключения берут на себя обратную раскрутку стека, что действительно снижает вероятность ошибки при этой процедуре. Это большой плюс исключений. Но правильно спроектированная система исключений или кодов должна точно указать место возникновения ошибки - в этом они близнецы братья.

Mike Chaliy писал(а):

Резюмируя , мона сказать, что отладочный фреймвёк - это набор формализованных и реализованных в коде процедур отладки. Можно сделать конечно выполнять их каждый раз руками или макросами в отладчики, но согласитесь, что подобная практика сама является источником ошибок, так как зависит от личностного фактора:) Кроме того, есть масса областей, где отладчики просто по аппаратным реалиям сливают - например при отладке через COM

Mike Chaliy писал(а):

Это и есть ТДД.

ТДД - делает это снаружи, работает через внешние интерфейсы, а отладочные фреймвёки позволяют показать детали внутренней организации. Именно это и делает дебаггер. Но фреймвёк делает это не только на этапе отладки, но и в релизе с помощью кодов, исключений и т.д. Локализовать ошибку без поддержки отладочно-контролирующего фреймворка TDD неспособен, бо видит модуль как черный ящик.

Mike Chaliy писал(а):

Если вас устраивает что я буду разговаривть исключительно на украинском можете запостить тему на http://dev.net.ua/.

Только я буду часто переспрашивать:)

Mike Chaliy · **Добавлено:** 24.07.2007 11:26

mosh писал(а):

ТДД - делает это снаружи, работает через внешние интерфейсы, а отладочные фреймвёки позволяют показать детали внутренней организации. Именно это и делает дебаггер. Но фреймвёк делает это не только на этапе отладки, но и в релизе с помощью кодов, исключений и т.д. Локализовать ошибку без поддержки отладочно-контролирующего фреймворка TDD неспособен, бо видит модуль как черный ящик.

В этом то и фишка, что код незасоряеться отладочным. Реально это необходимо уже в более мение заметном проекте... Код должен заниматься только выполнением. Желательно чтобы они вообще больше ничем не занимался. Но так как в реальных системах это не возможно то желательно стараться хотябы минимизировать.

Так вот связка ТДД и дебаггера плозволяет полностью убрать дебаг тайм ассерт код.
Автоматические прокси позволяют убрать инструметейшен.
А домаин специфик фрамеворки позволяют убрать код

.

Вобщемто это уже религиозная война

.

Intraday · **Добавлено:** 24.07.2007 13:53

А вот в чем Файрфокс переплюнул ИЕ - в браузер вмонтировали дебагер javascript. И послали еще дальше Билла в браузерной войне:

Firebug integrates with Firefox to put a wealth of web development tools at your fingertips while you browse. You can edit, debug, and monitor CSS, HTML, and JavaScript live in any web page.

http://www.getfirebug.com/

правда это приятно разработчикам, юзерам пополам

Mike Chaliy · **Добавлено:** 24.07.2007 15:37

Intraday писал(а):

А вот в чем Файрфокс переплюнул ИЕ - в браузер вмонтировали дебагер javascript. И послали еще дальше Билла в браузерной войне:

Firebug integrates with Firefox to put a wealth of web development tools at your fingertips while you browse. You can edit, debug, and monitor CSS, HTML, and JavaScript live in any web page.

http://www.getfirebug.com/

правда это приятно разработчикам, юзерам пополам

Ыыы, лес повезли... Дебаггер в ИЕ был тогда когда ФФ еще в проекте небыло :lol:

. Уморил.

Intraday · **Добавлено:** 24.07.2007 15:53

Ну ты и сравнил у них дебагеры! Заморил. В ИЕ конечно есть указание на номер строки и символ, но ты присмотрись к фокс-мазиле, установи примочки и почувствуешь почему был снят фильм килл билл. Вот тебе и религиозные войны. Мат часть надо знать.

Mike Chaliy · **Добавлено:** 24.07.2007 16:36

Intraday писал(а):

Ну ты и сравнил у них дебагеры! Заморил. В ИЕ конечно есть указание на номер строки и символ, но ты присмотрись к фокс-мазиле, установи примочки и почувствуешь почему был снят фильм килл билл. Вот тебе и религиозные войны. Мат часть надо знать.

Да ты крут..

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

П.С. Я сидел несколько лет на ФФ, так что можеш мне не заливать про его мощь...

П.П.С. Класные вещи можно вытворять на непрофильном сайте.... Пресдатвляю как бы на меня в комунити за такие коментарии посмотрели

).

Intraday · **Добавлено:** 24.07.2007 16:54

да, пыхпых, и поехали дальше, к концу рабочего дня коды на фиг

Drema · **Добавлено:** 24.07.2007 23:19

Ответил "Нет", хотя в принципе могу несложный сайт html, css, php, mySQL сделать, в дельфи что то простенькое
(без всяких WinAPI, БД) написать и давным давно даже пытался программировать PIC контроллер

Инструменты же моей деятельности - LaTeX, Mathematica, бумага, ручка

инструменты подработки Corel Draw, Corel Photopaint, Photoshop, RIP Express

Azar · **Добавлено:** 26.07.2007 16:37

Программер.. пока Junior C# Developer (Desktop - приложения) наверно я один из тех немногих, кто ещё не перешёл на web

Intraday · **Добавлено:** 31.07.2007 17:38

Azar писал(а):

Программер.. пока Junior C# Developer (Desktop - приложения) наверно я один из тех немногих, кто ещё не перешёл на web

Скажу тебе откровенно - с web головняка побольше. Если пишешь Win32 приложения, используя например делф, sqlserv - все проще. Влезешь в web, придется познакомиться параллельно с десятком накруток - аякс, смарти, пиар итд...

А вот до C# никак руки не дойдут... Хотя в прошлом Карниган и Ричи была настольной книгой, много написано на С, С++.

chak · **Добавлено:** 31.07.2007 20:59

игродел =) графика, физика, сеть =)

$L!M · **Добавлено:** 31.07.2007 21:37

немного Javа програмир (J2EE, WEB) и в бОльшей степени тридэшник :twisted:

Новости	Форум	Контакты
Отчеты	Барахолка	Реклама
Статьи	Календарь	Скидки ХТ

		На страницу Пред. 1 ... 4, 5, 6, 7, 8, 9, Bce След.
Страница 7 из 9 [ Сообщений: 126 ]