Спрашиваю про отношение к тестированию, и возможно ли развернуть идиотскую/некорректно поставленную задачу на доработку.
Если говорят "мы не против чтобы были тесты, но лишь бы сильно время выполнения не затягивало" + начинают деликатно юлить про разворот задачи - маркеры того, что здесь не очень, ну или совсем катастрофа, по тональности ответов станет ясно.
Но в целом, эти вопросы - артефакты рынка соискателя, когда ты реально выбираешь компанию
есть подозрение, что по фронту внятных книжек не почитать, тк книжка пишется дольше чем выходит yet another revolution feature в твоем фреймворке.
в бэке постабильнее
как вообще по ютубу программировать учиться - ума не приложу. разве что посмотреть лекции/доклады, или что то вроде объяснения алгоритмов. базу текстом воспринимать сильно легче
если у вас указана перем.окружения COMPOSE_PROJECT_NAME=SOME
то нужно прописывать его в настройках интерпретатора в phpstorm (в env variables). без этого что-то не срабатывает (уже не помню что именно, помню что провозился из за этого с настройкой docker+xdebug+phpunit)
т, зависит от того, что мы захотим. Пойдёт в один шаг, в другой или третий.
покажите псевдокод, в котором успешная оплата переводит статус оплаты заказа в "оплачено", а в случае если от банка приходит отказ, то статус оплаты заказа не меняется, а выводится ошибка.
судя по той одной большой цепочке вызовов, что я увидел в статье, это будет проблемой.
В худшем случае вы дадите социально одобряемый ответ, и покажетесь "своим".
В лучшем - вы сделаете пометку, что это не самый оптимальный способ, разбирались, знаете нюансы, сейчас продемонстрируете... и либо пройдете тест на "своего" (ага, мы тоже знаем!), либо удивите и продемонстрируете экспертизу, после чего решение по найму на этом этапе будет де-факто принято.
По итогу во многих наших командах сейчас наличие теханализа является частью Definition of Ready — увеличение Cycle time окупается предсказуемостью и ростом общей производительности.
Как продавать это менеджерам которые не в состоянии видеть ничего дальше 1 спринта? Они не видят общего роста производительности, они видят что сегодня ты че то там думаешь, а мог бы и код писать
Какие елочки, какие звезды со стикерами, вы в детском саду? Что за гомосятина на работе?
заглядывать в рот каким-то выдуманным "звездам" и участвовать в дебильных конкурсах
Я бы перекрестился
эпическая подборка высказываний. вот такие кадры и остались: ты ему "наклей стикер, если хочешь чтобы компания улучшила тебе условия труда чтобы тебя удержать", а он посчитал это "гомосятиной", обозвал всех дебилами и... перекрестился :)
корзина - это идентификатор продукта x количество + какой бы то ни было пэйлоад сверху. называйте как угодно, от сути не убежите
у нас это называется Purchase Order
называйте как угодно, от сути не убежите
Есть b2b, где каждый заказ индивидуален
и что еще хуже, скорее всего и каждое предложение (quotation) индивидуально, и проходит через сэйлзов, и именно поэтому важно отделять его от заказа, инвойса и корзины. называйте как угодно, от сути не убежите
И тут важно уже учитывать добавленную природу налога в виде налогового вычета.
именно поэтому важно его атомарно записывать, и отделить от заказа, чтобы иметь возможность построить любой отчет для любого клиента с любой стороны прилавка
любой из приведенных 4 этапов можно назвать хоть Сюзанной и раздробить еще на 48 дополнительных, но убрать один = выстрелить в панду
Кстати HR тут довольно важен, потому что если вдруг у кандидата в период испытательного срока будут проблемы, то он может пойти к начальнику и к... HR ("дорогой HR я к вам пришел работать и понял, что мой начальник идиот, что делать?")
И что такого важного может сделать HR, кроме как пожать плечами и сказать "ну да, мой тоже, работаю как-то"?
разработчику ставят задачу на оценку. эта задача выполняется в течение спринта рядом с обычными
разработчик оценивает
к оценке добавляется x запаса
если не отказались от идеи, увидев оценку - задачу ставят на разработчика, дедлайн = оценка
это тоже ломается об r&d
как оценивать решение задачи неизвестным образом - неизвестно. можно было бы закладывать время на "попробовать варианты абв и выбрать", но для этого нужно комплексно продумать каждый
оценку надо успеть выдать к следующему диалогу ПМа с заказчиком, чтобы они договорились о приоритетах
во время работы по задаче можно придумать лучшее решение, чем то что заложено в оценке. лучшее не значит более быстрое, а значит что в будущем поможет с другими задачами, емли заложиться в нее сейчас
на одной неделе тебе дают задачу x, а через еще две - x'. для решения задачи x не вводили новых сервисов/слоев, а для x' уже не получится. можно было сразу делать инфраструктуру для x', чтобы потом быстро закрыть обе задачи, но не вышло. теперь тебе нужно переносить x на x'. системно не решаемо, тк ПМ не может обобщить
а теперь расскажу вам про этикет в почтовых рассылках, которыми никто из вас уже не пользуется, потому что живет в другом тысячелетии
с "неприветом" согласен
Спрашиваю про отношение к тестированию, и возможно ли развернуть идиотскую/некорректно поставленную задачу на доработку.
Если говорят "мы не против чтобы были тесты, но лишь бы сильно время выполнения не затягивало" + начинают деликатно юлить про разворот задачи - маркеры того, что здесь не очень, ну или совсем катастрофа, по тональности ответов станет ясно.
Но в целом, эти вопросы - артефакты рынка соискателя, когда ты реально выбираешь компанию
frontenD, конечно же. глаз режет, простите.
есть подозрение, что по фронту внятных книжек не почитать, тк книжка пишется дольше чем выходит yet another revolution feature в твоем фреймворке.
в бэке постабильнее
как вообще по ютубу программировать учиться - ума не приложу. разве что посмотреть лекции/доклады, или что то вроде объяснения алгоритмов. базу текстом воспринимать сильно легче
есть еще нюанс с docker-compose:
если у вас указана перем.окружения
COMPOSE_PROJECT_NAME=SOMEто нужно прописывать его в настройках интерпретатора в phpstorm (в env variables). без этого что-то не срабатывает (уже не помню что именно, помню что провозился из за этого с настройкой docker+xdebug+phpunit)
если есть только одна реализация интерфейса - зарегистрируется.
когда появится вторая - начинается неприятная возня с ручным разруливанием
покажите псевдокод, в котором успешная оплата переводит статус оплаты заказа в "оплачено", а в случае если от банка приходит отказ, то статус оплаты заказа не меняется, а выводится ошибка.
судя по той одной большой цепочке вызовов, что я увидел в статье, это будет проблемой.
или нет?
Покажите как будет выглядеть в коде обработка 3х состояний, например, processPayment (успех, отказ, обнаружен фрод).
Ветки обработок каждого этого состояния как будут выглядеть в коде?
В паре с этим эффектнее
Здесь Сибирь, а не Урал, но не думаю что это хоть сколько-нибудь важно
Именно так.
Perception is reality.
В худшем случае вы дадите социально одобряемый ответ, и покажетесь "своим".
В лучшем - вы сделаете пометку, что это не самый оптимальный способ, разбирались, знаете нюансы, сейчас продемонстрируете... и либо пройдете тест на "своего" (ага, мы тоже знаем!), либо удивите и продемонстрируете экспертизу, после чего решение по найму на этом этапе будет де-факто принято.
Как продавать это менеджерам которые не в состоянии видеть ничего дальше 1 спринта? Они не видят общего роста производительности, они видят что сегодня ты че то там думаешь, а мог бы и код писать
Спасибо!
Сегодня столкнулись с тем что импорт вдруг внезапно сломался.
Благодаря тому что читал вашу статью, вспомнил, быстро починили.
эпическая подборка высказываний.
вот такие кадры и остались: ты ему "наклей стикер, если хочешь чтобы компания улучшила тебе условия труда чтобы тебя удержать", а он посчитал это "гомосятиной", обозвал всех дебилами и... перекрестился :)
словно из Салтыкова-Щедрина выписывали
корзина - это идентификатор продукта x количество + какой бы то ни было пэйлоад сверху. называйте как угодно, от сути не убежите
называйте как угодно, от сути не убежите
и что еще хуже, скорее всего и каждое предложение (quotation) индивидуально, и проходит через сэйлзов, и именно поэтому важно отделять его от заказа, инвойса и корзины. называйте как угодно, от сути не убежите
именно поэтому важно его атомарно записывать, и отделить от заказа, чтобы иметь возможность построить любой отчет для любого клиента с любой стороны прилавка
любой из приведенных 4 этапов можно назвать хоть Сюзанной и раздробить еще на 48 дополнительных, но убрать один = выстрелить в панду
/offtop
Дочитал до "НДС - это свойство заказа".
НДС (и подобные налоги) применяется к инвойсу.
Инвойс создается из заказа.
Заказ - из предложения (quotation).
Quotation из корзины.
Каждый раз, когда программист пытается экономить время на всем этом "неважном" - при первом "у нас появилась скидка/промокод" умирает панда.
это настолько слухи, что аж легенды.
или даже мифы
И что такого важного может сделать HR, кроме как пожать плечами и сказать "ну да, мой тоже, работаю как-то"?
Я вполне четко задал вопрос и он был не в том, как декомпозировать задачу
чтобы внести в спринт нужно оценить.
как оценивать "ищу варианты решения" и уложиться в дедлайн? нужно дать обещание неизвестного и уложиться в него
Google (или любой Google ***) это проект? Когда закончат?
втыкаемся в эту проблему.
заказчик захотел
пм с дизайнером нарисовали макет
макет приносят команде на оценку по срокам
разработчику ставят задачу на оценку. эта задача выполняется в течение спринта рядом с обычными
разработчик оценивает
к оценке добавляется x запаса
если не отказались от идеи, увидев оценку - задачу ставят на разработчика, дедлайн = оценка
это тоже ломается об r&d
как оценивать решение задачи неизвестным образом - неизвестно. можно было бы закладывать время на "попробовать варианты абв и выбрать", но для этого нужно комплексно продумать каждый
оценку надо успеть выдать к следующему диалогу ПМа с заказчиком, чтобы они договорились о приоритетах
во время работы по задаче можно придумать лучшее решение, чем то что заложено в оценке. лучшее не значит более быстрое, а значит что в будущем поможет с другими задачами, емли заложиться в нее сейчас
на одной неделе тебе дают задачу x, а через еще две - x'. для решения задачи x не вводили новых сервисов/слоев, а для x' уже не получится. можно было сразу делать инфраструктуру для x', чтобы потом быстро закрыть обе задачи, но не вышло. теперь тебе нужно переносить x на x'. системно не решаемо, тк ПМ не может обобщить