Может и о десятиминутных стендапах, ревью кода заказчика спрашивать — можно или нет их проводить? Ведь это трата времени не на реализацию фич, а на то, чтобы поболтать! Какая тут помощь бизнесу, прохлаждаться хотят…
Написание юнит тестов приводит к лучшему пониманию что надо писать
Имеете в виду качество кода? Имхо, после некоторой практики оптимальная структура кодовой базы сама пишется. :)
Юнит тесты объясняют как должен работать код
Это актуально, если модуль, который обложили юнит-тестами, выполняет какие то сложные вещи, ну например умные подсчеты.
Если брать стандартный ынтырпрайз (и соц сети ;)), где сервис сервисом погоняет и только перекладывает данные из одной структуры в другую, то юнит-тесты здесь не нужны. Код сам за себя все говорит, а функциональные тесты просто подтверждают, что все четко.
Предположу, что очень дорого писать первый тест и поддерживать инфраструктуру е2е тестов (отлавливать гейзен баги, разбираться, почему падают тесты).
Сейчас работаю над соц. сетью написанной на скале, есть 500 селениум тестов, которые кроют всю функциональность ui (весьма сложную, написанную на ангуляре). Сбоев нет (были, но разобрались почему и исправили инфраструктуру).
Как долго писать тест на селениуме у нас? Примерно за время написания двух-трех юнит-тестов.
Но мы кроем всю функциональность юнит-тестами. Для меня это нецелесообразно и затрудняет рефакторинг, потому что все основные юз кейсы кроют селениум тесты.
В своих проектах у меня есть только селениум тесты и интеграционные тесты апи за исключением border-cases. Например, надо проверить, что в апи, который выдает список сущностей параметр count не должен превышать 100 элементов, если пришло больше — юзаем значение 100. Для таких случаев пишется юнит-тест.
Результат: фактически покрыто 100% юз кейсов, свобода рефакторинга, меньше времени тратится на разработку (в том числе за счет написания малого количества тестов).
Все таки понимание целей проекта ортогонально скиллам менеджера (технические/не технические).
Вопрос в выдержке, силе воли, желанию в конце концов вывести проект в продакшн. Точно так же и обычные менеджеры могу запороть проект.
Нет. Заводите счет физ лица, на который будете переводить извне деньги и регистрируйте его в налоговой. Только гарантируйте, что через этот счет не проходят другие деньги — иначе налоговая их может интерпретировать как доход.
Подробности: гугл и звонок в налоговую.
Еще раз. Не обязательно, чтобы заработанные деньги приходили на счет юр. лица. Главное, чтобы налоговая знала, что на тот счет физ. лица приходят заработанные деньги.
Можете погуглить или позвонить в налоговую, если не верите.
Но, фактически, приемлемым вариантом для жителей СНГ является только один — Payoneer. Прямые платежи не пропускают банки из-за необходимости юридически правильного контракта от заказчика, который сделать довольно сложно и такие сложности не оправданы для маленьких проектов — PayPal на вывод средств в СНГ не работает.
Работаю на Одеске, живу в России, вывожу доллары на счет физического лица в Альфе, который зарегистрирован в налоговой и пенсионном.
Вопросов со стороны банка не возникало, и меня много раз уверяли сотрудники на поддержке, что к счетам физ лица не применяются блокировки денег.
Комиссии: $30 за перевод с одеска… и все.
Я вообще придерживаюсь мнения, что чистые РП ну очень редко где нужны.
Командам нужен сильный тим-лид, у которого одинакого круто прокачаны софт и тех скилы.
Я много раз видел людей на должности РП, выросшие из программистов, и это были мягко выражаясь никудышные технари, навязывающие разработчикам как делать им работу, естественно не самым лучшим способом. Про их код вообще молчу.
Сроки дают разработчики. Их может считать и РП при условии, что разработка совсем типовая.
Требования утрясаются путем узнавания use cases пользователей. Технического бэкграунда тут не надо (я не вижу по крайней мере).
Задача на умение проектировать БД проверяет только умение проектировать БД. Если нужно мышление проверить, ну предложите ему поанализировать задачу с крайне расплывчивыми формулировками. Пусть попробует конкретизировать.
Вы скажете, что для рисования структуры БД должен быть системный архитектор? Возможно, но не на уровне задачи на собеседовании. В проекте – да! Но уровень задачи на собеседовании аналитиком должен решаться.
А зачем давать задачу на собеседовании, которую в реальности решать не надо и вообще опыта иметь не нужно в этой области?
Вы же не тим-лида ищете, который еще и за разработку отвечать будет.
Роль чистого РП — анализ требований, переговоры с клиентом, утрясание сроков, тимбилдинг. При чем тут бд?
Не согласен. Необходимо потратить больше времени на парсинг этой кучи скобочек. Ну и код вида zip… zip… zip… zip… zip… вместо 1 вызова zip ничуть не добавляет читаемости.
Мы используем как раз implicit class с методами zip на все возможное количество аргументов.
Представьте лучше пример, где надо зипнуть 5-7 веток выполнения. ;)
Мне кажется, статья надуманная.
Я за свою карьеру в новосибирских фирмах и фрилансе встречал все возможные варианты: платят мало за rocket science, платят много за rocket science, платят мало за клепание формочек, платят много за клепание формочек. В том числе и случаи между этими четырьмя.
В общем, все зависит от тараканов в головах руководителей.
Например, откликался на один проект на одеске. Проект с нуля, чел чисто менеджер без технических скилов — хотел писать его на кложе. Объяснял тем, что сможет вырвать лучших спецов, потому что такие языки могут знать только лучшие. И при этом планировал платить копейки за проект — типа плата за крутой проект в резюме.
Достаточно много проектов на фрилансе, которые можно получить за рейт 50-60 баксов, при этом там голая джава и попахивает ынтырпрайзом, но руководитель хочет получить лучших из лучших, ставя рейт в приоритете.
Тут все сложно, имхо. Если чел реально ничего не хочет, его никто не обучит.
Но если чел готов учиться, но тупо не знает, чему можно учиться и зачем, ментор очччень будет кстати показать, куда можно двинуть, и что это даст.
Имеете в виду качество кода? Имхо, после некоторой практики оптимальная структура кодовой базы сама пишется. :)
Это актуально, если модуль, который обложили юнит-тестами, выполняет какие то сложные вещи, ну например умные подсчеты.
Если брать стандартный ынтырпрайз (и соц сети ;)), где сервис сервисом погоняет и только перекладывает данные из одной структуры в другую, то юнит-тесты здесь не нужны. Код сам за себя все говорит, а функциональные тесты просто подтверждают, что все четко.
Сейчас работаю над соц. сетью написанной на скале, есть 500 селениум тестов, которые кроют всю функциональность ui (весьма сложную, написанную на ангуляре). Сбоев нет (были, но разобрались почему и исправили инфраструктуру).
Как долго писать тест на селениуме у нас? Примерно за время написания двух-трех юнит-тестов.
Но мы кроем всю функциональность юнит-тестами. Для меня это нецелесообразно и затрудняет рефакторинг, потому что все основные юз кейсы кроют селениум тесты.
В своих проектах у меня есть только селениум тесты и интеграционные тесты апи за исключением border-cases. Например, надо проверить, что в апи, который выдает список сущностей параметр count не должен превышать 100 элементов, если пришло больше — юзаем значение 100. Для таких случаев пишется юнит-тест.
Результат: фактически покрыто 100% юз кейсов, свобода рефакторинга, меньше времени тратится на разработку (в том числе за счет написания малого количества тестов).
Вопрос в выдержке, силе воли, желанию в конце концов вывести проект в продакшн. Точно так же и обычные менеджеры могу запороть проект.
Подробности: гугл и звонок в налоговую.
Можете погуглить или позвонить в налоговую, если не верите.
Работаю на Одеске, живу в России, вывожу доллары на счет физического лица в Альфе, который зарегистрирован в налоговой и пенсионном.
Вопросов со стороны банка не возникало, и меня много раз уверяли сотрудники на поддержке, что к счетам физ лица не применяются блокировки денег.
Комиссии: $30 за перевод с одеска… и все.
Командам нужен сильный тим-лид, у которого одинакого круто прокачаны софт и тех скилы.
Я много раз видел людей на должности РП, выросшие из программистов, и это были мягко выражаясь никудышные технари, навязывающие разработчикам как делать им работу, естественно не самым лучшим способом. Про их код вообще молчу.
Требования утрясаются путем узнавания use cases пользователей. Технического бэкграунда тут не надо (я не вижу по крайней мере).
Задача на умение проектировать БД проверяет только умение проектировать БД. Если нужно мышление проверить, ну предложите ему поанализировать задачу с крайне расплывчивыми формулировками. Пусть попробует конкретизировать.
А зачем давать задачу на собеседовании, которую в реальности решать не надо и вообще опыта иметь не нужно в этой области?
Вы же не тим-лида ищете, который еще и за разработку отвечать будет.
Роль чистого РП — анализ требований, переговоры с клиентом, утрясание сроков, тимбилдинг. При чем тут бд?
Мы используем как раз implicit class с методами zip на все возможное количество аргументов.
Представьте лучше пример, где надо зипнуть 5-7 веток выполнения. ;)
Как отслеживали эффективность? Какие были проблемы?
P.S. Собственно, тоже самое спрашивает GraDea, на пост которого Вы отвечаете.
Я за свою карьеру в новосибирских фирмах и фрилансе встречал все возможные варианты: платят мало за rocket science, платят много за rocket science, платят мало за клепание формочек, платят много за клепание формочек. В том числе и случаи между этими четырьмя.
В общем, все зависит от тараканов в головах руководителей.
Например, откликался на один проект на одеске. Проект с нуля, чел чисто менеджер без технических скилов — хотел писать его на кложе. Объяснял тем, что сможет вырвать лучших спецов, потому что такие языки могут знать только лучшие. И при этом планировал платить копейки за проект — типа плата за крутой проект в резюме.
Достаточно много проектов на фрилансе, которые можно получить за рейт 50-60 баксов, при этом там голая джава и попахивает ынтырпрайзом, но руководитель хочет получить лучших из лучших, ставя рейт в приоритете.
Но если чел готов учиться, но тупо не знает, чему можно учиться и зачем, ментор очччень будет кстати показать, куда можно двинуть, и что это даст.