Care.Card UX Contest: React Native + UX Design for better healthcare. Join Now & Win 100 000 SOLVE!
×Закрыть

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

Когда приходится начинать или перенимать новый проект, всегда возникает заветное «а давайте все перепишем», «а почему технология X а не Y» и под конец — «а этот код писали индусы». Резюмируется все фразой «давайте перепишем и вместо Y используем X». Но когда начинаешь спрашивать: «Почему технология Y применима к этому проекту?». В ответ слышится невнятное: «Ну, новее, интереснее...», «Мне было бы интересно получить опыт по ней».

Дальше обычно спрашивают: «А как обстоят дела с тестами?». Ответ так же, как и на встречный вопрос «Какой вид тестирования интересует?», — невнятный... Обычно он повторяется, как мантра: «Юнит-тесты». А на просьбу «Продай-ка мне юнит-тесты применительно к этому проекту» в лучшем случае говорят: «Любую строчку кода стоит покрывать тестами, потому что так надо». О продаже юнит-тестов речь даже и не заходит. А теперь давайте попробуем разобраться, что не так с этими вопросами и ответами.

Чудо-оружие разработчика

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

С развитием технического прогресса роль «вундервафли» сильно возросла. В XX и уже XXI веке многие военачальники объясняли свои проигрыши тем, что «у него-то сверхоружие, да вообще и гранаты у меня были не той системы». К чему эта аналогия? В разработке сейчас происходит тоже самое. Многие специалисты прикрывают свою криворукость или неграмотность использованием того или иного фреймворка, библиотеки или технологии, которая всю работу сделает за них. Как говорит народная мудрость, на сосенке не могут вырасти яблоки, но часто проблема не в инструментах.

В неокрепшем сознании девелопера рисуется идеальный фреймворк или библиотека с одной функцией «сделать_все_зашибись()», которая сделает все как надо без помощи мозгов разработчика. Рядом с методом «сделать все зашибись», как серебряная пуля, лежат юнит-тесты. По мнению 75% разработчиков, это та вещь, которая позволяет писать без багов. То есть нужно просто стоит внедрить в проект тесты. Причем часто люди просто не имеют понятия о том, что вообще-то существуют разные виды тестирования, и то, что они хотят внедрить в проект, — скорее всего, далеко не юнит-тесты.

Давайте разбираться по порядку: как поступать в той или иной ситуации и почему возникают эти проблемы.

Фактор времени

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

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

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

Выбор технологии на проекте

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

Если же заказчик объясняет свое решение тем, что «я погуглил, и мне выдало», то смело включайте режим пламенного борца за полюбившийся вам фреймворк или технологию. Но опять же не забывайте про аргументы. Сразу подготовьте список линков на технологию, список компаний, которые ее используют, обучалки для новичков и так далее. Дайте клиенту погрузиться в технологию. Забудьте аргумент «модно, стильно, молодежно» — это не работает для бизнеса. Лучший инструмент — это тот, который вы досконально знаете. И если вы приведете примеры и покажете успешные проекты, сделанные вами на известном вам фреймворке или технологии, это будет лучшей его рекламой.

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

Если у вас уже есть рабочая версия или компания разрабатывает продукт с дальним горизонтом планирования, можно пойти на оправданный риск, заранее проинформировав о нем заказчика. Однако, если заказчик — стартап, который нанял команду из страны третьего мира, продав дедушкину лесопилку и заложив бабушкино фамильное серебро в ломбард, то лучше не рисковать, а использовать то, что даст 100% результат.

Про стартапы

Работать в стартапах, с одной стороны, интересно, а с другой — чрезвычайно сложно. Почему интересно? Стартапы — это новые и не очень идеи (украинские стартапы не в счет, тут на 90% не новые идеи). В стартапах люди идут на риски. Тут можно протолкнуть что-то новое, использовать новый подход. Можно настроить все под себя. Не устраивает стандартный git-flow — не проблема, модифицируй. Хочется ввести свои стили кодирования — да не вопрос.

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

Животрепещущий вопрос — чистый код

Чистый код очень важен для дальнейшего развития проекта. Без понимания этого написать что-то более или менее стоящее не представляется возможным. Однако есть и кое-что важнее, чем чистый код — это работающий продукт! Если код продукта написан идеально, но при этом были пролюблены все сроки, а заказчик пошел по миру, потому что вы в очередной раз решили порефакторить метод — то, как по мне, лучше рабочий код с костылями и подпорками.

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

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

И теперь задумаемся о проблеме так называемого индусского кода. Большинство наших разработчиков любят поливать парней с Индостана отходами жизнедеятельности, не вникая в причины, по которым был написан тот или иной кусок кода. Для начала примите за утверждение: наши говнокодят не меньше, а с количеством вайтишников в отрасли мы по говнокоду скоро будем впереди планеты всей. Так вот, попробуйте войти в условия разрабов, написавших тот или иной кусок кода. Против индусов работает закон больших чисел. На жалкие 40 тысяч кодеров и иже с ними в Украине приходится 1 миллион кодеров с Индостана. Понятное дело, даже если принять, что процент говнокодеров у них и у нас одинаков — то у них кодеров аналогичной квалификации будет на порядок больше.

Тесты

Вернемся к нашим баранам. Тесты несомненно важны. Они сразу помогают локализовывать ошибки без траты времени на их обнаружение при тестировании. Однако, чтобы тесты были, их кто-то должен написать. Плюс к этому вы должны позаботиться о настройке инфраструктуры CI системы. Тесты без CI мертвы. Их будут запускать единицы, да и то когда нечем будет заняться. Тесты — это такой же софт, как и ваш разрабатываемый продукт. Они рождаются живут, изменяются, устаревают и умирают. А теперь стоит понять, что это все время. К тому же тесты окупают себя через достаточно большой промежуток времени (адепты TDD — прошу не кидать в меня камни). А у нас уже понедельник, а поставка на вторник, потому что в среду сельскохозяйственная выставка.

Надо задаться вопросом, а стоит ли писать тесты. Может стоит написать, а в оставшееся время лучше пройтись по функциональности? Опять же девелоперского тестирования никто не отменял, и вот оно обязательно в любом случае! Да это просто проверка — работает или не работает фича, которую вы делали, после завершения работы над ней и до команды `git push`.

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

Выводы

Итак, что в сухом остатке? Увлекаясь так называемым «Technical Excellence», мы должны не забывать о главном — о продукте. Да, важен именно конечный продукт, а не тесты, кристальный код, использование новых технологий и методологий разработки. Никогда не стоит забывать, что конечный результат нашей работы — это не уходящий в ноль burndown chart, не 100% покрытие тестами кода, не выполнение условий линтера, а именно рабочий продукт — и есть цель, к которой мы должны стремиться.

LinkedIn

Лучшие комментарии пропустить

Рабочий продукт — прежде всего

И именно поэтому нужно писать тесты, делать рефакторинг, а иногда и начинать сначала. За примерами далеко ходить не надо. Скоро выходит iOS 12, на секундочку мажорная версия, в которой судя по аналитике нововведений не будет вообще (впервые в истории). Про количество багов в последние годы я молчу. Система достигла критической массы (и речь не только о коде и вообще не только о технологиях), где любое мельчайшее изменение это сотни и сотни человекочасов. Эта тенденция прослеживается абсолютно в любом продукте. Я предрекаю новый кризис доткомов в течении 10 лет, и его причиной послужит микс нарощенной комплексити из-за супер-эффективного менеджмента, не понимающего цену рефакторинга и тестов, девелоперов не умеющих эту цену донести, ну и общий наплыв рандомных фейсов в индустрии, которые вообще не понимают что они здесь делают.

По поводу юнит тестов хотелось бы замолвить отдельное словечко. Юнит тесты это в первую очередь инструмент разработки. Возможность проверить работу переключателя поворотника без сборки всего автомобиля и даже без сборки самого поворотника — экономит неописуемое количество времени и нервных клеток. А порой и прозвон косы без сборки даже самого переключателя. И уже во вторую очередь юнит тесты — это инструмент тестирования, но далеко не так как его многие представляют. Юнит тесты в git diff или в PR показывают как изменился код с точки зрения поведения, избавляя необходимость проводить компиляцию и симуляцию в голове, экономя опять-же время, уменьшая вероятность ошибок и повышая эффективность код ревью. Юнит тесты ко всем остальным видам тестирования имеют очень посредственное отношение. Особенно на гигантских проектах, где больше половины людей не знакомы и с половиной кодовой базы — где без наличия юнит тестов все просто боятся делать изменения и вместо этого предпочитают плодить костыли убивающие проект в долгосрочной перспективе. Я виню разработчиков только в том, что они либо не знают этого либо не умеют донести, но зачастую они нутром чувствуют, что «так надо» — на уровне ощущений из предыдущего опыта они понимают что так работается легче. TDD был лишь способом популяризации идеи, на самом деле не особо важно пишутся тесты до или после кода... но это отдельная история.

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

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

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

Плюс к этому вы должны позаботиться о настройке инфраструктуры CI системы. Тесты без CI мертвы.

Чушь.

Их будут запускать единицы, да и то когда нечем будет заняться.

Чушь. Сделайте нормальную процедуру разработки, а не хяк-хяк-продакшн.

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

Твердо уверен в том, что отказ от тестов увеличивает время разработки.

А еще у нас дороги по такому же принципу ремонтируют.

Отчетный километраж — прежде всего, или Когда не стоит увлекаться долговечностью и гостами

В любом деле прежде всего нужен баланс и стратегия.
Отдать все ресурсы на быстрый результат? Ок. Но что потом будет с развитием продукта после запуска, когда нужны будут новые фичи, а команда будет заниматься поддержкой того, что слепили на скорую руку. А оно будет валиться и валиться.
Гнаться за 100% покрытием тестами — тоже не имеет смысла. Надо определить ключевые участки.
Гнаться за передовыми технологиями — да, интересно, но можно вляпаться и потом тратить кучу времени на допиливание и костыли, потому что технология сырая и в продакшене появляются дыры и баги.
Чистый код? Все равно изначально делать все идеально не получится. Рефакторинг никто не отменял, и периодически этому надо уделять внимание.
Поэтому важно все. И правильно распределять ресурсы и задачи — это задача менеджеров.

Не понятно, почему тесты рассматриваются как отдельная сущность от функционала. TDD, BDD — тесты и есть часть фичи или функционала. Не пишите тесты — значит не пишите функционал. Нужно успеть к дедлайна? Сокращайте набор фич к нему, а не качество продукта.

227 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

як завжди тішать комментарі: «не читал но осуждаю», «я дочитав тільки до ... <перше твердження з яким я не згоден> », «я дочитав тільки до ... <перше твердження яке я не зрозумів але соромно собі зізнатись> », «автор некомпетентний бо ...<два слова зі всієї статті>, «автор не компетентний, — тому що я з ним не згодний ...<будь-які тези>», ...

если стартап — это PoC, который можно сваять на коленке за пару вечеров — сойдет и как попало. Но если задумка масштабная и компания закладывает бюджет, особенно на ранних стадиях — имхо, большая ошибка следовать той же дорогой.
На ранних стадиях стартапа продукт очень динамичная штука, и если сегодня решили выпилить все вот это и развернуться в другую сторону — сильно связанный, кое-как написанный код без тестов будет стоить очень дорого. Практически это означает начать все с нуля.
Да, поначалу вложения в архитектуру, платформу, CI/CD и тесты могут казаться избыточными, но дальше график работы с кодом становится логарифмическим — а при растущей codebase это критично.

Всегда можно нанять +100500 украинцев на аутсорс ))

точно! а так будут отбирать работу =)

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

...У автора были проблемы с изучением истории.

У гитлера были супер танки (тигр-2) супер-истребители (me.262) лучшее стрелковое оружие (StG 44), я про всяки Фау-2 молчу...
И кто в итоге победил ?

Ладно, ладно. Просто автор забыл в конце слово — «шутка» написать.

Тот, у кого ресурсов было больше.

Так появились в мифологии экскалибур, меч-кладенец, дюрандаль и др.

Хорошая аналогия.

Предлагаю переименовать статью в «Говнокод — наше все!»

Лучше смените ник на «Тролль-нечитатель», будет честнее.

habr.com/post/358178

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

Technical Excellence и наличие тестов, код ревю и рефакторинга — это не синонимы. Я не видел ни одного проекта за последние 20 лет, у которого возникли проблемы от переизбытка тестов, зато видел десятки, которые ставились под угрозу из-за их отсутствия.

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

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

Плюс к этому вы должны позаботиться о настройке инфраструктуры CI системы. Тесты без CI мертвы.

Чушь.

Их будут запускать единицы, да и то когда нечем будет заняться.

Чушь. Сделайте нормальную процедуру разработки, а не хяк-хяк-продакшн.

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

Твердо уверен в том, что отказ от тестов увеличивает время разработки.

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

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

Работать с неадекватными заказчиками и чайка-менеджерами можно до определенного предела. Хотите проект из говна и палок? Не вопрос, но не надо потом выносить мозг и ждать на выходе «убийцу фейсбука» уже через неделю.

Стаття хороша, не всі зрозуміють, особливо якщо не працювали на проектах з нуля та з обмеженими ресурсами) Я ще б додав якщо ви при коміті не читаєте кожен свій рядок коду і у вас немає процедури код ревю іншим членом команди, то вам юніт тести не допоможуть :)
Юніт тести «must have» якщо в команді є багато людей, що не знають проект, для аутсорсингу дуже актуально)

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

Если заказчик понимает, что он получит решение быстро, но стоимость (и сроки реализации задач) поддержки разработанного продукта вырастает в несколько раз — то замечательно. Лишь бы потом вопросов не возникало «а почему сделать вот это мааааленькое изменение займет столько времени и сил?»

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

Ни разу не обязанность. Если заказчик настолько умный и компетентный, что выбирает техническое решение самостоятельно — то он же и несет риски.

Ни разу не обязанность. Если заказчик настолько умный и компетентный, что выбирает техническое решение самостоятельно — то он же и несет риски.

Такі недомолвки — рецепт для катастрофи: один не досказав, інший — допридумав, в результаті кожен має в голові свою картинку і в кінці кінців це призведе до конфлікту на рівному місці.
Не треба створювати напряги там, де їх можна уникнути простою комунікацією.

А еще у нас дороги по такому же принципу ремонтируют.

Отчетный километраж — прежде всего, или Когда не стоит увлекаться долговечностью и гостами

Ну чому ж. У нас он в Київській області в деяких місцях повністю переклали дорогу. Київ-Обухів, наприклад. Вийшли 30 кілометрів цієї дороги по вартості як ціна ямкового ремонту по всій країні. При цьому в Черкаській області декілька весняних місяців навіть ямкового ремонту не робили, типу грошей не було, через що деякі дороги в стали непроїздними, водії вибирали інші маршрути, чи їздили по узбіччю.

В двух словах — автор пытается доказать что рабочий продукт должен делаться по принципу «и так сойдет, главное побыстрее»

Ви не повірите, але бізнесу чхати на красу вашого коду та відсоток покриття тестами. Головне — швидкість виведення нових фіч на ринок та задоволення потреб ринку в цілому.

Это все равно что сказать «какая разница из чего построен дом и есть ли у него фундамент, главное попродавать все квартиры, а если через 10 лет завалится то это уже не наши проблемы». Да, многие так и делают, особенно у нас, но зачем доказывать что это хорошо? Ну допустим у нас есть старый проект написаный как попало. Допустим мы потратим пару месяцев на то что бы переписать его на какой нибудь современный фреймворк который будет генерировать огромное количество кода несколькими строчками в консоли. Новые фичи в результате будут создаваться в разы быстрее.

Ви плутаєте тепле з м’яким. Вам хочеться думати, що ваша робота має хоч якийсь сенс. Але ви акцентуєте постійно увагу на процесі, а треба дивитися на результат. Продукти IBM може й написані лівою ногою, але це не заважає компанії продавати їх по мільйону за штуку.

Продукти IBM може й написані лівою ногою

откуда это известно?

Поспілкуйтеся із інтеграторами.

Это называется вендор локинг. Гнилой продукт будет тянуть не понимающего клиента на дно, а продавец будет жив пока не переведутся не понимающие кастомеры. У подрастающего поколения уже на уровне подкорки укоренилась ассоциация IBM = боль. Остальное вопрос времени.

Гнилой продукт будет тянуть не понимающего клиента на дно

Зазвичай клієнти IBM щасливі від наданих послуг....

У подрастающего поколения уже на уровне подкорки укоренилась ассоциация IBM = боль.

Проблеми негрів мало хвилюють шерифів з IBM. Навіть якщо зібрати всіх «розумників» до купи, вони не зможуть зробити рішення, яке б наблизилося до рішень IBM. Інша справа, що не сильно може й потрібно бути, але факт залишається фактом. Бо IBM — це не тільки софт.

Що хотів сказати автор? Розшифруйте, телепати всі у відпустці.

Как торгуется IBM на nasdaq за последние пять лет

Що ви хотіли сказати цим графіком? Що показує графік, на вашу думку? Чи корелює цей графік із звітністю компанії за останні 5 років? Як цей графік корелює із задоволеністю клієнтів?

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

Зазвичай клієнти IBM щасливі від наданих послуг....

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

Походу обычная буденность больших корпораций ))

Починається з 1) «є проблема!» — «ок, ми займаємось, відкрили тікет» , далі цикл від 2 до N-1 :
«- ну як там ?
— все ще займаємось»
в цей час по тікету йде млява переписка між підрозділами, іноді розбавлена вкрапленями запитів додаткової інформації від споживача.
І нарешті
N) замовник задовбався пинати техсаппорт
настає довгоочікувана тиша :)
P.S.
можливі варіанти
а) у вигляді продовження
N+1 «ну як там, проблема все ще актуальна?» (раптом вже ніфіга не треба робити)
якщо відповідь «так» goto 2
б) break з ескалацією на керівництво і процес починається по новій :)
P.S.
Іноді проблема таки вирішується в циклі 2..N-1, або через «чарівний пендель» від керівництва.
P.P.S.
Особливо важливим клієнтам виділяють персонального менеджера, чиє завдання прискорити видання «чарівних пенделів».

P.S.
можливі варіанти

Наприклад то не «є проблема» а була заявлена типу маркетингова фіча нової версії продукту ))

P.P.S.
Особливо важливим клієнтам виділяють персонального менеджера, чиє завдання прискорити видання «чарівних пенделів».

Працює точно так же ж само тіко різниця що уважаємий чілавєк не пише на форумі підтримки разом з усіма простими смертними (тим самим палячи комерційну таємницю клієнтських зв’язків) а «отримує підтримку» напряму але точно же ж так само «переважно моральну» ну у запущених випадках копроративної машини по роботі з клієнтами до нього ще іноді запускають «технічних спеціалістів» щоби типу «поясни і заспокой».

ЗЫ: «поясни і заспокой» шо то насправді не бага а фіча і якщо затиснути отут і не дьоргать отут (по-научному workaround) то все в общєм працює а шо до заявленої фічі то такі нє але ось так само workaround який насправді ну геть не то але же ж зовні виглядає наче працює.

Ну, когда у него на следующий день после релиза на продакшине «стреляет» какая-то бага которую не покрыли тестами — вот тогда сразу не начать.

Ви думаєте, що покриття тестами гарантує відсутність багів? У мене для вас погані новини...

Гарантує що багів буде меньше.

А ви думаєте що тести ні на що не впливають? І не тестуєте свої продукти бо «баги все одно будуть»? Буду здивований якщо з таким підходом в вас ще є замовники.

Гарантує що багів буде меньше.

Та нічого він не гарантує. Мільйони прикладів є. Ви вірите в цю тезу, бо ви хочете думати, що ви щось контролюєте. Це наповнює ваше життя сенсом. Давайте приведу приклад. Компанія Інтел проводить постійне тестування своїх процесорів на наявність помилок. Вони роками ганяють тести у вигляді рендомних інструкцій, щоб знайти баги. Там сидять кращі уми, в них процес тестування мабуть один з найскладніших в світі. Але з кожною новою архітектурою кількість багів стає тільки більше. Баги стають дедалі складнішими з гіршими наслідками. Такі вразливості як Meltdown та Spectre мають історію в більше ніж 10 років та понад 5 архітектур! Вам не здається дивним, що процес тестування, його складність, взагалі не вирішує проблему? Навіть можна сказати, що проблем стає дедалі більше. Еррата Сенді Бріджа нараховує 50+ багів, а в Скайлейка це вже 150+ (точніше можна дізнатися на сайті Інтела, якщо цікава точна цифра). Це не значить, що тестування стало кращим, це лише значить, що збільшилася кількість помилок через ускладнення системи. Так що вирішує тестування? Тільки одне — моральний спокій розробника. А як додаток — захист від його ліні, втоми, обмеженого досвіду та розумових здібностей.

А чи можна розробку вести без тестування, але таки зменшувати кількість багів? Можна. Я вже багато разів писав як саме, а ви можете придумати ще десяток різних способів. Вам тільки треба зробити один крок — перестати думати, що вам потрібні тести, а почати думати над тим, як без них поліпшити якість коду та процесу розробки.

Не можу зрозуміти на чому базується ваше твердження

Вам не здається дивним, що процес тестування, його складність, взагалі не вирішує проблему?

Ви можете гарантувати що тестування яке використовує Intel не знайшло жодного бага? Чи хоча б жодного критичного бага?

Ви можете гарантувати що тестування яке використовує Intel не знайшло жодного бага?

Це безглузде запитання. Ви перекрутили все навпаки та хочете приписати мені ваші власні думки, а не те, що я дійсно казав.

Чи хоча б жодного критичного бага?

Вивчіть історію Meltdown.

Я кажу лише те що тести потрібні.

Гарантує що багів буде меньше.

Ви чомусь намагаєтесь це спростувати згадуючи Meltdown.

Я кажу лише те що тести потрібні.

Вам — так. А в цілому то кореляції «чим більше тестів, тим менше багів», не існує. Приклад Інтел тому явне підтвердження.

Гарантує що багів буде меньше

Є інші способи досягнення цієї умови. Багів буде менше, якщо ви унеможливите або суттєво зменшите ризик появи їх в коді, якщо система буде толерантна до падінь та помилок, якщо система буде проводити свій власний health-check перед початком роботи, якщо ви будете використовувати API, Interfaces, Protocols та інші техніки не тільки у взаємодії із системами назовні, але й в середині, навіть якщо ви будете використовувати інші патерни програмування, наприклад із ситуативним потоком виконання інструкцій. Все це може краще впоратися із задачею мінімізації кількості багів в коді, ніж тести. Але ви продовжуйте вірити в магію тестів...

Приклад Інтел тому явне підтвердження.

Повторю вопрос: как он это подтверждает? Тесты Intel-а не находили багов, вообще никаких? Вы 100% уверены что они не нашли ни одного критичного бага схожего с нашумевшим Meltdown?

Є інші способи досягнення цієї умови.

Не существует.

якщо ви будете використовувати API, Interfaces, Protocols та інші техніки не тільки у взаємодії із системами назовні, але й в середині, навіть якщо ви будете використовувати інші патерни програмування, наприклад із ситуативним потоком виконання інструкцій

Вот как раз все тут перечисленное совершенно не влияет на наличие или отсутствие багов.

Вы 100% уверены что они не нашли ни одного критичного бага схожего с нашумевшим Meltdown?

Ви що мені хочете довести, що тести знайшли баги? Так я ніколи не казав зворотнього. Я вам інше казав. Тести не виловили всі баги та навіть не наблизили компанію до рівня, коли з’являється пару неважливих багів за рік. Навпаки, знаходять зараз вразливості, яким по 10(десять) років! Та один баг краще за інший, просто казка якась.

Не существует.

Для вас звісно ж ні. Але ви живете у власній мушлі та вважаєте, що це і є Всесвіт.

Вот как раз все тут перечисленное совершенно не влияет на наличие или отсутствие багов.

А яка основна причина виникнення багів? о_О

Ви що мені хочете довести, що тести знайшли баги?

Извините за то что приходится тыкать носом, но я с вами начал общения и потом еще раз повторил:

Гарантує що багів буде МЕНЬШЕ.

Никакие API, Protocols, any buzzwords не помогут если код не выполняет то что должен выполнять и что легко проверяется тем или иным видом тестирования. Особенно если это не написание совершенно новой фичи, а дополнение того что уже работало.

Извините за то что приходится тыкать носом

Слово «гарантує» як раз неправильно, а не «менше». Ваша фраза не співпадає з реальністю. Тестування може скорочувати кількість багів до певного рівня, але немає жодної гарантії, що тестування може звести кількість багів до нуля. Я вам не просто так писав про кореляцію. Її не існує.

если код не выполняет то что должен выполнять

Код завжди виконує те, що в ньому написане. Але факт може не співпадати із очікуванням. Тест не матеріалізує очікування на 100% та є кодом, який, за вашою ж теорією, теж може не виконувати те, що мусить виконувати. Тобто для досягнення 0 кількості багів мусить виконуватися дві умови: тест мусить покривати 100% випадків та не мати помилок в своєму коді. Тобто 0 багів досягається тільки при нескінченій кількості тестів. Л — логіка.

Особенно если это не написание совершенно новой фичи, а дополнение того что уже работало.

Які варіанти реалізації ви знаєте, коли доповнення того, що вже було написане, не ламає нічого з попереднього коду?

якщо система буде толерантна до падінь та помилок, якщо система буде проводити свій власний health-check перед початком роботи, якщо ви будете використовувати API, Interfaces, Protocols та інші техніки не тільки у взаємодії із системами назовні, але й в середині, навіть якщо ви будете використовувати інші патерни програмування, наприклад із ситуативним потоком виконання інструкцій. Все це може краще впоратися із задачею мінімізації кількості багів в коді

Якщо Ви говорите про іншу реальність, де всі ці «якщо» вдалося реалізувати, то так, мабуть, є можливість, що тести там не є такими ефективними. Але, якщо всіх тих «якщо» немає на конкретному проекті з різних причин(лекасі, third party, CMS, API, архітектура), тести можуть бути ефективними?

Якщо тестування не знайшло всі баги, треба відмовитися від тестування взагалі? Це має сенс. Якщо не тестувати — не буде багів... :-)

это называется: «х%№як, х%№як и в продакшн». новомодное течение в программизме. впервые применено формошлепами, сейчас потихоньку распростаняется на софтверных инжинеров ибо «вы нихера не рубите в бизнесе»

Прямое следствие «копроэкономики». Но не всем такое нравиться, посему не копропродукты есть, но дорогие. Даже приличные мышки, не копро и то уже от 60-70 бачей сейчас.
А я помню еще времена, когда мышь за 5-7 бачей была очень приличной.

А я так зрозумів, що автор хотів сказати, що не треба бути догматиком «правильного коду» за євангеліями Мартіна, Фаулера і Бека, і продовжувати писати тести «для рефакторингу», витрачаючи на це 60% часу, коли проект наближається до дупи.
Бо, наскільки я знаю, ніхто не довів, що сьогодні в індустрії більший відсоток успішно завершених проектів, ніж в часи, коли про тдд, і все таке, програмери і не чули.

Вот дать бы автору проект десятилетней давности с классами по 7-8 тысыч строк, с методами по 600-800 строк, с десятками ифок и посмотрим сколько ему понадобится времени на какую нибудь элементарную фичу

Цікаво а як би виглядав такий гігантський проект по новим стандартам? Проект с сотнями тисяч класів на 20 рядків кожен? :)

Пачиму? Всё же ж на лямбдах! Одна гигантская сплошная функция с миллионами лямбд же ж!

Сотен тысяч классов не будет, просто большая часть была бы удалена.

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

Багато коментів. У адептів ттд вже підривало ? Вони вже відписувались, що коду без тестів не буває і все таке ?

Якщо в вашому продукті виникло стійке бажання писати тести, значить ви вже його запороли. Значить у вас вже є велетенська проблема із якістю кода, надійністю систем, вибраними патернами та технологіями. Це явна ознака того, що система перестала влізати в вашу зону бачення.

Індустрія десятками років пропагує хибні підходи до розробки коду. Виросло покоління розробників, які просто не знають, чому та в який саме час виникла вимога тестувати. «Дєдитестували! Помнім, чтім, нєзабудім!». Коли починаєш розповідати, що є підходи та методології, які мінімізують ті самі негативні наслідки, які начебто мусять виявляти тести, на тебе дивляться як на дурника, який щось там верзе... Як без тестів? Ти шо, дурний? Ти проект запороти хочеш?

Так потім й будуються системи, які крихкі, які дуже погано підготовлені до змін, сильнопов’язані, але гордо покриті тестами. Одноразовими пластиковими тестами.

Коли починаєш розповідати, що є підходи та методології, які мінімізують ті самі негативні наслідки, які начебто мусять виявляти тести, на тебе дивляться як на дурника, який щось там верзе

Расскажите про эти подходы и методологии, многие могут не знать о них.

Та розповідав багато разів вже.

Як мінімізувати наслідки помилок при рефакторінгу? Звичайна відповідь — покрити тестами. Але можна ще інші речі впроваджувати, наприклад архітектурні. Якщо ви зафіксуєте API спілкування різноманітних систем/підсистем/модулів між собою, то це й буде ваш аналог тесту. А ще якщо й зробите слабкозв’язану архітектуру замість сильнозв’язаної, то будь-які зміни в модулях не будуть вимагати тестування функціональності, що вже існує, бо вони не впливають один на одне. Додамо сюди версійність функціональності на рівні коду, а реалізацію процесів винесемо в декларативний DSL, отримаємо такий собі реактор, який може змінювати свою поведінку на ходу та не боятися змін взагалі.

Виносимо по максимуму все в DSLs (domain specific languages), та отримуємо код, який буде схожий на конструктор LEGO, збирай що завгодно. Якщо не подобається DSL, переходимо до патерну «конфігуруйце», коли сам код пишеться один раз, потім тільки конфігурується.

Для інтеграційних тестів теж можна легко придумати заміну, наприклад health check під час запуску та системи моніторингу можуть розповісти більше, ніж тест, та ще й під час роботи системи.

А якщо досягти вищого пілотажу та почати майструвати fail safe системи, то тести будуть не просто зайвими, вони будуть шкідливими. Дивиться на приклади природи, собака бігає на трьох лапах майже без втрати функціональності. Навіть конфігурація з двох лап особливо не впливає. Чому? Нейропластичність та пристосування до зміни умов. Помилка не викликає миттєву смерть всієї системи, вона просто змінює поведінку, головне досягати результату. В собаки немає зайвої пари ніг на заміну, бо вони негативно впливають на ефективність. Із кодом все чомусь навпаки. Маленька помилка призводить до краху всього... Такий собі кришталевий код... А чому? Тестами не покрито?

Тут з’являться адепти фінансових алгоритмів та скажуть, що без тестів там можна влетіти на дохуліарди доларів. Я впевнений, що бот, який за 45 хвилин злив мінус 440 лямів баксів, був покритий тестами дуже гарно. То й що?

Якщо ви зафіксуєте API спілкування різноманітних систем/підсистем/модулів між собою, то це й буде ваш аналог тесту

Теряете гибкость в изменения под новые требования.

А ще якщо й зробите слабкозв’язану архітектуру замість сильнозв’язаної, то будь-які зміни в модулях не будуть вимагати тестування функціональності, що вже існує, бо вони не впливають один на одне

Или просто отвалятся эти модули — они же слабосвязаны, кто это заметит?

Виносимо по максимуму все в DSLs (domain specific languages), та отримуємо код, який буде схожий на конструктор LEGO, збирай що завгодно. Якщо не подобається DSL, переходимо до патерну «конфігуруйце», коли сам код пишеться один раз, потім тільки конфігурується.

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

Якщо не подобається DSL, переходимо до патерну «конфігуруйце», коли сам код пишеться один раз, потім тільки конфігурується.

Это позволяет изменятся только в тех пределах, куда позволяет конфигурация. В итоге требование получается — «А давайте напишем систему так, чтобы, когда нам что-то понадобится, оно там уже было» (подсказка — код и есть таким видом «конфигурации»)

Маленька помилка призводить до краху всього

Возможно Вам нужно указывать про какие системы вы говорите. Учитывая в последний год хайп на микросервис архитектуру (что не отменяет тестов) уже меньше ведет к подобным проблемам.

Теряете гибкость в изменения под новые требования.

Значить ви побудували не той API, якщо ви втрачаєте гнучкість. API мусить фіксувати процес, а не структури даних та функціональні можливості.

Или просто отвалятся эти модули — они же слабосвязаны, кто это заметит?

Моніторинг. Але втрата «бійця» все одне не мусить призводити до зупинки процесів.

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

Взагалі без помилок не вийде писати. Така природа людини. Але є одне але. DSL дозволяє суттєво скоротити шанс пострілу в ногу та швидше шукати помилки. Тому що ви переходите на один або більше рівнів абстракцій в гору.

Это позволяет изменятся только в тех пределах, куда позволяет конфигурация

В цьому є плюси та мінуси. Плюси — ніхто не зможе набокопорити. Мінуси — архітектура може бути настільки абстрактна, що в деяких моментах буде вимагати уваги сіньора, джун вже не розбереться.

Учитывая в последний год хайп на микросервис архитектуру (что не отменяет тестов) уже меньше ведет к подобным проблемам.

Мікросервіси теж падають як груші восени. Тому що покладаються на тести.

Попробовал когда-то давно TDD, слишком громоздко. Почти все время тратилось именно на 101 тест вместо бизнес-логики.
Как по мне, идеальный алгоритм такой
1. Наговнокодить рабочий «запорожец»
2. Написать тесты, попутно облагораживая код
3. Добавить еще мясца в «запорожец»
4. Снова тесты и рефакторинг
5. Повторить пункты 4 и 5, пока не получится «феррари»
Так и бизнес будет доволен и тех. долг выполнен

1. Наговнокодить рабочий «запорожец»
2. Написать тесты, попутно облагораживая код

Идеальный алгоритм делать это не последовательно а паралельно, команды то разные, на основании одних и тех же требований, так что 1-2 одновременно, потом тесты, потом 3-4 и тесты и тд

TDD было придумано в контексте юнит тестов, поскольку их пишут разработчики то это никакие не разные команды. Тем не менее это действительно должно быть параллельно. Написание юнит тестов по ходу написания самого кода позволяет смотреть на код сразу с двух точек зрения — автора и пользователя (кода — другого программиста использующего твой класс или метод). Самый простой пример — извечный вопрос когда метод нужно делить на два. Когда попытаешься покрыть метод тестами, так сразу само станет понятно, когда и где его делить, как лучше развернуть цикл, как избежать вложенных if итд. Когда делается все правильно, написание юнит тестов не тратит дополнительное время, а наоборот его экономит.

С остальными видами тестирования это отдельная история, однако согласен что это должно быть сделано тоже параллельно. Пока не решил для себя как лучше — видел и две команды работающие параллельно и DoD включающее покрытие тестами самим автором кода.

я думал ты НЕ про ТДД, мол попробовал, не то, вот алгоритм получше)
Да, единственное что тестирование должно отставать процентов на 10% что бы у дев команды было время принять ключевые архитектурные решения которые могут немного повлиять на структуру и начинку тест-кейсов

Ну не факт и не всегда.. есть например и BDD практики, где acceptance criteria либо сразу пишется тест кейсом (и оно практически plain English, например semaphoreci.com/...​h-protractor-and-cucumber), либо генерируется из acceptance criteria (например для бекенда acceptance criteria может быть задефайненый сваггер файл или модификация к нему из которой тесты могут быть сгенерированны автоматически).

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

Первое состоит из второго + очередность работы

У нас собственно кроме pitest’a и инструментов то и нету что бы ответить на вопрос «Оптимального Code Coverage». Касательно приёмочных E2E тестов — сейчас без них никак, тестить надо на куче устройств одновременно, по этому тут не «поклацаешь», Автоматизированные метрики и сплит-тестирование всегда лучше мануальных (если не высосаны из пальца дилетантом).

Касательно «бизнес логики» — 99% это CRUD’ы и AAA сервисы, рассылка и логирование.
Ума для переиспользования от проекта до проекта не хватает — особенно ощутимо на галерках.
Уже давно пора догадаться что CRUD — это не шаблонная копи-паста MVC контроллеров... некоторые и схемы СУБД мапят на GraphQL и REST с помощью мапперов (postgraphql, strongloop etc), правда существующее решения не пестрят функциональностью и надёжностью, но это уже другая история.

Касательно «х и в продакшен — потому что клиент сказал», это канает только когда накладные расходы на поддержку не растут экспоненциально, потом начинается Complaint Driven Development.

5. Повторить пункты 4 и 5, пока не получится «феррари»

Не получится.
Вообще, чтобы

«феррари»

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

Рабочий продукт — прежде всего

И именно поэтому нужно писать тесты, делать рефакторинг, а иногда и начинать сначала. За примерами далеко ходить не надо. Скоро выходит iOS 12, на секундочку мажорная версия, в которой судя по аналитике нововведений не будет вообще (впервые в истории). Про количество багов в последние годы я молчу. Система достигла критической массы (и речь не только о коде и вообще не только о технологиях), где любое мельчайшее изменение это сотни и сотни человекочасов. Эта тенденция прослеживается абсолютно в любом продукте. Я предрекаю новый кризис доткомов в течении 10 лет, и его причиной послужит микс нарощенной комплексити из-за супер-эффективного менеджмента, не понимающего цену рефакторинга и тестов, девелоперов не умеющих эту цену донести, ну и общий наплыв рандомных фейсов в индустрии, которые вообще не понимают что они здесь делают.

По поводу юнит тестов хотелось бы замолвить отдельное словечко. Юнит тесты это в первую очередь инструмент разработки. Возможность проверить работу переключателя поворотника без сборки всего автомобиля и даже без сборки самого поворотника — экономит неописуемое количество времени и нервных клеток. А порой и прозвон косы без сборки даже самого переключателя. И уже во вторую очередь юнит тесты — это инструмент тестирования, но далеко не так как его многие представляют. Юнит тесты в git diff или в PR показывают как изменился код с точки зрения поведения, избавляя необходимость проводить компиляцию и симуляцию в голове, экономя опять-же время, уменьшая вероятность ошибок и повышая эффективность код ревью. Юнит тесты ко всем остальным видам тестирования имеют очень посредственное отношение. Особенно на гигантских проектах, где больше половины людей не знакомы и с половиной кодовой базы — где без наличия юнит тестов все просто боятся делать изменения и вместо этого предпочитают плодить костыли убивающие проект в долгосрочной перспективе. Я виню разработчиков только в том, что они либо не знают этого либо не умеют донести, но зачастую они нутром чувствуют, что «так надо» — на уровне ощущений из предыдущего опыта они понимают что так работается легче. TDD был лишь способом популяризации идеи, на самом деле не особо важно пишутся тесты до или после кода... но это отдельная история.

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

sweet... все что я хотел сказать но ленился написать :) спасибо

Юнит тесты это в первую очередь инструмент разработки. Возможность проверить работу переключателя поворотника без сборки всего автомобиля и даже без сборки самого поворотника — экономит неописуемое количество времени и нервных клеток.

^this.

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

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

Я где-то сказал что юнит тесты заменяют интеграционные, функциональные, e2e, adhoc и еще кучу других типов тестов? Не припомню такого.

Конечно не заменяют. Только о них или забывают, или забивают, или в последствии не хватает времени потому что оно потрачено на написание и саппорт горы кода, по-факту тестирующего сеттеры и геттеры.
В теории всё красиво. На практике всегда главный ограничитель — имеющиеся в распоряжении ресурсы. И если руководитель проекта не способен чётко расставить приоритеты и надавать по рукам программистам-перфекционистам, то как правило на выходе с превышением бюджета и сроков х2 получается бажный продукт со 100% code coverage.

Еще раз. Написание юнит тестов не тратит время а экономит его. Когда используется правильно, а не как мантра.
1. Имея юнит тесты, не нужно сотни раз в течении дня собирать машину, выгонять ее на трассу и проезжать поворот просто что-бы проверить что нижнее положение переключателя включает именно левый поворотник.
2. Код пишется сразу нормально декомпозированный, с развернутыми циклами и ифами, что заранее предотвращает накопление технического долга и уменьшает необходимость и частоту рефакторинга.
3. Рано или поздно, когда рефакторинг таки нужен, или просто мажорное изменение — оно не превращается в полугодовой проект потому что люди боятся лезть в код который никогда не видели (не знаю что сломается). Как в свое время системы контроля версий дали свободу менять что угодно и как угодно в коде (потому-что всегда можно откатить), так юнит тесты позволяют менять что угодно и как угодно при этом сохраняя рабочее состояние и упрощая поиск точек вхождения, сломанных контрактов и прочих интерфейсов.

Ещё раз. Идеально работающая деталь вне контекста продукта не имеет смысла.

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

Я не видел потопленных продуктов из-за плохого покрытия юнитами. Через 5-10 лет его действительно тяжело саппортить. С этим кодом никто не хочет иметь дела. Но это вопрос решаемый. Зато я видел потопленные продукты из-за непонимания, как автоматизировать комплексное тестирование. Особенно печально, когда из-за непонимания зачем. Потому что покрытие юнитами даёт ложное ощущение надёжности.

Идеально работающая деталь вне контекста продукта не имеет смысла.

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

Думаю, что именно этот хайп сыграл с TDD злую шутку.

Согласен. TDD было попыткой популяризировать подход среди своей, технической аудитории.

Я не видел потопленных продуктов из-за плохого покрытия юнитами.

Да ладно... куда не ткни. Самая жесть начнется, как я сказал выше, в течении лет десяти. Пока только зреет.

Зато я видел потопленные продукты из-за непонимания, как автоматизировать комплексное тестирование.

True.

Потому что покрытие юнитами даёт ложное ощущение надёжности.

Also true.

80% кода любого продукта — это CRUD в разных его проявлениях, без внутренней логики. Это не имеет смысла тестировать потому что эти тесты не показывают _ничего_ кроме соответствия интерфейсов спецификациям. 20% — это разной степени сложности бизнес-логика, часть которой действительно имеет смыл атомарно, изолированно тестить, замокав все внешние зависимости (специально делаю на этом акцент). Т.е. де-факто лишь мизерная доля кода, которую надо выявить и покрыть тестами.
Львиная доля всех багов проявляется на интеграционном тестировании, на реальных грязных данных, на интеграциях со сторонними АПИ, с умирающими БД. И вот это надо покрывать так тестами, чтобы они ночью снились, чтобы их больше непосредственно рабочего кода было. Может об этом надо почаще говорить, а не о юнитах? Может программистам надо просто мыслить чуть шире и думать не о том, как протестить отдельно взятый класс, а компоненту в целом и писать соответствующий код и покрывать его тестами?

Это не имеет смысла тестировать

Это имеет смысл тестировать, потому что вылавливается вся мелочь типа опечаток, случайно закомменченных строк итд еще ДО пулл реквеста и код ревью, а значит дешевле пофиксить. К тому-же код ревью становится более эффективным, поскольку diff юнит тестов сразу поясняет поведенческое изменение пулл реквеста без необходимости компилировать и симулировать в голове. Опять-же, это учитывая что все делается правильно, и тогда написание юнит тестов это не экстра эффорт, это сохранение времени at no cost. Именно потому было придумано TDD, поскольку когда сначала пишешь логику, а потом начинаешь думать как теперь это все протестировать — сразу начинаешь рефакторить только что написанный код, и вот тебе экстра эффорт. Отсюда и миф.. отсюда TDD.. но если понять фишку — TDD не нужно, просто думай о тестах сразу и соблюдай баланс, решай сам когда удобно писать эти тесты. В некоторых случаях юнит тесты могут служить технической документацией (как использовать этот класс и этот метод) а так же служить защитой от дурака (ну точнее от людей которые впервые работают с этим куском кодовой базы).

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

О, конечно стоит, абсолютно согласен. Существует 1000 и 1 заблуждение про тестирование. Много копий сломано. Просто автор наехал конкретно на юнит тесты, потому я написал ответ конкретно про юнит тесты. Я ни в коем случае не ставлю юнит тесты важнее других видов тестирования. Нет такого вида тестирования, которое важнее чем другие. У каждого вида тестирования своя цель, и все они одинаково важны. Есть хорошо известная пирамида bfy.tw/I2Oz, иллюстрирующая сказанное. Которую, к слову, многие тоже неправильно читают (мол снизу значит нужно больше — хотя это значит снизу по факту получается больше, но не цель к которой нужно стремится).

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

Вот тут начинается как раз принципиальная разница. Проблемы такого клеевого кода очень просто вылавливаются на простейшем интеграционном тесте, локализуются и опознаются глазами легко (обычно на уровне "что я пил, когда писал это?), фиксятся тоже легко и дальше не всплывают. Юнит-тесты нужны там для тех 10%, где или что-то сложное, или надо общаться со зверем с туманной логикой (и тогда они работают как ещё одна документация по применённому API и вокруг).
А тот код, который дейпоствительно сложен (пусть алгоритмически), грамотным разработчиком и так покрыт для собственной уверенности.

TDD же заставляет писать лишние юнит-тесты на тупой клей и вообще не даёт грамотно писать наукоёмкую часть — там пошаговая разработка в его стиле не сработает.

отсюда TDD.. но если понять фишку — TDD не нужно, просто думай о тестах сразу

+100.

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

И тут +100.

очень просто вылавливаются на простейшем интеграционном тесте

Слишком поздно — интеграционный тест означает что уже был собран артефакт и куда-то задеплоен (собрали машину и вывели на трассу). Если это гаражный проект, может быть и пофигу, а если у тебя по 10 пулл реквестов в репо в час — что будешь делать?

Здесь нужно углубляться в детали решения — понятно, что серебряной пули не будет, и нужно учитывать специфику. С одной стороны, судя по

10 пулл реквестов в репо в час

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

Я не знаю, что такое нижние уровни деплоймента. PR открывается из фича-бренчи в бейзлайн (мастер или что-то еще в зависимости от выбранной стратегии бранчевания). Это самое начало CD цикла, кроме локальной машины девелопера этот код еще никто и ничто не видело. Тестам на локальной машине дева доверять нельзя, по ряду причин.

Собственно, потому я и спросил про детали — процесс по-разному везде настроен.

Я не знаю, что такое нижние уровни деплоймента.

Возможно, неточно выразился en.wikipedia.org/...​ki/Deployment_environment (у нас это выглядит несколько иначе).

PR открывается из фича-бренчи в бейзлайн (мастер или что-то еще в зависимости от выбранной стратегии бранчевания). Это самое начало CD цикла, кроме локальной машины девелопера этот код еще никто и ничто не видело.

У нас, например, PR не открывается, пока локальный + самый нижний удалённый уровень не прошли успешно. Опять же, настроить можно всё это дело по-разному.

Тестам на локальной машине дева доверять нельзя, по ряду причин.

Если подразумеваются только они и всё, то само собой). Но пропускать их при возможности безболезненно прогнать локально тоже нельзя.

Возвращаясь к

Слишком поздно — интеграционный тест означает что уже был собран артефакт и куда-то задеплоен (собрали машину и вывели на трассу). Если это гаражный проект, может быть и пофигу, а если у тебя по 10 пулл реквестов в репо в час — что будешь делать?

Почему поздно, и как здесь помогут юнит-тесты? Если, например, на dev и QA окружении тесты прошли, а на stage — упали, то проблема вряд ли лежит в плоскости юнит-тестов.

Нижние.. ну ок.

У нас, например, PR не открывается, пока локальный + самый нижний удалённый уровень не прошли успешно.

Это как? Что есть «нижний энв» (дев энв по нормальному) и что в него деплоется если разработчик еще даже не открыл PR? Он деплоит прямо из IDE? Ведущие параллельную разработку разработчики имеют персональные дев энвы о которых никто не знает? Ребята, это самопал какой-то. Еще раз, есть уже заезженная пирамида тестирования, есть придуманные бранчинг стратегии такие как гит флоу и гитхаб флоу, есть CI/CD и build once run everywhere. Не нужно ничего придумывать. Все уже придумано за вас. Пуш в фича бренч -> ПР -> линтинг -> юнит тесты -> пакетные тесты -> код ревью -> мердж -> сборка и паблиш пакета -> деплойменты в энвы -> интеграционное, функциональное, лоад, e2e и прочее тестирование -> промоут на следующий энв (количество энвов меняется по вкусу, допустимы мелкие аджастменты). Кто не знает этого простого базового сиквенса — тот не понятно за что получает свой хлеб и не проходят TI у меня.

Мы заходим во флейм от основной дискуссии.

Что есть «нижний энв» (дев энв по нормальному) и что в него деплоется если разработчик еще даже не открыл PR? Он деплоит прямо из IDE? Ведущие параллельную разработку разработчики имеют персональные дев энвы о которых никто не знает?

Открытие PR играет в этом какую-то сакральную роль? Pipeline сборщиков запускается по коммиту, например — где PR в этом случае находится? Если процесс подразумевает открытие PR сразу — ОК, но это не является каким-то железобетонным ограничителем совсем.

есть придуманные бранчинг стратегии такие как гит флоу и гитхаб флоу

Бранчинг стратегии могут существовать и сами по себе — наша дискуссия бранчинга напрямую не касается.

Пуш в фича бренч -> ПР -> линтинг -> юнит тесты -> пакетные тесты -> код ревью -> мердж -> сборка и паблиш пакета -> деплойменты в энвы -> интеграционное, функциональное, лоад, e2e и прочее тестирование

Напомню, что мы обсуждали (цитируя Валентина Нечаева):

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

Ключевая фраза здесь

простейшем интеграционном тесте

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

Пуш в фича бренч -> линтинг -> юнит тесты -> пакетные тесты -> сборка пакета -> деплоймент в отдельный «нулевой» энв с выносом либо просто дублированием части тестов более высокого уровня сюда (зависит от многих факторов, сколько и каких тестов) -> ПР -> код ревью -> мердж -> сборка и паблиш пакета -> деплойменты в энвы выше уровнем -> интеграционное, функциональное, лоад, e2e и прочее тестирование

Собственно, что я пытался донести. Если позволяют условия, PR должен открываться, а мердж производиться после максимально возможного контроля со стороны разработчика, чтобы не засорять процесс лишним шумом. Насчёт «10 пулл реквестов в час» я писал, что в этом случае да, возможно согласен, но в иных случаях (а их будет много) можно поступить гибче — это позволит отловить баги раньше. Поэтому, повторюсь

Если, например, на dev и QA окружении тесты прошли, а на stage — упали, то проблема вряд ли лежит в плоскости юнит-тестов.
Открытие PR играет в этом какую-то сакральную роль? Pipeline сборщиков запускается по коммиту, например — где PR в этом случае находится? Если процесс подразумевает открытие PR сразу — ОК, но это не является каким-то железобетонным ограничителем совсем.

Открытие ПР служит сигналом, что код в фича-бренче готов для дальнейших степов (CI и ревью). Я видел сетапы, где бранчу собирали и без ПР, по пушу, но реально представь это на скейле сотни параллельно активных бренчей с допустим ~20 пушами в час — это сколько энвов нужно параллельно иметь и откуда у вас столько денег?

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

Интеграционный тест локально? Что и с чем вы интегрируете в таком случае? Вы потом ваш лептоп в стойку в дц запихнете? Заранить конечно можно, только он говорит 0 информации, поскольку легко содержит и ложно-позитив и ложно-негатив.

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

Ну это разумеется так, но это не отменяет всех этих степов в CI. Мы же не отменяем валидацию ввода на бекенде потому что мы сделали ее на фронтенде, do we?

Насчёт «10 пулл реквестов в час» я писал, что в этом случае да, возможно согласен, но в иных случаях (а их будет много) можно поступить гибче — это позволит отловить баги раньше. Поэтому, повторюсь

Повторюсь, что раньше выловить баги позволяют юнит-тесты, а вы предлагаете нарушить CI/CD и деплоить динамик-энвы (то, что вы называете 0-энвами), что вообще никак не работает на скейле (ну разве-что у вас неограниченный поток финансов откуда-то). Мы же не базируем наши предположения на опыте гаражных пет-проектов на пять человек? А то так недолго дойти и до того «а зачем CI, а зачем git, а зачем jira» — че уж там юнит тестами ограничиваться.

Открытие ПР служит сигналом, что код в фича-бренче готов для дальнейших степов (CI и ревью). Я видел сетапы, где бранчу собирали и без ПР, по пушу, но реально представь это на скейле сотни параллельно активных бренчей с допустим ~20 пушами в час — это сколько энвов нужно параллельно иметь и откуда у вас столько денег?
а вы предлагаете нарушить CI/CD и деплоить динамик-энвы (то, что вы называете 0-энвами), что вообще никак не работает на скейле (ну разве-что у вас неограниченный поток финансов откуда-то).

Насчёт пуша — это был просто пример в разрезе обсуждения PR. Насчёт неограниченного кол-ва динамик энвов — я предлагаю один, где можно будет быстро проверить ограниченное кол-во тестов (естественно, опять же, каких и сколько, сильно зависит от проекта). Да, согласен, на большом скейле это не сработает, но настолько большой скейл далеко не везде.

Мы же не базируем наши предположения на опыте гаражных пет-проектов на пять человек? А то так недолго дойти и до того «а зачем CI, а зачем git, а зачем jira» — че уж там юнит тестами ограничиваться.

Множество проектов делаются командами до 20 чел., включая не-разработчиков. А Jira, git и CI нужны даже им).

Интеграционный тест локально? Что и с чем вы интегрируете в таком случае?

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

Заранить конечно можно, только он говорит 0 информации, поскольку легко содержит и ложно-позитив и ложно-негатив.

Если это касается той проблемы, которую мы обсуждаем («проблемы такого клеевого кода очень просто вылавливаются на простейшем интеграционном тесте»), то наоборот, а для остального есть уровни выше.

Ну это разумеется так, но это не отменяет всех этих степов в CI.

Согласен.

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

И как тогда локально делать интеграционные тесты для бекенда или мид-лейера К которому обращается множество других компонентов? Разворачивать целиком всю инфраструктуру на лептопе?

Да, согласен, на большом скейле это не сработает

Ну вот мы собственно и пришли к тому, к чему я и вел. Толпы «профи», которые в жизни не видели более-менее серьезный проект хотя-бы ОТ 50 человек хедкаунта приходят на доу и начинают рассказывать, что юнит тесты не работают. Не осилил != не работает.
.
Слабо подкованный заказчик находит слабо подкованных специалистов. Все довольны, получается нечто похожее на это s00.yaplakal.com/...​riginal/3/0/2/9783203.jpg
.
Проблема начинается тогда, когда эти слабо подкованные специалисты начинают выходить на публику и вещать о своих «удачах» базируясь на восторженных отзывах своего слабо подкованного кастомера.

И как тогда локально делать интеграционные тесты для бекенда или мид-лейера К которому обращается множество других компонентов? Разворачивать целиком всю инфраструктуру на лептопе?

Опять же: насколько_это_возможно.

Ну вот мы собственно и пришли к тому, к чему я и вел. Толпы «профи», которые в жизни не видели более-менее серьезный проект хотя-бы ОТ 50 человек хедкаунта приходят на доу и начинают рассказывать, что юнит тесты не работают. Не осилил != не работает.

Цитату плз, где написано, что юнит-тесты «не работают» (да и как они могут «не работать»)? Был описан подход, при котором часть кода, которую стоит покрыть, покрывается, а часть, которую не стоит покрывать, т.к. это не имеет особого смысла и невыгодно по времени — покрывается косвенно через тесты более высокого уровня, вот и всё. Вроде бы кто-то предлагает отказаться от них полностью — конечно, так не получится.

В общем, каждый остался при своём. Но, раз уж всё прям настолько «плохо» — какой процент проектов «с 10 PR в час» среди общего количества? И поэтому, может, right tool for the right job, вот это всё? Т.к. «только у меня правильные серьёзные проекты, поэтому делаем всегда вот так, и не иначе» оч странно звучит. При том, что Ваш применим к Вашей ситуации, я согласен, т.к. других вариантов-то и нет.

Это, конечно, не одно и то же, но REST API «по заветам» тоже не должен версионироваться, и вообще Филдинг говорит, что

The reason to make a real REST API is to get evolvability ... a «v1» is a middle finger to your API customers, indicating RPC/HTTP (not REST)

Только внезапно этот «миддл фингер для кастомеров» оказывается самым удобным способом, который использует весомая часть бизнесов — получается www.troyhunt.com/...​02/41694168readImage2.png , но гораздо практичнее всего остального. Тем не менее, можно предположить, что бывают бизнесы, где REST API можно сделать и «каноничным», без версий.

У меня так было, правда был бесплатный кредит на Azure на несколько лямов

Интеграционный тест локально? Что и с чем вы интегрируете в таком случае?

Компоненту A на вход передали набор сигналов. Он их обобщил, передал компоненту B, который переработал сигнал во что положено и выдал на выход.
Таким методом проверена связь компонентов A и B на всех видах взаимодействий между ними.
При этом полная система может содержать ещё 100500 компонентов, которые в этом не задействуются.
A и B, для простоты описания, сделаны микросервисами.
Запустить такое на машине разработчика — тривиально, и в нормальном варианте это его обязанность.

Я видел сетапы, где бранчу собирали и без ПР, по пушу, но реально представь это на скейле сотни параллельно активных бренчей с допустим ~20 пушами в час — это сколько энвов нужно параллельно иметь и откуда у вас столько денег?

Можно и без параллельности: закончил предыдущую сборку — запустил новую, если после предыдущей что-то было отправлено.
Если фичи проверены локально, то тот небольшой набор изменений, которые привели к поломке конкретного билда, легко отлавливается (практически всегда по тестам можно уточнить до 1-2 фич).

Это безотносительно темы про полезность юнит-тестов, просто по конкретным предложениям.

А что, если компонент B 3rd party? А если компонент другой команды? А какой версии брать компонент B? А если что-то упало, как определить виноват компонент A или компонент B? Мантра юнит тестирования превращается в мантру интеграционного, при том что постоянно интеграционные тесты путаются с пакетными, и при том что нет никакого понимания что интеграционные должны проводиться в контролируемом и предсказуемом энвайрменте (коим локальная тачка дева не является — очередная мантра, что если гоним локально то это есть достаточное условие).

Можно и без параллельности: закончил предыдущую сборку — запустил новую, если после предыдущей что-то было отправлено.
Если фичи проверены локально, то тот небольшой набор изменений, которые привели к поломке конкретного билда, легко отлавливается (практически всегда по тестам можно уточнить до 1-2 фич).

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

А что, если компонент B 3rd party?

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

А какой версии брать компонент B?

Текущей установленной, или просто текущей, если в репо.

Вы намеренно засыпаете вопросами, для ответа на который достаточно букваря?

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

Про «достаточное» условие вы высосали из пальца и приписали мне безо всяких оснований. Если будете продолжать в таком духе, дискуссию придётся свернуть за бессмысленностью.

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

То есть вы предлагаете еще дальше отложить интегрейшн поинт, который и без того уже отодвинут

Что-что отодвинуть?
Извините, ваш речекряк не распарсен.

все еще офф бранча о котором кроме самого девелопера никто не знает

Я вообще-то говорил в данной части о тестировании уже сводного результата. По-моему, это очевидно (и я не использую модный жаргон всуе).

мок

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

Текущей установленной, или просто текущей, если в репо.

Установленной где? В энве которого еще нет? В репе где? В бренче, в мастере? Секунду назад в мастере хедом был другой коммит — итд итп.

в клеевой слой

Что такое пресловутый клеевой слой, о котором все тут так распинаются? Кто-то еще пишет геттеры-сетерры прокси объектов вместо какого-то ямла или еще какого DSL с кодогенератором и получают за это зарплату? Проблемы индейцев..

Что-что отодвинуть?
Извините, ваш речекряк не распарсен.

Предлагаю пойти книжек почитать, на тему CI/CD, некоторые буквы после этого станут более понятными.

Предлагаю пойти книжек почитать, на тему CI/CD, некоторые буквы после этого станут более понятными.

А, то есть прочтен выброс потока сознания какого-то мегагуру и на этом основании начато лошение всех вокруг.
Тогда да, говорить бесполезно.

Проблемы индейцев..

От индейцев слышу (tm)

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

основной проблемы с которой CI призван бороться — отложенный интегрейшн поинт

О, пошла конкретика. Так у какого гуру взят этот термин?

Девелопер, не знающий что такое CI рассказывает мне тут за практики тестирования?

Девелопер, не умеющий русский язык, чтобы не ввернуть в него десятками никому не известные термины, даже при наличии своих? (Хм, он и английский уметь не будет...)
Я знаю, что такое CI. Это не помогает понимать ваш, назовём это так, язык.

И ещё одно — в этой ветке тема CI никем не поднималась, пока вы не начали говорить, что, мол, его не знают. Видимо, для вас это коньковая тема, но при чём тут мы и остальная дискуссия?

Девелопер, не умеющий русский язык

Ой вы меня извините пожалуйста, я тут в изгнании вдалеке от родины успел позабыть горячо любимый и родной язык (сарказм). Будь моя воля — на галерах бы только по английски разговаривали.

И ещё одно — в этой ветке тема CI никем не поднималась, пока вы не начали говорить, что, мол, его не знают. Видимо, для вас это коньковая тема, но при чём тут мы и остальная дискуссия?

Вот в том-то и прикол — никто не поднял эту тему :) хотя оно пипец как связанно и завязано на CI/CD процесс. Быстрый фидбек и вот это все.

хотя оно пипец как связанно и завязано на CI/CD процесс. Быстрый фидбек и вот это все.

Так в том и дело, что завязано оно только у тех, кому этот «быстрый фидбек» установлен внешними требованиями.

В задачах вот прямо сейчас, например, у меня никакой I/D в течение дня не допустим в принципе, за исключением 1% мест, которые никому особо не интересны. На следующий день, да, выкатывается новое (опробованное на мышах и кроликах). Но посреди дня — только если такой фиаско, что уже его не испортить.
А у соседей основная работа вообще чисто ручная в jupyter, зато важно, чтобы были данные к конкретному моменту.

А вот на предыдущей работе были или плановые окна, или периоды, когда всё тихо и можно творить что угодно, потому что, грубо говоря, ток не подан :)

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

И после этого ваш один пример с CI выглядит как что-то ну очень частное :)

Так в том и дело, что завязано оно только у тех, кому этот «быстрый фидбек» установлен внешними требованиями.

Что за бред, если у вас больше 5 человек на проекте эти требования реальности (или вы этого не понимаете — по вотерфоллу тоже много где сегодня работают, я не виню (ну справедливости ради где-то он и вправду нужен, не ядерной ЭС например)).

И после этого ваш один пример с CI выглядит как что-то ну очень частное :)

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

Что за бред, если у вас больше 5 человек на проекте эти требования реальности

Ну вот пока вы будете думать, что «бред» и «больше пяти» — не удивляйтесь последствиям.

по вотерфоллу тоже много где сегодня работают

Не по вотерфоллу :)

Никто вам не виноват в вашем выборе рабочего места.

Что оно не хайповое? Ну да, это так :)

Что оно не хайповое? Ну да, это так :)

Ой да ради бога :)

Слишком поздно — интеграционный тест означает что уже был собран артефакт и куда-то задеплоен (собрали машину и вывели на трассу).

А это уже проблема ваших процессов, что интеграционный тест нельзя сделать иначе, чем «собрать артефакт и задеплоить».
Для тестов самого верхнего уровня, я согласен, оно так. Но на уровне связи двух модулей ничего такого нафиг не надо.

а если у тебя по 10 пулл реквестов в репо в час — что будешь делать?

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

А тесты на клеевой код слишком легко подвержены тем же ошибкам, что и сам клеевой код, потому что 90% проблемы с ним не в недопонимании, а в уверенной неверной интерпретации чего-то, начиная от доки соседа и до системного API.

А это уже проблема ваших процессов, что интеграционный тест нельзя сделать иначе, чем «собрать артефакт и задеплоить».
Для тестов самого верхнего уровня, я согласен, оно так. Но на уровне связи двух модулей ничего такого нафиг не надо.

Очевидно, подразумеваются пакетные тесты, которые все еще не отменяют интеграционных. Или еще хуже, традиционное ’works fine on my machine, ops problem now’?

Очевидно, подразумеваются пакетные тесты,

Мне неочевидно. Потому что такой термин вообще не находится ни в известном мне наборе, ни в гуглении.

Или еще хуже, традиционное ’works fine on my machine, ops problem now’?

Эти домыслы уже не только бессмысленны, но ещё и оскорбительны.
Это было намеренно, или как?

Мне неочевидно. Потому что такой термин вообще не находится ни в известном мне наборе, ни в гуглении.

Если вы еще девопс загуглите, будет вообще интересно, ведь там столько мнений.. Обожаю этот современный мир, где коммунити стало важнее чем экспертиза :)
Ладно, поскольку это и правда не гуглится, удостою объяснения. Есть разница между интеграционным тестированием компонентов одного приложения (что я называю пакетными тестами), например тестирование в сборке нескольких мавен-модулей. А есть настоящее интеграционное тестирование, где тестируется весь продукт целиком, где все реальное и не замоканное.

Эти домыслы уже не только бессмысленны, но ещё и оскорбительны.
Это было намеренно, или как?

Я не виноват, что вы демонстрируете полное непонимание big picture в отрасли, которую представляете. Я расцениваю оскорблением необходимость доказывать вам это.

Есть разница между интеграционным тестированием компонентов одного приложения (что я называю пакетными тестами),

А, _вы_ называете. Ook. Ваше право, но надо было это сказать сразу.

Обожаю этот современный мир, где коммунити стало важнее чем экспертиза :)

Очевидно, что Вы считаете, что именно Ваша «экспертиза» (ещё один бездумно заимствованный термин при наличии ранее известных и при явной конфликтности) важнее других, в том числе «коммунити».

Я не виноват, что вы демонстрируете полное непонимание big picture в отрасли, которое представляете.

И опять термин из серии «кандидат для bullshit bingo».

Я расцениваю оскорблением необходимость доказывать вам это.

Красиво ушли от ответа. Апплодисменты.
Только вначале спросите самого себя — какая часть происходящего в отрасли соответствует именно Вашему пониманию «big picture», чем бы оно ни было? И чем отличаются, кроме отсутствия «экспертизы» (и вообще тем, что они все лохи), те, кто не соответствует?

А, _вы_ называете. Ook. Ваше право, но надо было это сказать сразу.

Нет, не я, я выучил этот термин у более умных людей.

Очевидно, что Вы считаете, что именно Ваша «экспертиза» (ещё один бездумно заимствованный термин при наличии ранее известных и при явной конфликтности) важнее других, в том числе «коммунити».

И это тоже были не мои слова, landing.google.com/...​ok/chapters/foreword.html

Today, we hear a brazen culture of «just show me the code.» A culture of «ask no questions» has grown up around open source, where community rather than expertise is championed. Google is a company that dared to think about the problems from first principles, and to employ top talent with a high proportion of PhDs.
бездумно заимствованный термин

Вам прямая дорога в 1С, там отлично ’парусски’ программируется.

Только вначале спросите самого себя — какая часть происходящего в отрасли соответствует именно Вашему пониманию «big picture», чем бы оно ни было?

Ну в 2010 я и мои единомышленники отстаивали CI, в 2012 отстаивали CD, потом девопс, инфра и конфигурейшн аз код итд итп. Из года в год слышу одно и то-же — нытье. А через пару лет все все равно делают так, как я говорил, и это становится де-факто стандартном в индустрии. Пока у меня нет причин сомневаться, что то что делаю и говорю я на эдже индустрии (ну справедливости ради — я это не придумываю, а подбреваю у еще более умных людей и сразу пытаюсь применить в своей компании). Да, звездная болезнь меня уже захватила, но на форуме криптохомячков ноунеймовой страны можно и повыеживаться без вреда карме.

Нет, не я, я выучил этот термин у более умных людей.

Ну хоть ссылочку дайте.

И это тоже были не мои слова, landing.google.com/...​ok/chapters/foreword.html

Ясно. Контекст — opensource. И автор таки неправ в случае ключевых продуктов, которые тянут его вперёд и известнее остальных: там не просто комьюнити, но комьюнити грамотных (хоть и вредных, в смысле стиля поведения — но это уже тема другой книги).
Я это предисловие пропустил вообще. Ну не читаю таких текстов;) может, и неправ.

Вам прямая дорога в 1С

Передёрг засчитан ;)

А через пару лет все все равно делают так, как я говорил, и это становится де-факто стандартном в индустрии.

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

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

Не-а. Карма она всё считает :)

Ну хоть ссылочку дайте.

GDPR, извините.

Ну не читаю таких текстов;)

Видно, зря.

Не-а. Карма она всё считает :)

Я не эзотерик, так ради красного словца.

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

Ну хз. Я особисто просто не можу писати код починаючи з тестів. Ну не мислю я так. Можливо, якби починав вчитися азам програмування, починаючи з TDD (хм, а така книжка/курс взагалі є ?), воно б і зайшло, а так... Далі, в процесі написання тестів, дійсно іноді код підправляти приходиться, ну це таке...
P.S.
От потроху ангуляром балуюсь, так взагалі прикол — іноді ніфіга не очевидно як написати тест на працюючий код. Ти ніби інжектиш мок, що підміняє роутер, воно повинно працювати, але в деяких випадках не працює — тупо висить десь глибоко в нетрях js. І ти тратиш кучу часу на спроби зрозуміти, чому, знаходиш топік з такою ж проблемою, і без відповіді і врешті кажеш собі — та ну його нафіг. :)

так взагалі прикол — іноді ніфіга не очевидно як написати тест на працюючий код

Действительно прикол, ведь юнит тест это автоматизированная запись того, что должно было происходить в голове при написании кода, что я называю «компиляцией в голове» и симуляцией исполнения. Если не понятно, как написать тест, то не понятно как развернуть этот метод/цикл и скомпилить и симулировать это все в голове, значит этого никогда не делалось, значит код написан по принципу «а что если я сюда воткну это и обновлю страничку? о, работает!», а значит код воняет, тяжело читабелен и не гибок.

справа в тому, що код тут майже ні при чому:
є Angular-компонент, у якого в html крім всього іншого є директива routerLinkActive="active"
... <td class="ownerFullName"><a routerLink="/owners/{{owner.id}}" routerLinkActive="active" (click)="onSelect(owner)">{{owner.firstName}} {{owner.lastName}}</a></td> ...
при цьому банальний тест
it('should call ngOnInit() method', () => { fixture.detectChanges(); expect(spy.calls.any()).toBe(true, 'getOwners called'); });
в Angular 4 виснув вглуху, якщо router не підміняти стабом
providers: [ {provide: Router, useClass: RouterStub},... ]
а після підміни він просто падав.
Видалення з routerLinkActive="active" проблему вирішувало — тест працював.
І проблема не виключно в директиві routerLinkActive, інакше б падали всі тести. де в компонентах вона є.
Тобто, схоже, десь в стаб-об’єкті потрібно встановити щось, що буде затичкою для неявного чеку стану routerLinkActive.
Дока ну ду-уже «детальна»:
angular.io/...​sting/RouterTestingModule
(хоча за останній рік в цілому по фреймворку суттєво покращилась)
Так от, прикол в тому, що зараз, в Angular 5, без заміни роутера на стаб тест відпрацьовує нормально (не висне).
З стабом, звичайно, помилка залишається — треба розбиратися, чого йому не вистачає. Але щось немає натхнення.
В Java якось з такими проблемами при тестуванні не стикався, можливо, в тому числі і тому що документація краща.

Какой-то edge case, он правда должен изменить мое отношение к тестам? Я не очень близок с ангуляром, но складывается впечатление что либо тест не правильный (не замокан сам вызов метода который чего-то там делает с роутером), либо мок роутера должен быть подправлен (нет доков — ангулярка опенсорсная, гитхаб в помощь).

Суть в тому, що щоб написати нормальний тест на робочий код, мені в цьому випадку прийдеться витратити набагато більше часу, ніж на написання самого коду. Розуміючи при цьому, що проблема в даному випадку не в моєму коді, а десь глибше, чи то в тесті чи то в коді фреймворка.
ангуляр то опенсорсний, тільки це не маленький такий фреймворк. і одних відкритих issues по routerLinkActive 18 штук, причому одна чимось схожа — там зависання в рантаймі при додаванні routerLinkActive всередину *ngFor, з невеликим нюансом ( я її на своєму проекті можу повторити). Тобто десь щось в консерваторії не так. Знову ж таки, маючи достатньо часу на копання в кишках ангуляра і достатню кваліфікацію, можна з’ясувати причину і можливо навіть пофіксити.
Тільки суть в чому — я на ці копання витратив достатньо багато часу. І якщо копатися далі — це ще займе час. В результаті маємо варіант: «я код не пишу, в мене з тестом проблема, буду копатися в коді ангуляра, так що на мене в найближчі кілька днів не розраховуйте» :)

і одних відкритих issues по routerLinkActive 18 штук

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

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

И что в этом плохого? Постоянно приходится всех учить говорить «нет», хотя на западе с этим проблем нету — у нас в нации в ДНК это прописано что-ли... Опять же к примеру выше, не получается пофиксить проблему — залепим индикатор скотчем и будем молиться что топлива хватит. Вдруг пронесет ©.

Действительно прикол, ведь юнит тест это автоматизированная запись того, что должно было происходить в голове при написании кода, что я называю «компиляцией в голове» и симуляцией исполнения.

И какое это имеет отношение к теме того, что тестирование кода может быть усложнено просто фактом, что он дёргает что-то внешнее, что нельзя или невыгодно мокать?

а значит код воняет, тяжело читабелен и не гибок.

Настоятельно прошу перестать речекрякать. Тут форум профессионалов, а не конференция криптохомячков.

И какое это имеет отношение к теме того, что тестирование кода может быть усложнено просто фактом, что он дёргает что-то внешнее, что нельзя или невыгодно мокать?

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

Настоятельно прошу перестать речекрякать. Тут форум профессионалов, а не конференция криптохомячков.

То есть вы в упор отрицаете, что написание тестов влияет на стиль вашего кода?

Если вы в упор не видите разницу юнит и интеграционного тестирования

Я безусловно вижу, что есть разница в том, как вы это называете.
Но я не считаю, что тут есть какая-то резкая граница. Для меня это непрерывная шкала от тестов уровня «одна функция/метод» и до программного комплекса в целом, с возможностью тестирования на каждом уровне.
Вы, похоже, принципиально отвергаете промежуточные уровни, и вот этого я не понимаю, потому что основные проблемы логики проектирования выявляются как раз на них.

и не понимаете, что не мокая в юнит тестировании вы превращаете это в интеграционное

Кто тут чего не понимает? По-моему, вы.

где присутствуют уже как минимум два компонента и баг может быть как там так и тут.

ДА!
И «там», и «тут», и в то же время может быть «ни там, ни тут» — когда проблема во взаимодействии.
Три места для бага, а не два.
И это значит, что подход «к пуговицам претензии есть?» не работает для построения работающего продукта.

Отсутствием одного из уровней вы превращаете свои тесты в шум

Не превращаю.

Неужели не понятно, что если юнит тесты компонента А были успешны но интеграционные зафейлились — с большой вероятностью проблемы в компоненте Б, в противном случае упали бы юнит тесты?

Нет, конечно, не понятно. Потому что неверно.
Может быть всё идеально в B, но нарушено или во взаимодействии с A, или в среде, которая создаётся в результате работы A.
И сколько вы ни покрывайте B, этого не отловите.

Может, у вас таких случаев не бывает (хм...), а у меня они постоянны.

То есть вы в упор отрицаете, что написание тестов влияет на стиль вашего кода?

То есть вы продолжаете фонтанировать домыслами от имени собеседника?

Нет, конечно, не отрицаю. В большинстве случаев написание тестов и просто помогает создать работающий код (ну ленивый я), и структурирует мышление, очищая интерфейсы этого кода, и делает понятнее реализацию... Но
1) в большинстве (и я не говорю про клеевой код, у меня его обычно нет, задачи другие)
2) переход от «компиляции в голове» совершенно не очевиден, например, при алгоритмоёмких задачах. Там тестирование предназначено или для регрессий, или для краевых случаев, но никак не для перекладки пути мышления о коде.
И вот именно последнее — это явно то, что вы не хотите понимать.

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

Странно, ибо у меня сложилось именно такое впечатление о вас лично.

Не превращаю.

Превращаете.

И сколько вы ни покрывайте B, этого не отловите.

Да, это правда для конкретно озвученного кейса, но я говорил выше что юнит тесты не отменяют всех других видов тестов. Однако мне вменяют тут, что остальные тесты могут отменить юнит тесты, с чем я категорически не согласен. Найти и отдебажить проблему вызванную опечаткой «=» и «==» когда она словлена где-бы то ни было выше чем юнит тесты — будет сильно дороже.

клеевой код

То есть вам само вымышленные термины можно, а мне нет? :(

2) переход от «компиляции в голове» совершенно не очевиден, например, при алгоритмоёмких задачах. Там тестирование предназначено или для регрессий, или для краевых случаев, но никак не для перекладки пути мышления о коде.
И вот именно последнее — это явно то, что вы не хотите понимать.

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

То есть вам само вымышленные термины можно, а мне нет? :(

Glue code даже в википедии есть, так что посыл не по адресу :)

Странно, ибо у меня сложилось именно такое впечатление о вас лично.

С чего бы это? ;)

Однако мне вменяют тут, что остальные тесты могут отменить юнит тесты, с чем я категорически не согласен. Найти и отдебажить проблему вызванную опечаткой «=» и «==» когда она словлена где-бы то ни было выше чем юнит тесты — будет сильно дороже.

Так слово «отменить» и есть ваш домысел (за исключением, да, присутствующих тут отдельных фриков).
Так и пример с «=» вместо «==»: в 90% случаев сейчас это просто ловится компилятором (а если автор не словил — значит, не читал предупреждения).
Юнит-тесты не панацея, но средство в первую очередь самоконтроля автора кода (во вторую — документирование метода использования). Есть методы написать честный тест, и есть методы написать ничего не проверяющий тест. Есть код, которому они безусловно нужны, и есть, который от них просто ничего не выиграет.
Любое навязывание их присутствия независимо от специфики кода это административное самодурство.

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

У нас и по 5 лет бывает :) не девопс ;) и какая связь со всем названным?

Так слово «отменить» и есть ваш домысел (за исключением, да, присутствующих тут отдельных фриков).

Я именно это читаю в теле самой статьи. «Юнит тесты не нужны» — и все больше я слышу это от джунов.

Так и пример с «=» вместо «==»: в 90% случаев сейчас это просто ловится компилятором

В большинстве языков какой нибудь if (a = b) не запродюсит никакого варнинга.

(а если автор не словил — значит, не читал предупреждения)

Почитайте про фейл при запуске Апполо 8.

Юнит-тесты не панацея

Нет панацей и серебряных пуль, согласен.

но средство в первую очередь самоконтроля автора кода (во вторую — документирование метода использования)

Я бы на первое место вывел все-же другое, ну ладно. И это не полный список.

У нас и по 5 лет бывает :) не девопс ;) и какая связь со всем названным?

Речь не про легаси а вполне живой код, и не какой нибудь очередной костыль. Я не совсем корректно описал ситуацию — просто в девопс мире ПР часто открываются в незнакомую кодовую базу, например джава девелопер открывает ПР в шеф кукбук или терраформ модуль (то есть не просто кодовая база не знакома — а технология). Юнит тесты и линтеры помогают отсеить 99% ошибок без траты времени SRE инжинеров на ревью, и ошибок на реальных энвах (пусть даже и на дев энвах).

Я именно это читаю в теле самой статьи. «Юнит тесты не нужны»

С каких это пор «не стоит увлекаться» == «не нужны»?
Ъ — логика?

и все больше я слышу это от джунов.

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

В большинстве языков какой нибудь if (a = b) не запродюсит никакого варнинга.

JS? Так на нём вообще напрямую писать не надо.

Почитайте про фейл при запуске Апполо 8.

Не уловил связи.

джава девелопер открывает ПР в шеф кукбук или терраформ модуль (то есть не просто кодовая база не знакома — а технология). Юнит тесты и линтеры помогают отсеить 99% ошибок без траты времени SRE инжинеров на ревью, и ошибок на реальных энвах (пусть даже и на дев энвах).

Ну в тематике-то хоть у таких девелоперов есть «экспертиза»? Или народ вообще лезет немытыми руками в операционное поле, вооружившись только учебником терапевта, и предполагая, что ничего не испортят?

С каких это пор «не стоит увлекаться» == «не нужны»?
Ъ — логика?

Я читаю между строк

JS? Так на нём вообще напрямую писать не надо.

На вскидку та-же джава

Не уловил связи.

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

Ну в тематике-то хоть у таких девелоперов есть «экспертиза»? Или народ вообще лезет немытыми руками в операционное поле, вооружившись только учебником терапевта, и предполагая, что ничего не испортят?

Да, именно в этом и прикол — наличие юнит тестов позволяет ребятам без экспертизы прийти и поменять какую-то мелочь в кукбуке, не создавая излишнее депенденси в своем скраме, не создавая лишний делей итд итп. Казалось бы, какое отношение имеют юнит тесты к скраму итд, да? :)

На вскидку та-же джава

«На вскидку», полный незачёт. Потому что в Java в if, while и т.п. требуется строго boolean, а автоконверсии из других типов нет — надо явно писать (выр)!=0, (выр)!=null и т.п.

Так о каких языках шла речь?

Ну там как раз отличный пример про «а давайте не будем ничего фиксить а просто задокументируем»,

Это точно про Apollo 8?

Да, именно в этом и прикол — наличие юнит тестов позволяет ребятам без экспертизы прийти и поменять какую-то мелочь в кукбуке, не создавая излишнее депенденси в своем скраме, не создавая лишний делей итд итп.

Ага, и сломать «по мелочи» код — подумаешь, там тест прежний не прошёл, получилась регрессия, мы же лучше знаем, как надо...
Таки стыд и скрам (tm)

Я читаю между строк

Лучше бы вы этого не делали, чесслово.

полный незачёт

Каюсь, был уверет в обратном. Ладно, неудачный пример, у меня было 5 утра — но суть же была понятна. Можно найти кучу подобных — пропущенное !, пропущенные <> итд, и это только в условии.

Это точно про Apollo 8?

Да, точно. Предисловия в книжках тоже надо читать.

Ага, и сломать «по мелочи» код — подумаешь, там тест прежний не прошёл, получилась регрессия, мы же лучше знаем, как надо...
Таки стыд и скрам (tm)

Как это «подумаешь». Тест не прошел — система не даст смерджить ПР, я уже молчу про код ревью, которое будет производиться уже кем-то с релевантной экспертизой, и еще про целую кучу линтеров и уровней тестирования.

Лучше бы вы этого не делали, чесслово.

Меня устраивает.

Как это «подумаешь». Тест не прошел — система не даст смерджить ПР,

Тест пройдёт, потому что будет исправлен соответственно. А как же без адаптации тестов под новый код? Так не бывает :)

Как это «подумаешь». Тест не прошел — система не даст смерджить ПР,

О. Таки кто-то есть, и ему нужно время, чтобы изучить все новости от коллеги. Чудо испарилось на глазах.

Меня устраивает.

А собеседников — обычно нет.

О. Таки кто-то есть, и ему нужно время, чтобы изучить все новости от коллеги. Чудо испарилось на глазах.

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

и надавать по рукам программистам-перфекционистам

Плиз сразу скидывай в ЛС координаты провинившихся. Когда они будут бежать с тонущего корабля, мы их с удовольствием приютим, нам такие нужны :)

Договорились! Сброс балласта вовремя может спасти корабль.

Мне кажется, что помимо всего прочего, далеко не все компании и разработчики хотят/умеют писать(вовремя) рабочий код(это я не про автора), но своё существование надо же как-то оправдать, вот и начинаются всякие «тесты не нужны», «архитектура не нужна», «что за рефакторинг...» и тд. =)

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

Повторю свой старый комментарий.

Мне кажется, что все эти разговоры, что нет времени, денег, тестировщиков, одобрения заказчика etc писать тесты — это симптомы. Тесты не пишутся, потому что их слишком сложно или вообще невозможно написать. А причина — плохая компоновка кода. Даже если просто держать в уме «а как я этот метод буду тестировать?» — это уже очень сильно помогает. И Arrange-Act-Assert не должен особо выходить за рамки трёх строчек.

Если это не так, то не с тестом проблема, а сигнал, что код плохой.

Причём даже довольно короткий и простой. Чтобы не быть голословным, приведу пример

public void congrats() {
    Date today = new Date();
    if (today.getMonth() == 1 && today.getDay() == 1) {
        System.out.println("Happy New Year!");
     }
}

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

Вот. Можете не благодарить ;)

    public void testCongrats() throws UnsupportedEncodingException {
        PrintStream oldOut = System.out;

        ByteArrayOutputStream baos = new ByteArrayOutputStream();
        System.setOut(new PrintStream(baos));

        congrats();

        System.setOut(oldOut);

        Calendar cal = Calendar.getInstance();
        if (cal.get(Calendar.DAY_OF_MONTH) == 1 && cal.get(Calendar.MONTH) == 1) {
            assertEquals("Happy New Year!", baos.toString("UTF-8"));
        } else {
            assertEquals("", baos.toString("UTF-8"));
        }
    }

Wrong.
1. Подмена System.out — бррр. Эксепшн внутри congrats? Паралельный ран? Аутпут с других потоков?
2. Ничего не замокано. Я могу протестировать поздравительный сценарий один день в году?
3. И вообще — ифы в тесте? Серьезно?
Если это был прикол, то очень тонко, снимаю шляпу.

зате юніт тест цовераґе — 100%

Предлагаете ждать НГ, чтобы протестировать метод?!

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

И на знамени, которое они гордо понесут перед собой, будет написано:

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

Автомат Калашникова имеет «не красивый код»? Как раз таки наоборот.
В среду утром будет рогатка вместо автомата, и это ОК, не проблема. Мысль ясна, справедлива и стара как мир. Пример мог бы быть более релевантным.

В первом же абзаце баг.

Когда приходится начинать или перенимать новый проект, всегда возникает заветное «а давайте все перепишем», «а почему технология X а не Y» и под конец — «а этот код писали индусы». Резюмируется все фразой «давайте перепишем и вместо Y используем X». Но когда начинаешь спрашивать: «Почему технология Y применима к этому проекту?». В ответ слышится невнятное: «Ну, новее, интереснее...», «Мне было бы интересно получить опыт по ней».

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

и да, каждая строка ТЗ должна быть закрыта тест-кейсом. особенно где написано про «передовые методики разработки» и «современный интерфейс». и адаптивность решения — на всем актуальном ассортименте телефонов из Розетки!)

Тесты несомненно важны. Они сразу помогают локализовывать ошибки без траты времени на их обнаружение при тестировании.

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

I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent. © Dwight D. Eisenhower

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

Только вот, хочется вступить в дискуссию с адептами TDD. Вы утверждаете, что вы будете разрабатывать с той же скоростью с тестами, что и без тестов? Или все-таки поменьше? Потом, тесты также как и любой здоровый код требует времени на поддержку. Никто спорить не будет? Кто за это платить будет? Или же вы будете в оставаться в не оплачиваемый овертайм и педалить?

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

Касательно ограниченного бюджета. Если нет денег на то что бы начинать нормальный бизнес то может и не стоит его начинать и тесты тут не причем.

Я понимаю что для тебя ценно поддерживать дискуссию, но может все таки почитаешь книги и попробуешь сам что-то сделать с тестами и без них?

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

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

Так что продайте мне тесты не входя в технические подробности. Допустим я заказчик. Хочу вложить в разработку, бюджет на полгода команды из 1 сеньйора и двух мидло/джунов, а теперь продайт мне тесты? В чем для меня выгода?

1. Цена за строчку кода без тестов х * 2, c тестам n + x * 1, подставь n и нарисуй график, подумай что будешь делать когда после того как график 1 пересечет график 2.
2. На самом деле функции в 1 пункте должны быть не линейными, а экспоненциальными, придумайте что делать когда цена за новую фичу будет неподъемной.
3. Идеи и фразы типа «мы все исправим потом», «мы переделаем позже» это лож т.к.
а — позже всегда будет дороже и сложнее.
б — давление бизнеса не ослабнет, а когда ослабнем то и необходимость в разработке и исправлениях пропадет.

1. Цена за строчку кода без тестов х * 2, c тестам n + x * 1, подставь n и нарисуй график, подумай что будешь делать когда после того как график 1 пересечет график 2.

Чем подтверждены эти формулы расчёта цены?

Здравым смыслом?
goo.gl/qA5NCo

Ясно :)
Отвечу такого же уровня здравым смыслом
macode.ru

Продаю. Вы задумали построить свою машину. Придя в магазин — вы можете купить только типовой инструмент, например отвертку и пассатижи. Вам явно этого не хватит, вам потребуется изготовить некоторое количество своих собственных инструментов и станков для изготовления деталей автомобиля по вашему дизайну. Так-же, вероятно, вам придется сконструировать сборочный конвеер, поскольку собирать автомобили вручную — очень трудозатратно имея только одного синьора и двух мидло/джунов, и скорее всего каждая собранная машина будет иметь погрешности поскольку ручной труд слабо воспроизводим (каждая машина это каждый билд софта).

Очень просто: заменяем вычурный «технический долг» на доходчивый множитель себестоимости каждой новой условной юзерстори в оплачиваемых человекочасах, растущий вместе с ним (геометрически).

Ого как оптимистично! Скажите пожалуйста, у вас в компании тестами покрыто 100% кода даже тех сайтов, которые достались вам от предшественников?

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

а почему 100% не покрыто?

есть прототипы, внутренние эксперименты, есть проекты в процессе миграции от предшественников ну и наши косяки иногда тоже есть (но их действительно не много)

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

Мы же ему не будем говорить, нету денег на тесты с самого начала, уходи?

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

С этим я тоже согласен, статья называется

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

 А не Рабочий продукт — прежде всего, никогда не стремитесь к чистому коду и забудьте о тестах?

Интересно Ваше мнение, когда не стоит увлекаться кодом и тестами. Возможны ли такие ситуации, что мы можем ими увлечься больше целесообразного?

Никто не отрицает что на написание тестов уходит время. Фанаты ТДД лишь говорят что на написание тестов уходит меньше времени чем на исправление багов в не протестированном коде.
И еще одно замечание от себя, тестировать нужно логику продукта. Если ваш продукт/прототип — это формочки которые просто показывают информацию(99% продуктов) то можно и не тестировать, действительно запустить легче. Если же вы пишите аналитику или базу данных или что либо другое что содержит в себе логику то я позволю себе процитировать классика:

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

Николай, прежде чем давать высказывания космического масштаба и космической же глупости, почитайте Р. Мартина и Фаулера для начала. Так вот, чем больше кодовая база, тем больше времени будет занимать внесение новых изменений в код, вплоть до того, что фикс 1 час будет занимать недели-месяцы без тестов. И сюда оносятся не только юнит-тесты, но и остальные тоже.

Вы утверждаете, что вы будете разрабатывать с той же скоростью с тестами, что и без тестов?

Представь стандартный рефакторинг, например ты хочешь изменить сигнатуру метода. Что ты делаешь? Идешь в IDE, кликаешь правой мышкой по методу и выбираешь ринейм — и умная IDE находит все вызовы этого метода и делает переименование там тоже. Сколько у тебя заняло бы времени на такую простую операцию без умной IDE?
Так вот IDE умеет понимать только синтаксис, она не понимает логику. При рефакторинге, который затрагивает поведенческое изменение, при наличии юнит тестов, ты запустил их после рефакторинга и в течении минуты знаешь результат. Без тестов, затраченное время будет прямо пропорционально размеру кодовой базы, и после некоторого психологического барьера будет в принципе послано нахер ибо «и так сойдет». Все эти эпизоды суммируются в течении времени и за год-два получаем кодовую базу, которую никто не хочет брать на саппорт и толковые инженеры пачками бегут с проекта и все сложнее найти новых ибо сарафанное радио работает хорошо. Казалось бы, какое отношение юнит тесты имеют к джоб сатисфашну и аттришн рейту на проекте, huh?

В любом деле прежде всего нужен баланс и стратегия.
Отдать все ресурсы на быстрый результат? Ок. Но что потом будет с развитием продукта после запуска, когда нужны будут новые фичи, а команда будет заниматься поддержкой того, что слепили на скорую руку. А оно будет валиться и валиться.
Гнаться за 100% покрытием тестами — тоже не имеет смысла. Надо определить ключевые участки.
Гнаться за передовыми технологиями — да, интересно, но можно вляпаться и потом тратить кучу времени на допиливание и костыли, потому что технология сырая и в продакшене появляются дыры и баги.
Чистый код? Все равно изначально делать все идеально не получится. Рефакторинг никто не отменял, и периодически этому надо уделять внимание.
Поэтому важно все. И правильно распределять ресурсы и задачи — это задача менеджеров.

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

Имхо, не совсем согласен с тем, что

Чистый код нужен только нам

 А как же те случаи, когда заказчик забирает исходники и отдает их на сторонний аудит? Если не будет чистого кода — хана репутации компании\команды. Как по мне, этого нужно избегать.

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

Так — честно, да. Но мне знакомы случаи, когда код «неожиданно» для разработчиков проверяется аудиторами и тогда «ох сколько матов летит » от заказчика.

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

Согласен, если PM правильно выполняет свою функцию прокладки фильтра и не пропускает маты на команду — это здорово. Но если из-за такой ситуации PM навсегда потеряет клиента и его друзей — руководству явно это не понравится. Атата, все дела.

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

Чистый код нужен только нам, чтобы легче было работать дальше.

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

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

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

Это не совсем правильная аналогия мягко говоря нет фундамент нужен вам как проектная часть дома другое дело как именно будет достигнуто его строительство в процессе как результат вы покупаете результат одни строители могут достичь его одним путём другие другим одни дороже другие дешевле но результат одинаковый у тех и у других.

и доктора могут руки не мыть перед операцией

Могут и не мыть могут обрабатывать каким-то высокотехнологичным бактерицидным как во многих современных клиниках могут вообще обрабатывать ультрафиолетом как не во многих современных клиниках могут конечно и по-старинке мылом результат «мытые руки» опять же ж в пределах нормы вопрос в эффективности какой он достигнут и вообще возможности такового как процесса чисто технологически (мыло везде а вот специальная жидкость нет а ультрафиолет в свою очередь также сертифицирован и специальный а то просто руки сожжёт вместе с микробами и т.д. и т.п.)

Хорошим «примером по аналогии» может служить вот актуальный GDPR compliance одним это стоило $2 млн потому что у них тысячи сотрудников и вообще любой чих стоит тысячи чисто бюрократически другим это стоило $500 потраченных на юридическое бюро которое подготовило им «terms & conditions» и провело бесплатный вводный курс для всех троих сотрудников третьим это вообще ничего не стоило потому как они и так оказывается были готовы и всегда были потому что бронь принимают они по телефону записывают в тетрадку которую хранят в сейфа и записи не держат кроме карточек на которых клиент может оставить свой адрес и они пришлют ему открытку и на Рождество тоже чисто бумажной почтой но в результате результат достигнут единый и у них даже могут быть общие клиенты.

но результат одинаковый у тех и у других

Нет, не одинаковый. Сроки эксплуатации «хрущевок» — 50 лет, сталинского типа — 150 лет. Сроки на проведение необходимого капитального ремонта тоже отличаются. Проводка и всё остальное в домах тоже резко отличаются. Чудес нет и качество стоит денег.

одни строители могут достичь его одним путём другие другим одни дороже другие дешевле

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

Даже приемлемое качество всегда чего-то да стоит и кто-то его оплачивает. Из воздуха деньги не берутся — значит оплачивает клиент. Разница лишь в том понимает он это или нет, активно управляет своими рисками или живёт на авось и требует/ожидает от окружающих чудес.

Даже приемлемое качество всегда чего-то да стоит и кто-то его оплачивает. Из воздуха деньги не берутся — значит оплачивает клиент. Разница лишь в том понимает он это или нет, активно управляет своими рисками или живёт на авось и требует/ожидает от окружающих чудес.

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

Нет варианта — вы там стройте как хотите, а мы оплатим только нужное нам, но все риски будете нести вы.

Ах ты ж йопта я же ж забыл я же ж с Родиной говорю! ))

Мечтать конечно можно, но в реальности — нет.

Так вот деточка не в СССР это суровая капиталистическая реальность ))

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

Тут таки аналогія не вірна тому, що не враховані основні обмеження проекту.

Пацієнт у дуже важкому стані лежить на операційному столі і буквально залишилось 10 хв. Для хірурга старанно помити руки перед операцією — 11 хв. Що оберемо — починати негайно чи таки мити?

аналогія не дуже — хірурга за порушення правил і посадити можуть, або клініка на мільйонний позов влетить. Тому якщо в правилах буде сказано «мити руки 11 хв», він буде мити руки 11 хв.

Да нет, с аналогией тут всё хорошо. Это была отсылка к истории медицины и Земмельвейсу, но думаю вы эту отсылку не поняли. Почитайте историю. Медики тоже дико сопротивлялись этой практике и доводы против неё были абсолютно аналогичны — «это забирает важное время, а мы спасаем жизни», «у нас нет времени на эту чепуху», «роженицы умрут, если мы будем медлить». Чувствуете сходство? И хотя сейчас есть полевая медицина, где операции могут проводить в тяжелых условиях — но она это большое исключение, менее пару процентов и даже там стараются делать минимум в таких условиях и довести пациента до нормальной клиники, где будут другие правила игры.

Медицина повзрослела, ИТ ещё нет. Все хотят быть исключением, ну не может 9 из 10 проектов быть исключением из правил... У нас слишком много проектов, которые мнят, что они на войне.

Медики на столько дико сопротивлялись, что регламент санитарной обработка рук перед хирургической операцией видоизменялся много раз часто чтобы щадить руки хирургов, у которых начинались экземы и другие проблемы от муравьиной кислоты и всего подобного. Сейчас можно помыть руки перед операцией и примерно за минуту. Проблема здесь еще и в том, что нельзя надолго помыть руки чисто. Бактерии выползут из пор на коже через пару часиков и руки опять не стерильны. А хирург тем временем продолжает многочасовую операцию с уже нестирильными руками, но в стерильных перчатках, как временная мера. И аналогия с обсуждаемым вопросом здесь интересная.

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

Медицина повзрослела, ИТ ещё нет. Все хотят быть исключением, ну не может 9 из 10 проектов быть исключением из правил... У нас слишком много проектов, которые мнят, что они на войне.

Это не война, это просто жизнь, где все часто меняется, нет архитектурного постоянства, а есть бизнес цели прежде всего.

Хороший посыл, но дихотомия говнокод/technical excellence — ложная. Всегда нужно писать нормально, потому что если нет времени написать сейчас нормально, то откуда оно возьмётся в будущем?

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

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

Классический пример — Twitter, который в определённый момент вообще полностью переписал всё с нуля.

Технический долг это не долг в банке. Тут с самого начала нужно правильно оценивать, что можно отложить, а что нужно исправлять сразу при любой бизнес-стратегии. С некоторыми долгами можно и первой версии не суметь сделать и загнуться в процессе её написания. Хорошая таксономия описана тут — taxonomy-tech-debt

За чтиво большое спасибо, ознакомлюсь!

С некоторыми долгами можно и первой версии не суметь сделать

А мы здесь точно не путаем технический долг с вопиющим непрофессионализмом?
Ибо видел продукты, написанные в лучших традициях «индусского кода», но они работают и приносят деньги.

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

en.wikipedia.org/...​havior-driven_development

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

текст не читай @ голову не включай @ в калюжу сідай

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

війни і конфлікти -> обросли легендами і байками -> приглядітись до легенд і байок -> переможці були з вундервафлями, а не краще організовані

скоро народ буде вимагати книжок-розмальовок, а то інакше не буде доходити...

Забудьте аргумент «модно, стильно, молодежно» — это не работает для бизнеса.

Странно, а судя по блокчейну везде и всюду, то очень даже работает.

Не понятно, почему тесты рассматриваются как отдельная сущность от функционала. TDD, BDD — тесты и есть часть фичи или функционала. Не пишите тесты — значит не пишите функционал. Нужно успеть к дедлайна? Сокращайте набор фич к нему, а не качество продукта.

Повністю з вами згідний, але, нажаль, неоднократно зустрічав ситуації, коли тести або повністю відсутні як такі і все виключно руками тестується або тести написані на «від’їб*ся», просто аби хоча б щось було, а все тестування виконується руками.

Так это же проблема в процессах и людях, а не в тестах.

И опять я возвращаюсь к основной теме в статье — если заказчику надо все и сразу? Никогда не сталкивались с моментом — если в итерации Х не будет такой фичи то итерации Х + 1 просто не будет? В стартапах такие аргументы везде и всюду. Есть моменты когда можно и нужно говорить нет, а есть моменты когда говорить нет нельзя. Тогда приходится писать быстро.

если заказчику надо все и сразу?

Тогда дари ему губозакаточную машинку.

В стартапах такие аргументы везде и всюду

В стартапах определяют приоритеты делания фич на ближайшее время и потом не дергаются. Ибо быстро прогоришь.

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

И опять я возвращаюсь к основной теме в статье — если заказчику надо все и сразу?

И как, 9 женщин рожают ребенка за месяц?

Никогда не сталкивались с моментом — если в итерации Х не будет такой фичи то итерации Х + 1 просто не будет?

Каждый день. Нет денег на N фич — значит делаем только те, на которые хватает. Приоритезируйте с клиентом. Многие хотят фейсбук за $100, это не повод делать «плохо».

Ни кто не говорит про фейсбук за $100 — но и разработка замедленными темпами тоже не предполагается. Да — если есть время, работаем по Red-Green-Refactor логику тестируем полностью, делаем ревью от архитектурных до код ревью каждой строчки, поверьте, я знаю как делать все правильно — однако, если клиент прибегает говорит — чуваки, не сделаем функциональность инвестор уйдет, показать надо — делаем, абы ж работало. Никто не призывает нерабочую функциональность поставлять клиенту, однако, если на вылизывание нет времени — включается превосходство работающей функциональности над всем остальным

А зачем связывать «вылизывание», «разработка замедленными темпами» и «правильный процесс разработки». При правильном процессе — нужна другая фича, без проблем. Сдвигаем эти на другую итерацию и делам фичу, которая нужна первой (и да, тут тесты никто не отменял — смешно будет, если на демо инвестору упадет эта фича и он из-за этого и уйдет). Это приоритет, а не «слоники побежали» (без тестов).

Чому ми вирішили, що жертвувати потрібно саме скоупом, а якість ставимо на перше місце? Може потрібно пожертвувати або дедлайном, aбо таки якістю?

Глобально, замовник спочатку пріоритезує між собою скоуп/час/якість. А потім спускається на рівень пріоритезації фіч.

Не розумію тих, хто говорить, що тести — завжди must have. Для Вас приклад (спрощено, про те, що доносив автор):

Село в Рівненській області, син говорить тату — «Купи мені Lamborgini! Я хочу до Наталки підкатити на ній, щоб точно сподобатись».

Наче норм, але син не розуміє, що:
— У сім’ї немає грошей на Lamborgini
— В селі настільки розбиті дороги, що навряд чи він доїде до Наталки на край села
— Наталці взагалі подобається Range Rover :)

Чому ми вирішили, що жертвувати потрібно саме скоупом, а якість ставимо на перше місце?

Что вы подразумеваете под «жертвой скоупа»? Есть команда, она делает (предположим) 20 «estimation point» в неделю. Например скоуп на две недели. Команда может сделать 40 «estimation points» за скоуп. Никто не будет просить их перерабатывать (хотя зависит от компании и как она относится к людям). Значит если пришла задача, у которой приорит самый высокий — она добавляется в текуший скоуп и, что логично (поскольку у этой задачи есть свой estimation point), поскольку все тех же поинтов 40, то задачи внизу «вытесняются» (переходят) на следующий скоуп. Они не умирают на каком то жертвенном алтаре.

Може потрібно пожертвувати або дедлайном, aбо таки якістю?

Ни тем не другим, если вы заботитесь о продукте. Приоритет и расчет, что команда успеет до дедлайна без потери качества. Каждая компания сама определяет свой стандарт качества, от которого она ниже не опускается. Так что «нет тестов» — это может быть такой стандарт качества от этой организации/команды, а не какая то проблема.

Глобально, замовник спочатку пріоритезує між собою скоуп/час/якість

Не знаю что значит «между собой», но нужно приоритизировать вместе с ним (многие клиенты не знаю даже как это верно сделать). И уж точно клиенты не создаю скоуп — они только говорят что им требуется и какие сроки.

Не розумію тих, хто говорить, що тести — завжди must have

Не всегда — почитайте комментарии, тут уже писали про «прототипирование».

Про село и ламборджини — не уловил связь со статьей. В данном случае во время планирования сыну не донесли, что ему нужен трактор.

Только в этом случае твой вброс не подходит

заказчику надо все и сразу

Заказчик определяет приоритеты и другие работы откладываются.

разработка замедленными темпами

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

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

Вы, ребята из railsware, прямо радуете.

если заказчику надо все и сразу?

Очень часто — такой заказчик манипулятор, который с высокой вероятностью не будет давать время на улучшение и так далее.
Будут ставиться еще более жесткие условия на реализацию нового ф-ла, фичи будут впихиваться в спринт, любая попытка переделки будет блокироваться «а почему так медленно, мне надо срочно, раньше быстрее все делали, не буду платить пока не сделаете еще +100 фишек», технический долг будет расти очень быстро, проект начнет пробуксовывать и т.д.
И вина будет при таком раскладе как раз на том, кто пишет. Заказчик забудет все, что говорил вчера и на что соглашался, он просто скажет «я Вам платил деньги а Вы — сделали г..но»

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

Такие мессаджи понимают все

нет

Тогда вы плохо — доносили. Разговаривайте про стоимость. Не пытайтесь оперировать техническими терминами — и вас обязательно поймут. Проверено годами опыта. Деньги помогут достучаться до мозгов любого

окей.

работал в стартапе. деньги у заказчика были от основного бизнеса. заказчику было интересно планировать, демки смотреть. релиза за несколько лет так и не случилось. ему нравилось «играться».

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

не представляю, как можно аргументировать деньгами(потерей или получением), если у конкретных людей собственные цели совсем не в доходах компании. ни прямо, ни косвенно.

Сами же и отвечаете.

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

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

Это не всегда хорошая цель, но это уже другой вопрос.

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

=>

— В цирке?! Нет, за штуку я, конечно, соглашусь, но зачем вам в цирке программисты?
(к)
Это не всегда хорошая цель, но это уже другой вопрос.

А так +

Автор уверенно топит за деньги, как за единственный универсальный аргумент, но это всего лишь один из аргументов

я-то в курсе.

При этом хорошо бы и себя не подставить, так как представители заказчика не вечны, и ситуация «новая метла по-новому метёт» может без должного прикрытия вылиться в очень неприятный нежданчик.

Стартрапы это пример испорченной экономики. Многие из них вообще не собираются стать нормальным бизнесом и зарабатывать деньги. Обычно они проедают деньги инвесторов и хотят кому-то продаться. Их стратегии принятия решений и то, как они полностью «забивают» на будущее своих проектов ради временного результатов не является примером здоровых/нормальных бизнес компромиссов и управления рисками. Это клиенты у которых нет интереса в самом продукте. Программный продукт тут случайным атрибут процесса доения инвесторов. Исключения бывают, но мало.

Подписаться на комментарии