ну почти)

а отчетики, новые таски в ci, отьяснить команде что к чему

отчетики?

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

у меня проблемка сейчас... допустим я потратил на реализацию задачи 4 часа + тесты, скидываю в тестирование, там в целом все тест кейсы почти покрыты, и QA всеравно тратит по 2 часа на проверки

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

одно другому не мешает) юнит тесты это вообще такой себе гарант работоспособности приложения

одно другому не мешает) юнит тесты это вообще такой себе гарант работоспособности приложения

не не, это testing vs verification

у меня проблемка сейчас... допустим я потратил на реализацию задачи 4 часа + тесты, скидываю в тестирование, там в целом все тест кейсы почти покрыты, и QA всеравно тратит по 2 часа на проверки

так это ж ок

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

мне было бы лучше если бы QA проверили мои тест кейсы

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

а приложение не работало по итогу?)

работало конечно

у нас сейчас трабл - 90% времени QA тратят не на тестирование а на верификацию работы программистов

что я считаю категорически неправильным

а баги все равно находят стейкхолдеры и клиенты ?

у нас qa больше делает еще аналитику, мол, на таком-то девайсе по углом в 30 градусов я как юзер кнопку и не заметил бы

хуже

чет не выделяется она

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

хотя и такое бывает что клиенты баги находят

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

идешь по коммитам и смотришь что было?

но это в основном те кейсы про которые мы не думали

мы ревью делаем только в PR в основном

идешь по коммитам и смотришь что было?

не, просто хожу по исходникам мастера

1. ищу где используются сеттеры

2. ищу где используются геттеры

)))

по нарушениям инкапсуляции можно легко найти проблемы

тип "где-то что-то забыли"

public function setName(string ... и сразу triggered ))

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

шучу)

и ищу аргументы таким образом

мол "вот чувак, если бы ты тут не делал геттеров, у тебя небыло бы пробле"

блин, может мне тоже таким позаниматься

за месяц нашел в своем проекте как минимум десяток таких вот мелких проблем. Половину уже зарефакторил

ну как мелких

они бизнес логику по итогу делают неконсистентной

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

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

забывали какие-то проверки

в основном

небольшие бизнес правила пропадали

ну я уже говорил, у меня в основном баги - это неучтенная логика например недавно были проблемы с трекингом шиппинга. нам присылали in progress, а потом посылка просто пропадала из их апи или вот тоже, ожидался маппинг 1:1, а оказалось что может вернуться 1:n в редких случаях просто ошибка логики и невнимательность разраба. когда в метод передают 2 ордера и их нужно смержить в 1, нет учета того что эти 2 ордера просто референсы на 1 и тот же

ну это нормальные баги

у меня же на проектах пока осоновные баги рождаются проблемами коммуникации в команде

~20 человек не могут договориться

или просто не хотят как правило

3 бизнес аналитика)

ну это нормальные баги

я к тому что это такие баги, что тебя даже тесты не спасут от них. и QA могут не найти такое

а отчетики, новые таски в ci, отьяснить команде что к чему

так а что за отчетики?

отчетики по тестам

так а что за отчетики?

code coverage, репорты по тестам

а это сразу надо?

простого exit 1 при падении недостаточно?

так а что за отчетики?

уже ответили, сорян, пропустил твоё сообщенько

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

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

уже ответили, сорян, пропустил твоё сообщенько

как-то мне было лень подключать либу для тестов https://github.com/mkusher/reactphp-co/blob/master/specs/spec.php в итоге либа для тестов внизу, примерно 15 строк

время велосипедов

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

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

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

подходы даже у мужиков различаются

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

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

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

разница не зависит от пола разработчика, разница зависит от мировозрения и личностного восприятия

время велосипедов

изначально я просто сделал скрипт, который запускал для проверки. По мере набора кейсов решил их именовать

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

ну вот заметь. ты зашла и начала топить за гендерность. а не за ООП или ТДД о котором мы тут уже час говорим)

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

?, а вот тут я с тобой согласна ?

ERROR: S client not available

ну вот заметь. ты зашла и начала топить за гендерность. а не за ООП или ТДД о котором мы тут уже час говорим)

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

не часто девушек увидишь в этих чатах

хотя недавно удивился, увидел в скала чатике девушку, работает в Тинькофф банке и топит сильно за скалу, ФП и математику

не часто девушек увидишь в этих чатах

ты уже делился фоточками)

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

да не, вливайся в обсуждения)

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

а то тут вечно что-то стандартное обсуждают

(

да тут просто никто из нас ничего толком не знает(

поэтому ходим покругу

да тут просто никто из нас ничего толком не знает(

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

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

твиттер)

(на самом деле впечатлился Adam ruins everything)

oopunderhood

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

ну типа как jsunderhood, backendunderhood

и там еще 5ка точно таких есть

да вот я хз надо ли продвигать ООП

я бы хотел с функциональным программированием поближе познакомиться что бы как-то паралели лучше строить

глядел уже?

http://www.oreilly.com/programming/free/object-oriented-vs-functional-programming.csp

вот кстати пойду ее дочитаю

надо заставлять себя книги читать(

хотя бы пол часика в день

эх раньше было легко... сел в маршрутку и 45 минут почитать есть

а сейчас сел в такси и через 10 минут на работе

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

ага.. из твиттера >2017 we're still discussing static vs dynamic typing and FP vs OO. I do hope in 2018 we get back to discussing optional semicolons.

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

а ты на чем пишешь то?

?, а вот тут я с тобой согласна ?

Оо, ты и тут есть