Здравствуйте, Erop, Вы писали:

E>Предлагаю отделить ветку и переехать в "философию" с темой вроде того: "[Бывают ли у программиста задачи, ]когда распечатка удобнее IDE?"

Хорошая мысль

Здравствуйте, Ikemefula, Вы писали:

I>Не "можешь", а "умеешь".

Иногда "умеешь" слишком дорого стоит.
Пример 1. Оправляем два аппарата на Марс. Один, очень может быть, по сбою ПО теряет ориентацию и связь. Мы про него забываем. Но хотим побороться за второй. Наши действия?

Пример 2. Тестовый прогон -- это пуск ракеты, например. Или автоматическая посадка "Бурана"...
Соответственно, ваши действия по предотвращению сбоя ПО на боевом прогоне? Запуск пары сотен тестовых устройств? Или таки подробный анализ когда стоит включить?

Пример 3. Мы разрабатываем ПО для вундер-вафли для доктора Зло. Зоктор Зло щедр, но если наше ПО подведёт его в боевой лихой час, он нас накормит своими яйцами, и внутренностями, и мы вообще очень даже обрадуемся когда наконец умрём. Вот в таких условиях лично ты ограничишься модульными тестами и рефакторилкой, или таки постараешься организовать вычитку кода с подробным анализом?

Здравствуйте, Ikemefula, Вы писали:

I>Следовательно, ты просто трепло, потому что вопрос был про то, где инструменты не помогают.

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

Здравствуйте, Erop, Вы писали:

E>Ну можно и так сформулировать. Я подозреваю, что коллега, когда говорил о покрытии модульными тестами имел в виду, что можно сделать такую систему тестов, что их прохождение гарантирует верность алгоритма. Но мы тогда получим рекурсивную задачу проверки правильности системы тестов. IMHO, она будет сложнее.

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

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

И заметь — про это уже было сказано.

Здравствуйте, Ikemefula, Вы писали:

I>Есть инструменты, которые облегчают просмотр и анализ кода.

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

Здравствуйте, Ikemefula, Вы писали:

I>Когда ты читаешь чего по бумажке, попробуй сформулировать, чем бы мог помочь инструмент а потом погугли

Нужно построить формальное и верифицируемое доказательство корректности кода. Погугли, пожалуйста, сам?

Здравствуйте, Ikemefula, Вы писали:

I>Максимум — фетиш который помогает сменить обстановку и отдохнуть.

Кстати, лично мне, иногда бывает полезно во время раздумий над проблемами курить. А на рабочем месте сейчас в РФ это а-та-та, например...
Ну и вообще, я сложные задачи на хожу часто решаю. Во время прогулок, например. И иметь с собой какое-то хардкопи-представление задачи очень даже полезно. Если вдруг приходит на ум идея какая-то, то можно достать бумажку и проверить идею прямо вот непосредственно, а не звонить откуда-то из леса коллеге и не просить продиктовать код такого-то метода или интерфейса

Это я не про поиск багов, а вообще про разное. Ну вот положим стоит у тебя в плане фича "улучшить качество распознавания тайского языка на 25%"...
Задачи такого рода свистелками вроде VAX и подсветка не решаются

Здравствуйте, ambel-vlad, Вы писали:

I>>Да, старая песня — стоит тебя попросить прояснить тобой же сказаное, как сразу жди взрыва бочки с говном

AV>Паша, если ты не в состоянии прочитать и понять двух предложений, то я тебе ничем не могу помочь.

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

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

Вобщем ты таки попробуй взять себя в руки и объяснить, как это сервер обламывался-необламывался и какое отношение имели к этому тестеры.

Ты, VV и Егор утверждаете что случаев хватает но так и не привели внятный пример. Даже описать не можете, чего же с кодом то делаете, что бы проблему найти. Какая то мутная полуинтуитивная отсебятина.

У меня, кстати говоря, были случаи когда нужно было сидеть над простынями с кодом — когда инструментов вообще не было. Даже компьютера И при этом надо было найти ошибку в программе. Это единственный случай, когда бумажка с кодом действительно пригодится.

Здравствуйте, vladimir.vladimirovich, Вы писали:

VV>Я так понимаю, что разночтение в том является ли автоматическое тестирование панацеей или нет?
Дык, блин, давно же известно, что нет никакой серебряной ложки, в смысле пули!

VV>Умному ответ и так ясен .
Ну, в целом, спор не так уж глуп. И вполне возможно I знает чего-то, чего я не знаю и у него можно поучиться. Правда несколько напрягает излишний эмоциональный накал обсуждения...

Здравствуйте, Erop, Вы писали:

E>Иногда "умеешь" слишком дорого стоит.
E>Пример 1. Оправляем два аппарата на Марс. Один, очень может быть, по сбою ПО теряет ориентацию и связь. Мы про него забываем. Но хотим побороться за второй. Наши действия?

Начинать анализ системы Для анализа кода лучше брать не бумагу, а Code Collaborator например, ибо известно — две головы лучше одной.

E>Пример 2. Тестовый прогон -- это пуск ракеты, например. Или автоматическая посадка "Бурана"...
E>Соответственно, ваши действия по предотвращению сбоя ПО на боевом прогоне? Запуск пары сотен тестовых устройств? Или таки подробный анализ когда стоит включить?

Не валяй дурку. От тебя требуется обосновать необходимость необходимость бумажки с кодом для анализа оных алгоритмов.

E>Пример 3. Мы разрабатываем ПО для вундер-вафли для доктора Зло. Зоктор Зло щедр, но если наше ПО подведёт его в боевой лихой час, он нас накормит своими яйцами, и внутренностями, и мы вообще очень даже обрадуемся когда наконец умрём. Вот в таких условиях лично ты ограничишься модульными тестами и рефакторилкой, или таки постараешься организовать вычитку кода с подробным анализом?

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

При этом бумажка с кодом для анализа лучше только отсутствия инструментов.

Но я сильно уверен, что ты через сообщение снова будешь рассказывать мне, что я де тесты назвал панацеей. Это один из твоих любимых приемов.

Здравствуйте, Erop, Вы писали:

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

Ты до сих пор не дал нормального примера

Здравствуйте, vladimir.vladimirovich, Вы писали:

VV>Здравствуйте, Ikemefula, Вы писали:

I>>Следовательно, ты просто трепло, потому что вопрос был про то, где инструменты не помогают.

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

Это ты по себе судишь ? Если доктор нужен тебе, не значит что и другим он нужен.

Кстати, на счет бумаги. Ты в курсе, что это один из симптомов ! Расскажи подробно, что ты с этой бумагой делаешь ?

Здравствуйте, Erop, Вы писали:

E>Ну и вообще, я сложные задачи на хожу часто решаю. Во время прогулок, например.

И часто ты гуляешь месяцами что бы решить задачу ?

>И иметь с собой какое-то хардкопи-представление задачи очень даже полезно. Если вдруг приходит на ум идея какая-то, то можно достать бумажку и проверить идею прямо вот непосредственно, а не звонить откуда-то из леса коллеге и не просить продиктовать код такого-то метода или интерфейса

Я и говорю — каменный век

E>Это я не про поиск багов, а вообще про разное. Ну вот положим стоит у тебя в плане фича "улучшить качество распознавания тайского языка на 25%"...
E>Задачи такого рода свистелками вроде VAX и подсветка не решаются

Конечно не решаются. При этом от бумаги с кодом толку еще меньше будет, потому что для таких дел есть специальные инструменты.

Здравствуйте, Erop, Вы писали:

VV>>Умному ответ и так ясен .
E>Ну, в целом, спор не так уж глуп. И вполне возможно I знает чего-то, чего я не знаю и у него можно поучиться. Правда несколько напрягает излишний эмоциональный накал обсуждения...

Очень сомневаюсь, что он может выдать что-то сакральное. Если бы такое знание было — он бы его выдал уже давно. Хотя я буду рад ошибиться.

Здравствуйте, Ikemefula, Вы писали:

А как у Вас с соблюдением режима? Вы сегодня зарядку делали?

Здравствуйте, Ikemefula, Вы писали:

I>>>Нахрена тратить время, если юниттест может показать место ошибки ?
E>>А кто покажет ошибку в тесте?
I>Тесты если уметь ими пользоваться, получаются очень простыми.

Ну покажи на модельной задаче, как надо делать. AFAIK, тесты получаются простыми, только в задачах с простой спецификацией.

E>>И вот на каком-то изображении получаем, что некоторые пикселы результата не того цвета. И что мы делаем дальше?
I>Очевидно, юнит-тесты написаны коряво. Нужно фиксить юнит-тесты, они должны основываться на реальных данных.
Это я не понял. Что такое "реальные данные" для библиотеки обработки изображений?

I>Из деклараций функций мне например ничего не ясно.
Упс, я ошибся. Правильно, конечно же так:

void HrzCompressTwiceKeepBlackStrokes( ImageStroke*& dst, ImageStroke const* &src, int linesCount = 1)

Мы берём в src ссылку на указатель на строки. Вычитываем оттуда linesCount строк, и помещаем в параметр указатель за эти строки.
А в dst записывае результат, и сам dst передвигаем за результат.

I>Должен быть набор паттернов, на которых будут отрабатываться алгоритмы. Кроме того, нужен тул который будет подготавливать эти паттерны.
Ну пусть всё это есть. Тем более это не сложно устроить. Просто файлы с BMP, например. Правда ещё код конверсии BMP в RLE придётся написать.

I>Поначалу работы много, зато позже ты сможешь модифицировать, оптимизировать и тд, без страха застрять на недели в дебаге.
I>А если ты просто взял и нахерачил функцию на 100 строчек, кто ж тебе доктор ?
Нет, речь вообще не об этом. То, что ты описал -- это понятные минимальные требования на культуру разработки. И они очень эффективны против простых ошибок. Но когда заканчиваются простые ошибки, начинаются сложные...

Вот ты написал, что надо разбить сложную функцию на простые и всё починится. Я за такой подход, но я не понимаю, как его применить в задаче про медианную фильтрацию картинки. Но реализовывать медианную фильтрацию ради учебных целей слишком сложно, IMHO. Поэтому я предлагаю размяться на модельной задаче. Она, на мой взгляд достаточно сложная, чтобы уже захотелось юзать бумажки.

Попробуй объяснить на примере этой задачи твою методу?

Здравствуйте, vladimir.vladimirovich, Вы писали:

VV>А как у Вас с соблюдением режима? Вы сегодня зарядку делали?

Думаешь это как то коррелирует с твоими мыслями ?

Здравствуйте, Ikemefula, Вы писали:

VV>>А как у Вас с соблюдением режима? Вы сегодня зарядку делали?
I>Думаешь это как то коррелирует с твоими мыслями ?

Вам кажется, что Вы можете читать мои мысли?

Здравствуйте, Ikemefula, Вы писали:

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

I>И заметь — про это уже было сказано.

А мне вот бумажка с распечаткой помогает как раз. Возможно именно потому, что это ФОРМАЛЬНОЕ представление алгоритма, и я УМЕЮ с ним работать на бумажке. Тоже формально. Если мне надо что-то проверить потом с компом, по результатам раздумий с бумажкой, то нет проблем. Комп-то не выброшен...
Один и простых примеров такого сценария -- это мы курим бумажку и понимаем какие инварианты каких циклов хорошо бы проверить. И если они ещё не проверяются в коде, то расставляем asserts и делаем прогон...

Здравствуйте, Ikemefula, Вы писали:

E>>Пример 1. Оправляем два аппарата на Марс. Один, очень может быть, по сбою ПО теряет ориентацию и связь. Мы про него забываем. Но хотим побороться за второй. Наши действия?

I>Начинать анализ системы
IMHO, в таких условиях НАЧИНАТЬ анализ как-то поздновато. Я, например, в аналогичных обстоятельствах обычно знаю несколько мест, которые надо срочно пристально курить.

I> Для анализа кода лучше брать не бумагу, а Code Collaborator например, ибо известно — две головы лучше одной.
Кому как. Это всего лишь вопрос, как организовать коллективную работу. Почему ты считаешь что именно Code Collaborator лучше всего? Я бы, например, быстренько бы обсудил с теми, кто в теме, что надо проанализировать, а потом раздал бы куски для анализа по людям...

E>>Пример 2. Тестовый прогон -- это пуск ракеты, например. Или автоматическая посадка "Бурана"...
E>>Соответственно, ваши действия по предотвращению сбоя ПО на боевом прогоне? Запуск пары сотен тестовых устройств? Или таки подробный анализ когда стоит включить?

I>Не валяй дурку. От тебя требуется обосновать необходимость необходимость бумажки с кодом для анализа оных алгоритмов.
Дык я вот и обосновываю. Как ты предлагаешь снизить число неудачных прогонов? Я знаю проверенный десятилетиями способ -- анализ кода на бумажке. Вернее модернизированную версию. Сначала полуавтоматические инструменты позволяют выделить критические куски, а потом анализ этих кусков на бумажке. На бумажке потому, что удобно писать на полях

I>Я привел гораздо больше инструментов, нежели тесты и рефакторинг, например логи, профайлер, отладчик, анализатор кода и тд и тд.
И как же всё это поможет нам в одном из трёх приведённых случаев?

I>Но я сильно уверен, что ты через сообщение снова будешь рассказывать мне, что я де тесты назвал панацеей. Это один из твоих любимых приемов.
Разве это я про панацею написал? Ссылочку привести не затруднит?

Но я предлагаю не распыляться, и показать мастер-класс на модельной задаче
Если моя задача тебе не нравится, предложи свою. Только она должна содержать разработку и отладку небанального алгоритма.