Смысл заворачивать исключение в том, что обработчик исключения может ловить определенные exceptions, зная точно его тип (ему нет надобности знать другие типы). А данные исходного исключения потом использовать при необходимости, напр. для информирования, что именно произошло на низком уровне.
Такой подход в DevExpress мы применяли для планировщика при парсинге из iCalendar-файлов (пример).
Свойство OriginalException там как раз исходное исключение в более высокоуровневом iCalendarParseException.
Это лучше чем получить автоматическое MainExtracted (судя по вашей картинке), с последующим переименованием и самого метода
Дело в том, что после выделения метода уже не требуется делать дополнительного вызова на rename. Если бы видео было чуть подробнее — то стало бы понятно, что после extract-а сгенеренное имя метода уже выделено, курсор стоит на нужном месте и достаточно лишь начать клавиатурный ввод, что б изменить имя на желаемое. Так что, рекомендую попробывать.
Review быть обязан — каким бы опытным не был разработчик
Это должно быть на усмотрение компании — жесткого требования может и не быть.
Да, коде-ревью, бесспорно полезно, но в любом случае отнимает время и создает излишнюю «бюрократию» в хорошем смысле слова. Для опытных разработчиков с массовым количеством закладок ревью проводить слишком накладно — это может быть сдвиги по времени и прочие факторы. А для менее опытных, вполне разумно придерживаться это правила, предварительно перед закладкой «выправив» его код, т.к. обычно скорость их разработки меньше и даже среднего-класса разработчик может выполнить ревью.
Спасибо за интересную ссылку. У нас в DevExpress в принципе подобная схема с общим доступом всех ко всему, но менее жесткая на закладки. Так что руки разработчиков не так связаны. )
Валидность закоммиченного в коде-репозиторий отслеживается через Continuous Interation, так что некорректные закладки сразу будут отражены в сломанных тестах с оповещением сломавших и должны быть сразу же пофикшены или временно может быть сделан роллбэк.
Спасибо за статью. Хочу добавить кое-что из личного опыта работы.
Симптом#1 можно предотвратить если ввести в компании правило совместного владения кодом, и, напр., устраивать code-review для программистов не самого высшего уровня.
Касательно unit-тестирования полностью согласен с автором в их полезности. Наличие тестов развязывает руки для выполнения рефакторинга любой сложности.
Когда тестов нет, а проект уже запущен, то возможно и нет смысла тратить время что бы достичь приличного покрытия. Получится что вы будете «писать тесты ради тестов». В такой ситуации целесообразно писать тесты на новые пришедшие баги и при дописывание нового функционала сразу окружать его тестами. В таком случае со временем вы достигните необходимого покрытия системы тестами и более экономично потратите свое время.
Нет конечно, я говорю об идее, как ее можно донести без утомительного описания в тексте. Короткое видео (буквально несколько секунд), показывающее цель или проблему порой гораздо информативнее для донесения идеи.
Хотя, конечно, лучше сразу писать код понятно и компактно :)
Нет предела совершенству ) А если серьезно код всегда будет видоизменяться в той или иной степени, если проект живой.
он может интерпретировать идеи
В целях сокращения описаний и текста у нас часто используются скриншоты или видео, иллюстрирующие проблему или как воспроизвести тест ;) Картинки идеи доносят лучше чем текст.
Хорошо структурированный код с понятным именованием методов и переменных в 90% случаев заменяет комментарии, даже если это код тестов. «Ужимание» в вашей терминологии — есть по сути рефакторинг кода теста с целью улучшения его читабельности.
А вы не пробывали в большей степени смотреть в сторону юнит-тестирования, а не функционального? В любом случае пиксел-зависимые тесты достаточно трудно поддерживать при изменяющихся условиях. Сравнение с эталонными картинками и чек-суммами будет приводить к необходимости постоянно их обновлять. Лучшие тесты, это те, которые будут работать не зависимо от изменяющихся условий.
Привязка к значениям координат окна в таких тестах не есть хорошее решение. Для такого способа критичны будут изменения разрешения экрана (напр. переход в 120 DPI) или размеров шрифтов, элементов управления (к примеру ширины полос прокрутки и т.д). Интересно, как с этим справляется AutoIt3?
Если же тестирование всегда производится в неизменяемой среде, то другое дело…
Опять же изменение GUI программы (напр. скины) обяжет вас писать другие наборы тест-кейсов для всех случаев.
По ссылке не рекорд, но зато вживую видно, как это делает чемпион мира Ю. Накаджима за 6.57 секунд.
Такой подход в DevExpress мы применяли для планировщика при парсинге из iCalendar-файлов (пример).
Свойство OriginalException там как раз исходное исключение в более высокоуровневом iCalendarParseException.
Дело в том, что после выделения метода уже не требуется делать дополнительного вызова на rename. Если бы видео было чуть подробнее — то стало бы понятно, что после extract-а сгенеренное имя метода уже выделено, курсор стоит на нужном месте и достаточно лишь начать клавиатурный ввод, что б изменить имя на желаемое. Так что, рекомендую попробывать.
таким образом появились первые хакеры :)
Это должно быть на усмотрение компании — жесткого требования может и не быть.
Да, коде-ревью, бесспорно полезно, но в любом случае отнимает время и создает излишнюю «бюрократию» в хорошем смысле слова. Для опытных разработчиков с массовым количеством закладок ревью проводить слишком накладно — это может быть сдвиги по времени и прочие факторы. А для менее опытных, вполне разумно придерживаться это правила, предварительно перед закладкой «выправив» его код, т.к. обычно скорость их разработки меньше и даже среднего-класса разработчик может выполнить ревью.
Валидность закоммиченного в коде-репозиторий отслеживается через Continuous Interation, так что некорректные закладки сразу будут отражены в сломанных тестах с оповещением сломавших и должны быть сразу же пофикшены или временно может быть сделан роллбэк.
Симптом#1 можно предотвратить если ввести в компании правило совместного владения кодом, и, напр., устраивать code-review для программистов не самого высшего уровня.
Касательно unit-тестирования полностью согласен с автором в их полезности. Наличие тестов развязывает руки для выполнения рефакторинга любой сложности.
Когда тестов нет, а проект уже запущен, то возможно и нет смысла тратить время что бы достичь приличного покрытия. Получится что вы будете «писать тесты ради тестов». В такой ситуации целесообразно писать тесты на новые пришедшие баги и при дописывание нового функционала сразу окружать его тестами. В таком случае со временем вы достигните необходимого покрытия системы тестами и более экономично потратите свое время.
Нет предела совершенству ) А если серьезно код всегда будет видоизменяться в той или иной степени, если проект живой.
В целях сокращения описаний и текста у нас часто используются скриншоты или видео, иллюстрирующие проблему или как воспроизвести тест ;) Картинки идеи доносят лучше чем текст.
Если же тестирование всегда производится в неизменяемой среде, то другое дело…
Опять же изменение GUI программы (напр. скины) обяжет вас писать другие наборы тест-кейсов для всех случаев.