Есть у нас в базе таблица, где хранится плоская запись. Точнее, хранилась, теперь там BLOB. Но не суть. В плоской записи 600 полей, которые называются field_1, field_2... field_600.
В коде зашит меппинг этих филдов на нормальные названия:
<entry key="cat" value="6"/>
<entry key="dog" value="13"/>
...
<entry key="human" value="15"/>
Файлик с меппингом назовем... Ну, допустим, р2о (plain to object). Он с хитринкой — так как в java отсчет начинается с нуля, а не с единицы, то к value надо было добавить 1, чтобы получить field в базе. Вот, например, key="cat" → в базе это был field_7.
Сами по себе поля field_* проблем не приносили, потому что обычно база заполнялась из файликов, а дальше уже темная магия все разруливала и сразу красота! А вот в автотестах всегда черт ногу сломит. Открываешь тест, тебе надо поправить фамилию. А у тебя на входе эти 600 полей. И в каждой сборке свой меппинг. Где-то фамилия — это номер 2, где-то номер 4, где-то 6, и так далее.
И вот ты такой открываешь тест, который надо поправить. Открываешь р2о. Находишь там нужное тебе поле. Сидишь, тупишь, вспоминая, надо от value отнять единичку или прибавить... Правишь тест. Профит! Но затупы на «отнять или прибавить» особенно раздражали.
А уж если кто-то внес изменения в р2о! Изменил одно поле? Все, гудбай все тесты → рассыпались как карточный домик, надо ходить и уныло актуализировать. Так как актуализацией занималась я, то и страдала тоже я
Страдала я громко, плакалась на митингах и в чатике:
— Опять тесты развалились из-за р2о. Давайте сделаем так, чтобы они не падали??
— Оля, отстань! Зачем тратить на это ресурсы? Не так уж часто р2о меняется. Один раз в год подняла тесты, это проще, чем тратить пару дней разработчика.
В общем, в случае пожара — горите.
Но у меня эта проблема стала стрелять все чаще и чаще. У нас появилось больше заказчиков — больше разных сборок. Тут добавили поле, тут удалили. А там пойди тесты пополни, на него, родимого р2о.
С каждой актуализацией у меня все четче рисовалось внутреннее видение того, как это должно работать в идеале. Но куда это записать? Поставишь задачу, так разработчики ругаться начнут, что оно того не стоит. Но высказаться то, высказаться то надо! А где? Специально под свою #жизньболь создала в конфлюенсе (это такая вики, которая вместе с джирой идет) свой спейс. И записала туда!
Даже описала сам механизм:
Ведь робот тупой, ему нужна четкая инструкция, «пойди туда, возьми то, сделай се». Это пример простой инструкции, у нас есть и вторая часть, для карты значений.Но тебе, лысый, я телефон не скажу. Но для блога хватит и одной в качестве примера :-)
Неожиданно я получила поддержку! До этого только разработчики шикали «отстань, это редко бывает», а после публикации статьи коллега-тестировщик откомментил ее:
Это придало мне уверенности и я завела задачу на «сделать хорошо». Со ссылкой на свою страницу, как полноценное ТЗ.
На планирование релиза я шла с готовностью отстаивать свою задачу. Благо у нас есть волшебное правило «одна задача в релиз». Это значит, что ты можешь взять одну задачу в релиз. Даже если она минорная и не приносящая денег (рефакторинг или пополнение тестов), но вот лично тебе она нужна — можешь взять в релиз. Конечно, разработчики опять попытались соскочить с этой темы:
— Оно вам точно мешает?
И снова коллега меня поддержал:
— Да, это очень уныло делать. Мне не прям горит, но уныло.
— Ну ла-а-а-адно, давайте сделаем.
Внимательный читатель заметил на скриншоте дату. Статью-хочушку я написала 3 года назад, Dec 03, 2013. Задачу сделали в январе. То есть в ближайшем релизе. И ведь сделали за 14 часов, из них 5 часов разработки. 5 часов, Карл! Тогда как последнее изменение влетело мне в 40. Хотя в той задаче на 40 часов был капитальный рефакторинг, но все же... В общем, разработчик страдал больше, чем делал =)))
Да, безусловно, опытные автоматизаторы могут покачать головой — «Оля, ну что ты страдала? Написала бы логику сама!» И будут правы. Если есть знания и опыт, рутину надо автоматизировать. Но тогда знаний у меня было еще меньше, чем сейчас. Да одно дело — написать рядом на коленке робота, а другое — вкрячить логику в тестовый фреймворк, который разрабатывался до меня. У нас такие изменения вносят разработчики, так быстрее и проще. Но я согласна, что уровень мастерства надо повышать и не страдать зазря =)
Но смысл то не в том. Если вам что-то мешает жить и вы страдаете от унылой рутины — автоматизируйте ее. Попросите разработчиков помочь, если не можете сами. Посмотрите на мой пример, сделать получилось быстрее, чем ворчать ))) Но! Разработчик сделал быстро потому, что я четко описала нужную логику. Если просто поставить задачу «Мне вот это мешает, помогите», ее будут отладывать в дальний ящик. Это ведь разработчику нужно придумать алгоритм, чтобы стало хорошо. А ему сложно его придумать, ведь он не видит проблемы, он не делает вручную повторяющиеся действия. Подробное описание хочушки — залог успеха.
Помните, что любую задачу надо «продать» команде. Опишите проблему, которую создает то, как работает сейчас. Иначе зачем же это делать? И опишите решение. То, которое поможет вам. Не перекладывайте на разработчика то, что вполне можете сделать сами
Почему я вспомнила о той задаче сейчас? Логика р2о давно передала и всем нравится. И даже не представляю, как мы раньше жили без такого удобного написания. Но, когда вы убираете одно узкое место, сразу вылезает другое. Которое раньше было незаметно. Об этом отлично пишет Элияху Голдратт в своей книге Цель.
Сейчас у меня появилась новая #жизньболь. Теперь я хочу, чтобы базовый тест на 1000 колонок генерился сам! Потому что он одинаковый везде и составляется без включения мозга, так почему бы это не сделать роботу? Я снова пошла в раздел автотестов в своем спейсе и теперь, спустя три года, но тоже в декабре, сижу и пишу свою идеальную картину мира. Надеюсь, новогоднее пожелание исполнится и в ближайшем релизе разработчик снова сделает "чтобы все было хорошо". А я потом поделюсь результатами, исполнилось желание или нет =)
Но вы все равно просите улучшений. Если умеете сами — улучшайте сами. Не умеете. но страдаете от рутины — просите помочь. Это окупится удобством использования фреймворка в дальнейшем!
PS — а мой спейс то, однако, сильно разросся за это время! =)
В коде зашит меппинг этих филдов на нормальные названия:
<entry key="cat" value="6"/>
<entry key="dog" value="13"/>
...
<entry key="human" value="15"/>
Файлик с меппингом назовем... Ну, допустим, р2о (plain to object). Он с хитринкой — так как в java отсчет начинается с нуля, а не с единицы, то к value надо было добавить 1, чтобы получить field в базе. Вот, например, key="cat" → в базе это был field_7.
Сами по себе поля field_* проблем не приносили, потому что обычно база заполнялась из файликов, а дальше уже темная магия все разруливала и сразу красота! А вот в автотестах всегда черт ногу сломит. Открываешь тест, тебе надо поправить фамилию. А у тебя на входе эти 600 полей. И в каждой сборке свой меппинг. Где-то фамилия — это номер 2, где-то номер 4, где-то 6, и так далее.
И вот ты такой открываешь тест, который надо поправить. Открываешь р2о. Находишь там нужное тебе поле. Сидишь, тупишь, вспоминая, надо от value отнять единичку или прибавить... Правишь тест. Профит! Но затупы на «отнять или прибавить» особенно раздражали.
А уж если кто-то внес изменения в р2о! Изменил одно поле? Все, гудбай все тесты → рассыпались как карточный домик, надо ходить и уныло актуализировать. Так как актуализацией занималась я, то и страдала тоже я
Страдала я громко, плакалась на митингах и в чатике:
— Опять тесты развалились из-за р2о. Давайте сделаем так, чтобы они не падали??
— Оля, отстань! Зачем тратить на это ресурсы? Не так уж часто р2о меняется. Один раз в год подняла тесты, это проще, чем тратить пару дней разработчика.
В общем, в случае пожара — горите.
Тебе тяжело? Ты и страдай
Но у меня эта проблема стала стрелять все чаще и чаще. У нас появилось больше заказчиков — больше разных сборок. Тут добавили поле, тут удалили. А там пойди тесты пополни, на него, родимого р2о.
С каждой актуализацией у меня все четче рисовалось внутреннее видение того, как это должно работать в идеале. Но куда это записать? Поставишь задачу, так разработчики ругаться начнут, что оно того не стоит. Но высказаться то, высказаться то надо! А где? Специально под свою #жизньболь создала в конфлюенсе (это такая вики, которая вместе с джирой идет) свой спейс. И записала туда!
Надо было записать свою идею. Хотя бы в свой спейс!
Даже описала сам механизм:
Инструкция для робота
Ведь робот тупой, ему нужна четкая инструкция, «пойди туда, возьми то, сделай се». Это пример простой инструкции, у нас есть и вторая часть, для карты значений.
Неожиданно я получила поддержку! До этого только разработчики шикали «отстань, это редко бывает», а после публикации статьи коллега-тестировщик откомментил ее:
Вот тут плюсую, это бы помогло избежать ситуации, когда тратится тонна времени на переименование FIELD_1 в FIELD_2
Это придало мне уверенности и я завела задачу на «сделать хорошо». Со ссылкой на свою страницу, как полноценное ТЗ.
На планирование релиза я шла с готовностью отстаивать свою задачу. Благо у нас есть волшебное правило «одна задача в релиз». Это значит, что ты можешь взять одну задачу в релиз. Даже если она минорная и не приносящая денег (рефакторинг или пополнение тестов), но вот лично тебе она нужна — можешь взять в релиз. Конечно, разработчики опять попытались соскочить с этой темы:
— Оно вам точно мешает?
И снова коллега меня поддержал:
— Да, это очень уныло делать. Мне не прям горит, но уныло.
— Ну ла-а-а-адно, давайте сделаем.
Внимательный читатель заметил на скриншоте дату. Статью-хочушку я написала 3 года назад, Dec 03, 2013. Задачу сделали в январе. То есть в ближайшем релизе. И ведь сделали за 14 часов, из них 5 часов разработки. 5 часов, Карл! Тогда как последнее изменение влетело мне в 40. Хотя в той задаче на 40 часов был капитальный рефакторинг, но все же... В общем, разработчик страдал больше, чем делал =)))
Да, безусловно, опытные автоматизаторы могут покачать головой — «Оля, ну что ты страдала? Написала бы логику сама!» И будут правы. Если есть знания и опыт, рутину надо автоматизировать. Но тогда знаний у меня было еще меньше, чем сейчас. Да одно дело — написать рядом на коленке робота, а другое — вкрячить логику в тестовый фреймворк, который разрабатывался до меня. У нас такие изменения вносят разработчики, так быстрее и проще. Но я согласна, что уровень мастерства надо повышать и не страдать зазря =)
Но смысл то не в том. Если вам что-то мешает жить и вы страдаете от унылой рутины — автоматизируйте ее. Попросите разработчиков помочь, если не можете сами. Посмотрите на мой пример, сделать получилось быстрее, чем ворчать ))) Но! Разработчик сделал быстро потому, что я четко описала нужную логику. Если просто поставить задачу «Мне вот это мешает, помогите», ее будут отладывать в дальний ящик. Это ведь разработчику нужно придумать алгоритм, чтобы стало хорошо. А ему сложно его придумать, ведь он не видит проблемы, он не делает вручную повторяющиеся действия. Подробное описание хочушки — залог успеха.
Помните, что любую задачу надо «продать» команде. Опишите проблему, которую создает то, как работает сейчас. Иначе зачем же это делать? И опишите решение. То, которое поможет вам. Не перекладывайте на разработчика то, что вполне можете сделать сами
Почему я вспомнила о той задаче сейчас? Логика р2о давно передала и всем нравится. И даже не представляю, как мы раньше жили без такого удобного написания. Но, когда вы убираете одно узкое место, сразу вылезает другое. Которое раньше было незаметно. Об этом отлично пишет Элияху Голдратт в своей книге Цель.
Сейчас у меня появилась новая #жизньболь. Теперь я хочу, чтобы базовый тест на 1000 колонок генерился сам! Потому что он одинаковый везде и составляется без включения мозга, так почему бы это не сделать роботу? Я снова пошла в раздел автотестов в своем спейсе и теперь, спустя три года, но тоже в декабре, сижу и пишу свою идеальную картину мира. Надеюсь, новогоднее пожелание исполнится и в ближайшем релизе разработчик снова сделает "чтобы все было хорошо".
А я потом поделюсь результатами, исполнилось желание или нет =)Но вы все равно просите улучшений. Если умеете сами — улучшайте сами. Не умеете. но страдаете от рутины — просите помочь. Это окупится удобством использования фреймворка в дальнейшем!
PS — а мой спейс то, однако, сильно разросся за это время! =)
Комментариев нет:
Отправить комментарий