А там, где этот код использовался в дальнейшем - есть несколько потоков, в котором обрабатываются данные и один из этапов фильтрация json. Плодить лишние потоки ради одного этапа - с большой вероятностью уменьшить общую производительность. В любом случае насколько я знаю, никто не пытался расспаралелить алгоритм.
А насчет однопроходности: в первом проходе используется AVX2 для разбора и по моим тестам, чем больше идёт подряд AVX2 команд с последовательной обработкой данных - тем быстрее получается. А во втором AVX2 использовать не получилось, там приходится обходить дерево, "прыгать" по данным туда сюда с кучей условий. А это не очень удобно на AVX делать, поэтому вынесли во второй проход.
TDD разве не подразумевает, что мы пишем новую функциональность только тогда, когда имеем красный тест на неё? Это автоматически означает 100% покрытие.
Я частично ответил в предыдущем комментарии. Могу лишь добавить, что мне очень жаль, что не довелось поработать с коллегами, которые отлично понимают концепции TDD и могли бы мне оппонировать. Я бы очень хотел иметь возможность позадавать вопросы по реальным задачам, которые появляются на работе. Через чат это сделать почти не возможно.
Но в любом случае перечитав все комментарии я вынес много новых для себя идей и мнений, которые можно обдумать и решить как к ним относиться.
Моя ошибка, нужно было более явно выразить мысль в статье. Тут наверное ближе всего будет аналогия с Библией и подобными вещами. Мало кто читает Библию сам, особенно в оригинале, обычно есть переводы с акцентами на что-то, есть адаптированные версии, есть толкования и пояснение. Проблема в том, что с одной стороны такие вольные изложения могут иметь мало общего с оригиналом и взглядом автора. А с другой - они сильно более популярны, чем оригинал.
С TDD (и прочими) абсолютно та же история, есть сотни людей, которые пытаются донести свою версию, преображенную через призму их опыта и восприятия. Но именно их голоса слышны громче всех, именно они определяют, как в дальнейшем будет использоваться та или иная идея и в каком-то смысле именно они определяют что будет подразумеваться под термином TDD. Наверное против такой версии TDD в основном и написана статья.
Я встречал кейсы, когда результат математической функции был различным в одной и той же версии языка установленной на разных ОС. И эта проблема была обнаружена благодаря написанным тестам и не ушла в прод.
Я люблю тесты, пишу их сам и заставляю других по возможности, у меня проблема только с TDD
Вы смешали все заблуждения и плохие практики в кучу и обвинили TDD во всех грехах. Просто потому, что не поняли концепции.
Возможно не понял.
Да, юнит тесты нужны для тестирования кирпичиков. Лучше описать что мы хотим от кирпичика до того, как мы его слепили и обожгли и поставили в стену.
Да, из хороших кирпичиков можно собрать плохой дом. Но хороший дом проще создать из хороших кирпичиков.
Ещё раз, я ЗА юнит тесты, они почти всегда уместны и помогают
Да, сами авторы идеи говорят, что нет смысла в 100% кода и оно только вредит.
Насколько я помню авторы идеи говорят, что код пишется только после того, как написан тест, это разве не подразумевает, что весь написанный код покрыт тестами и что автоматически дает 100% покрытия?
Я комментарием выше имел ввиду, что в идеале в итоге несмотря на методологию мы получим выполненную задачу, которая обложена тестами. Возможно с разным процентом покрытия, но важные места ИМХО точно должны быть покрыты тестами. И типично разработка задачи ведётся одним разработчиком в отдельной ветке, где нет чужих изменений, где никто не обновляет версии языка.
Как тут уже писали в комментариях есть целый класс задач, в которых писать до удобно. Обычно это математические алгоритмы, где мы четко знаем что и как нужно сделать. К сожалению в моей практике таких задач очень мало.
У меня на практике обычно вот эта часть, что вы назвали "через добавление 10 ифчиков, а потом заменяете это на нормальный алгоритм" вызывала трудности, т.к. "нормальная" реализация всегда приводила к переименованию\удалению интерфейсов\классов\методов\аргументов, перестройке всей структуктуры кода. После чего все ранее написанные тесты грубо говоря проще выкинуть и написать заново. Как вы с этим боролись?
Я для себя выработал следующее решение: я пишу решение задачи на "человеческом языке", упуская несущественные (но объемные в реализации на ЯП) детали. Т.к. такой с позволения сказать код сильно меньше и проще, его быстро и легко рефакторить и держать в голове целиком, до тех пор пока он не решит всех кейсов, которые я придумаю. Если задача сложная можно постепенно углублять решение, прорабатывать детали, когда высокоуровнево проблем не осталось. Потом уже дело техники перевести его на нормальный ЯП и написать тесты.
Я очень надеюсь, что постепенно разовьются подходы автоматической валидации\верификации кода, вроде линтеров, статических анализаторов, TLA+/TLC и т.п. И после этого фундаментально сократиться кол-во тестов, которые нужно будет писать. А с развитием ЯП сложность написания любого кода, в том числе тестов уменьшиться.
А там, где этот код использовался в дальнейшем - есть несколько потоков, в котором обрабатываются данные и один из этапов фильтрация json. Плодить лишние потоки ради одного этапа - с большой вероятностью уменьшить общую производительность. В любом случае насколько я знаю, никто не пытался расспаралелить алгоритм.
А насчет однопроходности: в первом проходе используется AVX2 для разбора и по моим тестам, чем больше идёт подряд AVX2 команд с последовательной обработкой данных - тем быстрее получается. А во втором AVX2 использовать не получилось, там приходится обходить дерево, "прыгать" по данным туда сюда с кучей условий. А это не очень удобно на AVX делать, поэтому вынесли во второй проход.
TDD разве не подразумевает, что мы пишем новую функциональность только тогда, когда имеем красный тест на неё? Это автоматически означает 100% покрытие.
А не хотите статью запилить с объяснением, примерами и особенностями подхода, по комментарию не совсем понятно как это?
Я частично ответил в предыдущем комментарии. Могу лишь добавить, что мне очень жаль, что не довелось поработать с коллегами, которые отлично понимают концепции TDD и могли бы мне оппонировать. Я бы очень хотел иметь возможность позадавать вопросы по реальным задачам, которые появляются на работе. Через чат это сделать почти не возможно.
Но в любом случае перечитав все комментарии я вынес много новых для себя идей и мнений, которые можно обдумать и решить как к ним относиться.
Моя ошибка, нужно было более явно выразить мысль в статье. Тут наверное ближе всего будет аналогия с Библией и подобными вещами. Мало кто читает Библию сам, особенно в оригинале, обычно есть переводы с акцентами на что-то, есть адаптированные версии, есть толкования и пояснение. Проблема в том, что с одной стороны такие вольные изложения могут иметь мало общего с оригиналом и взглядом автора. А с другой - они сильно более популярны, чем оригинал.
С TDD (и прочими) абсолютно та же история, есть сотни людей, которые пытаются донести свою версию, преображенную через призму их опыта и восприятия. Но именно их голоса слышны громче всех, именно они определяют, как в дальнейшем будет использоваться та или иная идея и в каком-то смысле именно они определяют что будет подразумеваться под термином TDD. Наверное против такой версии TDD в основном и написана статья.
Я люблю тесты, пишу их сам и заставляю других по возможности, у меня проблема только с TDD
Возможно не понял.
Ещё раз, я ЗА юнит тесты, они почти всегда уместны и помогают
Насколько я помню авторы идеи говорят, что код пишется только после того, как написан тест, это разве не подразумевает, что весь написанный код покрыт тестами и что автоматически дает 100% покрытия?
Наверное имелось ввиду "НЕ используя TDD"?
Я комментарием выше имел ввиду, что в идеале в итоге несмотря на методологию мы получим выполненную задачу, которая обложена тестами. Возможно с разным процентом покрытия, но важные места ИМХО точно должны быть покрыты тестами. И типично разработка задачи ведётся одним разработчиком в отдельной ветке, где нет чужих изменений, где никто не обновляет версии языка.
Как тут уже писали в комментариях есть целый класс задач, в которых писать до удобно. Обычно это математические алгоритмы, где мы четко знаем что и как нужно сделать. К сожалению в моей практике таких задач очень мало.
У меня на практике обычно вот эта часть, что вы назвали "через добавление 10 ифчиков, а потом заменяете это на нормальный алгоритм" вызывала трудности, т.к. "нормальная" реализация всегда приводила к переименованию\удалению интерфейсов\классов\методов\аргументов, перестройке всей структуктуры кода. После чего все ранее написанные тесты грубо говоря проще выкинуть и написать заново. Как вы с этим боролись?
Я для себя выработал следующее решение: я пишу решение задачи на "человеческом языке", упуская несущественные (но объемные в реализации на ЯП) детали. Т.к. такой с позволения сказать код сильно меньше и проще, его быстро и легко рефакторить и держать в голове целиком, до тех пор пока он не решит всех кейсов, которые я придумаю. Если задача сложная можно постепенно углублять решение, прорабатывать детали, когда высокоуровнево проблем не осталось. Потом уже дело техники перевести его на нормальный ЯП и написать тесты.
Суммаризирую свои мысли: юнит тесты это здорово и почти всегда уместно, но из личных наблюдений писать их после кода гораздо практичнее.
Я очень надеюсь, что постепенно разовьются подходы автоматической валидации\верификации кода, вроде линтеров, статических анализаторов, TLA+/TLC и т.п. И после этого фундаментально сократиться кол-во тестов, которые нужно будет писать. А с развитием ЯП сложность написания любого кода, в том числе тестов уменьшиться.
Согласен, слегка увлекся представляя сферического TDD разработчика в вакууме и приписал ему несколько иной стиль разработки в этом месте статьи.
TDD это про процесс, результат в идеале плюс минус одинаков при должной квалификации разработчика.