ну да

есть люди которым это не нужно

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

у меня в команде есть один такой чувак который постоянно кричит мол "тесты не нужны"

я довольно долго с ним холиварил

но потом мы пришли к тому что конкретно ему тесты для проектирования не нужны

тесты не нужны совсем?

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

тесты не нужны совсем?

именно TDD в контексте проектирования

а

кто-то умлы рисует

кто-то crc карточки

один фиг)

ну вот этот чувак может в голове все представить и ему норм

причем я таких людей знаю ну только вот его

большинство же не могут в голове удержать всю систему или хотя бы кусок над которым работают. Не могут предсказать сайд эффекты и т.д.

потому uml/crc/tdd/dbc

для них норм

у меня была разработчица... я хз с чем это было связано но она не могла видеть последствий своих действий даже на один шаг вперед. Одна фича сделана - забываем о ней пилим следующую. То что реализация второй фичи полностью ломает первую - узнаем на код ревью/тестировании

девичья память, все дела

девичья память, все дела

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

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

сильно сомневаюсь что половой признак тут на что-то влияет.

Больше не буду шутить, пожалуй

не насамом деле вопрос интересный)

как пол влияет на уровень разработчика)

и не только разработчика а в целом как влияет

На самом деле, мне кажется, только характер меняется. А навыки не зависят от пола

есть нюансы... Девушки менее склонны к риску и более усидчивы в среднем

и не только разработчика а в целом как влияет

ага, как у дяди Боба было, почему после 70ых соотношение от 50\50 сместилось в пользу мужчин

потому uml/crc/tdd/dbc

dbc?

причем я таких людей знаю ну только вот его

это проект одного человека у него?

ага, как у дяди Боба было, почему после 70ых соотношение от 50\50 сместилось в пользу мужчин

ну тут такой момент... вспомни что до 70-х программистами были в основном люди состоявшиеся в других сферах

dbc?

design by contract

ну тут такой момент... вспомни что до 70-х программистами были в основном люди состоявшиеся в других сферах

да, это понятно

design by contract

а

был видос где дядя боб холиварил насчет tdd vs dbc

https://www.youtube.com/watch?v=KtHQGs3zFAM

у меня была разработчица... я хз с чем это было связано но она не могла видеть последствий своих действий даже на один шаг вперед. Одна фича сделана - забываем о ней пилим следующую. То что реализация второй фичи полностью ломает первую - узнаем на код ревью/тестировании

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

а то с дебаггерами совсем уже обленились)

там не в коде проблемы

ну например

"так мне надо сделать метод api для активации юзера"... сделано "так мне надо сделать так что бы неактивированный юзер не мог пользоваться апи" - сделано. "черт... теперь юзеры не могут актикировать аккаунт и никогда не смогут использовать api"

тут как по мне больше бездумность действий. Ну то есть человек не продумал задачу от слова совсем

как минимум ее 2 человека не продумали, а то и больше

тут bdd шикарно подойдет, хехе

это да

ну и из общения с людьми на курилке - никто ничего не понял

это вообще странная вещь

как минимум ее 2 человека не продумали, а то и больше

в смысле? тут только разработчиков проблема. Это чисто технические нюансы

ну то есть тупо разработчика проблема

потому что BDD сценарии не будут описывать взаимодействие приложеньки с API

они будут описывать только выосоуровневые сценарии на уровне пользователя

ну то есть тупо разработчика проблема

ну почему же, что такое активация юзера? А неактивированный это кто?

он может пользоваться приложенькой?

ну почему же, что такое активация юзера? А неактивированный это кто?

не не, на уровне требований бизнеса все это было покрыто

там деваха тупо ваервол в симфони врубила без учета деталей

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

они вяжутся

а некоторые разрабы молча делают то что им сказали, особо не вникая

там деваха тупо ваервол в симфони врубила без учета деталей

ну вот простой бихат сценарий сразу бы ей показал

что говно ее решение)

да давай по другому) автотесты бы показали что сломалось)

тут бехат, bdd и т.д. не решение проблемы, а дорогой способ

который неявно укажет на техническую ошибку

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

или автоматически

последние пол года в компании мы практикуем такую простую тему как написание критериев приемки. Ну то есть разработчики делают сабтаски технические к сторе или таску, и там прописываю "как это должно работать" и там продумывают уже все детали

ERROR: S client not available

У меня вопрос назрел, вот вы все тут про tdd, bdd прочие лучшие практики разговариваете. Как вы понимаете что делаете это правильно, ну и ещё, обычно вы лично внедряете или просто присутствуете в команде, где это уже есть и так делают все?

> она не держит в голове все кейсы это нормально. А вот когда ты за один день сделал 2 кейса причем подряд

и один ломает другой

ну она вообще в голове кейсы не держит

бывает

есть решение)

есть) заставлять тесты писать)

если бы у нас была одна кнопка)

которая говорила

))

https://www.youtube.com/watch?v=9NANcPTbDBQ

У меня вопрос назрел, вот вы все тут про tdd, bdd прочие лучшие практики разговариваете. Как вы понимаете что делаете это правильно, ну и ещё, обычно вы лично внедряете или просто присутствуете в команде, где это уже есть и так делают все?

для начала надо разобраться в каких ситуациях какие "лучшие практики" подходят лучше. Иногда это тупо учиться на своих ошибках

У меня вопрос назрел, вот вы все тут про tdd, bdd прочие лучшие практики разговариваете. Как вы понимаете что делаете это правильно, ну и ещё, обычно вы лично внедряете или просто присутствуете в команде, где это уже есть и так делают все?

что такое правильно?

оно просто иногда работает и помогает не тратить деньги

например вот в случае с этой девчушкой ATDD/BDD хорошо бы сработало (TDD - врядли)

а иногда нет)

что такое правильно?

Вот это один из главных вопросов.

У меня вопрос назрел, вот вы все тут про tdd, bdd прочие лучшие практики разговариваете. Как вы понимаете что делаете это правильно, ну и ещё, обычно вы лично внедряете или просто присутствуете в команде, где это уже есть и так делают все?

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

Вот это один из главных вопросов.

"правильно" - это значит "работает в данной ситуации"

ну это я так трактую

работает? Почти все работает, чаще вопрос, сколько это стоит сейчас и в будущем

именно

"правильно" - это значит "работает в данной ситуации"

коннекты к БД из юнит тестов, это не правильно, но работает. так что сомнительное утверждение

с учетом краткосрочной и долгосрочной перспектив, с учетом того какие вещи важнее для бизнеса сейчас

коннекты к БД из юнит тестов, это не правильно, но работает. так что сомнительное утверждение

тест на репозиторий

всегда можно добавить технического долга

а если система разделена более-менее грамотно

тест на репозиторий

ключевое слово "юнит тест"

а что такое юнит?

ключевое слово "юнит тест"

юнит тест на репозиторий?)

репозиторий нужно тестить вместе с базой данных

иначе дорого выходит и непонятно что ты проверяшь