Sergey
если с TDD конечно
Ale
ну да
Sergey
есть люди которым это не нужно
Sergey
они и так могут в голове все представить
Sergey
у меня в команде есть один такой чувак который постоянно кричит мол "тесты не нужны"
Sergey
я довольно долго с ним холиварил
Sergey
но потом мы пришли к тому что конкретно ему тесты для проектирования не нужны
Ale
тесты не нужны совсем?
Sergey
потому что он в голове всю эту структуру может спокойно представить и покрутить
Ale
а
Ale
кто-то умлы рисует
Ale
кто-то crc карточки
Ale
один фиг)
Sergey
ну вот этот чувак может в голове все представить и ему норм
Sergey
причем я таких людей знаю ну только вот его
Sergey
большинство же не могут в голове удержать всю систему или хотя бы кусок над которым работают. Не могут предсказать сайд эффекты и т.д.
Sergey
потому uml/crc/tdd/dbc
Sergey
для них норм
Sergey
у меня была разработчица... я хз с чем это было связано но она не могла видеть последствий своих действий даже на один шаг вперед. Одна фича сделана - забываем о ней пилим следующую. То что реализация второй фичи полностью ломает первую - узнаем на код ревью/тестировании
invariance
девичья память, все дела
Sergey
девичья память, все дела
сильно сомневаюсь что тут проблемы с памятью. Были и парни разработчики такие но я там не особо был вкурсе происходящего.
Sergey
ну и у меня есть еще девчушки разработчицы у которых таких проблем нет
Sergey
сильно сомневаюсь что половой признак тут на что-то влияет.
invariance
Больше не буду шутить, пожалуй
Sergey
не насамом деле вопрос интересный)
Sergey
как пол влияет на уровень разработчика)
Sergey
и не только разработчика а в целом как влияет
invariance
На самом деле, мне кажется, только характер меняется. А навыки не зависят от пола
Sergey
есть нюансы... Девушки менее склонны к риску и более усидчивы в среднем
Ale
и не только разработчика а в целом как влияет
ага, как у дяди Боба было, почему после 70ых соотношение от 50\50 сместилось в пользу мужчин
Sergey
ага, как у дяди Боба было, почему после 70ых соотношение от 50\50 сместилось в пользу мужчин
ну тут такой момент... вспомни что до 70-х программистами были в основном люди состоявшиеся в других сферах
Ale
Sergey
был видос где дядя боб холиварил насчет tdd vs dbc
Sergey
https://www.youtube.com/watch?v=KtHQGs3zFAM
Sergey
у меня была разработчица... я хз с чем это было связано но она не могла видеть последствий своих действий даже на один шаг вперед. Одна фича сделана - забываем о ней пилим следующую. То что реализация второй фичи полностью ломает первую - узнаем на код ревью/тестировании
уменять прокручивать написанный код в голове не запуская дебаггер - важный навык
Sergey
а то с дебаггерами совсем уже обленились)
Sergey
там не в коде проблемы
Sergey
ну например
Sergey
"так мне надо сделать метод api для активации юзера"... сделано
"так мне надо сделать так что бы неактивированный юзер не мог пользоваться апи" - сделано.
"черт... теперь юзеры не могут актикировать аккаунт и никогда не смогут использовать api"
Sergey
тут как по мне больше бездумность действий. Ну то есть человек не продумал задачу от слова совсем
Sergey
как минимум ее 2 человека не продумали, а то и больше
Тенпеннай
тут bdd шикарно подойдет, хехе
Ale
это да
Sergey
как минимум ее 2 человека не продумали, а то и больше
в смысле? тут только разработчиков проблема. Это чисто технические нюансы
Sergey
ну то есть тупо разработчика проблема
Sergey
потому что BDD сценарии не будут описывать взаимодействие приложеньки с API
Sergey
они будут описывать только выосоуровневые сценарии на уровне пользователя
Ale
ну то есть тупо разработчика проблема
ну почему же, что такое активация юзера? А неактивированный это кто?
Ale
он может пользоваться приложенькой?
Sergey
ну почему же, что такое активация юзера? А неактивированный это кто?
не не, на уровне требований бизнеса все это было покрыто
Sergey
там деваха тупо ваервол в симфони врубила без учета деталей
Sergey
если приходит 2 задачи, которые не вяжутся друг с другом, то это проблема тех кто их ставил
Sergey
они вяжутся
Sergey
а некоторые разрабы молча делают то что им сказали, особо не вникая
Ale
там деваха тупо ваервол в симфони врубила без учета деталей
ну вот простой бихат сценарий сразу бы ей показал
Ale
что говно ее решение)
Sergey
да давай по другому) автотесты бы показали что сломалось)
Sergey
тут бехат, bdd и т.д. не решение проблемы, а дорогой способ
Sergey
который неявно укажет на техническую ошибку
Ale
ну, тут вообще про подход человека, она не держит в голове все кейсы, ей либо руками их каждый раз прогонять, а до этого записать на листике
Ale
или автоматически
Sergey
последние пол года в компании мы практикуем такую простую тему как написание критериев приемки. Ну то есть разработчики делают сабтаски технические к сторе или таску, и там прописываю "как это должно работать" и там продумывают уже все детали
guga
У меня вопрос назрел, вот вы все тут про tdd, bdd прочие лучшие практики разговариваете. Как вы понимаете что делаете это правильно, ну и ещё, обычно вы лично внедряете или просто присутствуете в команде, где это уже есть и так делают все?
Sergey
> она не держит в голове все кейсы
это нормально. А вот когда ты за один день сделал 2 кейса причем подряд
Sergey
и один ломает другой
Ale
ну она вообще в голове кейсы не держит
Ale
бывает
Ale
есть решение)
Sergey
есть) заставлять тесты писать)
Ale
если бы у нас была одна кнопка)
Ale
которая говорила
Ale
))
Ale
https://www.youtube.com/watch?v=9NANcPTbDBQ
Sergey
У меня вопрос назрел, вот вы все тут про tdd, bdd прочие лучшие практики разговариваете. Как вы понимаете что делаете это правильно, ну и ещё, обычно вы лично внедряете или просто присутствуете в команде, где это уже есть и так делают все?
для начала надо разобраться в каких ситуациях какие "лучшие практики" подходят лучше. Иногда это тупо учиться на своих ошибках