Здравствуйте, Курилка, Вы писали:
К>Хочется поделиться, на мой взгляд, занимательным и небезынтересным докладом Андрея Аксёнова(автора sphinx)) — Прекращаем писать код К>Предупреждение: присутствует ненормативная лексика К>P.S. Вроде это самый подходящий форум для данной ссылки.
Как же меня задолбали все эти видеодоклады.. просто нереально задолбали
Текст есть где-нибудь?
Здравствуйте, Klatu, Вы писали:
K>Здравствуйте, Курилка, Вы писали:
К>>Хочется поделиться, на мой взгляд, занимательным и небезынтересным докладом Андрея Аксёнова(автора sphinx)) — Прекращаем писать код К>>Предупреждение: присутствует ненормативная лексика К>>P.S. Вроде это самый подходящий форум для данной ссылки.
K>Как же меня задолбали все эти видеодоклады.. просто нереально задолбали K>Текст есть где-нибудь?
Конечно нет. Такие доклады ценны не контентом, а презентацией. Важно не что человек говорит, а как он это преподносит.
В принципе суть всего доклада можно ужать до трех фраз:
"думайте головой", "не делайте ненужного", "не бойтесь выбрасывать то что стало ненужным"
Здравствуйте, gandjustas, Вы писали:
G>Конечно нет. Такие доклады ценны не контентом, а презентацией. Важно не что человек говорит, а как он это преподносит. G>В принципе суть всего доклада можно ужать до трех фраз: G>"думайте головой", "не делайте ненужного", "не бойтесь выбрасывать то что стало ненужным"
Ну это уже цирк какой-то, а не IT.
Может им еще подтанцовку пригласить а-ля Балмер?
Здравствуйте, Undying, Вы писали:
U>С чего это будет дерьмом? Тесты всего лишь позволяют снизить вероятность того, что ошибка в коде дойдет до пользователя. На качество кода наличие/отсутствие тестов вообще никак не влияет.
Влияет косвенно. С тестами код в среднем чище, потому что его не боятся трогать что бы привести в порядок.
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, Undying, Вы писали:
VD>>Создания тестов для больших и/или сложных стистем — это отдельная инжинерная задача. Но без них никак. Ваш продут заведомо будет дерьмом, если у него не будет качественных тестов.
U>С чего это будет дерьмом? Тесты всего лишь позволяют снизить вероятность того, что ошибка в коде дойдет до пользователя. На качество кода наличие/отсутствие тестов вообще никак не влияет.
С того что или все будут дрожать кода меняют код, или пользователи будут периодически материться потому что очередное изменение привело к появлению старых (или новых) глюков.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>У нас в проекте ровно один тестировщик. Если он будет понимать какое поведение системы ожидаемое, а какое — нет — уже хорошо
И по-твоему это хорошо?
VD>>Автоматизировать можно все. Надо только хорошенько над этим подумать.
NGG>И тут всплывает фраза из той же презентации: если автоматизация требует много времени и ресурсов, а руками сделать 5 минут (провести тест в ручную), то её вроде бы как и не стоит делать
Тесты — это не одноразовая работа. Их нужно прогонять после каждого изменения. То что ты что-то там дин раз сделал нужно будет повторять тысячи раз (и не ошибаться при этом). Так что это не тот случай.
NGG>Знаешь, я с тобой полностью согласен на интуитивном уровне.
NGG>Но у меня перед глазами живой пример приложения на полтора миллиона строк, которое живёт 10 лет и умирать не собирается. И в тоже время в нём отсутствуют не только хорошие тесты, но и тесты плохие. Т.е. автоматических тестов вообще нет (это не шутка), а ручных тестеров два человека на десяток разработчиков и четыре региона (общая база кода, но у каждого региона своя специфика).
Пользуясь случаем выражаю искренние соболезнования вашим пользователям.
NGG>Поэтому важно познать дзен и делать рефакторинг и тесты одновременно (а не вместо) с новым функционалом.
Тесты и надо писать параллельно разработке. Сделал фичу — добавь тест проверяющий что фича работает как надо. Но если для старых фич тестов нет, то менять код в мало-мальки сложной ситеме становится опасным. Фактически вы перекладываете тестирование на своих пользователей.
Скажем у сайта на котором сидит миллион человек тоже может не быть тестов, так как любая ошибка тут же будет выловлена пользователем. Но при этом мы должны понимать, что пользователи входят в систему тестирования. Если они платят за этот продукт, то это является форменным издевательством.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>И по-твоему это хорошо?
По-моему — нет. Однако моё мнение на количество тестировщиков повлиять не может.
VD>Тесты — это не одноразовая работа. Их нужно прогонять после каждого изменения. То что ты что-то там дин раз сделал нужно будет повторять тысячи раз (и не ошибаться при этом). Так что это не тот случай. VD> Но если для старых фич тестов нет, то менять код в мало-мальки сложной ситеме становится опасным.
Видишь как интересно получается. Вроде бы и "нужно" и "иначе никак", а на деле получается, что 10 лет живёт и здравствует...
Парадокс — не правда ли?
Ты только не подумай чего лишнего — я на стороне "сил добра и света",
а потому плюнул на "местные" традиции и стал-таки писать юнит тесты.
Однако, парадокс не даёт покоя.
Наверное, человеческий фактор значит в нашем деле больше, чем ворох рассуждений на тему "чего нужно, а без чего жить нельзя".
VD>Пользуясь случаем выражаю искренние соболезнования вашим пользователям.
Я им тоже сочувствую. Только по другой причине: страшен наш UI аки смерть.
Но пользователь существо подневольное, будет работать с чем дадут если функционал достаточен (банки, банки, банки...).
VD> Фактически вы перекладываете тестирование на своих пользователей.
Неа. Ошибки в продакшине у нас хоть и бывают, но довольно-таки редко.
Сам удивляюсь.
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>Видишь как интересно получается. Вроде бы и "нужно" и "иначе никак", а на деле получается, что 10 лет живёт и здравствует... NGG>Парадокс — не правда ли?
Думаю, что он живет в почти неизменном виде. Или все изменения пользователи тестируют своими нервами.
NGG>Ты только не подумай чего лишнего — я на стороне "сил добра и света",
NGG>а потому плюнул на "местные" традиции и стал-таки писать юнит тесты.
Да даже не о юнит-тестах говрю. Но хотя бы функциональное тестирование. Чтобы быть уверенным, что реализованное до это не поломалось.
NGG>Наверное, человеческий фактор значит в нашем деле больше, чем ворох рассуждений на тему "чего нужно, а без чего жить нельзя".
Человеческий фактор конечно значит многое. Но если у системы вообще нет тестов, то скорее всего этот фактор просто постоянно кричит "Не тронь! А то не дай Бог что-нить случится!".
VD>>Пользуясь случаем выражаю искренние соболезнования вашим пользователям. NGG>Я им тоже сочувствую. Только по другой причине: страшен наш UI аки смерть.
Ну, к страшной морде привыкают. Вот Лужков же к Батуриной привык.
NGG>Но пользователь существо подневольное, будет работать с чем дадут если функционал достаточен (банки, банки, банки...).
Это. Да. Я вот вынужден работать с Банк-Клиентом Сбербанка. Матерюсь каждый раз когда его использую. Хотя интерфейс у него вполне современный — дельфевый.
VD>> Фактически вы перекладываете тестирование на своих пользователей. NGG>Неа. Ошибки в продакшине у нас хоть и бывают, но довольно-таки редко. NGG>Сам удивляюсь.
Чудо?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>>>Пользуясь случаем выражаю искренние соболезнования вашим пользователям. NGG>>Я им тоже сочувствую. Только по другой причине: страшен наш UI аки смерть.
VD>Ну, к страшной морде привыкают. Вот Лужков же к Батуриной привык.
Ага, если надо на каждый чих кликать по десять раз да скроллеры крутить, то ну его нахрен, такой интерфейс.
Здравствуйте, VladD2, Вы писали:
VD>С того что или все будут дрожать кода меняют код, или пользователи будут периодически материться потому что очередное изменение привело к появлению старых (или новых) глюков.
Если код сложный и запутанный, то и при наличии тестов его никто не будет менять без крайней на то необходимости. А если код хороший, т.е. не содержит дублирования, не содержит лишних сущностей в особенности сеттеров и абстракций, и имеют низкую связанность, то его не страшно менять и без наличия тестов, т.к. забыть при изменении такого кода о чем-то сложно, а описки выявляются однократным прогоном на реальных данных. Поэтому нужность тестов на качество кода не влияет, и определяется только критичностью возможных ошибок, понятно, что если мы пишем программу для ядерного реактора, то без тестов никуда, а вот если решаем обычную бизнес-задачу, то в большинстве случаев тесты становятся слишком дорогим удовольствием. Т.к. на их написание уходит очень много времени, а при этом они все равно мало что гарантируют, все случаи в бизнес-задачах все равно рассмотреть невозможно.
Здравствуйте, VladD2, Вы писали:
VD>С того что или все будут дрожать кода меняют код, или пользователи будут периодически материться потому что очередное изменение привело к появлению старых (или новых) глюков.
Главная проблема тестов в том, что большинство ошибок, которые доходят до пользователя, это случаи, которые мы забыли рассмотреть. Но проблема в том, что если мы случай забыли рассмотреть при написании кода, то с тем же успехом мы его забыли бы его рассмотреть и при написании тестов.
Здравствуйте, LR, Вы писали:
LR>Влияет косвенно. С тестами код в среднем чище, потому что его не боятся трогать что бы привести в порядок.
О каких тестах мы говорим? Если о юнит-тестах, то все как раз наоборот, т.к. практически любое изменение архитектуры приводит к необходимости переписывания тестов. Соответственно улучшениями архитектуры заниматься перестают.
Здравствуйте, Undying, Вы писали:
LR>>Влияет косвенно. С тестами код в среднем чище, потому что его не боятся трогать что бы привести в порядок.
U>О каких тестах мы говорим? Если о юнит-тестах, то все как раз наоборот, т.к. практически любое изменение архитектуры приводит к необходимости переписывания тестов. Соответственно улучшениями архитектуры заниматься перестают.
Это смотря как тестами пользоваться. При правильном использовании таких проблем нет.
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, Undying, Вы писали:
U>Главная проблема тестов в том, что большинство ошибок, которые доходят до пользователя, это случаи, которые мы забыли рассмотреть. Но проблема в том, что если мы случай забыли рассмотреть при написании кода, то с тем же успехом мы его забыли бы его рассмотреть и при написании тестов.
Это не проблема, так как тесты можно добавить в любой момент.
Тесты позволяют зафиксировать ожидаемое поведение. Если мы обнаружили, что тесты этого не делают, то просто дорабатываем тесты и все ОК. Зато если кто-то что-то испортит, мы сразу же об этом узнаем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Undying, Вы писали:
U>Если код сложный и запутанный, то и при наличии тестов его никто не будет менять без крайней на то необходимости.
Это не так. Отличный пример — компилятор немрела. Код сложный, дико связанный (опыта у поляков было мало) и не всегда понятный. Но меняется он с завидной частотой. И именно тесты позволяют отлавливать плохие изменения.
U>А если код хороший, т.е. не содержит дублирования, не содержит лишних сущностей в особенности сеттеров и абстракций, и имеют низкую связанность, то его не страшно менять и без наличия тестов,
Делаем вывод из твоих слов — тесты не нужны!
Самому то не смешно?
Какой бы ясный код не был бы в нем все равно найдутся не очевидные места которые легко пропустить (особенно когда изменения делаются сильно после большого перерыва).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Думаю, что он живет в почти неизменном виде. Или все изменения пользователи тестируют своими нервами.
Ну, почему в неизменном... Релизы (серверные компоненты или гуи клиенты) выходят в продакшин в среднем раз в месяц. За неделю команда суммарно может потрогать в cvs штук 100-200 файлов.
VD>Да даже не о юнит-тестах говрю. Но хотя бы функциональное тестирование. Чтобы быть уверенным, что реализованное до это не поломалось.
А тут тот самый случай про "сложность автоматизации".
Система представляет из себя набор серверных компонент общающихся через общую шину между (по принципу: слушаю всё, беру/отвечаю только на своё) + сервера-фасады для UI клиентов.
Серверные компоненты, в частности, могут иметь выход к внешним системам и служить своего рода гейтвеями или бриджами.
К каждому компоненту прилагается конфигурационный файл с массой "странных" пропертей.
Самые важные flow (или юзкейсы) состоят в получении сообщений из одной системы, их преобразования, публикации на шину и чтения другим компонентом, ещё одного преобразования и отсылки в ещё одну систему (и где-то между всем этим может вклиниться пользователь)
Значит для автоматических интеграционных (они же по сути и функциональные) тестов нужно:
— поднять шину
— поднять пару серверных компонентов с _правильной_ конфигурацией
— поиметь эмуляторы для моделирования сообщений из/в внешние системы (и следить, что они не отстают от действительности)
— написать скрипты для эмуляторов
— написать скрипты для валидации тестовых прогонов (учтя асинхронную природу сообщений...)
— и ведь ещё надо, чтобы каждый понял как этот зверинец настраивать и _мог/хотел_ его поддерживать в живом виде.
А на другой чаше весов:
— как пользователь зайти во внешние системы стоящие в "пред" продакшин зоне
— выполнить пару действий на одном конце
— посмотреть всё ли хорошо на другом конце
— пробежаться по детальным логам серверных компонент, убедиться, что им не стало плохо
— и конечно же ревью кода с участием того, кто хоть чуть-чуть понимает, что это за внешние системы и как всё должно работать
Слишком много усилий нужно за раз приложить, чтобы от ручного само-тестирования перескочить к автомату.
Обвязку юнит тестами сделать технически проще.
VD>Человеческий фактор конечно значит многое. Но если у системы вообще нет тестов, то скорее всего этот фактор просто постоянно кричит "Не тронь! А то не дай Бог что-нить случится!".
Здравствуйте, VladD2, Вы писали:
VD>Это не так. Отличный пример — компилятор немрела. Код сложный, дико связанный (опыта у поляков было мало) и не всегда понятный. Но меняется он с завидной частотой. И именно тесты позволяют отлавливать плохие изменения.
В компиляторе тесты, которые тестируют вход/выход нужны. Т.к. вход(исходный код) и выход(байт-код) здесь простые, строго формализованы и не должны изменяться при добавлении новой функциональности. Соответственно и расходы на написание тестов низки и однажды написанные тесты практически никогда не устаревают. Однако в большинстве бизнес-задач ситуация совершенно другая.
VD>Делаем вывод из твоих слов — тесты не нужны! VD>Самому то не смешно?
Всю жизнь пишу без автоматических тестов. В результате ошибки, которые могли бы отловить тесты, пользователю уходят очень редко (в одной версии из десяти), гораздо чаще до пользователя доходят ошибки, которые как ловить тестами вообще не понятно. При этом затраты времени на написание тестов очень существенны и могут быть сопоставимы с временем решения самой задачи. Соответственно на практике оказывается, что в большинстве случаев написание тестов себя не окупает.
А отсутствие боязни изменений достигается за счет другого. Если код написан хорошо и понятно, то есть уверенность, что при обнаружении ошибки в 99% случаев она будет локализована за 5 минут и исправлена за 15 минут.
Здравствуйте, Gaperton, Вы писали:
ГВ>>Вроде как нет, я процитировал статус devpoint, взятый с их сайта.
G>Открываю. Что вижу. Новосибирский девпойнт. Аудитория — веселые программеры. Докладчик немного стесняется (бывает), сверхкомпенсируя свою стеснительность повышенной развязностью (также бывает), и — не смотря на перечисленное, довольно быстро преодолевает барьер (я это вижу на записи, не надо мне тут) и входит в эмоциональный контакт с аудиторией, ибо, — там сидят такие же программеры, как и он сам.
Ой, да ладно... К уставшей, задолбаной за день аудитории выходит ну вот вообще свой в доску парень и начинает рассказывать ни о каких-то там сложных вещах, а сыплет анекдотами, шутками-прибаутками, весёлые картинки опять-же... Временами пересыпает всё это банальности типа КISS, "преждевременная оптимизация, конечно зло, но и голову никто не отменял, надо иногда задумываться, что за бред ты пишешь".
Если бы еще слайды перематывали девочки в купальниках — да его бы вообще на руках вынесли!
Здравствуйте, NotGonnaGetUs, Вы писали:
VD>>Думаю, что он живет в почти неизменном виде. Или все изменения пользователи тестируют своими нервами.
NGG>Ну, почему в неизменном... Релизы (серверные компоненты или гуи клиенты) выходят в продакшин в среднем раз в месяц. За неделю команда суммарно может потрогать в cvs штук 100-200 файлов.
Тогда, если пользователи не огребают с каждый релизом баги, это чудо!
NGG>...А на другой чаше весов: NGG>- как пользователь зайти во внешние системы стоящие в "пред" продакшин зоне NGG>- выполнить пару действий на одном конце NGG>- посмотреть всё ли хорошо на другом конце NGG>- пробежаться по детальным логам серверных компонент, убедиться, что им не стало плохо NGG>- и конечно же ревью кода с участием того, кто хоть чуть-чуть понимает, что это за внешние системы и как всё должно работать
Вот это можно и повторит в тестах. Плюс можно написать юнит-тесты для отдельных компонентов.
NGG>Слишком много усилий нужно за раз приложить, чтобы от ручного само-тестирования перескочить к автомату.
С этим я не спорю. Но ведь было время когда всю эту архитектуру придумывали и разрабатывали. В то время было вполне не трудно предусмотреть средства тестирования. И то что это не было сделано — это огромный архитектурный просчет, плоды которого ты лично и вынужден расхлебывать.
NGG>Обвязку юнит тестами сделать технически проще.
Вполне возможно. Но сам понимаешь, юнит-тесты отлавливают только сугубо протокольные баги. Более сложную логику ими не охватить. Так что это будет частичное решение. Но лучше что-то чем ничего.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
