Из интересного - для откликов часто приходилось писать сопроводительное письмо.
Мне кажется, что в Европе так принято. Так, что если не просят, то всё равно сделайте. Я например сделал себе шаблон и его каждый раз перефразировал немного словами из вакансии.
Даже в простом письме есть традиция писать кучу не информативного текста (opening, closing). Если, вы это не делаете, то можете показаться грубой. Вот такая культурная разница.
Во втором релизе весь тест был разделен на юнит-тесты. Используя pytest, библиотеку Python, мы разработали юнит-тесты, чтобы выяснить, где именно ломается служба идентификации. Тесты должны были:
Определить, работает ли Slackbot, который помог нам обойти 2FA.
Проверить, доступен ли сервер веб-приложения. Это необходимо, потому что если сервер веб-приложения выйдет из строя, вся система будет скомпрометирована, включая тесты.
Проверить, правильно ли заполнена страница входа в систему, поскольку иногда команда UI/UX изменяет веб-компоненты, чтобы улучшить дизайн приложения или исправить ошибку, которая может нарушать работу службы идентификации. Например, если текстовое поле неправильно связано с именем пользователя или паролем, пользователь не сможет войти в систему.
Проверить, что Slackbot получает уведомление о необходимости кода аутентификации 2FA и извлекает код после получения уведомления.
Проверить, действителен ли код 2FA, полученный Slackbot.
Проверить, все ли профили на странице согласия разрешены.
Проверить, что после нажатия кнопки "разрешить" из url извлекается код, и подтвердить, что этот код был извлечен.
Получить токен доступа (access token) и рефреш токен (refresh token) через OAuth 2.0.
Сгенерировать новый токен доступа, который должен отличаться от предыдущих.
Мнение о том, что есть юнит-тесты сильно расходятся. Но в среднем для тестов которые делают проверку сетевого взаимодействия используют другие термины, например: интеграционные.
От названий вещей не своими именами ничего хорошего не происходит.
Про типизацию много копий сломанно. Если немного приложить усилий (аннотации типов, мапинг объектов) то в Питоне становится намного комфортнее.
Джава обычно также отформатированна отступами, плюс дополнительные скобки. Я на обоих пишу и разницы в чтении особо не вижу, так что это скорее дело привычки.
Условиях из разных частей проекта будут как не разделяй. Иначе бы это были вообще отдельные программы.
Сторонние библиотеки не особо и отличаются от собственно написанных модулей, а с ними это вполне удаётся. Конечно есть случаи когда сторонние библиотеки форкются и в них протекает знание вашего проекта, но это скорее исключение.
Разделение - это не отсутствие зависимостей, это однонаправленные зависимости, которые вы контролируете. Ваш бизнес зависит от АПИ и ваш модуль зависит от АПИ. Пока вы поддерживает обратную совместимость АПИ (добавление нового метода не ломает её), добавление новых фич должно идти хорошо. Конечно при добавлении новых фич вы должны добавлять их и не ворошить внутрянку модуля. То есть если вы для новой фичи поменяли какой-то приватный метод, который используется везде то старое может сломаться, а мы этого не хотим.
Подход с добавлением нового очень контр-интуитивный, код написанный с таким подходом будет более развесистым чем, если бы вы писали его сразу зная все требования. Хотя, если модуль имеет хорошее тестовое покрытие, то вообще пофиг, чтоб вы делаете с ним внутри, хоте весь перепишите с нуля.
С багами сложнее, чем он глубже, тем больше вещей он затронет. Хотя по статистике, он скорее всего будет в свеже добавленном функционале.
> каждый состоит из пары десятков условий, которые очень сильно разносятся между собой и находятся в разных областях знания о проекте.
Изучая рекомендации от Боба Мартина, я для себя сделал вывод, что разделять код на модули по областям знания - это одна из важных идей при написании кода.
Код загрузки и сети явно напришивается в отдельные модули отделённые с инкапсуляцией и публичным API. Тогда их не получился сломать случайно. И по по моему опыту, сделать это можно с самого начала проекта, так как потребуется пару лишних минут. В начале проекта этот API будет часто меняться, но в какой-то момент устаканится и количество измений снизиться. Практически за бесплатно вы получити видимость того, что может сломаться в коде.
> С добавлением функционала так же просто, пока он не задевает логику старого.
Другой важный момент который я вынес (open-closed-principle), что не надо менять внутреннее API для новых фич. Просто добавляйте новые методы и документацияю к ним. Два похожих метода это нормально, три тоже. Перед добавлением четвёртого можно подумать о рефакторинге, но если нет времени то добавить и четвёртый, пятый, десятый. Если вы не меняёте существующий код, вы не сломаете старое добавляя новое, а если что-то чините, то это часто сужает количество кода который нужно перепроверять. Тоже получился мешанина, но уже намного более контролируемая.
Все эти паттерны (усложнения) в коде они в том числе направленны на то, чтобы больше фич можно было добавлять, просто добавляя новый код.
Так что ваше предположение, что e2e всегда сложнее и медленнее писать, чем юнит-тесты тоже ложно.
Я знаю ровно два случая когда юнит-тесты не проще чем e2e.
Первое, это когда продукто настолько маленький, что это одно и тоже. Втрое, когда юнит-тестами называют e2e.
> Юнит-тесты не могут проверять бизнес-задачи по определению
Это да, но могут очень сильно это упростить. Например у меня был кейс, когда нужно взять айдишник, его отформатировать (несколько правил для разных типов айдишника), и зашифровать. У меня было с десяток юнитов типа `assert function(input) == output`. И только один тест на уровне e2e.
> времени у одного тестировщика на четырёх программистов хватает.
Там, где я работал, на этот уровень не вышли.
В основном была проблема, что тесты начали писать позже и кроме нового функционала, надо было еще и покрывать старый. А из за высокой связанности, и вообще неприспособленности системы к тестам (микросервисный монолит), часто отваливалось и приходилось что-то переделывать.
Только если выкатывать большими пачками то ревью будет низкого качества.
Одно из решений найти несколько человек которые разделяют ваши мысли по поводу рефакторинга и просто просить их. Я к таким запросам всегда добавляю, что ревью на минутку.
Второй вариант поднять это на уровне команды/отдела и дружно прийти к каким то соглашениям. Возможно часть проблем именно из-за недопонимания. Не стоит ожидать, что это получился сразу, я бы закладывал 3-4 встречи с промежутком. Попробовали, собрались обсудили, подкорректировали.
На прошлой работе делал по первому сценарию, сейчас мы пошли по второму, первая встреча прошла на этой неделе.
Идея с маленькими шагами, как раз и позволяет не фиксить баги в перемешку с рефакторингом.
С точки зрения кодревью это должно быть ревью за чашкой чая, человеком вне глубокого контекста.
Например мы переименовали функция и получили 100+ файлов с изменениями. Просишь человека фидбек на новое имя, а остальное можно смотреть быстро пролистав.
С багами иногда нужна более детальная экспертиза. Ну и если запрятать изменения среди тон косметики, его просто могут пропустить при ревью. Или придётся вдумчиво смотреть на всё.
Второй критерий для меня, я делаю это без постановки задачи. То есть размазываю по текущей нагрузке. Фиксишь баг, нашёл что-то не связанное когда код читал, быстренько пофиксил. Или делаешь новую фичу, посмотрел на код порефакторил, а потом добавляешь новую фичу.
Это может показаться тратой времени, но мне зачастую проще в коде разобраться начав его рефакторить.
Я бы сказал, что ваше выпиливание не совсем рефакторинг, это изменение архитектуры проекта. Да публичный интерфейс не поменялся, но внутрянка сильно переделана. Как и рефакторинг это избавление от технического долга.
Во имя рефакторинга делается много разных вещей, и зачастую создают о нем плохую репутацию. Даже не потому, что это плохие вещи, а просто что результат от них не совпадает с ожиданием от рефакторинга. Может у одного из ваших менеджеров до сих пор волосы дыбом встают от слова рефакторинг, ведь это вся команда занимается чем-то две недели и не пилит новых фич.
Что-бы перейти с самописного ORM (уж не знаю какого художника так вдохновила идея написания своего ORM и почему его не остановили коллеги) малыми шагами не отделаешься
Философский вопрос, можно ли такое крупное изменения назвать рефакторингом?
Если ставить цель найти маленькие части, то они находятся. Хотя если вам выделили на этот рефакторинг кучу времени, то зачем разбивать?
Если нужно заменить все использования одной библиотеки на другую, то это очень хорошо делается по шагам.
Я не мог рефакторить маленькими кусками, потому что тогда бы мне пришлось каждый раз менять что то в своей обёртке, что уже было сделано.
Это абсолютно нормально. Посмотрели часть использований, обобщили, сделали обёртку, выкатили МР. Потом посмотрили еще, нашли что-то новое для себя переписали обёртку, выкатили МР. Рефакторинг это не про красоту с первого коммита, это про то, что после любого коммита система продолжала работать.
Большой объем информации просто так в голове не перекрутить. Нужно периодически фиксировать результат где-то. Вряд ли вы читали код две недели и потом просто сели и сразу готовую обёртку с первого раза написали.
Я когда делаю обёртки предпочитаю не изменять существующий интерфейс, а просто создавать новые методы. А потом, когда все использования уже переключены на обёртку, тут уже модно отрефакторить сам интерфейс. В этот момент у вас вся актуальная информация уже сгруппирована внутри обёртки.
Главное препятствие на пути рефакторинга малыми шагами это время тестирования. Если протестировать код занимает минут 10, то хочется делать изменения большими пачками.
Для меня рефакторинг это набор маленьких шагов. Удалил неиспользуемую функцию, закомитил, отправил на ревью, пошёл что-то другое делать. Где-то переименовал, где-то вынес в функцию. Где-то не выходит, тогда без сожаления выкидываю и начинаю с начала.
Да это долго, но небольшими шагами можно достаточно далёко уйти. Попытки разгрести большими кусками часто проваливаются.
Поиск работы за границей. Попытка номер раз
Мне кажется, что в Европе так принято. Так, что если не просят, то всё равно сделайте.
Я например сделал себе шаблон и его каждый раз перефразировал немного словами из вакансии.
Даже в простом письме есть традиция писать кучу не информативного текста (opening, closing). Если, вы это не делаете, то можете показаться грубой. Вот такая культурная разница.
Поиск работы за границей. Попытка номер раз
Через пять лет у вас будет не гражданство, а право на него податься. Там надо будет еще подождать.
Как я использовал Pytest для написания QA-тестов, гарантированно обходящих 2FA
Мнение о том, что есть юнит-тесты сильно расходятся. Но в среднем для тестов которые делают проверку сетевого взаимодействия используют другие термины, например: интеграционные.
От названий вещей не своими именами ничего хорошего не происходит.
Python или Java: что выбрать новичку?
Про типизацию много копий сломанно. Если немного приложить усилий (аннотации типов, мапинг объектов) то в Питоне становится намного комфортнее.
Джава обычно также отформатированна отступами, плюс дополнительные скобки. Я на обоих пишу и разницы в чтении особо не вижу, так что это скорее дело привычки.
Инженер изготовил умные брюки, сообщающие о расстёгнутой ширинке
Лучший код, это когда его нет!
Носите легинсы, нет ширинки, нет проблемы!
Дайте крудошлепа
Сторонние библиотеки не особо и отличаются от собственно написанных модулей, а с ними это вполне удаётся. Конечно есть случаи когда сторонние библиотеки форкются и в них протекает знание вашего проекта, но это скорее исключение.
Разделение - это не отсутствие зависимостей, это однонаправленные зависимости, которые вы контролируете. Ваш бизнес зависит от АПИ и ваш модуль зависит от АПИ. Пока вы поддерживает обратную совместимость АПИ (добавление нового метода не ломает её), добавление новых фич должно идти хорошо. Конечно при добавлении новых фич вы должны добавлять их и не ворошить внутрянку модуля. То есть если вы для новой фичи поменяли какой-то приватный метод, который используется везде то старое может сломаться, а мы этого не хотим.
Подход с добавлением нового очень контр-интуитивный, код написанный с таким подходом будет более развесистым чем, если бы вы писали его сразу зная все требования. Хотя, если модуль имеет хорошее тестовое покрытие, то вообще пофиг, чтоб вы делаете с ним внутри, хоте весь перепишите с нуля.
С багами сложнее, чем он глубже, тем больше вещей он затронет. Хотя по статистике, он скорее всего будет в свеже добавленном функционале.
Инженер изготовил умные брюки, сообщающие о расстёгнутой ширинке
Сразу вспоминаются проблемы лирического героя из одной песни.
Песню, я смог найти только в контакте, по запросу: "Швеццкий Стол Ширинка"
Дайте крудошлепа
Списибо, что поделились опытом.
> каждый состоит из пары десятков условий, которые очень сильно разносятся
между собой и находятся в разных областях знания о проекте.
Изучая рекомендации от Боба Мартина, я для себя сделал вывод, что разделять код на модули по областям знания - это одна из важных идей при написании кода.
Код загрузки и сети явно напришивается в отдельные модули отделённые с инкапсуляцией и публичным API. Тогда их не получился сломать случайно. И по по моему опыту, сделать это можно с самого начала проекта, так как потребуется пару лишних минут. В начале проекта этот API будет часто меняться, но в какой-то момент устаканится и количество измений снизиться.
Практически за бесплатно вы получити видимость того, что может сломаться в коде.
> С добавлением функционала так же просто, пока он не задевает логику старого.
Другой важный момент который я вынес (open-closed-principle), что не надо менять внутреннее API для новых фич. Просто добавляйте новые методы и документацияю к ним. Два похожих метода это нормально, три тоже. Перед добавлением четвёртого можно подумать о рефакторинге, но если нет времени то добавить и четвёртый, пятый, десятый. Если вы не меняёте существующий код, вы не сломаете старое добавляя новое, а если что-то чините, то это часто сужает количество кода который нужно перепроверять. Тоже получился мешанина, но уже намного более контролируемая.
Все эти паттерны (усложнения) в коде они в том числе направленны на то, чтобы больше фич можно было добавлять, просто добавляя новый код.
Дайте крудошлепа
Я знаю ровно два случая когда юнит-тесты не проще чем e2e.
Первое, это когда продукто настолько маленький, что это одно и тоже.
Втрое, когда юнит-тестами называют e2e.
> Юнит-тесты не могут проверять бизнес-задачи по определению
Это да, но могут очень сильно это упростить. Например у меня был кейс, когда нужно взять айдишник, его отформатировать (несколько правил для разных типов айдишника), и зашифровать. У меня было с десяток юнитов типа `assert function(input) == output`. И только один тест на уровне e2e.
> времени у одного тестировщика на четырёх программистов хватает.
Там, где я работал, на этот уровень не вышли.
В основном была проблема, что тесты начали писать позже и кроме нового функционала, надо было еще и покрывать старый. А из за высокой связанности, и вообще неприспособленности системы к тестам (микросервисный монолит), часто отваливалось и приходилось что-то переделывать.
«Хакер»: Python с абсолютного нуля! Учимся кодить без скучных книжек
Побуду педантом, но начинать обучение с полохих практик не стоит. И так с безопастностью в индустрии не всё хорошо.
Дайте крудошлепа
Это да.
Только если выкатывать большими пачками то ревью будет низкого качества.
Одно из решений найти несколько человек которые разделяют ваши мысли по поводу рефакторинга и просто просить их. Я к таким запросам всегда добавляю, что ревью на минутку.
Второй вариант поднять это на уровне команды/отдела и дружно прийти к каким то соглашениям. Возможно часть проблем именно из-за недопонимания. Не стоит ожидать, что это получился сразу, я бы закладывал 3-4 встречи с промежутком. Попробовали, собрались обсудили, подкорректировали.
На прошлой работе делал по первому сценарию, сейчас мы пошли по второму, первая встреча прошла на этой неделе.
Дайте крудошлепа
Идея с маленькими шагами, как раз и позволяет не фиксить баги в перемешку с рефакторингом.
С точки зрения кодревью это должно быть ревью за чашкой чая, человеком вне глубокого контекста.
Например мы переименовали функция и получили 100+ файлов с изменениями. Просишь человека фидбек на новое имя, а остальное можно смотреть быстро пролистав.
С багами иногда нужна более детальная экспертиза. Ну и если запрятать изменения среди тон косметики, его просто могут пропустить при ревью. Или придётся вдумчиво смотреть на всё.
Второй критерий для меня, я делаю это без постановки задачи. То есть размазываю по текущей нагрузке. Фиксишь баг, нашёл что-то не связанное когда код читал, быстренько пофиксил. Или делаешь новую фичу, посмотрел на код порефакторил, а потом добавляешь новую фичу.
Это может показаться тратой времени, но мне зачастую проще в коде разобраться начав его рефакторить.
Я бы сказал, что ваше выпиливание не совсем рефакторинг, это изменение архитектуры проекта. Да публичный интерфейс не поменялся, но внутрянка сильно переделана. Как и рефакторинг это избавление от технического долга.
Во имя рефакторинга делается много разных вещей, и зачастую создают о нем плохую репутацию. Даже не потому, что это плохие вещи, а просто что результат от них не совпадает с ожиданием от рефакторинга. Может у одного из ваших менеджеров до сих пор волосы дыбом встают от слова рефакторинг, ведь это вся команда занимается чем-то две недели и не пилит новых фич.
Дайте крудошлепа
Философский вопрос, можно ли такое крупное изменения назвать рефакторингом?
Если ставить цель найти маленькие части, то они находятся. Хотя если вам выделили на этот рефакторинг кучу времени, то зачем разбивать?
Дайте крудошлепа
Если нужно заменить все использования одной библиотеки на другую, то это очень хорошо делается по шагам.
Это абсолютно нормально. Посмотрели часть использований, обобщили, сделали обёртку, выкатили МР. Потом посмотрили еще, нашли что-то новое для себя переписали обёртку, выкатили МР. Рефакторинг это не про красоту с первого коммита, это про то, что после любого коммита система продолжала работать.
Большой объем информации просто так в голове не перекрутить. Нужно периодически фиксировать результат где-то. Вряд ли вы читали код две недели и потом просто сели и сразу готовую обёртку с первого раза написали.
Я когда делаю обёртки предпочитаю не изменять существующий интерфейс, а просто создавать новые методы. А потом, когда все использования уже переключены на обёртку, тут уже модно отрефакторить сам интерфейс. В этот момент у вас вся актуальная информация уже сгруппирована внутри обёртки.
Главное препятствие на пути рефакторинга малыми шагами это время тестирования. Если протестировать код занимает минут 10, то хочется делать изменения большими пачками.
Дайте крудошлепа
У нас видимо разное понимание "не используется".
Для меня рефакторинг это набор маленьких шагов. Удалил неиспользуемую функцию, закомитил, отправил на ревью, пошёл что-то другое делать. Где-то переименовал, где-то вынес в функцию. Где-то не выходит, тогда без сожаления выкидываю и начинаю с начала.
Да это долго, но небольшими шагами можно достаточно далёко уйти.
Попытки разгрести большими кусками часто проваливаются.
Дайте крудошлепа
Чтобы боло 300?
Дайте крудошлепа
Если смотреть с определённого ракурса, у Камаза будет видно только 3 колеса :)
Возможно проблема не в шаблонах, а в чём то другом. А случай яркий и запоминающийся.
Дайте крудошлепа
Появились ли после этого тесты?
Дайте крудошлепа
Неиспользуемых? Так удалите и дело с концом.
По моему опыту выпиливать не так уж и сложно.
У вас кстати ревью на проекте есть? Или тоже потеря времени?
Дайте крудошлепа
Так про полиморфизм был разговор в рамках другой задачи.
К опечаткам обычно не предираюсь, сам горазд, но вы там про имена целый абзац наказали, так что минус вам за Findvoice