Здравствуйте, kaa.python, Вы писали:
KP>Ну и ещё раз, серьёзный не-Windows проект ты просто не откроешь в VS. Скорее всего это будет монорепозиторий с Bazel, или CMake + Conan.
Здравствуйте, alex_public, Вы писали:
vaa>>пока еще браузер очень сильно ограничивает клиента в правах.
_>На самом деле уже давно нет. А если сравнивать скажем с мобильным (а не десктопным) приложением, то считай вообще почти одинаковый уровень возможностей (ну кроме некоторых достаточно специфических вещей).
Большая проблема браузера в том, что он на каждый чих запрашивает у пользователя разрешение и не запоминает их между сеансами. Это делает его намного неудобней обычных и мобильных приложений. Конечно это лучше, чем не иметь вообще АПИ, но всё равно недостаточно хорошо.
Здравствуйте, Serginio1, Вы писали:
S> Да но я не понимаю людей которые отказываются от VS в пользу консоли?
Так VS бесполезна (ну IDE как IDE, их как грязи сейчас), а консоль дает прямой доступ к разрабатываемой системе.
S> Это прежде всего отладка с кучей окон для мониторинга.
Это если тебе есть чего отлаживать отладчиком. Очень часто отлаживать под отладчиком можно разве что модульные тесты, в то время как отладка системы базируется на логах и модульных/интеграционных тестах.
S> Я пишу на C#. Это кроссплатформенный проект. И тема то как раз про него.
Могу только предположить что проект не взаимодействует достаточно много для того, что бы сделать отладку не возможной как класс.
S>как я уже писал отлаживать кроссплатформенный код проще в винде, а для уже отлаженного кода уже применять плюшки для линукса
Ну это прекрасно когда есть что отлаживать, а когда у тебя система распределённая, с несколькими потоками и еще и события постоянно генерируются внешние, ты просто не можешь поставить точки останова, т.к. она в корне меняет логику. Зачастую добавление одной лишней строки лога может сделать ошибку почти неуловимой, какой уж тут отладчик.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Во-первых железо. Если я ставлю более менее свежую винду на более менее свежее железо с более менее свежей периферией, то есть почти 100% гарантия того что все заработает с минимумом усилий. На линухе это до сих пор лотерея. В лучшем случае ты потратишь несколько дней на поиск драйверов, ядра и прочего стаффа, в худшем останешься без части железок.
Современная Убунта из коробки подхватывает вообще всё железо что есть. У меня на ноуте Убунта все сразу находит, а для Венды надо еще драйвера КАЧАТЬ и ставить В РУЧНУЮ. И это в 2022 году!
НС>Во-вторых софт. Из того что последние полгода было нужно — Иллюстратор, Фотошоп, Лайтрум, Архикад, Ворд/Эксель/Поверпоинт. Что из этого легко поставить на Убунту? И это я еще не игроман, с играми все намного смешнее выходит.
О, вот про это мне есть что сказать, как минимум про PS и C1 (ну или LR) Так вот, что на Windows, что на Ubuntu нормально работать с графикой очень геморно. Если хочешь делать что-то с графикой, то тебе без вариантов нужен macOS.
НС>В-третьих юзабилити. МС подрезал бюджет винды сравнительно недавно, и народ уже пищит. А в линухах никакого особого бюджета на UX никогда и не было. UX любого линуха по прежнему навевает вселенскую скуку и образы столлманов, жрущих мозоли, своей кустарщиной.
Так бубунтоделы особо и не думают про юзабилити, они просто из macOS тащат. А в macOS очень даже думают!
НС>Ага, главное себя в этом убедить.
Тут ты прав, я долго пытался себя убедить что "залезть на сайт производителя ПО, скачать инсталлятор, накликать ему кучу Ок, а потом не забывать периодически обновлять" это не хуже чем "sudo apt-get install bla-bla", но не смог.
Здравствуйте, Ночной Смотрящий, Вы писали:
KP>>Ну и ещё раз, серьёзный не-Windows проект ты просто не откроешь в VS. Скорее всего это будет монорепозиторий с Bazel, или CMake + Conan.
НС>А, опять чисто плюсовая боль.
Почему плюсовый? У меня сейчас проект несколько КК линий кода (там и C++, и Python, и Go и еще по мелочи), работа в монорепозитории. Как с этим в VS вообще совладать?
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Serginio1, Вы писали:
S>> Да но я не понимаю людей которые отказываются от VS в пользу консоли?
KP>Так VS бесполезна (ну IDE как IDE, их как грязи сейчас), а консоль дает прямой доступ к разрабатываемой системе.
Отладка в консоли это анахронизм! S>> Это прежде всего отладка с кучей окон для мониторинга.
KP>Это если тебе есть чего отлаживать отладчиком. Очень часто отлаживать под отладчиком можно разве что модульные тесты, в то время как отладка системы базируется на логах и модульных/интеграционных тестах.
Угу какой то сложный алгоритм нужно отладить в студии. Никто не пишет без ошибок.
И что бы понять где ошибка нужен стек вызова, значения переменных в каждом методе, список потоков итд
Нахрена мне консоль. Я выводом консоль даже в консольном приложении не пользуюсь.
Логи только для получения ошибок у клиентов.
S>> Я пишу на C#. Это кроссплатформенный проект. И тема то как раз про него.
KP>Могу только предположить что проект не взаимодействует достаточно много для того, что бы сделать отладку не возможной как класс.
Ну основное это облака. Там особо то нет специфики файловой системы итд. То ест базы данных,
S>>как я уже писал отлаживать кроссплатформенный код проще в винде, а для уже отлаженного кода уже применять плюшки для линукса
KP>Ну это прекрасно когда есть что отлаживать, а когда у тебя система распределённая, с несколькими потоками и еще и события постоянно генерируются внешние, ты просто не можешь поставить точки останова, т.к. она в корне меняет логику. Зачастую добавление одной лишней строки лога может сделать ошибку почти неуловимой, какой уж тут отладчик.
Почему не можешь? Переключаешься между потоками или их фризишь, точки останова с условием итд.
Еще раз конечно есть логи (в том числе бд) и есть программы для их анализа, но они нужны для отлова редко воспроизводимых ошибок. Для обычной отладки точек останова и стека вызова вполне достаточно.
А вот постоянно сидеть в консоли это анахронизм!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
KP>>Так VS бесполезна (ну IDE как IDE, их как грязи сейчас), а консоль дает прямой доступ к разрабатываемой системе. S> Отладка в консоли это анахронизм!
S> Угу какой то сложный алгоритм нужно отладить в студии. Никто не пишет без ошибок. S>И что бы понять где ошибка нужен стек вызова, значения переменных в каждом методе, список потоков итд S> Нахрена мне консоль. Я выводом консоль даже в консольном приложении не пользуюсь.
Вот как по мне, то что ты написал тут и есть анахронизм, я так в конце 2000-х писал
В современном мире, ты делишь сложный алгоритм на простые куски и для каждого простого куска пишешь юнит-тест. Потом собираешь куски в кучу, и пишешь еще один тест. Причем если сделать именно так, ты даже ни разу не откроешь отладчика, т.к. он просто не нужен.
S>Логи только для получения ошибок у клиентов.
Логи — это для отладки сложной, распределенной системы, поведение которой зависит от потоков данных.
S>>>как я уже писал отлаживать кроссплатформенный код проще в винде, а для уже отлаженного кода уже применять плюшки для линукса
Код хорошо покрытый тестами и логами в отладке не нуждается.
S> Еще раз конечно есть логи (в том числе бд) и есть программы для их анализа, но они нужны для отлова редко воспроизводимых ошибок. Для обычной отладки точек останова и стека вызова вполне достаточно.
А откуда взяться в коде просто воспроизводимым ошибкам, если он тестами покрыт? Ради интереса, у вашего проекта хотя бы 80% покрытие юнит-тестами есть?
KP>В современном мире, ты делишь сложный алгоритм на простые куски и для каждого простого куска пишешь юнит-тест. Потом собираешь куски в кучу, и пишешь еще один тест. Причем если сделать именно так, ты даже ни разу не откроешь отладчика, т.к. он просто не нужен.
Даа уж. Я так буду доолго писать! S>>Логи только для получения ошибок у клиентов.
KP>Логи — это для отладки сложной, распределенной системы, поведение которой зависит от потоков данных.
Не только. Прежде всего от кучи параметров и их сочетания. Это из NP-полная задача которую просто невозможно покрыть тестами.
S>>>>как я уже писал отлаживать кроссплатформенный код проще в винде, а для уже отлаженного кода уже применять плюшки для линукса
KP>Код хорошо покрытый тестами и логами в отладке не нуждается.
Напомню про NP-полная задача. Да и как ты собираешься покрывать например печать? отрисовку итд.
Как ты в тестах поймешь, что нарисовано, напечатано правильно? S>> Еще раз конечно есть логи (в том числе бд) и есть программы для их анализа, но они нужны для отлова редко воспроизводимых ошибок. Для обычной отладки точек останова и стека вызова вполне достаточно.
KP>А откуда взяться в коде просто воспроизводимым ошибкам, если он тестами покрыт? Ради интереса, у вашего проекта хотя бы 80% покрытие юнит-тестами есть?
Еще раз напомню про NP-полная задача. А на самом то деле они практически все такие. Слишком много параметров.
И на написание тестов уйдет больше времени, чем на написание программы!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
KP>>В современном мире, ты делишь сложный алгоритм на простые куски и для каждого простого куска пишешь юнит-тест. Потом собираешь куски в кучу, и пишешь еще один тест. Причем если сделать именно так, ты даже ни разу не откроешь отладчика, т.к. он просто не нужен. S> Даа уж. Я так буду доолго писать!
Зато цена поддержки сильно ниже и регрессии сразу отслеживаются, а не уже в проде. Что за хуяк-хуяк и в продакшн?
KP>>Логи — это для отладки сложной, распределенной системы, поведение которой зависит от потоков данных. S> Не только. Прежде всего от кучи параметров и их сочетания. Это из NP-полная задача которую просто невозможно покрыть тестами.
Всё можно покрыть тестами в достаточном объеме для предотвращения регрессий.
KP>>Код хорошо покрытый тестами и логами в отладке не нуждается. S> Напомню про NP-полная задача. Да и как ты собираешься покрывать например печать? отрисовку итд.
С печатью не уверен, но я бы попробовал печатать в PDF и сравнивать с ожидаемым образцом. Отрисовка — тут ничего не скажу, я вообще не спец по UI.
Подумал немного. Если говорить про печать, то сама фактическая печать это вызов 1-2 внешний API не имеющих отношения к твоей системе. В то время как подготовка данных для печати — это как раз логика работы твоего приложения. Если ты покроешь тестами подготовку данных, то саму печать (те самый 1-2 строчки кода) можно в тесте и проигнорировать. Всяко для UI приложения будет делаться минимальная регрессия в ручном режиме.
S>Как ты в тестах поймешь, что нарисовано, напечатано правильно?
В ряде случаев поможет сопоставление с образцом. В других случая — стоит спросить того кто и в современных методологиях разработки и в UI хорошо разбирается. Я ничего не могу про UI сказать.
S> Еще раз напомню про NP-полная задача. А на самом то деле они практически все такие. Слишком много параметров. S>И на написание тестов уйдет больше времени, чем на написание программы!
Нет, на написание тестов уйдет столько же времени, сколько и на написание программы, не больше, и это нормально. Так же не забываем про фаззинг, как раз для хитрой логики, которая может упасть на неожиданной комбинации входных данных.
Пока у меня ощущение, что если подход к разработке "хуяк-хуяк и в продакшн", то без отладчика никуда. Но так нельзя, так не возможно написать надежное и поддерживаемое приложение. И чсх, это делает утверждение "без VS не возможно разрабатывать" довольно забавным, я бы это переписал как "VS помогает говнокодить".
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Serginio1, Вы писали:
KP>>>В современном мире, ты делишь сложный алгоритм на простые куски и для каждого простого куска пишешь юнит-тест. Потом собираешь куски в кучу, и пишешь еще один тест. Причем если сделать именно так, ты даже ни разу не откроешь отладчика, т.к. он просто не нужен. S>> Даа уж. Я так буду доолго писать!
KP>Зато цена поддержки сильно ниже и регрессии сразу отслеживаются, а не уже в проде. Что за хуяк-хуяк и в продакшн?
KP>>>Логи — это для отладки сложной, распределенной системы, поведение которой зависит от потоков данных. S>> Не только. Прежде всего от кучи параметров и их сочетания. Это из NP-полная задача которую просто невозможно покрыть тестами.
KP>Всё можно покрыть тестами в достаточном объеме для предотвращения регрессий.
Не сможешь. На то они и NP-полная задача https://ru.wikipedia.org/wiki/NP-%D0%BF%D0%BE%D0%BB%D0%BD%D0%B0%D1%8F_%D0%B7%D0%B0%D0%B4%D0%B0%D1%87%D0%B0
KP>>>Код хорошо покрытый тестами и логами в отладке не нуждается. S>> Напомню про NP-полная задача. Да и как ты собираешься покрывать например печать? отрисовку итд.
KP>С печатью не уверен, но я бы попробовал печатать в PDF и сравнивать с ожидаемым образцом. Отрисовка — тут ничего не скажу, я вообще не спец по UI.
Угу нужно нарисовать все возможные образцы. Затем обучить нейронную сеть на сравнение картинок итд.
KP>Подумал немного. Если говорить про печать, то сама фактическая печать это вызов 1-2 внешний API не имеющих отношения к твоей системе. В то время как подготовка данных для печати — это как раз логика работы твоего приложения. Если ты покроешь тестами подготовку данных, то саму печать (те самый 1-2 строчки кода) можно в тесте и проигнорировать. Всяко для UI приложения будет делаться минимальная регрессия в ручном режиме.
Угу ну покрою я тестами и получу, что не так отрисовывает. И дальше в отладчик смотреть почему неправильно отрисовывает.
А это зависит от сотни, а то и тысячи параметров и алгоритмов. Библиотеки бывают ооочень сложными.
Иногда даже приходится лезть в чужой отдекомпилированный код, что бы понять почему и что не так.
S>>Как ты в тестах поймешь, что нарисовано, напечатано правильно?
KP>В ряде случаев поможет сопоставление с образцом. В других случая — стоит спросить того кто и в современных методологиях разработки и в UI хорошо разбирается. Я ничего не могу про UI сказать.
Проще посмотреть глазами и понять, что и как без юнит тестов. S>> Еще раз напомню про NP-полная задача. А на самом то деле они практически все такие. Слишком много параметров. S>>И на написание тестов уйдет больше времени, чем на написание программы!
KP>Нет, на написание тестов уйдет столько же времени, сколько и на написание программы, не больше, и это нормально. Так же не забываем про фаззинг, как раз для хитрой логики, которая может упасть на неожиданной комбинации входных данных.
Нет в сложных алгоримах ты не сможешь все покрыть. Это нереально. Там даже сочетание 2x интов может выдавать ошибку а если говорить о сотни то физически не сможешь даже дождаться окончания теста.
KP>Пока у меня ощущение, что если подход к разработке "хуяк-хуяк и в продакшн", то без отладчика никуда. Но так нельзя, так не возможно написать надежное и поддерживаемое приложение. И чсх, это делает утверждение "без VS не возможно разрабатывать" довольно забавным, я бы это переписал как "VS помогает говнокодить".
Я уже тебе написал, что многое просто невозможно покрыть тестами.
Ну и в итоге нашел ты ошибку, а дальше то надо понять почему она возникла. И здесь без отладки нужно анализировать, что и почему пошло не так.
Юнит тестами ты только найдешь входные параметры, а дальше уже идет перемалывание этих параметров кучей алгоритмов с кучей ветвлений итд.
Вот здесь то VS впереди планеты всей!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Ну и в итоге нашел ты ошибку, а дальше то надо понять почему она возникла. И здесь без отладки нужно анализировать, что и почему пошло не так. S>Юнит тестами ты только найдешь входные параметры, а дальше уже идет перемалывание этих параметров кучей алгоритмов с кучей ветвлений итд. S> Вот здесь то VS впереди планеты всей!
Я вот подумал, и ужаснулся. Ты ВООБЩЕ тесты не пишешь?!
Здравствуйте, kaa.python, Вы писали:
KP>Пока у меня ощущение, что если подход к разработке "хуяк-хуяк и в продакшн", то без отладчика никуда. Но так нельзя, так не возможно написать надежное и поддерживаемое приложение. И чсх, это делает утверждение "без VS не возможно разрабатывать" довольно забавным, я бы это переписал как "VS помогает говнокодить".
обычно, сколько вижу "здесь не покрыть тестами! здесь слишком сложный мок получается! здесь проще вх*ть шаблон БД с данными вручную и под дебагером тык-тык, разберемся быстро!" — это просто нежелание сесть, покурить примеры действительно сложных систем с изоляцией внешних сервисов в виде моков или стабов. Конечно, если система написана как-то так: procedure Button1Click(Sender: TObject); begin doSomeJob(false, false, 0, false, true, true, 0xDEADBEEF); if( state > 1 ) then doPrint(); end; то очень неохото привести в порядок. Ни в коем случае не утверждаю что у Serginio1 так и может и правда, в его системе вполне возможно прогнать все под отладчиком, но это только больше укрепляет веру в отладчик-всемогутор, до тех пор, пока его же система внезапно не будет встроена как микросервис в цепочке вызовов других сервисов и уже отладка если и будет возможна, то явно сложнее, чем почитать логи или тренироваться на моках
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Serginio1, Вы писали:
S>>Ну и в итоге нашел ты ошибку, а дальше то надо понять почему она возникла. И здесь без отладки нужно анализировать, что и почему пошло не так. S>>Юнит тестами ты только найдешь входные параметры, а дальше уже идет перемалывание этих параметров кучей алгоритмов с кучей ветвлений итд. S>> Вот здесь то VS впереди планеты всей!
KP>Я вот подумал, и ужаснулся. Ты ВООБЩЕ тесты не пишешь?!
Конечно пишу. Но просто невозможно покрыть все тестами. Кроме входных параметров нужно еще учитывать все состояние системы которые влияют на обработку этих параметров.
Ты вот полностью игнорируешь NP полные задачи.
Поделись опытом, как ты их тестируешь.
Еще раз ошибки есть в сторонних библиотеках. Как ты находишь ошибки в них?
Толку то, что ты нашел ошибку. Нужно понять почему она возникла. И входных параметров мало! Нужно еще и дамп памяти итд!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Отладка в консоли это анахронизм! S> А вот постоянно сидеть в консоли это анахронизм!
*facepalm*
Вместо того, чтобы упорно называть стандартную практику разработки в современном мире, лучше потратить немного времени, чтобы выглянуть из своего очень ограниченного мира Windows/VS программирования в весь остальной мир и посмотреть, как другие это делают. Думаю, пользы от такого занятия будет больше, ибо сможешь подсмотреть какие-то best practices и перенять их для себя.
Здравствуйте, Serginio1, Вы писали:
S> Ты вот полностью игнорируешь NP полные задачи. S> Поделись опытом, как ты их тестируешь. S> Еще раз ошибки есть в сторонних библиотеках. Как ты находишь ошибки в них?
kaa.python все правильно тут сказал, стоит прислушаться к его словам и подучить/подтянуть свои знания на тему как писать юнит тесты.
Здравствуйте, kaa.python, Вы писали:
KP>проще
Не соглашусь — это очень индивидуально.
У меня было несколько эпизодических задач, где требовалось написать небольшую утилитку, с условием, что она должна запускаться и работать в том числе под Linux.
Так как ничего платформ-специфичного не требовалось, я вполне успешно отлаживал всё под своей основной ОС (Windows) и, по сути, просто убеждался в работоспособности под Linux.
В такой ситуации поддерживать полноценную Linux-среду, разбираться в её инструментарии, переключаться (даже если это просто виртуальная машина), ... — ну вот никак у меня это не ассоциируется со словом проще.
KP>и надёжнее
Вот это — возможно, но опять же, если присутствует некая специфика платформы.
На сколько я понимаю, текущий WSL, это не просто хитрый промежуточный слой — это полноценная виртуальная среда с полноценным Linux (правда, своё, слегка допиленное ядро). Если не стоит каких-то сверх низкоуровневых задач, то отличия будут просто ничтожными.
Ну и я, с какой-то нестабильностью не сталкивался. Возможно, просто мало работал.
Здравствуйте, Serginio1, Вы писали:
S>Конечно пишу. Но просто невозможно покрыть все тестами. Кроме входных параметров нужно еще учитывать все состояние системы которые влияют на обработку этих параметров. S> Ты вот полностью игнорируешь NP полные задачи.
У меня нет таких задач (обычно, кажется...), а если бы и были, то всегда можно выделить достаточные для тестирования сценарии. И то что у тебя там нарисовано в веб сервере и напечатано тоже на такие задачи никак не тянет, так что мне не понятно зачем ты их тут вообще приплетаешь.
S> Еще раз ошибки есть в сторонних библиотеках. Как ты находишь ошибки в них? S>Толку то, что ты нашел ошибку. Нужно понять почему она возникла. И входных параметров мало! Нужно еще и дамп памяти итд!
Будут тесты которые покажут где конкретно падает и при каких входных данных. Будет лог который четко покажет как всё пошло не так. Почти всегда этого достаточно, в те редкие (меньше 1%, т.е. не каждый месяц даже) случае когда этого не достаточно, возьму корку со стеком вызовов в тесте, да погляжу что там пошло не так в одном маленьком, изолированном сценарии. В чем сложность? Не надо на всю систему глядеть, достаточно на очень небольшой сценарий. Мне думается, тебе и в правду было бы полезно заняться самообразованием, там всякие TDD и прочее. Ну нельзя же так работать, прогресс далеко шагнул, сильно дальше кропотливого изучения падения приложения в отладчике.
Здравствуйте, blacktea, Вы писали:
B>Здравствуйте, Serginio1, Вы писали:
S>> Отладка в консоли это анахронизм! S>> А вот постоянно сидеть в консоли это анахронизм!
B>*facepalm* B>Вместо того, чтобы упорно называть стандартную практику разработки в современном мире, лучше потратить немного времени, чтобы выглянуть из своего очень ограниченного мира Windows/VS программирования в весь остальной мир и посмотреть, как другие это делают. Думаю, пользы от такого занятия будет больше, ибо сможешь подсмотреть какие-то best practices и перенять их для себя.
У нас в студии есть окно вывода и куча других окон, что позволяет мониторить события.
Но главное это точки останова в критических местах, стек вызова и значения переменных.
Вот вопрос почему ты считаешь, что VS это отстой, а те кто не пользуются VS самые крутые перцы?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Serginio1, Вы писали:
S>>Конечно пишу. Но просто невозможно покрыть все тестами. Кроме входных параметров нужно еще учитывать все состояние системы которые влияют на обработку этих параметров. S>> Ты вот полностью игнорируешь NP полные задачи.
KP>У меня нет таких задач (обычно, кажется...), а если бы и были, то всегда можно выделить достаточные для тестирования сценарии. И то что у тебя там нарисовано в веб сервере и напечатано тоже на такие задачи никак не тянет, так что мне не понятно зачем ты их тут вообще приплетаешь.
Ну значит тебе вполне хватает консоли. На самом то деле многое зависит не от входных параметров, а от состояния системы.
Поэтому важнее дамп памяти. А что касается вэб сервера, то он занимается в том числе и печатью и еще кучей всего. Так сервис может состоять из сотни методов дергаемых клиентами.
И все это взаимосвязано. При этом есть взаимосвязь с кучей сторонних сервисов. И все это покрыть тестами невозможно!
Да создаются нагрузочные тесты, но можно упереться в сторонний сервис итд.
S>> Еще раз ошибки есть в сторонних библиотеках. Как ты находишь ошибки в них? S>>Толку то, что ты нашел ошибку. Нужно понять почему она возникла. И входных параметров мало! Нужно еще и дамп памяти итд!
KP>Будут тесты которые покажут где конкретно падает и при каких входных данных. Будет лог который четко покажет как всё пошло не так. Почти всегда этого достаточно, в те редкие (меньше 1%, т.е. не каждый месяц даже) случае когда этого не достаточно, возьму корку со стеком вызовов в тесте, да погляжу что там пошло не так в одном маленьком, изолированном сценарии. В чем сложность? Не надо на всю систему глядеть, достаточно на очень небольшой сценарий. Мне думается, тебе и в правду было бы полезно заняться самообразованием, там всякие TDD и прочее. Ну нельзя же так работать, прогресс далеко шагнул, сильно дальше кропотливого изучения падения приложения в отладчике.
Ну вот в итоге то тебе нужна отладка с точками останова, стеком вызова, оком потоков итд. Что и составляет основную задачу программиста!
А VS прекрасно для этого подходит!
А насчет образования поверь, я постоянно учусь невзирая на мои 58 лет. Если бы было все так просто, как ты пишешь, то ошибок не было бы ни у одной крупной компании. Однако чем больше проект, тем куча ошибок и куча обновлений с исправлениями ошибок.
А вот вам отвергающие студию явно нужно подучить её.
и солнце б утром не вставало, когда бы не было меня
RW>обычно, сколько вижу "здесь не покрыть тестами! здесь слишком сложный мок получается! здесь проще вх*ть шаблон БД с данными вручную и под дебагером тык-тык, разберемся быстро!" — это просто нежелание сесть, покурить примеры действительно сложных систем с изоляцией внешних сервисов в виде моков или стабов. Конечно, если система написана как-то так: procedure Button1Click(Sender: TObject); begin doSomeJob(false, false, 0, false, true, true, 0xDEADBEEF); if( state > 1 ) then doPrint(); end; то очень неохото привести в порядок. Ни в коем случае не утверждаю что у Serginio1 так и может и правда, в его системе вполне возможно прогнать все под отладчиком, но это только больше укрепляет веру в отладчик-всемогутор, до тех пор, пока его же система внезапно не будет встроена как микросервис в цепочке вызовов других сервисов и уже отладка если и будет возможна, то явно сложнее, чем почитать логи или тренироваться на моках
Ну логи то конечно есть и они анализируются. Куда же без них. Нашли ошибку решаем если возможно в студии. Или анализируя данные предполагаем решение,
если есть дамп памяти и без отладки можно решать кучу проблем. Вернее опять же в студии анализировать дамп памяти!
Опять же проще сначала отдельно оттестировать микросервис (не тратя время на запуск всей системы), а уж потом встраивается в систему с логами.
БбОльшая часть работы это точки останова, стек вызовов, окно вывода, потоки итд
и солнце б утром не вставало, когда бы не было меня
Так вот, что на Windows, что на Ubuntu нормально работать с графикой очень геморно. Если хочешь делать что-то с графикой, то тебе без вариантов нужен macOS. 
