testomat.io управление авто тестамиВсем привет. Только начинаю писать автотесты на Java. Но, как сказали у нас в компании, то скоро будут проверять код.
Есть ли какие-либо best practices для рефакторнга кода?
В данный момент я только обучаюсь, поэтому у меня самые простые кейсы, типа залогинься, проверить данные и т.д.
1 лайк
Прежде чем что-либо рефакторить, надо для начала чему-то научиться. 
Рефакторинг, как правило, проводится в нескольких случаях:
- Человек намеренно писал на скорую руку, чтобы выкатить прототип. При этом, будучи уверенным, что в дальнейшем это обязательно трансформируется в tech debt, который будет непременно закрыт. Все это естественно честно озвучивается заказчику, мол: “смотри при твоих хотелках, дедлайнах и доступных ресурсах, я могу сделать вот так, но это будет какашкой. Если не хочешь, чтобы потом эта какашка развалилась по всем известным причинам, надо будет выделять время на рефакторинг”. Ну и конечно же при таком кейсе заказчику сразу предоставляется выбор - делаем либо быстро, но плохо, либо хорошо, но долго. Когда это становится выбором заказчика, то потом он уже не отвертится.
- Человек писал, как умел. Но за какой-то период научился чему-то новому (умные книжки, курсы, пет проекты, whatever). И вот, глядя на свой предыдущий код через время, он начинает осознавать, что и как можно было бы переписать, исходя из своего свежего взгляда и приобретенного опыта.
- Человек сознательно придерживается подхода - “вначале сделать, чтобы работало, затем сразу отрефакторить”. При этом, он уже сейчас обладает нужными скиллами, чтобы это сделать.
Ваш кейс пока не попадает ни под один из пунктов. В последствии вы скорее всего придете ко второму. Но на текущий момент, нельзя просто взять, почитать какие-то best practices, и сразу начать писать лучше, чем было. Для осмысления чего-то нового нужно много практиковаться: читать и писать код. А это невозможно без фундаментальных знаний в программировании. Задавали ли вы себе вопрос - а насколько хорошо на текущий момент вы знаете, к примеру, java core? Только изучив основы, вы сможете хотя бы отдаленно начать воспринимать паттерны проектирования и best practices в написании кода.
П.С. Под проверкой кода скорее всего подразумевалось подключение средств статического анализа. Соответственно, наименьшее, что вы сейчас сможете сделать, - это добавить соответствующие тулы первыми, и пофиксить все проблемы. Ну а дальше - учиться и еще раз учиться. Поскольку на code review все ваши “best practices” сразу же повсплывают на поверхность.
4 лайка
- Почитайте литературу:
- “Refactoring. Improving the Design of Existing Code” Мартин Фаулер
- “Философия Java” Брюс Эккель
- еще можете почитать цикл статей на ДОУ “Пособие для будущего Java разработчика” чисто для полноты картины
- Много практикуйтесь - пишите код, читайте код (свой и чужой), переписывайте старый код, так сказать, “набивайте руку”. Не нужно бояться написать что-то кривое или страшное, попробуйте следовать подходу: рабочее решение > оптимальное > красивое.
И самое главное: по затраченному времени, написание кода << чтение кода, поэтому всегда старайтесь в итоге работы получить читабельный код, с которым други люди смогут нормально работать, а не тот код который бездумно следует каким-то конвеншнам/правилам итд.
cto pod etim podrazumevaetsia?
Нет) Я сам QA, а проверять будет Test Automation Lead
Качество кода в автоматизации зачастую гораздо ниже чем в разработке да и задачи не рокет-сайенс, так что не стоит особо переживать, даже если проверять будет сам Test Automation Lead. Да и по-хорошему его задача не загнобить, а помочь быстрее развиться в спеца, приносящего профит компании
Никита, если говорить о рефакторинге, то могу посоветовать code refactoring | SELENIUM Automation in JAVA и Refactoring: clean your code (2-ой имеет версии українською и по-русски). Там очень хорошие объяснение, что к чему 
Но, наверное, в вашем случае надо смотреть на automation best practise - как писать хорошие локаторы, названия тестов, и т.д. Я накинула на коленке все, что мне наиболее часто приходилось исправлять после review моего кода . Надеюсь, вам это хоть как-нибудь поможет
http://listmoz.com/view/J3DHdMPCJxfTFfHJ5fs
Ну и так, навскидку, есть хорошие видео по этой теме:
- Типичные ошибки начинающих писать тесты на WebDriver
- Everything you want to know about Page Object design pattern (Mikalai Alimenkou, Ukraine), part 1
- Статьи
- Алексей Баранцев: Десять правил построения хороших локаторов
Очень надеюсь, что если вы научитесь чему-то новому или у вас будет собственная шпаргалка по рефакторингу, вы поделитесь этим с новичками, так как для начинающих действительно мало структурированной информации.
Успехов вам 
3 лайка
- По хорошему у каждого рефакторинга должна быть конкретная цель - улучшить читаемость, развязать сложно написанный код, привести к общему стилю, улучшить стиль кода, починить антипатерн (тут на сайте можно как раз прочитать).
Просто так рефачить без цели плохая идея. - Удобно рефакторить небольшими понятными кусками и запускать до и после тесты
Мне нравится эта статья
Technical Debt: Rescuing Legacy Code through Refactoring — SitePoint
1 лайк