Удаленка для jenkins+selenide+selenoid+allure+docker спецов на 2-3 часа в день. 100% remote! Присоединиться к проекту

Насколько вы следуете принципам чистого кода при построении систем

oop
design-patterns
architecture
solid
codedesign
Теги: #<Tag:0x00007fedbbdb0c58> #<Tag:0x00007fedbbdb0b18> #<Tag:0x00007fedbbdb09b0> #<Tag:0x00007fedbbdb07f8> #<Tag:0x00007fedbbdb0640>

(Dzmitry Ihnatsyeu) #1

Всем привет!

Возник такой вопрос: насколько, разрабатывая программы для тестирования, вы следуете принципам чистого кода, SOLID etc? Или же вы считаете, что для автотестов качественная архитектура не так важна и можно писать код с минимальными усилиями в рамках архитектурных решений?
Буду благодарен за обоснованные позиции.


(Максим Таран) #2

ОО, Мне кажется это вечный спор. :)) Вот, например, у нас работе так. :slight_smile:


(Yury) #3

Для автотестов качественная архитектура важна, потому что после вас могут придти другие люди, которым это все разгребать и поддерживать :slight_smile:


(Volodymyr) #4

Или даже самому разбираться в своем же коде через месяц будет гораздо проще и быстрее, если архитектурно проект построен грамотно.


(Dzmitry Ihnatsyeu) #5

Интересно и как вы живете на одном проекте с разным видинием подхода к архитетуре? У меня, например, на проекте ситуация такая, что в никакую не хотят писать код хоть с каким-то прицелом на долгую поддержку и расширяемость. Руководство хочет результат прямо сейчас, и тех лид как бы думает точно также: “Сейчас запилим, а там разберемся”. Я пытаюсь объяснить, что “а там разберемся” это будет переписывание все заново, но не помогает.


(Yury) #6

Бегите оттуда, вас не любят :wink:

А если серьезно, конечно, так бывает и часто. Постарайтесь максимально прикрыться, чтобы в случае большого взрыва не просто сказать “Ну вот, я же говорил!”, а чтобы было что-то материальное, на что можно сослаться - переписка, нотариально заверенные скриншоты и т.п. Чтобы им, а не вам, стало мучительно больно за свое поведение.

Можно создать простенькие требования к написанию кода. Все с радостью под ними подпишутся. Соблюдать, конечно, не будут. Зато у вас будет железобетонный аргумент в случае чего.


(Максим Таран) #7

Ну, пытаемся к компромиссу прийти. Тех лиды считают, что не надо писать Framework, а пилить, что попроще. А мы же пытаемся сделать по-красивее. Вот так и живём :slight_smile:


(Dzmitry Ihnatsyeu) #8

Спасибо всем за ответы ). Конечно мое видение такое:

  • если автоматизация делается, она делается с прицелом на долгий срок ( а иначе зачем вообще она нужна), а значит нужно разрабатывать систему достаточно понятную и гибкую.
    Юрий, в каждой шутке есть доля шутки). По факту я уже порядком времени пишу говнокод, который мне совершенно не нравится и с этим явно мириться не стоит, как я это вижу.

#9

по личному опыту скажу что иногда лучше сделать просто и быстро чем пилить фреймворк который все кейсы будет учитывать, но потом что то пойдет не так (проект поменяет свое русло или еще что то ) и все ваше затраченое время пойдет коту под хвост.
P.S. я о гавнокоде не говорю, а о том что все-все все учитывать это плохой вариант.


(Dzmitry Ihnatsyeu) #10

Мы с тобой работаем?)) Никто не говорит, что нужно учитывать все все все. Есть практики и методы позволяющие писать поддерживаемый и расширяемый код. Расширяемый != поддерживающий все все. Как раз таки если все пойдет в другое русло, то вы весь ваш простой и быстрый код выкинете


#11

не вместе :slight_smile: просто был опыт когда напилился фреймворк - основная часть которого так и не заиспользовалась :slight_smile:


(Dzmitry Ihnatsyeu) #12

для каждого проекта есть такая вероятность, но это ведь не значит, что нужно делать абы как на случай - а вдруг все надо будет переделывать. В таких случаях изменения кода продукта не менее значительные, чем ваши, и у вас будет время что подправить русло. В любом случае все всегда остается за вами ). Я лишь поинтересовался какие подходы кто использует


#13

было усложнение логики и добавленые уровни абстракции - через которые было сложнее писать код. Но потом оказалось что оно не принесло велью. :joy:


(Sergey Korol) #14

Автоматизация - это долгосрочная инвестиция. От прочности заложенного фундамента зависит ее эффективность в будущем.

Если следовать принципу:

вероятней всего первое время это даже будет отлично работать.

Но, как правило, если рассмотреть более длительный промежуток времени, можно будет заметить постепенную деградацию, выражающуюся в первую очередь в увеличении времени на поддержку автотестов / фреймворка / инфраструктуры и т.п.

А когда дело доходит до точки невозврата - QA инженеры тратят все свое время на поддержку - эффективность автоматизации сводится к нулю. К вам тут же прибегают лиды, менеджеры и прочие “Сейчас запилим, а там разберемся”, и начинают искать крайнего, с умным видом разбираться в причинах, принимать ошибочные решения о том, что необходимо нанимать больше людей и т.п.

П.С. У нас для автоматизаторов действуют те же правила, что и для девелоперов. Начинающих сразу приучают использовать quality плагины, думать в лучших традициях ООП, не забывать о патернах, строго следить за тем, что пушится в репозиторий и т.п.


#15

Так речь о написании качественного кода. Много не значит хорошо. А по поводу неиспользуемого кода, то есть хороший принцип https://en.m.wikipedia.org/wiki/You_aren't_gonna_need_it


(Vatslau) #16

Ммм сейчас стараюсь заложить масимум абстракции…
несколько раз приходилось переписывать из-за этого много кода
или костыли писать


(Dzmitry Ihnatsyeu) #17

приятно знать, что большинство за написание качественного кода, а не на скорую руку)


(Павел Сенин) #18

А что конкретно за плагины?..


(Sergey Korol) #19

Конкретно для Java: Checkstyle, PMD, FindBugs. В зависимости от используемого build tool, они могут либо по отдельности подключаться, либо в виде плагинов-агрегаторов. Некоторые предпочитают ставить SonarQube сервер и т.п. Вариантов на самом деле много.