E>А так, да, лучше писать чистый, безбажный код, и его же поддерживать и отлаживать.
Ты, наверное, забыл, что я считаю, что использование программистом отладчика в процессе разработки недопустимо.
E>Тут сомнений нет. В раю, наверное, так все и делают
Кто-то надеется на рай в загробной жизни. А кто-то пытается свою жизнь в этом бренном мире сделать максимально комфортной.
Здравствуйте, landerhigh, Вы писали:
L>я считаю, что использование программистом отладчика в процессе разработки недопустимо.
Забавная заморочка.
А смысл себя в инструментарии ограничивать?
Разработка в себя включает тестовые прогоны и отладку. А в этом без дебаггера конечно можно, но придётся надевать лыжи и залазить в них в гамак.
Здравствуйте, CreatorCray, Вы писали:
L>>я считаю, что использование программистом отладчика в процессе разработки недопустимо. CC>Забавная заморочка.
Ага.
CC>А смысл себя в инструментарии ограничивать?
Есть инструмент, который помогает. Отладчик при разработке в их число не входит.
CC>Разработка в себя включает тестовые прогоны и отладку. А в этом без дебаггера конечно можно, но придётся надевать лыжи и залазить в них в гамак.
Здравствуйте, landerhigh, Вы писали:
CC>>А смысл себя в инструментарии ограничивать? L>Есть инструмент, который помогает. Отладчик при разработке в их число не входит.
Ещё как входит, потому что позволяет многие баги отловить за один раз, без нудного инструментирования
CC>>Разработка в себя включает тестовые прогоны и отладку. А в этом без дебаггера конечно можно, но придётся надевать лыжи и залазить в них в гамак. L>Про юнит-тесты слышал?
Ага, в сферическом вакууме.
Юнит тесты банально далеко не везде применимы.
У меня к примеру дохрена всего работает в связке с другими компонентами, где определённая цепочка событий с определёнными таймингами играет важную роль в формировании состояния всей системы в котором воспроизводится баг. И вот тогда breakpoint или coredump в нужном месте играет очень важную роль.
Здравствуйте, CreatorCray, Вы писали:
L>>Есть инструмент, который помогает. Отладчик при разработке в их число не входит. CC>Ещё как входит, потому что позволяет многие баги отловить за один раз, без нудного инструментирования
Ага. А многие баги не заметить вообще.
Нудное инструментирование к юнит-тестам вообще никак не относится.
CC>>>Разработка в себя включает тестовые прогоны и отладку. А в этом без дебаггера конечно можно, но придётся надевать лыжи и залазить в них в гамак. L>>Про юнит-тесты слышал? CC>Ага, в сферическом вакууме. CC>Юнит тесты банально далеко не везде применимы.
Число случаев, когда их использовать объективно непрактично, можно пересчитать по пальцам одной руки. Все остальное — вопрос исключительно лени, ну или воображения.
CC>У меня к примеру дохрена всего работает в связке с другими компонентами,
Это у всех сейчас так.
CC>где определённая цепочка событий с определёнными таймингами играет важную роль в формировании состояния всей системы в котором воспроизводится баг.
И это тоже.
CC>И вот тогда breakpoint или coredump в нужном месте играет очень важную роль.
А отладчик совершенно не влияет на тайминги, ага. Особенно забавно, когда баг воспроизводится исключительно в оптимизированной сборке (кто-то там что-то говорил про стоя и гамаке?)
Здравствуйте, landerhigh, Вы писали:
L>Ага. А многие баги не заметить вообще. L>Нудное инструментирование к юнит-тестам вообще никак не относится.
Отвертка нужна чтобы отвинчивать завинченное а не ковырять в ухе.
Если дебаггер использовать вместо тестов — да, будет фигня.
Если написать юнит тесты и думать что багов не будет — будет тоже фигня.
CC>>Юнит тесты банально далеко не везде применимы. L>Число случаев, когда их использовать объективно непрактично, можно пересчитать по пальцам одной руки.
Говори за свою колокольню.
CC>>И вот тогда breakpoint или coredump в нужном месте играет очень важную роль. L>А отладчик совершенно не влияет на тайминги, ага.
Правильный отладчик сидит тихо и не лезет пока его не попросят.
Здравствуйте, CreatorCray, Вы писали:
CC>Отвертка нужна чтобы отвинчивать завинченное а не ковырять в ухе. CC>Если дебаггер использовать вместо тестов — да, будет фигня. CC>Если написать юнит тесты и думать что багов не будет — будет тоже фигня.
Какие интересные тараканы. Кто-то заявлял, что с тестами багов не будет? (На самом деле это почти достижимо, но не всем дано).
Юнит-тестами можно сделать все то, что ты делаешь отладчиком. Только в разы быстрее и на порядки эффективнее. К вопросу о "стоя и в гамаке".
CC> CC>>>Юнит тесты банально далеко не везде применимы. L>>Число случаев, когда их использовать объективно непрактично, можно пересчитать по пальцам одной руки. CC>Говори за свою колокольню.
Колокольня везде одна.
CC>>>И вот тогда breakpoint или coredump в нужном месте играет очень важную роль. L>>А отладчик совершенно не влияет на тайминги, ага. CC>Правильный отладчик сидит тихо и не лезет пока его не попросят.
Здравствуйте, landerhigh, Вы писали:
L>Какие интересные тараканы. Кто-то заявлял, что с тестами багов не будет?
Ну ты ж их продвигаешь как серебряную пулю и утверждаешь что отладчик не нужен.
L>Юнит-тестами можно сделать все то, что ты делаешь отладчиком.
Нет.
L>Колокольня везде одна.
Что за чушь?
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, landerhigh, Вы писали:
L>>Какие интересные тараканы. Кто-то заявлял, что с тестами багов не будет? CC>Ну ты ж их продвигаешь как серебряную пулю и утверждаешь что отладчик не нужен.
Я не говорю, что он не нужен.
Я отмечаю, что в процессе разработки использование его контпродуктивно.
L>>Юнит-тестами можно сделать все то, что ты делаешь отладчиком. CC>Нет.
Все то, а также то, что отладчиком в жизни не проверить.
L>>Колокольня везде одна. CC>Что за чушь?
Ну так разработчиков чего-то уникального в своем роде тут отродясь не водилось.
Здравствуйте, landerhigh, Вы писали:
L>Я не говорю, что он не нужен.
L>я считаю, что использование программистом отладчика в процессе разработки недопустимо
В чём отличие "недопустимо" от "не нужен"?
L>Я отмечаю, что в процессе разработки использование его контпродуктивно.
Так недопустимо или контрпродуктивно?
И что ты тогда считаешь процессом разработки?
Когда заканчивается разработка и начинается разрешённое использование отладчика?
L>>>Юнит-тестами можно сделать все то, что ты делаешь отладчиком. CC>>Нет. L>Все то, а также то, что отладчиком в жизни не проверить.
То, для чего надо отладчик юниттестами в реальной жизни ты не проверишь.
Есессна можно микроскопом гвозди забивать, но за этим не ко мне.
Отладчик надо для вычёсывания кода от затесавшихся туда блох. В процессе разработки.
L>>>Колокольня везде одна. CC>>Что за чушь? L>Ну так разработчиков чего-то уникального в своем роде тут отродясь не водилось.
А не надо уникального. Вид с колокольни тех кто клепает Web Frontend UX сильно отличается от вида с колокольни тех кто пилит EFI драйвера.
Здравствуйте, CreatorCray, Вы писали:
L>>Я отмечаю, что в процессе разработки использование его контпродуктивно. CC>Так недопустимо или контрпродуктивно?
В моей команде — недопустимо. То, что ты там второй час вручную в отладчике глазками проверяешь, за тебя должен делать дядя Дженкинс.
В других командах — контрпродуктивно. Я ими не руковожу и не могу устанавливать свои правила.
CC>И что ты тогда считаешь процессом разработки? CC>Когда заканчивается разработка и начинается разрешённое использование отладчика?
L>>>>Юнит-тестами можно сделать все то, что ты делаешь отладчиком. CC>>>Нет. L>>Все то, а также то, что отладчиком в жизни не проверить. CC>То, для чего надо отладчик юниттестами в реальной жизни ты не проверишь.
Ну, для разбора коры юнит-тесты и правда неприменимы.
CC>Есессна можно микроскопом гвозди забивать, но за этим не ко мне.
Вообще-то микроскоп в данном случае — это отладчик
CC>Отладчик надо для вычёсывания кода от затесавшихся туда блох. В процессе разработки.
А юнит-тесты нужны, чтобы эти блохи туда даже не попали. В процессе разработки.
Вот и договорились.
Здравствуйте, landerhigh, Вы писали:
L>То, что ты там второй час вручную в отладчике глазками проверяешь
Шта? А, ясно, вы его просто готовить не умеете.
В отладчике не проверяют, в отладчике отлаживают.
L>Ну, для разбора коры юнит-тесты и правда неприменимы.
Кора обычно если проблема в кернеле, который порой не так то просто полноценно остановить
CC>>Есессна можно микроскопом гвозди забивать, но за этим не ко мне. L>Вообще-то микроскоп в данном случае — это отладчик
Именно. Не надо его использовать не по назначению.
CC>>Отладчик надо для вычёсывания кода от затесавшихся туда блох. В процессе разработки. L>А юнит-тесты нужны, чтобы эти блохи туда даже не попали.
В процессе разработки блохи попадают неминуемо.
Один из лучших способов их найти — отладчик.
Но это всё ещё во время процесса разработки.
Возвращаясь к тому, с чего всё началось:
L>я считаю, что использование программистом отладчика в процессе разработки недопустимо
Я считаю это контрпродуктивной заморочкой. Применение отладчика в процессе разработки для выяснения как возникает тот либо иной баг крайне полезно.
Здравствуйте, CreatorCray, Вы писали:
L>>То, что ты там второй час вручную в отладчике глазками проверяешь CC>Шта? А, ясно, вы его просто готовить не умеете.
Умеем. Поэтому и не используем.
CC>В отладчике не проверяют, в отладчике отлаживают.
Тебе нужно отлаживать собственный свеженаписанный код? Подумай, прежде чем отвечать
L>>Ну, для разбора коры юнит-тесты и правда неприменимы. CC>Кора обычно если проблема в кернеле, который порой не так то просто полноценно остановить
Неважно.
CC>>>Есессна можно микроскопом гвозди забивать, но за этим не ко мне. L>>Вообще-то микроскоп в данном случае — это отладчик CC>Именно. Не надо его использовать не по назначению.
Вот именно.
CC>>>Отладчик надо для вычёсывания кода от затесавшихся туда блох. В процессе разработки. L>>А юнит-тесты нужны, чтобы эти блохи туда даже не попали. CC>В процессе разработки блохи попадают неминуемо. CC>Один из лучших способов их найти — отладчик. CC>Но это всё ещё во время процесса разработки.
Странно. А я почему-то всегда считал, что если ты пишешь код, то ты обязан иметь полное или практически полное представление о возможных путях проникновения блох в твой код и вариантах некорректного поведения твоего кода. Иначе ты не инженер, а так. Мимокрокодил.
CC>Я считаю это контрпродуктивной заморочкой. Применение отладчика в процессе разработки для выяснения как возникает тот либо иной баг крайне полезно.
Я считаю, что если "разработчику" нужен отладчик, чтобы понять, как возникает баг в его собственном коде, то ему следует поискать работу в другой отрасли.
Здравствуйте, landerhigh, Вы писали:
L>Умеем. Поэтому и не используем.
Да вот что то в глаза не бросается.
CC>>В отладчике не проверяют, в отладчике отлаживают. L>Тебе нужно отлаживать собственный свеженаписанный код? Подумай, прежде чем отвечать
Загни пальцы. Баги были есть и будут везде. И чем сложнее хреновина тем заковыристее в ней баги, причём часто crossfunctional, в стиле мы тупо красили дом Болконских и после этого у Наташи при прогулке с Пьером падают трусы.
CC>>>>Есессна можно микроскопом гвозди забивать, но за этим не ко мне. L>>>Вообще-то микроскоп в данном случае — это отладчик CC>>Именно. Не надо его использовать не по назначению. L>Вот именно.
Т.е. ты со мной согласен?
L>А я почему-то всегда считал, что если ты пишешь код, то ты обязан иметь полное или практически полное представление о возможных путях проникновения блох в твой код и вариантах некорректного поведения твоего кода.
Возможно потому что пишешь что то изолированное, сферическое и в вакууме. Ничего этот код чужого не использует и его никто чужой не использует. Всё вокруг только своё.
С чего ты вообще взял что баги всегда возникают только в новом коде? Порой оно ломается там, где вообще сто лет никто не заглядывал, либо, что веселее, у тех, кто этот код юзает через пару слоёв выше были кривые руки и юзают его не по спекам но раньше по какой то причине у них прокатывало.
L>Я считаю, что если "разработчику" нужен отладчик, чтобы понять, как возникает баг в его собственном коде, то ему следует поискать работу в другой отрасли.
Слово "собственный" надо вычеркнуть. Мы не в вакууме код пишем, он взаимодействует с другим кодом, в том числе и древним.
Здравствуйте, CreatorCray, Вы писали:
CC>Загни пальцы. Баги были есть и будут везде. CC>И чем сложнее хреновина тем заковыристее в ней баги,
Задача инженера — раздробить сложную хреновину на простые части. Как раз чтобы всю жизнь заковыристые баги не ловить.
CC>причём часто crossfunctional, в стиле мы тупо красили дом Болконских и после этого у Наташи при прогулке с Пьером падают трусы.
Причем, эти crossfunctional баги вызваны именно этим самым "думать некогда, копать надо, а мы в отладчике уже прогнали и все работает". Иными словами, они вызваны ленивыми (или самонадеянными) типа погромиздами.
Crossfunctional баги в большинстве своем есть следствие паразитных неявных связей.
И вот тут есть такая небольшая интересность — код с подобными связями не поддается юнит-тестированию либо вообще никак, либо через такую задницу, что разработчики, которые пробовали писать юнит-тесты для такого кода, потом из поколения в поколение рассказывают страшилки.
Хорошее покрытие кода юнит-тестами означает, что в коде нет подобных связей или они выкорчеваны до минимума. Ну то есть трусы Наташи никак не связаны с цветом дома Болконских.
CC>>>>>Есессна можно микроскопом гвозди забивать, но за этим не ко мне. L>>>>Вообще-то микроскоп в данном случае — это отладчик CC>>>Именно. Не надо его использовать не по назначению. L>>Вот именно. CC>Т.е. ты со мной согласен?
Что отладчик — это микроскоп и ты им забиваешь гвозди? Я с самого начала об этом говорю.
CC>С чего ты вообще взял что баги всегда возникают только в новом коде? Порой оно ломается там, где вообще сто лет никто не заглядывал, либо, что веселее, у тех, кто этот код юзает через пару слоёв выше были кривые руки и юзают его не по спекам но раньше по какой то причине у них прокатывало.
И что это меняет?
L>>Я считаю, что если "разработчику" нужен отладчик, чтобы понять, как возникает баг в его собственном коде, то ему следует поискать работу в другой отрасли. CC>Слово "собственный" надо вычеркнуть. Мы не в вакууме код пишем, он взаимодействует с другим кодом, в том числе и древним.
Отлаживаешь-то ты свой код, а не код сторонней библиотки.
L>Странно. А я почему-то всегда считал, что если ты пишешь код, то ты обязан иметь полное или практически полное представление о возможных путях проникновения блох в твой код и вариантах некорректного поведения твоего кода. Иначе ты не инженер, а так. Мимокрокодил.
Вы хоть раз многопоточное приложение писали? Юнит-тесты шибко помогали покрыть все варианты взаимодействия потоков?
Здравствуйте, landerhigh, Вы писали:
S>>Вы хоть раз многопоточное приложение писали? L>Ну, приходилось.
К отладчику не прибегали?
Без отладчика тут даже баг не воспроизведешь...
S>>Юнит-тесты шибко помогали покрыть все варианты взаимодействия потоков? L>И сколько у вас вариантов взаимодействия потоков, позвольте спросить?
Учитывая недетерминизм присущий многозадачности, то вариантов взаимодействия крайне много.
Здравствуйте, Sharov, Вы писали:
L>>Ну, приходилось. S>К отладчику не прибегали?
Нет. Зачем?
S>Без отладчика тут даже баг не воспроизведешь...
Какой такой баг, присущий исключительно многопоточной программе, можно воспроизвести исключительно отладчиком? И как именно, позвольте полюбопытствовать?
S>>>Юнит-тесты шибко помогали покрыть все варианты взаимодействия потоков? L>>И сколько у вас вариантов взаимодействия потоков, позвольте спросить? S>Учитывая недетерминизм присущий многозадачности, то вариантов взаимодействия крайне много.
Недетерминированность состояния не имеет прямого отношения к количеству вариантов взаимодействия.
