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

I>>Давай проверим точки на одной прямой дают треугольник? Здорово, правда? Ноль тестов, значит этот кейс ты не учел. А так же не учел, что, скажем, из десериалазера вылезет точка null, с координатами Infinity и тд и тд.
PJ>Да, признаю, я не пытался обдумать определение треугольника, на что, справедливо, было указано. Если это пример, что и в своей задаче можно не всю модель учесть или учесть неверно, то это очевидно совершенно.
PJ>Ну так в результате-то что? Что ты пытался доказать? Что точки лежащие на одной прямой ты будешь ловить дебаггером?

Вопрос был: "Сколько тестов надо написать?"
Это демонстрация того самого человеческого фактора на твоём примере. Именно этот фактор и даёт основную часть ошибок.

Задача, которая казалась тривиальной, оказалась нетривиальной. Именно так и появляется человеческий фактор.
Скажем, в версии 1 у нас идут честные треугольники и всё работает.
А в версии 2 у нас скрытая поломка в интеграции и в проде изредка появляются отрезки прямых, точки, бесконечности, нули и тд.
Опаньки!

Здесь могут помочь различные подходы, в зависимости от симптомов, архитектуры и тд
1. какая нибудь валидация — скорее всего, раз тестов 0, ты об этом не думал.
2. логирование инпута — аналогично п1
3. отладчик

I>>Большая разница — чистота функции не гарантирует, что ты вберёшь в мозг все детали до единой за 0 времени.
PJ>Какие все детали? Функция должна делать ровно одну вещь используя ограниченное количество параметров. Если ты не можешь осилить это, то что тебе даст снапшот системы где 100500 параметров могут влиять друг на друга?

Обычные детали. Вот у тебя страховой кейс и тебе надо вычислить все выплаты, удержания и тд. Дано — страховка мамы, страховка папы, отдельно зубы у каждого, и ребенок, который частично на маминой страховке, частично на папиной.
И ошибка — иногда софтина некорректно рассчитывает выплаты, удержания и тд.
"Функция" которая считает это дело, не влазит ни в 1 экран кода, ни в 10, ни в 100 В ней заложено все текущее законодательство и особенности устройства конкретной конторы.

Соответсвенно мне не нужен снапшот всей системы — мне нужен конкретный срез под задачу.

I>>Соответсвенно, человеческий фактор в наличии. См выше, про треугольник.
PJ>А дебаггер его убирает что ли?

Вот у тебя вычисления пошли в 10 раз медленее, логов нет, валидацию ты не написал — раз тестов 0, то полагают и логики 0. Что делать, что бы побороть это дело?
Или так — сыплются странные ошибки, непонятной природы. В предыдущей версии на этом же наборе данных было всё хорошо.

I>>У тебя абсолютная память?
PJ>Нет, а нужна? Функция должна быть понятна даже если ты ее первый раз видишь.

Ок, см пример про страхование.

I>>А что здесь непонятно?
I>>N фич по 3 теста на фичу, дает нам N*3
I>>А если фичи интегрируются парами, то это уже 3*(N*3)^2
I>>А если тройками? И так — до N
I>>Сколько надо писать интеграционных тестов?
PJ>Вообще ничего не понятно. Какие-то цифры высосонные непонятно откуда. Интеграционные тесты тестируют валидность внешних контрактов. Им вообще пофиг для каких фич они используются.

Всё предельно просто — часть багов находится в самих юнитах, часть багов в коде интеграции. Что бы это все решить именно тестами, этих тестов приходится писать не линейное число O(n), относительно юнитов, а экспоненциальное O(n^x).

PJ>Что именно? Если ты без понятия о твоих контрактах, то как ты их можно использовать вообще? Типа оно случайно работает, если в дебаггере подобрать нужную комбинацию полей?

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

PJ>Из твоего примера я понял только что отлачик что-то мог показать, но мог так же ничего не показать. Вместо того, чтобы видя не сходжение баласа пересмотреть модель, как было сделано выше с тем же треугольником.

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

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

Что может быть проще американского медицинского страхования?

I>>Что такое "нет уровня время" ?
PJ>Это значит, что два такта спустя у тебя может быть совершенно другая картина и все твои выводы будут неверными.

Разумеется.

I>>Это в идеальном мире, где всё написано тобой. По факту таких примеров около 0. И полноценная функциональщина встречается чуть-чуть правее нуля.
PJ>Мы говорим о коде который ты пишешь сам.

Это тебе хочется говорить об этом. А я говорю о системе в целом.

I>>Это тебе лично хочется говорить о своей программе. А я только после обеда влез в три чужих проекта, которые ни раз не слышал.
I>>Прими как правило — чем выше позиция, тем больше чужого, неизвестного кода в работе.
PJ>Я встречал кучу людей который дорастали до архитекторов и прочих высоких позиций не видя вообще ничего кроме своего кода, работая 25 лет на одном месте.

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

PJ>К тому, если у тебя такая высокая позиция, но ты не можешь повлиять на качество кода и архитектуру, то не достиг ли ты своего потолка в принципе Питера?

Откуда следует "не можешь повлиять?" Надеюсь это не телепатия?

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

I>>О чем и речь. Ты выдумал свою теорию и влез с нею в чужой монастырь

L>Попрошу! Это мой монастырь.

Термины вида сценарий, юз кейс, тест кейс появились задолго до того, как ты в детский сад пошел. Гленфорд Мейерс опубликовал свою книгу ажно в 79м году.
Ты пока что яростно оспариваешь каждую букву этой книги

I>>Предположим, все тесты написаны верно, покрытие годное — валидный инпут, невалидный, пограничный.
I>>Количество тестов во все времена зависело от количества use case. Добавляешь use case, добавляешь хрен знает сколько тестов. Например, magnitude можно "дорабоать", что бы кроме вектора он принимал две точки, начало и конец. Упс! Добавили X тестов.

I>>Если добавим еще один сценарий, например, magnitude может принимать вектор в полярных координатах, добавим еще Y тестов.
L>Добавляем, какие проблемы?

Проблема в том, что это всегда ограниченое число проверок, то есть, метод дискретный.
Никто в своем уме не проверяет все пространство Int32, не говоря про Int64 или Double или BigInt.

Вопрос — как добиться непрерывности ? Представь — ошибка исчисляется миллионами долларов. Как быть?

I>>Ты недавно признался в том, что даже язык на 100% не знаешь. А платформа, например, гораздо сложнее А если покрывать все ветвления, то слишком многие вещи дают астрономическое количество тестов.

L>Вот поэтому тестировать нужно юниты. Которые нужно дробить до тех, которые удобно тестировать.

Юниты проявляют свои баги в комбинациях, в интеграции и тд. А следовательно число тестов экспоненциальное.

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

I>>>О чем и речь. Ты выдумал свою теорию и влез с нею в чужой монастырь
L>>Попрошу! Это мой монастырь.
I>Термины вида сценарий, юз кейс, тест кейс появились задолго до того, как ты в детский сад пошел. Гленфорд Мейерс опубликовал свою книгу ажно в 79м году.

Если бы эта книга задала industry standard, то я бы с тобой согласился

I>Ты пока что яростно оспариваешь каждую букву этой книги

Но пока что даже в этом чати только и слышно "я быстренько в отладчике найду и поправлю".

L>>Добавляем, какие проблемы?
I>Проблема в том, что это всегда ограниченое число проверок, то есть, метод дискретный.
I>Никто в своем уме не проверяет все пространство Int32, не говоря про Int64 или Double или BigInt.
I>Вопрос — как добиться непрерывности ? Представь — ошибка исчисляется миллионами долларов. Как быть?

Мелко берешь. Ошибка измеряется человеческими жизнями. Как быть?

I>>>Ты недавно признался в том, что даже язык на 100% не знаешь. А платформа, например, гораздо сложнее А если покрывать все ветвления, то слишком многие вещи дают астрономическое количество тестов.
L>>Вот поэтому тестировать нужно юниты. Которые нужно дробить до тех, которые удобно тестировать.
I>Юниты проявляют свои баги в комбинациях, в интеграции и тд. А следовательно число тестов экспоненциальное.

Число комбинаций и интеграций — линейное. Следовательно, число тестов — линейно.

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

S>Перед продом, софт проходит через отделы тестирования, которые и выявляют 90% всех ошибок за пару недель. Для того чтобы тестами выявить то, что они находят, тесты нужно писать два года.

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

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

Pzz>>Есть, похоже, люди, которым он не нужен вовсе и люди, которые не совсем представляют, как без него можно жить.
CC>Не ну есть люди которые освоили шуруповёрт а есть те, кто шурупы молотком загоняют и кричат что ничего другого им не нужно, да.

А есть еще люди, которые все делают швейцарским ножом, и никакие отвертки, шуруповерты и молотки им не нужны.

У них, наверное, руки очень сильные. Я лично швейцарским ножом никакой нормальный шуруп не завинчу.

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

L>>>Попрошу! Это мой монастырь.
I>>Термины вида сценарий, юз кейс, тест кейс появились задолго до того, как ты в детский сад пошел. Гленфорд Мейерс опубликовал свою книгу ажно в 79м году.

L>Если бы эта книга задала industry standard, то я бы с тобой согласился

Эти термины старше чем книга этого мэтра

I>>Ты пока что яростно оспариваешь каждую букву этой книги
L>Но пока что даже в этом чати только и слышно "я быстренько в отладчике найду и поправлю".

Ты плохо читаешь. Я утверждаю, что классы решаемых задач у тестов и отладчика всего лишь пересекаются
1 тесты фиксируют ожидания
2 отладчик дает возможность исследовать систему, когда не знаешь, чего ожидать

I>>Никто в своем уме не проверяет все пространство Int32, не говоря про Int64 или Double или BigInt.
I>>Вопрос — как добиться непрерывности ? Представь — ошибка исчисляется миллионами долларов. Как быть?

L>Мелко берешь. Ошибка измеряется человеческими жизнями. Как быть?

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

L>>>Вот поэтому тестировать нужно юниты. Которые нужно дробить до тех, которые удобно тестировать.
I>>Юниты проявляют свои баги в комбинациях, в интеграции и тд. А следовательно число тестов экспоненциальное.

L>Число комбинаций и интеграций — линейное. Следовательно, число тестов — линейно.

Ты путаешь линейность и конечность. Надо всего то перебрать все комбинации пар, все комбинации троек, все комбинации четверок... и так до N

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

L>>Если бы эта книга задала industry standard, то я бы с тобой согласился
I>Эти термины старше чем книга этого мэтра
I>>>Ты пока что яростно оспариваешь каждую букву этой книги
L>>Но пока что даже в этом чати только и слышно "я быстренько в отладчике найду и поправлю".
I>Ты плохо читаешь. Я утверждаю, что классы решаемых задач у тестов и отладчика всего лишь пересекаются
I>1 тесты фиксируют ожидания
I>2 отладчик дает возможность исследовать систему, когда не знаешь, чего ожидать

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

I>>>Никто в своем уме не проверяет все пространство Int32, не говоря про Int64 или Double или BigInt.
I>>>Вопрос — как добиться непрерывности ? Представь — ошибка исчисляется миллионами долларов. Как быть?
L>>Мелко берешь. Ошибка измеряется человеческими жизнями. Как быть?
I>Уже лучше. В таких случаях юнит-тестов недостаточно из-за их дискретности, а потому используются те самые вещи, про которые я говорю и которые ты почему то назвать не можешь

Те самые вещи, которые ты почему-то стесняешься назвать, не заменяют юнит-тесты.

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

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

Ты хочешь вернуться к удалению файла? Там именно последовательность событий

I>>>>Никто в своем уме не проверяет все пространство Int32, не говоря про Int64 или Double или BigInt.
I>>>>Вопрос — как добиться непрерывности ? Представь — ошибка исчисляется миллионами долларов. Как быть?
L>>>Мелко берешь. Ошибка измеряется человеческими жизнями. Как быть?
I>>Уже лучше. В таких случаях юнит-тестов недостаточно из-за их дискретности, а потому используются те самые вещи, про которые я говорю и которые ты почему то назвать не можешь

L>Те самые вещи, которые ты почему-то стесняешься назвать, не заменяют юнит-тесты.

Не я, а ты Я то их назвал много раз, но ты даже не заметил этого

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


I>Вопрос был: "Сколько тестов надо написать?"
I>Это демонстрация того самого человеческого фактора на твоём примере. Именно этот фактор и даёт основную часть ошибок.
Ну спасибо, кэп. Все еще не очевидно, как ты хотел доказать пользу дебаггера вот этим примером. Оно если что и доказывает, то ровно обратное — его полную бесполезновть в данном конкретном случае.
Если ты выяснишь в дебаггере, что треугольник 1,2,3 4,5,6 7,8,9 не работает. То выяснять, что эти точки лежат на одной прямой ты будешь долго и мучительно, потому как не прочитал определение в первом случае.
Если вместо этого ты задашься вопросом "правильно ли я понял модель" и таки прочитаешь определение, то дебаггер не понадобиться, так как в модели очевидный изъян.

I>А в версии 2 у нас скрытая поломка в интеграции и в проде изредка появляются отрезки прямых, точки, бесконечности, нули и тд.
Что такое скрытая поломка интеграции? Интеграция проверяет, что твой апи выдает вылидную производную от твоей модели. В любом случае первой рассматривается модель, а не ее интеграция. Пока модель не исправлена дебажить все остальное даже не имеет смысла, это никак не приблизит тебя к ответу.

I>Здесь могут помочь различные подходы, в зависимости от симптомов, архитектуры и тд
I>1. какая нибудь валидация — скорее всего, раз тестов 0, ты об этом не думал.
I>2. логирование инпута — аналогично п1
I>3. отладчик

0. Ретроспектива модели. Все остальное бесполезно. Если ты не понимаешь модель, то и не можешь ее правильно провалидировать, логирование инпута и дебаг тоже ничего не даст, так как ты все еще не знаешь как это привязать к модели.

I>>>Большая разница — чистота функции не гарантирует, что ты вберёшь в мозг все детали до единой за 0 времени.
PJ>>Какие все детали? Функция должна делать ровно одну вещь используя ограниченное количество параметров. Если ты не можешь осилить это, то что тебе даст снапшот системы где 100500 параметров могут влиять друг на друга?

I>Обычные детали. Вот у тебя страховой кейс и тебе надо вычислить все выплаты, удержания и тд. Дано — страховка мамы, страховка папы, отдельно зубы у каждого, и ребенок, который частично на маминой страховке, частично на папиной.
I>И ошибка — иногда софтина некорректно рассчитывает выплаты, удержания и тд.
I>"Функция" которая считает это дело, не влазит ни в 1 экран кода, ни в 10, ни в 100 В ней заложено все текущее законодательство и особенности устройства конкретной конторы.
Если тебе платят по часам за фикс каждого бага, то ты конечно полезешь отлаживать. И еще костылей добавишь, чтобы потом дольше зависать. Если платят не за время, а за результат и это надо поддерживать в будущем, то это надо переписать, а не дебажить.

I>Соответсвенно мне не нужен снапшот всей системы — мне нужен конкретный срез под задачу.
Это же индус-стайл.

I>Вот у тебя вычисления пошли в 10 раз медленее, логов нет, валидацию ты не написал — раз тестов 0, то полагают и логики 0. Что делать, что бы побороть это дело?
I>Или так — сыплются странные ошибки, непонятной природы. В предыдущей версии на этом же наборе данных было всё хорошо.
Если логики ноль, то ничего работать не будет, это просто определение. А если что-то работает, то логики уже не ноль и тесты можно сделать.

PJ>>Нет, а нужна? Функция должна быть понятна даже если ты ее первый раз видишь.
I>Ок, см пример про страхование.
Я сомневаюсь, что это был пример чистой функции. Разумеется можно наговнокодить так, что понять не сможет никто, даже с дебаггером.

I>Всё предельно просто — часть багов находится в самих юнитах, часть багов в коде интеграции. Что бы это все решить именно тестами, этих тестов приходится писать не линейное число O(n), относительно юнитов, а экспоненциальное O(n^x).
Твой пример выше не решишь никакими тестами. Это решается переписыванием. Дебажить ты это будешь вечно, как и писать тесты. Забег на вечность, все как ты любишь. Непонятно только почему ты это считаешь правильным и разумным поведением?

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

I>Именно что смог — пошагово захожу в функцию и вижу, что валидация не работает для некоторых модулей, маленькая человеческая ошибка, как в твоем случае с треугольником. Некто решил, что это тривиальная вещь, но создал пустое правило в конфиге. В первой версии работало, потому что ничего военного не случалось, а во второй это правило забыли обновить. Когда правило отсутствует, движок пишет в лог варнинг. А здесь есть, хотя и пустое, движок проглатывает и выдает Valid.
А что мешает в нее просто зайти, а не пошагово? У тебя есть ситуация и есть функция которая должна это не допустить. Если ее не писали 100 индусов под гашишем, то зачем начинать с отладки?

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

PJ>>Это значит, что два такта спустя у тебя может быть совершенно другая картина и все твои выводы будут неверными.
I>Разумеется.
Ну т.е., разумеется, твои данные о системе неполны.

I>Это тебе хочется говорить об этом. А я говорю о системе в целом.
А тебе хочется пообсуждать проблемы работы с индуским спаггетти кодом? Это надо в общество анонимных быдлокодеров идти.

I>Тем не менее, в норме с ростом квалификации доля чужого растет. Все очень просто — сначала ты пилишь свое, а потом ты свое готовое внедряешь другим. И на этом этапе надо влазить в чужой код.
Это твоя сова натянутая на весь глобус, а не норма. С ростом квалификации ты пишешь более лучший код, только и всего. Внедрение это какая-то уже другая специализация, вообще хз, что ты под ним понимаешь.

I>Откуда следует "не можешь повлиять?" Надеюсь это не телепатия?
Т.е. ты повлиять можешь, но вместо этого продолжаешь страдать дебажа говнокод? Ты противоречия никакого не видишь?

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

I>>Вопрос был: "Сколько тестов надо написать?"
I>>Это демонстрация того самого человеческого фактора на твоём примере. Именно этот фактор и даёт основную часть ошибок.
PJ>Ну спасибо, кэп. Все еще не очевидно, как ты хотел доказать пользу дебаггера вот этим примером.

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

I>>А в версии 2 у нас скрытая поломка в интеграции и в проде изредка появляются отрезки прямых, точки, бесконечности, нули и тд.
PJ>Что такое скрытая поломка интеграции? Интеграция проверяет, что твой апи выдает вылидную производную от твоей модели.

Скрытая — значит еще не обнаруженая. У тебя есть секрет обнаружения 100% багов?

I>>Здесь могут помочь различные подходы, в зависимости от симптомов, архитектуры и тд
I>>1. какая нибудь валидация — скорее всего, раз тестов 0, ты об этом не думал.
I>>2. логирование инпута — аналогично п1
I>>3. отладчик

PJ>0. Ретроспектива модели.

То есть, ты собираешься сравнивать N версий дерева из тысяч а возможно и сотен тысяч элеметов, правильно я тебя понял?

I>>"Функция" которая считает это дело, не влазит ни в 1 экран кода, ни в 10, ни в 100 В ней заложено все текущее законодательство и особенности устройства конкретной конторы.
PJ>Если тебе платят по часам за фикс каждого бага, то ты конечно полезешь отлаживать. И еще костылей добавишь, чтобы потом дольше зависать. Если платят не за время, а за результат и это надо поддерживать в будущем, то это надо переписать, а не дебажить.

На секундочку — ты собрался переписывать код, который создавался большой конторой в течение последних 20 лет
А задача — пофиксить баг и выпустить патч-релиз.

I>>Или так — сыплются странные ошибки, непонятной природы. В предыдущей версии на этом же наборе данных было всё хорошо.
PJ>Если логики ноль, то ничего работать не будет, это просто определение. А если что-то работает, то логики уже не ноль и тесты можно сделать.

И на какую из подсистем ты собираешься писать тесты? Ну вот 'access violation', например, без стек трейса. Как быть? Каким чудом заподозрить, что такая ошибка возникла именно из за треугольников а не остальных 100500 фич?

PJ>>>Нет, а нужна? Функция должна быть понятна даже если ты ее первый раз видишь.
I>>Ок, см пример про страхование.
PJ>Я сомневаюсь, что это был пример чистой функции. Разумеется можно наговнокодить так, что понять не сможет никто, даже с дебаггером.

Баги фиксятся по конкретным последовательностями или симптомам, типа
— сегодня отредактировали
— видим изменения
— через N часов данные меняются сами собой
— аудит отваливается и говорит, что данных вообще нет
— рестарт сервера не помогает
Твои действия?

I>>Всё предельно просто — часть багов находится в самих юнитах, часть багов в коде интеграции. Что бы это все решить именно тестами, этих тестов приходится писать не линейное число O(n), относительно юнитов, а экспоненциальное O(n^x).
PJ>Твой пример выше не решишь никакими тестами. Это решается переписыванием.

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

I>>Именно что смог — пошагово захожу в функцию и вижу, что валидация не работает для некоторых модулей, маленькая человеческая ошибка, как в твоем случае с треугольником. Некто решил, что это тривиальная вещь, но создал пустое правило в конфиге. В первой версии работало, потому что ничего военного не случалось, а во второй это правило забыли обновить. Когда правило отсутствует, движок пишет в лог варнинг. А здесь есть, хотя и пустое, движок проглатывает и выдает Valid.
PJ>А что мешает в нее просто зайти, а не пошагово? У тебя есть ситуация и есть функция которая должна это не допустить. Если ее не писали 100 индусов под гашишем, то зачем начинать с отладки?

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

I>>Что может быть проще американского медицинского страхования?
PJ>Оно может быть скольугодно сложным. Но любая сложная вещь состоит из множества простых. Работа программиста и состоит в том, чтобы эту декомпозицию выполнить.

Это все требует времени которое далеко не всегда в наличии.

I>>Тем не менее, в норме с ростом квалификации доля чужого растет. Все очень просто — сначала ты пилишь свое, а потом ты свое готовое внедряешь другим. И на этом этапе надо влазить в чужой код.
PJ>Это твоя сова натянутая на весь глобус, а не норма. С ростом квалификации ты пишешь более лучший код, только и всего. Внедрение это какая-то уже другая специализация, вообще хз, что ты под ним понимаешь.

Именно — рост от джуна к сеньору и выше это последовательная смена специализаций. А лучший код — это горизонтальный рост, никакого сеньорства здесь нет.

I>>Откуда следует "не можешь повлиять?" Надеюсь это не телепатия?
PJ>Т.е. ты повлиять можешь, но вместо этого продолжаешь страдать дебажа говнокод? Ты противоречия никакого не видишь?

Нет противоречия. Вот мы сделали свой пакет и 80 приложений перешли на него, а ради этого выбросили свои спагетти. Что бы помочь им в этом, я провожу время в ихнем коде. Но это не в один клик, а занимает время.

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

I>Этим примером я показал тебе человеческий фактор на твоем вот примере
Ты сделал очень большой крюк, чтобы выдать вот такую банальность. А что кто-то отрицал человеческий фактор?

I>>>А в версии 2 у нас скрытая поломка в интеграции и в проде изредка появляются отрезки прямых, точки, бесконечности, нули и тд.
PJ>>Что такое скрытая поломка интеграции? Интеграция проверяет, что твой апи выдает вылидную производную от твоей модели.

I>Скрытая — значит еще не обнаруженая. У тебя есть секрет обнаружения 100% багов?
Если она не обнаружена, то ты ее никак не видишь. А если у тебя появляются отрезки вместо треугольников, то проблема обнаружена. И первое что любой следует сделать — убедиться, что апи гарантированно возвращает валидный треугольник. Что сразу вовзращает нас к вопросу, а правльно ли мы поняли определение треугольника и... ну ты понял.

I>То есть, ты собираешься сравнивать N версий дерева из тысяч а возможно и сотен тысяч элеметов, правильно я тебя понял?
Че? Нет, ты тут о чем-то своем. Модель это выраженный в коде инвариант твоего страхового случая.


I>На секундочку — ты собрался переписывать код, который создавался большой конторой в течение последних 20 лет
Ой, а это нельзя? Если большая компания и аж 20 лет, то это как в граните отлито?

I>А задача — пофиксить баг и выпустить патч-релиз.
Я видел случаи когда реально добавлялся if на баг и просто исправлялись данные. Типа ожидается 5, а пришло 4. Ну и пишем if (x == 4) x = 5
Ты, стесняюсь спросить, из таких же? А че, фиксит же баг?!

I>И на какую из подсистем ты собираешься писать тесты? Ну вот 'access violation', например, без стек трейса. Как быть? Каким чудом заподозрить, что такая ошибка возникла именно из за треугольников а не остальных 100500 фич?
А о чем именно речь? О коде, что ты привел выше? Там я никаких тестов писать не собираюсь, они бесполезны. В моем коде? В моем коде это сайд-эффект, и место где оно возникнет искать даже не надо, сразу понятно куда лезть — место где модель преобразуется в системный вызов, который что-то делает с памятью. Получить его случайным образом практически невозможно. Вероятнее всего я даже скомпилировать не смогу такую программу.

PJ>>>>Нет, а нужна? Функция должна быть понятна даже если ты ее первый раз видишь.
I>>>Ок, см пример про страхование.
PJ>>Я сомневаюсь, что это был пример чистой функции. Разумеется можно наговнокодить так, что понять не сможет никто, даже с дебаггером.

I>Баги фиксятся по конкретным последовательностями или симптомам, типа
Ждали 5, а пришло 4?
Ну может у вас они так и фиксятся. А так-то фиксятся не баги, а причина их появления.

I>- сегодня отредактировали
I>- видим изменения
I>- через N часов данные меняются сами собой
I>- аудит отваливается и говорит, что данных вообще нет
I>- рестарт сервера не помогает
I>Твои действия?
Отделить сайд-эффекты от логики, проверить валидность логики, если проблема сохраняется, если модель верна, а проблема сохраняется, то она на границе домена. Это учень узкий слой. Ну, не знаю, сиквел запрос направильно написал. Ну там уже по обстаятельства. Если вот так непонятно в чем проблема, я бы дебаггер запустил, просто от лени. Но легко представляю, что кто-то может выразить эту пробелему тестами, дабы не повторялось. Но вот именно в этом случае, когда я понимаю где проблема, не пониваю почему я ее не вижу в коде. Сидеть и часами дебажить несколько страниц кода в надежде понять логику это безумие. Я так делал, когда бы юн и глуп.

I>Мой опыт говорит, что переписыванием вообще ничего не решается Именно по этому до сих пор Кобол до сих пор один из лидеров по количеству строк.
Не, ну если переписывать так же и в том же стиле, то конечно ничего не решится.

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

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

I>Именно — рост от джуна к сеньору и выше это последовательная смена специализаций. А лучший код — это горизонтальный рост, никакого сеньорства здесь нет.
Рост от джуна к сеньору это как раз вертикальная, горизонтальная это все остальное. Лид это уже горизонтальное смещение, вместо разработки — управление. Много свого тут не попишешь, да.

I>>>Откуда следует "не можешь повлиять?" Надеюсь это не телепатия?
PJ>>Т.е. ты повлиять можешь, но вместо этого продолжаешь страдать дебажа говнокод? Ты противоречия никакого не видишь?

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

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

I>>Этим примером я показал тебе человеческий фактор на твоем вот примере
PJ>Ты сделал очень большой крюк, чтобы выдать вот такую банальность. А что кто-то отрицал человеческий фактор?

Ты и отрицаешь. У тебя "чистая функция" вдруг становится гарантией отсутствия ошибок

I>>Скрытая — значит еще не обнаруженая. У тебя есть секрет обнаружения 100% багов?
PJ>Если она не обнаружена, то ты ее никак не видишь. А если у тебя появляются отрезки вместо треугольников, то проблема обнаружена.

На самом деле у тебя только симптом. Например, симптомом может быть и просто увеличившееся время работы или непонятные сообщения или вообще что угодно.
Обнаружить проблему и обнаружить симптом это две большие разницы.

I>>То есть, ты собираешься сравнивать N версий дерева из тысяч а возможно и сотен тысяч элеметов, правильно я тебя понял?
PJ>Че? Нет, ты тут о чем-то своем. Модель это выраженный в коде инвариант твоего страхового случая.

Инварианты это хорошая вещь, но так же как и тесты, не гарантирует 100% случаев.

I>>На секундочку — ты собрался переписывать код, который создавался большой конторой в течение последних 20 лет
PJ>Ой, а это нельзя? Если большая компания и аж 20 лет, то это как в граните отлито?

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

I>>А задача — пофиксить баг и выпустить патч-релиз.
PJ>Я видел случаи когда реально добавлялся if на баг и просто исправлялись данные. Типа ожидается 5, а пришло 4. Ну и пишем if (x == 4) x = 5
PJ>Ты, стесняюсь спросить, из таких же? А че, фиксит же баг?!

Не можешь удержаться что бы нахамить?

I>>И на какую из подсистем ты собираешься писать тесты? Ну вот 'access violation', например, без стек трейса. Как быть? Каким чудом заподозрить, что такая ошибка возникла именно из за треугольников а не остальных 100500 фич?
PJ>А о чем именно речь? О коде, что ты привел выше? Там я никаких тестов писать не собираюсь, они бесполезны.

О том и речь. Зато после решения проблемы тесты очень даже пригодятся. А вот для локализации и идентификации тесты как то не очень.

I>>Баги фиксятся по конкретным последовательностями или симптомам, типа
PJ>Ждали 5, а пришло 4?
PJ>Ну может у вас они так и фиксятся. А так-то фиксятся не баги, а причина их появления.

Ага, один ты умный.

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

Валидность логики — это забег на много дней В системе от 1..10 mloc, надо бы как то локализовать

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

А почему ты думаешь, что дебажить надо не иначе как часами? Типичный кейс для отладки — пару минут.

I>>Мой опыт говорит, что переписыванием вообще ничего не решается Именно по этому до сих пор Кобол до сих пор один из лидеров по количеству строк.
PJ>Не, ну если переписывать так же и в том же стиле, то конечно ничего не решится.

"Переписывать" — такое бизнесу непонятно, а за непонятное бюджет не дают.

I>>Без отладки я вообще не знаю, в чем причина и в какой модуль заглядывать.
PJ>Т.е. спагетти код, который непонятно что делает, как делает и где делает. Такой надо отлаживать да. Хотя обычно как мертвому припарки. В одном починишь, в другом отвалится.

Я тебе про большую систему, а тебе мерещится спагетти

I>>Это все требует времени которое далеко не всегда в наличии.
PJ>Отладка одно из самых затраных по времени и умственному напряжению занятий. У тебя, как в том анекдоте, нет времени топор наточить?

А еще это одно из самых эффективных занятий при правильном подходе.

I>>Именно — рост от джуна к сеньору и выше это последовательная смена специализаций. А лучший код — это горизонтальный рост, никакого сеньорства здесь нет.
PJ>Рост от джуна к сеньору это как раз вертикальная, горизонтальная это все остальное. Лид это уже горизонтальное смещение, вместо разработки — управление. Много свого тут не попишешь, да.

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

I>>Нет противоречия. Вот мы сделали свой пакет и 80 приложений перешли на него, а ради этого выбросили свои спагетти. Что бы помочь им в этом, я провожу время в ихнем коде. Но это не в один клик, а занимает время.
PJ>Это уже какой-то саппорт, а не разработка. Что угодно, но только не рост.

Это не саппорт, а внедрение. Без этого ты не знаешь, что вообще нужно от твоего солюшна.

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


I>Ты и отрицаешь. У тебя "чистая функция" вдруг становится гарантией отсутствия ошибок
Я написал, что у нее детерменированное поведение. Это у тебя отсутствие ошибок?

I>На самом деле у тебя только симптом. Например, симптомом может быть и просто увеличившееся время работы или непонятные сообщения или вообще что угодно.
I>Обнаружить проблему и обнаружить симптом это две большие разницы.
И что конкретно ты собираешься дебажить в этом случае?

I>Инварианты это хорошая вещь, но так же как и тесты, не гарантирует 100% случаев.
Нет, не гарантирует. Но избавляет от необходимости дебажить каждый чих, а так же делает очевидным места где искать проблему.

I>>>На секундочку — ты собрался переписывать код, который создавался большой конторой в течение последних 20 лет
PJ>>Ой, а это нельзя? Если большая компания и аж 20 лет, то это как в граните отлито?

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

I>Не можешь удержаться что бы нахамить?
Ой, да прям там. Вполне логичный вопрос. Ты сам дал понять, что тебя волную только фикс и сроки. Мне интересно волнует ли тебя качество твого фикса?

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

I>Ага, один ты умный.
Нет, не один.

I>Валидность логики — это забег на много дней В системе от 1..10 mloc, надо бы как то локализовать
Если ты не понимаешь как оно работает, то как ты определяешь корректность твоего фикса? Как ты определяешь, что именно решил проблему, а не скрыл симптом?

I>А почему ты думаешь, что дебажить надо не иначе как часами? Типичный кейс для отладки — пару минут.
Если типичный фикс пару минут, то это что-то очень простое, которое при должной культуре и появится не должно. Я тут не могу комментировать, не видя вашу систему, типичные случаи и типичные фиксы.

I>"Переписывать" — такое бизнесу непонятно, а за непонятное бюджет не дают.
Ну ты-то понял? Я тут вроде не с бизнесом разговариваю.

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

I>А еще это одно из самых эффективных занятий при правильном подходе.
одно из самых неэффективных.

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

I>Это не саппорт, а внедрение. Без этого ты не знаешь, что вообще нужно от твоего солюшна.
Если ты копаешь в коде клиентов, то это саппорт. Но ты можешь называть это внедрением, конечно.

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

CC>>

L>>>я считаю, что использование программистом отладчика в процессе разработки недопустимо.

PJ>Мне кажется это подразумевается. Иначе какая же это разработка?!
С чего бы? Код пишется для работы не в вакууме, он будет взаимодействовать с чужим кодом. Причём как вызывать его так и вызываться им.

PJ>И мысль его вполне простая и очевидная — не следует подпирать костылями кривые решения, а если их не давать в руки, то и соблазна не будет.
Мы уже выяснили реальные причины его фобии.

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

PJ>>Мне кажется это подразумевается. Иначе какая же это разработка?!
CC>С чего бы? Код пишется для работы не в вакууме, он будет взаимодействовать с чужим кодом. Причём как вызывать его так и вызываться им.

Сидит команда и пишет игру, допустим. С каким чужим кодом она взаимодействует? ОС?

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

PJ>Сидит команда и пишет игру, допустим. С каким чужим кодом она взаимодействует? ОС?
Ты не поверишь!
Те же дрова видюхи полны сюрпризов, и видеокарта сама порой выкидывает коленца, + кучка стороннего middleware для звука, физики, рендеринга итп.

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

I>>Ты и отрицаешь. У тебя "чистая функция" вдруг становится гарантией отсутствия ошибок
PJ>Я написал, что у нее детерменированное поведение. Это у тебя отсутствие ошибок?

Посмотри на свои сообщения в данной теме. Ты чистоту функций тащишь как решение каждой проблемы.

I>>На самом деле у тебя только симптом. Например, симптомом может быть и просто увеличившееся время работы или непонятные сообщения или вообще что угодно.
I>>Обнаружить проблему и обнаружить симптом это две большие разницы.
PJ>И что конкретно ты собираешься дебажить в этом случае?

Я собираюсь установить, симптомом чего является наблюдаемое поведение. Например, если летят странные ошибки, то легче всего и посмотреть сразу этот источник. Это занимает секунды и даёт ответ в большинстве случаев.
Разумеется, это актуально, если нет способов получше. И тесты в их число не входят, т.к. тестами уже все что надо покрыто.

I>>Инварианты это хорошая вещь, но так же как и тесты, не гарантирует 100% случаев.
PJ>Нет, не гарантирует. Но избавляет от необходимости дебажить каждый чих, а так же делает очевидным места где искать проблему.

Цитирую себя:
"для диагностики лучше использовать проверки типа инвариантов, пред-, пост- условий" @ Ikemefula

Автор: Ikemefula
Дата: 06.05.20

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

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

На мой взгляд латание гораздо чаще встречается
1 в бОльшей части продуктовых проектов, т.к. здесь в норме крутятся как белка в колесе. Далеко не все утруждают себя такими вещами как требования.
2 у мелких заказчиков
3 у нервных паникующих менеджеров вне зависимости аутсорс, продукт, заказ или еще что

I>>Не можешь удержаться что бы нахамить?
PJ>Ой, да прям там. Вполне логичный вопрос. Ты сам дал понять, что тебя волную только фикс и сроки. Мне интересно волнует ли тебя качество твого фикса?

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

I>>О том и речь. Зато после решения проблемы тесты очень даже пригодятся. А вот для локализации и идентификации тесты как то не очень.
PJ>Явно не об этом. Тесты тут просто бесполезны. И до и после. Ты просто физически не сможешь их написать достаточно, чтобы создать инвариант хотя бы так. Единственное разумное решение тут переделывать дизайн, изолируя части и их уже тестировать.

Это смотря что за проблема. Как я говорил — большинство ошибок это человеческий фактор. Пропущеную валидацию очень даже можно включить и покрыть тестами.

I>>Валидность логики — это забег на много дней В системе от 1..10 mloc, надо бы как то локализовать
PJ>Если ты не понимаешь как оно работает, то как ты определяешь корректность твоего фикса? Как ты определяешь, что именно решил проблему, а не скрыл симптом?

Здесь мы возвращаемся к тому, что говорил Синклер — все, включая инженеров, работают в условиях нехватки информации.
Для того, что бы утверждать о наличии решения, необходимо точно идетифицировать и локализовать проблему.
То есть, продраться через эту самую нехватку информации.

I>>А почему ты думаешь, что дебажить надо не иначе как часами? Типичный кейс для отладки — пару минут.
PJ>Если типичный фикс пару минут, то это что-то очень простое, которое при должной культуре и появится не должно. Я тут не могу комментировать, не видя вашу систему, типичные случаи и типичные фиксы.

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

I>>"Переписывать" — такое бизнесу непонятно, а за непонятное бюджет не дают.
PJ>Ну ты-то понял? Я тут вроде не с бизнесом разговариваю.

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

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

I>>Вертикальная это именно смена специализаций. Молодые багфиксают, средние инженеры пишут фичи, старшие проектируют, внедряют, договариваются.
PJ>Чушь какая. Организация для чесания ЧСВ, в реальности я такого нигде не видел, по крайней мере в западных компаниях. Народ на пенсию уходит с позиций инженеров, потому что им не интересно ни с кем договариваться, им интересно код писать.

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

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

I>>Это не саппорт, а внедрение. Без этого ты не знаешь, что вообще нужно от твоего солюшна.
PJ>Если ты копаешь в коде клиентов, то это саппорт. Но ты можешь называть это внедрением, конечно.

У тебя цель как то не фигурирует. Суппорт это не про ковыряние в чужом коде, это услуга помощи твоим клиентам по твоему собственному решению. Консультируешь ли ты в чате, лично, в коде или без — дело десятое. Главное, что ты помогаешь клиентам по своему решению.

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

Даже если ты в десять раз ускоришь разработку, все остальные составляющие не изменятся.

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


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

Интересно. А вот мы каким-то образом смогли предугадать, что:

1. Появится девайс, не совсем совместимый со стандартом
2. Инженеры попытаются сконфигурировать его для работы с нашим софтом определенным образом, которая может привести к hazardous ситуации по классификации FMEA

Из этого мы добавили ловушку в код.

Через два года и 10 тысяч километров ловушка сработала.

Почему нам удалось это предвидеть?

Варианты ответа:
1. У нас был хрустальный шар
2. Ввиду того, что мы не были заняты отладками проездов по памяти по трупу слепку состояния в отладчике, у нас было много свободного времени на обсуждение потенциальных логических high level багов, то есть проблем, когда код работает ровно так, как было задумано, но вовсе не так, как следовало бы.

R>Не знаю какую либу ваяет landerhigh

Да небольшую такую.. которой так или иначе каждый здесь пользуется.

Только больше не ваяет. Уж лет 10 как в продакшене.

R>на условной core java и живёт в своём маленьком мире контроллеров, но подобные случаи всё ж редки. Мы лично работаем с внешними данными, где юнит-тесты покроют лишь белый шум. Так что логи и отладчик — наше всё.

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

PJ>И мысль его вполне простая и очевидная — не следует подпирать костылями кривые решения, а если их не давать в руки, то и соблазна не будет.

Вот именно. Хоть кто-то догадался.
Код ревью. Петя добавляет новую функциональность. Без тестов. Спрашиваю — как докажешь, что оно работает? Ответ "ну я запустил и под отладчиком поглядел".
А завтра что ты будешь делать, когда Вася добавит поддержку Y в свой модуль, от которого зависит твой? А ты проверил на ошибочных данных? И т.п.
Только на этот гнилой базар тратится больше времени, нежели на написание нескольких простых, но исчерпывающих тестов.

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

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

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

I>Я собираюсь установить, симптомом чего является наблюдаемое поведение. Например, если летят странные ошибки, то легче всего и посмотреть сразу этот источник. Это занимает секунды и даёт ответ в большинстве случаев.
Ну да, треугольник с точками 1.122 3.654 1.689 ведет себя странно. Удачи в исследованиях.

I>Разумеется, это актуально, если нет способов получше. И тесты в их число не входят, т.к. тестами уже все что надо покрыто.
Есть конечно. Убедится, что модель правильная.

I>>>Можно. Но на конкретный баг уже есть сроки, которые надо соблюсти, иначе контора несет пенальти за просрочку.
I>>>Если ты предложишь на каждый баг чтото переписывать, тебя даже слушать не будут.
PJ>>Не каждый баг это и требует. Но если ты их будешь только латать, то как это отразится на конечном качестве и дальнейших сроках?
PJ>>Если у тебя аутсорс, то это тебя может не парить, конечно. Но я никогда в аутсорсе не работал и стабильность системы была важна.
I>А где я предлагаю латать каждый баг? Потрудись найти ссылку, а то мне кажется, ты сам себе чтото доказываешь.
Да вот прям в этом тексте, я выделил, если ты свои слова забыл.

I>На мой взгляд латание гораздо чаще встречается
I>1 в бОльшей части продуктовых проектов, т.к. здесь в норме крутятся как белка в колесе. Далеко не все утруждают себя такими вещами как требования.
I>2 у мелких заказчиков
I>3 у нервных паникующих менеджеров вне зависимости аутсорс, продукт, заказ или еще что
Это встречается там где менеджер дурак, а команде на это пофиг. Такое тихо гниет пока не сдохнет. И в местах где люди принципиально не хотят учиться, считая что они уже познали дзен и больше им ничего не надо.

I>Это смотря что за проблема. Как я говорил — большинство ошибок это человеческий фактор. Пропущеную валидацию очень даже можно включить и покрыть тестами.
Если у тебя цикломатическая сложность 100500, хоть упокрывайся тестами это ничего не даст.

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

I>>>А почему ты думаешь, что дебажить надо не иначе как часами? Типичный кейс для отладки — пару минут.
PJ>>Если типичный фикс пару минут, то это что-то очень простое, которое при должной культуре и появится не должно. Я тут не могу комментировать, не видя вашу систему, типичные случаи и типичные фиксы.

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

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

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

I>Если ты пилишь архитектуру, у тебя будет много коммуникации всеми способами — диаграмы, документы, митинги, консультации.
А если ты пилишь фичи, то у тебя будут — диаграмы, документы, митинги, консультации.

I>Соответственно, архитектором не получится стать, если ты просто пилишь хороший код. Пилишь хороший код, пилишь без ошибок, пилишь быстро — за это обычно дают бонус и так до определенного потолка.
Если все что такое архитектор пилит это "диаграмы, документы, митинги, консультации", то хорошим архитектором ему тоже не стать. Если ты говоришь о том, кого часто называют системным архитектором. То такой код не пишет вообще. И, возможно, не умеет. Его задача сделать согласованные требования к разным частям, чтобы эта шайтан-машина работала, если речь о девайсах, например. Требования к софту, требования к электромеханической части, требование к безопасности итд... Это не смещение, это вообще другая специализация. Специализация на продукте, так сказать.

I>Хочешь больше — бери на себя бОльше ответсвенности, чем просто за свой код.
Это совок вида "я начальник ты дурак". В западных компаниях, во многих, есть грейды, чем больше тебя ценят, тем выше у тебя уровень, бонусы и зарплата. Специалист может легко получать больше, чем его менеджер, у которого формально ответственности больше.
Смешение в сторону управления это горизонтальное смещение. Для этого нужны другие скилы и желание этим заниматься. Как специалист ты при этом станешь хуже, однозначно. И возможно не станешь хорошим менеджером. Ссылку искать лень, но как-то видел интервью чувака из МС, который из PM вернулся в разработчики, потому что ему не нравился уровень стресса, но нравится писать код.

I>У тебя цель как то не фигурирует. Суппорт это не про ковыряние в чужом коде, это услуга помощи твоим клиентам по твоему собственному решению. Консультируешь ли ты в чате, лично, в коде или без — дело десятое. Главное, что ты помогаешь клиентам по своему решению.
Это все равно support.

I>Вопрос — кто тебе расскажет, какое именно должно быть твоё решение, какую проблему решать каким образом?
Никто. Мне рассказывают требования. Как и каким образом решаю я. Коллективный "я", разумеется. Если твой следующий вопрос кто собирает эти требования, то это не разработчики. У нас таких зовут product owner. Это не над разработчиками, это сбоку. Если ты про ответственность. Просто другая специализация. В нашем случае они даже программировать не умеют, в вашем, возможно, это необходимо.