Я понял, у вас какая-то личная боль при проведении собеседований. Слишком много людей приходится отсеивать. У меня же аналогичная проблема — я не могу физически успеть спросить во всех вакансиях без зарплаты — какая у них зарплата. Откликаюсь на самые интересные и говорю свою цену. С вакансиями, где зарплата указана — гораздо проще. Поэтому и говорю об экономии времени. И вот эти пляски как в диалоге в статье (у меня тоже такие были) — выглядят глупо.
Мне не обидно, когда я не прохожу собеседование. Я ведь ничего не теряю. Просто не подошел конкретной компании и остаюсь при своей работе.
У меня была лютая жесть. Попалась вакансия, интересное тестовое, сделал, отправил. Неделю молчат, я пишу — ну что как? Мне в ответ — нам некогда проверять тестовые. С тех пор тестовые не делаю.
пока нет реальной оценки вашей квалификации — не может быть никаких конкретных обещаний по зарплате
Со стороны работодателя реальной оценки и не будет. Однажды я проходил собеседование в одну и ту же компанию два раза (филиал в США и филиал в России, они не знали друг о друге, так случайно вышло, сам не ожидал, когда пригласили на второе и решил не отказываться) — первым понравился, вторым нет. Собеседование — очень тонкая материя.
Со стороны соискателя — у меня есть текущая работа и зарплата. Дополнительно она подтверждается тем, что я прохожу регулярно собеседования в других компаниях на эту же сумму и некоторые из них мне делают офферы. Но очередной работодатель разумеется этому не верит. И заявляет что, пока я ему не докажу — я не стою своих денег. Какая-то уничижительная позиция. Нет, так не пойдет, пишите зарплату в вакансии — и я сам решу, откликаться или нет, а там уж выясним подходят мои скилы вашей компании или нет.
А все эти «зарплата после собеседования» — это все трата времени как работодателя, так и соискателя. И ограничения есть всегда, в каждой компании. Просто hr и работодатели зачастую не представляют, сколько программисты могут зарабатывать и считают, что их «баснословная» верхняя планка, допустим в 200 тр, которую они скрывают — это очень круто. Но в телефонной трубке программист, у которого сейчас 400. И выглядит это очень глупо.
На это можно посмотреть с другой стороны — сколько друзей люди заводят во взрослой жизни, живя в России, среди своих? Именно друзей, а не знакомых — кто поможет в трудную минуту, кому доверяешь, кто не предаст, с кем можно рвануть хоть на край света и т.п. У меня, например, все они еще со школьной скамьи. В универе, когда стал работать, когда создал семью — все новые контакты так и остались знакомствами разной степени близости и рано или поздно сводились на нет. Исключение составляют родители и близкие родственники супруги.
На УСН ничего такого не было. Когда перешел на патент, то налоговая один раз запросила у меня КУДиР — там было 4,5 млн. Я сначала напрягся, но дальше ничего не произошло, тьфу тьфу тьфу). Вообще есть такой параметр как налоговая нагрузка от оборота в процентах для отрасли (вот например www.klerk.ru/buh/articles/500900). Если налогов поступает меньше — налоговая начинает париться. Но к ней много вопросов. Айтишники с патентом по-любому должны не нравится налоговой. Банки же парятся при 2,5% от оборота, раньше было 0,9%
Имхо, обе позиции проигрышные. А если настраиваться на одинаковые зарплаты для конкретной вакансии, не зависимо от места жительства сотрудника — тогда вин-вин. Работодатель экономит на спичках, а вы 2-4 часа своей жизни каждый день.
Да, оно самое. Но для Москвы есть зарубежная удаленка. Мне попадались до 6-7 тыс в валюте, такие вакансии встретишь не часто даже в Москве. А вот жителям Сан-Франциско уже все) потолок.
Тоже считаю, что это спорное утверждение. Если сидишь в провинции, то работая на Москву можно спокойно зарабатывать как в Москве. Главное соответствовать.
менее оперативно взаимодействие с коллегами
Тоже спорное утверждение. Чем меньше отвлекаешь людей умственного труда (бизнес-аналитики тоже туда входят), тем эффективней они работают. Поэтому ИТ — это вообще, в целом, про асинхронное взаимодействие. Когда я давным-давно работал в офисе, я сначала спрашивал в аське — свободен ли человек, чтобы к нему подойти. Иначе смысл идти через два этажа в противоположное крыло здания. Простые вопросы решались сразу в аське. Хотя, соглашусь, порой требуется личное присутствие, чтобы обсудить действительно сложные задачи. Но скайпа с веб-камерой и еще некоторых инструментов вполне хватает, некомфортно, но хватает.
Требуется самоорганизованность
Это верно, но тут вопрос мотивации. Если человек лентяй/мажор/ему-ничего-не-надо-по-жизни, разумеется таким будет трудно. Но есть люди, которые хотят пользоваться материальными благами (квартира-не-в-ипотеку, машина, путешествия, дорогие хобби). И как думаете, что в таком случае лучше — ходить в офис за 30-50 тр/мес, или самоорганизоваться, найти удаленку и зарабатывать 150-300 тр/мес?
Нужно учитывать разницу во времени
Разница в 1-2 часа вообще не заметна. А разница в 8 часов — есть такая поговорка, чем дальше начальство, тем спокойней работается. Так вот, при разнице в 8 часов можно спокойно целый день делать задачи и никто тебя не отвлекает. А вечером показать демо руководителю проекта. Но, конечно же есть особенности — надо заранее задачи обсудить и составить план.
Эти штуки я не делал. Потому что по ту сторону сервисы, которые обещают 99% SLA. А если сеть упала на проде — то у меня проблемы посерьезней, чем недоступность сервиса погоды.
В тех случаях, когда у меня был значимый сервис для бизнеса — тот же ретрай обеспечивался очередью или hangfire-ом, а откат — транзакцией БД, но они базировались на логике исключений (причем любых, не только во время обращения к внешним сервисам). В итоге обращение к сервису все равно было тривиальное, а вот, скажем так, «инфраструктурная» (не бизнесовая) обработка результата операции — не совсем.
Если же прям очень надо вот это все рядом с сервисом, я бы думал в сторону отделения этой инфраструктурной логики, чтобы ее можно было навесить на обращение к любому внешнему сервису. Это уже некий архитектурный шаблон, который надо будет тестировать отдельно.
Обращение к внешнему сервису я оборачиваю классом оберткой. Внутри либо try catch с возвратом null/default, либо проброс исключения наверх.
Смысла тестировать этот код юнит-тестами с моками я не вижу. Получится тестирование моков. Интеграционный с реальным вызовом по http у меня идет даже больше как песочница, где я могу быстро пощупать сервис.
А вот как бизнес-логика работает с хорошим/плохим ответом от внешнего сервиса — там да. Но там у меня тоже интеграционные + моки на вот эти классы-обертки.
Тоже пришел к примерно таким же выводам, как и в статье.
Юнит-тесты слишком мелкие и хрупкие, но они отлично подходят для тестирования каких-нибудь алгоритмов и расчетов. Т.е. там где чистый код на языке программирования, без вызовов внешних систем/БД и так далее. Для таких случаев я их и использую. Моки в 95% там и не нужны.
В основном я пишу интеграционные (функциональные).
На одном из проектов видел следующий подход — утилита, которая кидается http запросами к web api. Утилита самописная, тесты оформляются в виде внешних json файлов. Оставляя удобство за скобками — мне этот подход не очень понравился. Это было больше похоже на smoke тестирование, нежели проверку конкретных сложносоставных кейсов.
Я же выбрал несколько другой — интеграционные тесты на бизнес-логику и все что ниже (обращения к БД). БД я подготавливаю специальным образом. Раньше делал восстановление БД перед тестами, в последнее время перешел на запуск тестов в транзакциях с откатом. Активно использую атрибут TestCase из NUnit, чтобы натравить на один блок кода несколько различных кейсов. Вызовы внешних чужих сервисов (погода, гео-кодинг и тому подобные) обычно делаю через моки. При таком подходе не надо поднимать целый веб-сервис. Достаточно зарезолвить из контейнера экземпляр тестируемого бизнес-кода. Но минусы все равно есть — такие тесты менее хрупкие, но не защищены от изменений структуры моделей и dto. Зато отлично защищают при рефакторинге и доработках.
Для тестирования обращений к внешним вызовам — пишу отдельные интеграционные тесты. Там непосредственно вызывается некий сервис по http. Эти тесты в отдельной сборке и не включены CI/DC, чтобы не тратить бабло платных внешних сервисов при каждом прогоне.
И еще надо взять за основу правило: пришел баг в техподдержку — дописал тест.
То, что вы описали — это не юнит-тест. О чем в статье и говорится:
Любопытно, что некоторые разработчики в подобных ситуациях в конечном итоге всё-таки пишут интегральные тесты, но по-прежнему называют их юнит-тестами.
Единственное, что плохо делает монолит — это скейлится
Причем в данном случае масштабируется довольно хорошо — под каждую пиццерию выделенная виртуалка с копией монолита. Тем самым решается куча вопросов:
Отказоустойчивость — упавшая одна виртуалка никак не влияет на все остальные 599
Надежность — все обращения в рамках одного «физического» компьютера, нет обращений по сети. Опционально можно разве что разбить сервер-приложений и сервер-БД
Распределение нагрузки — думаю такой выделенный монолит легко выдержит нагрузку с одной пиццерии
Своего рода CDN — для Владивостока виртуалка поднимается в дата центре во Владивостоке
Тестировать обновления — можно только на одной машине, опять же все остальные спокойно работают
Можно вообще подумать в сторону копии в самой пиццерии с синхронизацией в облако — тогда отсутствие интернета не застопорит работу пиццерии. Но тут конечно больше вопросов, чем ответов
Можно даже распределить финансовые затраты — стоимость аренды сервера вешается на пиццерию
Проблем сходу видно три:
Пользователи — должны иметь сквозной идентификатор, потому что один и тот же человек может приехать в другой город и заказать пиццу там — вот для них надо выделить общую базу
Консолидированные отчеты по всем пиццериям — но тут достаточно сливать все данные из всех мастеров в одну отдельную БД с такой же структурой и поменять строку подключения в админке
Обновление всех этих монолитов, но с микросервисами такая же фигня
Если есть понимание, что проект дальше определенного состояния не пойдет и ему будет достаточно написать код в контроллерах или хранимках и без тестов — то никто не запрещает этого делать. Даже наоборот, не будет лишней сложности. Или, например, будут использованы внутренние инструменты СУБД, которые для данной задачи будут подходить лучше.
Но главная проблема в изменчивости требований. С опытом начинаешь понимать, что есть неиллюзорный шанс однажды все переписать. Очень не хочется этого делать. Ни мне, как программисту, ни бизнесу. Отсюда все эти — «На одну кнопку две недели? Как??!!!». И поэтому подкладываешь соломку заранее. Где-то по простому — сразу не пишешь код в контроллерах или хранимках, потому что это дешево. Где-то оставляешь задел на вероятное будущее, которое может и не наступить. А заранее это делать дорого, да и есть более важные задачи. Все эти решения принимаются на основе опыта, видимого потенциала конкретного проекта и деадлайнов.
Пожалуй единственная категория проектов, где было все (или почти все) заранее известно — это для гос. учреждений по водопаду. На моей практике — такие проекты никогда серьезно не развивались. Их либо выкидывали совсем, либо заменяли другими. Я там мог сложить бизнес логику в хранимки и 5-10 лет это никого бы не парило.
А когда дело касается государственной машины — там полный ахтунг. Когда на сайте суда написано, что можно подать иск в электронном виде. Ты его подаешь через ГАС Правосудие, а потом Почтой России приходит определение суда, что иск должен быть на бумажном носителе. Или когда обжалование штрафа висит в суде и ждешь заседания, а ФССП списывает этот штраф с твоего банковского счета.
Мне, как программисту, эти дикие и очевидные противоречия сильно бросаются в глаза, а толпа людей по ту сторону — даже не замечают.
Я не про конкретную группу программистов, а про то, что в целом люди инженерных специальностей обладают аналитическим складом ума, а бизнес-аналитики и программисты-аналитики в ИТ еще и натаскиваются на проверку различных тест-кейсов. И это помогает разбираться в законах/медицине порой лучше основной массы юристов и врачей.
Я много раз попадал на врачей-джуниоров и крайне редко на врачей-сениоров. Один раз даже был «доктор хаус». Так вот последние — как раз смотрят на пациента в целом, анализируют информацию всесторонне насколько это возможно, а не лечат по протоколам, даже пальпацию проводят по иному. Как раз все то, о чем написано в статье.
Мне не обидно, когда я не прохожу собеседование. Я ведь ничего не теряю. Просто не подошел конкретной компании и остаюсь при своей работе.
Со стороны работодателя реальной оценки и не будет. Однажды я проходил собеседование в одну и ту же компанию два раза (филиал в США и филиал в России, они не знали друг о друге, так случайно вышло, сам не ожидал, когда пригласили на второе и решил не отказываться) — первым понравился, вторым нет. Собеседование — очень тонкая материя.
Со стороны соискателя — у меня есть текущая работа и зарплата. Дополнительно она подтверждается тем, что я прохожу регулярно собеседования в других компаниях на эту же сумму и некоторые из них мне делают офферы. Но очередной работодатель разумеется этому не верит. И заявляет что, пока я ему не докажу — я не стою своих денег. Какая-то уничижительная позиция. Нет, так не пойдет, пишите зарплату в вакансии — и я сам решу, откликаться или нет, а там уж выясним подходят мои скилы вашей компании или нет.
А все эти «зарплата после собеседования» — это все трата времени как работодателя, так и соискателя. И ограничения есть всегда, в каждой компании. Просто hr и работодатели зачастую не представляют, сколько программисты могут зарабатывать и считают, что их «баснословная» верхняя планка, допустим в 200 тр, которую они скрывают — это очень круто. Но в телефонной трубке программист, у которого сейчас 400. И выглядит это очень глупо.
А покажите пжл отдельно график «Зарплаты разработчиков по языкам программирования» для 1% самых высоких. Очень интересно, что там.
Тоже считаю, что это спорное утверждение. Если сидишь в провинции, то работая на Москву можно спокойно зарабатывать как в Москве. Главное соответствовать.
Тоже спорное утверждение. Чем меньше отвлекаешь людей умственного труда (бизнес-аналитики тоже туда входят), тем эффективней они работают. Поэтому ИТ — это вообще, в целом, про асинхронное взаимодействие. Когда я давным-давно работал в офисе, я сначала спрашивал в аське — свободен ли человек, чтобы к нему подойти. Иначе смысл идти через два этажа в противоположное крыло здания. Простые вопросы решались сразу в аське. Хотя, соглашусь, порой требуется личное присутствие, чтобы обсудить действительно сложные задачи. Но скайпа с веб-камерой и еще некоторых инструментов вполне хватает, некомфортно, но хватает.
Это верно, но тут вопрос мотивации. Если человек лентяй/мажор/ему-ничего-не-надо-по-жизни, разумеется таким будет трудно. Но есть люди, которые хотят пользоваться материальными благами (квартира-не-в-ипотеку, машина, путешествия, дорогие хобби). И как думаете, что в таком случае лучше — ходить в офис за 30-50 тр/мес, или самоорганизоваться, найти удаленку и зарабатывать 150-300 тр/мес?
Разница в 1-2 часа вообще не заметна. А разница в 8 часов — есть такая поговорка, чем дальше начальство, тем спокойней работается. Так вот, при разнице в 8 часов можно спокойно целый день делать задачи и никто тебя не отвлекает. А вечером показать демо руководителю проекта. Но, конечно же есть особенности — надо заранее задачи обсудить и составить план.
В тех случаях, когда у меня был значимый сервис для бизнеса — тот же ретрай обеспечивался очередью или hangfire-ом, а откат — транзакцией БД, но они базировались на логике исключений (причем любых, не только во время обращения к внешним сервисам). В итоге обращение к сервису все равно было тривиальное, а вот, скажем так, «инфраструктурная» (не бизнесовая) обработка результата операции — не совсем.
Если же прям очень надо вот это все рядом с сервисом, я бы думал в сторону отделения этой инфраструктурной логики, чтобы ее можно было навесить на обращение к любому внешнему сервису. Это уже некий архитектурный шаблон, который надо будет тестировать отдельно.
Смысла тестировать этот код юнит-тестами с моками я не вижу. Получится тестирование моков. Интеграционный с реальным вызовом по http у меня идет даже больше как песочница, где я могу быстро пощупать сервис.
А вот как бизнес-логика работает с хорошим/плохим ответом от внешнего сервиса — там да. Но там у меня тоже интеграционные + моки на вот эти классы-обертки.
Юнит-тесты слишком мелкие и хрупкие, но они отлично подходят для тестирования каких-нибудь алгоритмов и расчетов. Т.е. там где чистый код на языке программирования, без вызовов внешних систем/БД и так далее. Для таких случаев я их и использую. Моки в 95% там и не нужны.
В основном я пишу интеграционные (функциональные).
На одном из проектов видел следующий подход — утилита, которая кидается http запросами к web api. Утилита самописная, тесты оформляются в виде внешних json файлов. Оставляя удобство за скобками — мне этот подход не очень понравился. Это было больше похоже на smoke тестирование, нежели проверку конкретных сложносоставных кейсов.
Я же выбрал несколько другой — интеграционные тесты на бизнес-логику и все что ниже (обращения к БД). БД я подготавливаю специальным образом. Раньше делал восстановление БД перед тестами, в последнее время перешел на запуск тестов в транзакциях с откатом. Активно использую атрибут TestCase из NUnit, чтобы натравить на один блок кода несколько различных кейсов. Вызовы внешних чужих сервисов (погода, гео-кодинг и тому подобные) обычно делаю через моки. При таком подходе не надо поднимать целый веб-сервис. Достаточно зарезолвить из контейнера экземпляр тестируемого бизнес-кода. Но минусы все равно есть — такие тесты менее хрупкие, но не защищены от изменений структуры моделей и dto. Зато отлично защищают при рефакторинге и доработках.
Для тестирования обращений к внешним вызовам — пишу отдельные интеграционные тесты. Там непосредственно вызывается некий сервис по http. Эти тесты в отдельной сборке и не включены CI/DC, чтобы не тратить бабло платных внешних сервисов при каждом прогоне.
И еще надо взять за основу правило: пришел баг в техподдержку — дописал тест.
Причем в данном случае масштабируется довольно хорошо — под каждую пиццерию выделенная виртуалка с копией монолита. Тем самым решается куча вопросов:
Проблем сходу видно три:
Но главная проблема в изменчивости требований. С опытом начинаешь понимать, что есть неиллюзорный шанс однажды все переписать. Очень не хочется этого делать. Ни мне, как программисту, ни бизнесу. Отсюда все эти — «На одну кнопку две недели? Как??!!!». И поэтому подкладываешь соломку заранее. Где-то по простому — сразу не пишешь код в контроллерах или хранимках, потому что это дешево. Где-то оставляешь задел на вероятное будущее, которое может и не наступить. А заранее это делать дорого, да и есть более важные задачи. Все эти решения принимаются на основе опыта, видимого потенциала конкретного проекта и деадлайнов.
Пожалуй единственная категория проектов, где было все (или почти все) заранее известно — это для гос. учреждений по водопаду. На моей практике — такие проекты никогда серьезно не развивались. Их либо выкидывали совсем, либо заменяли другими. Я там мог сложить бизнес логику в хранимки и 5-10 лет это никого бы не парило.
Мне, как программисту, эти дикие и очевидные противоречия сильно бросаются в глаза, а толпа людей по ту сторону — даже не замечают.
Я много раз попадал на врачей-джуниоров и крайне редко на врачей-сениоров. Один раз даже был «доктор хаус». Так вот последние — как раз смотрят на пациента в целом, анализируют информацию всесторонне насколько это возможно, а не лечат по протоколам, даже пальпацию проводят по иному. Как раз все то, о чем написано в статье.