А как сейчас с работой?
Тебя с пенсии гонят на работу? :)
------
До этого замечательного момента еще есть некоторое время.
И, в принципе, его собираются хорошенько увеличить... на 15 лет уже сделали...
только что вышел из
-----
Не обязательно.
Достаточно просто работать... скажем... с имплементацией сервисов для Б-2-Б - там все актуально, но фронта вообще нет
Так что unit testing - must have.
------
Да. Для конторы.
Но совсем не обязательно это уметь на профессиональном уровне фронтеру, мидлу или бакеру.
SQL у них тоже в nice to have
-----
И откуда такие выводы?
Им нужет back end разработчик.
-----
Не вижу оснований для данного вывода.
В результате сам остался без потенциального места работы ;)
-----
Это не моя работа - шарага из "серого" списка.
Вполне может быть, что в реальности столько не требуется
-----
Ну и нахрена тогда писать столько?
Написали бы что именно требуется - люди бы себя точнее оценили применительно к позиции.
А с "запасом" в среде где технологии меняются почти за время вхождения в тематику - это даже не верх тупости.
Будет чел год закрывать тикеты в баг-трекере.
-----
По всему списку закрывать тикеты 4-х леток не сможет.
Тем более что ему еще скрамить толпу абалдуев...
Так свяжитесь с ними и узнайте.
-----
С кем? С рекрутером?
Так там больше чем написано информации нет.
Да и то что написано чел может и не понимать совсем...
они согласны и с 4 годами опыта взять
-----
Именно это и означает, что им годен кто-то, кто 4 года назад узнал как делать "Херов Ворлд!" на соответствующем инструменте и что-то на нем делал эти 4 года.
Проблема - за 4 года работы (не профильного обучения, а работы) инструмент не изучается в достаточно глубоко - изучается только то что надо по работе.
И таких инструментов там перечислено... хммм... много. Если на каждый отвести по 4 года работы, то получится... пенсионер. 
Ооо... еще одна позиция:
•3+ years of experience developing AI enabled applications (experience in equivalent web or distributed applications will be considered).
Кто нибудь возмется объяснить как АИ можно заменить вебом или дкомом?
Но это из совсем дурной шараги - там даже название меняют - на старое, видимо, вообще никто не соглашается даже смотреть...
Но совсем не обязательно это уметь на профессиональном уровне фронтеру, мидлу или бакеру.
Это совершенно обязательно. Тут даже говорить не о чем :) Понимать модульное тестирование и уметь писать тесты - must have для разработчика.
И откуда такие выводы?
Большинство описаний вакансий построены по одной схеме:
- описание фирмы
- описание обязанностей
- must have скилы
- nice to have скилы
- контакт рекрутера
Так что в описанной тобой вакинсии скилы must have отделены от nice to have. SQL там в блоке nice to vahe.
По последней знаю что предлагают 350/день на работах где платят 550/день... туда народ идет только от полного безденежья с безработицей.
350 в день - 7700 pro Monat (22 Arbeitstäge)? Пусть даже брутто - дофигище деньжищь. Вы, наверное, просто привыкли к огромным зарплатам как в Гугле? )))
Но требования при этом не снижаются? Т.е. платят существенно меньше, а всяких середняков всё равно не берут? Ищут отчаявшихся сеньоров фуллстек-ниндзя? Так их по определению отчаявшихся быть не может - они же все типа нарасхват и "не их выбирвают - они выбирают"?
Это совершенно обязательно. Тут даже говорить не о чем :) Понимать модульное тестирование и уметь писать тесты - must have для разработчика.
Настолько понимают, что хвастаются процентов покрытия кода юнит-тестами - чем ближе к 100, тем круче считается. А если далеко от 100, то уже не Test Driven Development. Поэтому приходится писать тесты даже на примитивные элементарные функции, для которых и так понятно, что они правильно работают. Ну и в результате быстро приходят к проблеме, что раньше, без 100% покрытия тестами писал один код, а теперь чуть ли не в 2-3 раза больше надо (хорошее покрытие тестами может в разы превышать основную кодовую базу). При этом тесты - тоже программы, только как бы маленькие, скриптовые. Но кто будет гарантировать их правильность? Где тесты для тестов? Если вы такой крутой, что можете все кейсы предвидеть и отработать в тестах, то вы сразу и в коде можете это предвидеть и отработать - зачем тогда тесты? По мне юнит-тесты должны проверять только важные вещи, т.е. подход Test Driven Development является очередным вредным максимализмом, когда фанатики доводят что-то до абсурда и начинают других заставлять делать так же.
Я уже не говорю о том, что тесты должны обновляться вместе с кодом. Поправил, условно говоря, кнопочку на один пиксель - обнови тесты, документацию и прочее. А потом начинается "да это же за 5 минут сделать можно! почему ты возился 2 дня?".
Как я понимаю, в юнит-тестах должны все кейсы отрабатываться и проверяться. В том числе бросаются ли исключения и какие при разных аномальных данных. Верно?
Большинство описаний вакансий построены по одной схеме:
- описание фирмы
- описание обязанностей
- must have скилы
- nice to have скилы
- контакт рекрутера
Так что в описанной тобой вакинсии скилы must have отделены от nice to have. SQL там в блоке nice to vahe.
Обычно если нет 100% совпадения со всеми найс и маст, то "мы вам перезвоним..." - т.е. ты просто зря теряешь время. А точнее, ваше резюме будут откладывать от тех, у кого в нём 100% совпадение, даже если это ложь. Скромные в этом мире не нужны. Миром правят любители и неподготовленные, приписавшие себе кучу способностей, которыми они не обладают.
Satya Nadella Cortana Demo Epic Failure (Funny Video) - YouTube
В комментах там тоже не понимают, что он говорит. Но видно, что для того, чтобы управлять одной из самых дорогих компаний в мире, не обязательно хорошо знать английский, в том числе иметь хорошее произношение. Можно даже проваливать важные презентации и не готовиться к ним заранее, чтобы предвидеть подобные ситуации.
Если вы такой крутой, что можете все кейсы предвидеть и отработать в тестах, то вы сразу и в коде можете это предвидеть и отработать - зачем тогда тесты?
Я единственный смысл в подобных подробных тестах вижу лишь в командной разработке, да ещё когда команда довольно часто меняет состав. Т.е. когда код передаётся из рук в руки, в том числе менее опытным разработчикам. Тогда да - один раз написанный тест более опытным разработчиком является как бы документацией и одновременно валидацией кода, написанного менее опытным или пришедшим новичком, которые пока ещё не "въехал" в работу.
Но опять же, почему тесты подменяют документацию? Кто будет следить за правильностью и актуальностью гениально написанных тестов, если гений уволился или занялся другим кодом? Т.е. такой подход может работать, если гений постоянно в фирме и за всем следит.
О, кстати Не верь всему, что пишут на хабре / Habr
Только это не про вас - вы же уже опытный?
Там жалуются, что не то, что на работу не берут, а даже на собесы не зовут. Вообще никак на резюме не отвечают.
Особенно умиляют подобные комменты
Ерунда. К нам пришел парень 44 лет джуном на С++ разработку в довольно наукоемкую область из сферы никак не связанной с программированием, сейчас тащит получше некоторых. Просто ему интересно, как мне было интересно в 20 лет изучать программирование и алгоритмы.
Бац - пришёл джун 44 лет без бэкграунда в программировании, бац - взяли.
А как сейчас с работой?
"в сша в Чикаго например дефицит погромистов и иммигранты из экс-СССР стран (таксисты и водители траков) за полгода переучиваются сначала на тестировщиков ПО (зп $60k в год), потом выучивают жаву и становятся спецами по selenium QA Automation (зарплата $90к в год), а потом и в полноценные ява бекендеры на спрингбуте ($120k в год) переходят — это люди, которые год назад крутили баранку, а потом пишут код который перетаскивает джейсоны из фронта в бекенд."
20-летние сеньоры накодили. И где тесты, проверки перед релизом, вся эта муть, что спрашивают на собесах?
YouTube video volume resetting to 100% or max on website? (piunikaweb.com)
У меня на телеке громкость высоко стоит, а на ютубе - низко. Я аж подпрыгнул, когда сегодня первый ролик открыл.
Кто нибудь возмется объяснить как АИ можно заменить вебом или дкомом
Ну так это не R&D позиция, скорее всего. Вполне возможно, что у них есть что-то, где они используют AI (в каком-то виде) и нужен погромист, работающий с этим. Видел уже не мало таких описаний.
что хвастаются процентов покрытия кода юнит-тестами - чем ближе к 100, тем круче считается. А если далеко от 100, то уже не Test Driven Development.
Ну если цель - дойти до 100%, то из такой конторы надо валить :) Эти люди не понимают того, чем занимаются. Либо это какая-то специфическая сфера. У меня знакомый работает в фирме и они делают тесты для СуперДжета. У них покрытие около 98%. При этом на 600кБ исходного кода приходится больше 55Мб тестовых скриптов. Так что софт для самолетов/вертолетов или каких-то особенно чувствительных частей медицинского оборудования стремление к 100% покрытию оправдано. Вменяемые конторы стремятся к 70-80% покрытию. Стоимость покрытия больше этого уровня растет по экспоненте.
Где тесты для тестов?
:) А потом еще тесты для тестов тестов :)
Если вы такой крутой, что можете все кейсы предвидеть и отработать в тестах, то вы сразу и в коде можете это предвидеть и отработать - зачем тогда тесты?
1) тесты нужны для надежности, т.е. чтобы быть уверенным, что кто-то случайно не изменил поведение.
2) тестами описывается спецификация. так что нет необходимости предвидеть все кейсы. и уж тем более нет необходимости предвидеть все кейсы на стадии программирования ;)
По мне юнит-тесты должны проверять только важные вещи, т.е. подход Test Driven Development является очередным вредным максимализмом, когда фанатики доводят что-то до абсурда и начинают других заставлять делать так же.
Юнит-тестами описываются требования спецификации. Плюс к этому юнит-тесты - способ документации из серии how to.
Серебрянной пули не существует :) А сходить с ума можно по любой технологии.
Я уже не говорю о том, что тесты должны обновляться вместе с кодом.
Ну вообще говоря нет.
Как я понимаю, в юнит-тестах должны все кейсы отрабатываться и проверяться. В том числе бросаются ли исключения и какие при разных аномальных данных. Верно?
Нет, не верно. Юнит-тесты проверяют работу твоего кода. Т.е. если твой код не отлавливает никакие специфические исключения, то нет смысла тестировать реакцию на них. И если у тебя
try
{
...
}
catch (Exception ex)
{
...
}то нет никакого смысла делать больше одного теста с любым исключением ;)
Вменяемые конторы стремятся к 70-80% покрытию. Стоимость покрытия больше этого уровня растет по экспоненте.
Тогда это уже не Test Driven Development? При последнем ты сначала пишешь тесты, а потом код к ним. Если тесты покрывают только 70-80%, то получается, что ты потом кучу кода дописываешь без тестов. Не лучше ли тогда сначала код писать, а потом к нему тесты?
А ещё обычно начинается всё чинно, по методологиям, а потом аврал и на всё плюют - лишь бы успеть код нафигачить.
:) А потом еще тесты для тестов тестов :)
В идеале круг должен замкнуться.
Я уже не говорю о том, что тесты должны обновляться вместе с кодом.Ну вообще говоря нет.
Если у вас тесты первичны и играют роль, как вы сказали, спецификации, то нет. А если сначала код, а потом тесты - то да.