Если вам понадобилось пооверять инициализированна ли переменная - поздравляю у вас повышеная цикломатическая сложность и стоит пересмотреть код.
То же и к проверке пропсов в объектах, где еще хоть както пииемлимо это если объектом управляешь не сам, а получаешь от вендора, но опять же рефлексия.... буееее
ищу 9 месяцев работу имея за спиной 9лет опыта в разработкe
9 лет стажа != 9 лет опыта
Занимаюсь наймом и проведением тех собесов последние три года. За прошлый год провел под сотню собесов и насмотрелся на таких "сеньоров-помидоров" (10-15 лет стажа) которые по резюме Лев Толстой, а по факту не могут ответить даже на базовые вопросы, на которые должен знать ответ даже джун. Причем я ни когда не спрашиваю того, чего бы не пригодилось в работе на требуемую вакансию.
С этими тремя ролями такая же путаница возникает как и с техлид, тимлид и менеджер разработки. Все зависит от размера компании и от того какие смыслы компария вкладывает в эти роли. По факту это может быть как один человек, так и 3. Очень часто в небольших компаниях на одного человека сгружают обязанности всех трех ролей и зовут его гордо тимлид.
Проблемы в позициях мидла и выше растут из того что люди путают что стаж != опыт (я проработал N лет, пора бы уже и ачивку сеньора на себя навешать, и не важно что кандидат перекладывал все эти N лет JSONчики) и забивают своими говнооткликами и такими же резюме открытые вакансии, работадатель в свою очередь идет на ухищрения что бы отсеять таких деятелей, от чего страдают реально скиловые кандидаты.
Я пошел немного другим путем когда переделывал формат тестового. Поскольку одна из задач это проведение ревью (а еще очень любят в резюме указывать что хорошо читаю и понимаю чужой код, могу пердложить оптимальный вариант) тестовое именно на проведение ревью и переписать имеющийся код. В исходном варианте 14 файлов, бизнесово значимых 5. Имеется задача, которая была дана изначально разраблтчику и список условностей. Задание для тестового звучит так - проведите ревью передоставленного кода, напишите замечания и по каким причинам их стоит исправить, предоставте исправленный вариант кода согласно проведенного ревью и вашего видения. Что могу сказать - многие плохо читают задание видят только "сделать ревью и исправить". Редкий кандидат напишет о пртчинах изменений. Почему это важно:
есть куски кода где была ошибка, его полностью переписывают, без указания причин
есть пару логических ошибок, при иправлении которых хотелось бы посмотреть на ход мысли и понимание почему нужно сделать так
иногда полностью все переписывают и вот тем более хотелось бы посмотреть на причины принятия решений.
Про ошибки в исходном коде: архитектурные, логияеские и есть 2 критически где упадем с фаталом, одна из них при опредкленных условиях, эти видны при просмотре кода.
Про ИИ - его прям в 90% случаев вид сразу же. Таким кандидатам я отказываю с формулиоовкой что это сгенерированно нейросетью. Остальным расписываю их ошибки и указываю на значемые не исправлемые в рамках тз.
Про размеры команды. Я руководитель бэкенд разработки, в подчинении 5 команд, 23-25 разработчиков.
Хехех. Вспомнил пару своих эпичных фэйлов, после одного меня все таки уволили.
Когда еще только начинал работать программистом работал в компании которая занимается продажей инструмента. Ни о каких CI/CD и прочих прелестях доставки изменений на прод и слыхать не слыхивал, да и понятий таких тогда еще не было. Под конец рабочего дня мне надо было выкатить изменения и в частности накатить миграции. Но я же решил перестраховаться и захотел сделать перед этим дамп базы, но то ли уставший, то ли просто затупил и вместо того что бы в вести в консоли mysqldump ввожу mysql -u -p < dump.sql и просто наливаю дамп который был сделан утром((( Как итог похерилось около 300 заказов, которые были сделаны за день через сайт, а на основе их ночью формируются заявки поставщикам, наряды на доставку, запускаются еще какие-то процессы. До полуночи с менеджерами сидели восстанавливали заказы по отбивкам из почты. Следующим днем меня уволили.
Второй факап случился несколько лет назад. Работал в компании которая разрабатывает продукт как для своего пользования (важный момент), так и продает его на рынок, как saas решение. Понадобилось затащить на прод профилирование, не спрашивайте почему)))), выбор пал на xhprof, был написан функционал который в качестве одного из аргументов принимает callback который по сути и выполняет весь рантайм приложения, и в коде было нечто вроде
function profiling(Closure $callback): void
{
if (extension_loaded('tideways_xhprof')) {
return;
}
//Тут проверки других условий нужно ли запускать профилирование
//Запускаем профилирование
tideways_xhprof_enable();
$callback();
//записываем результаты профилирования
file_put_contents();
}
profiling(
function (): void {
$application = new Application();
$application->run();
}
);
Через 5 минут после релиза клиенты начинают обрывать телефоны техподдержки, сыпать письмами в почту что ничего не работает и вместе приложения видят белый экран. В свою очередь мы в офисе понять ничего не можем, у нас все корректно открывается все работает. А проблема оказалось в том, что под сам сайт было выделено 5 нод, на одну, с офисного IP, идет трафик собственно с офиса, на остальные четыре распределятся остальной. И xhprof был установлен только на той, на которую ходят сотрудники компании и на стйджах, поэтому все тесты прошли нормально и задача уехала в прод. Ну и вся проблема ясна из кода, в первом пресловутом if'е вместо того что бы вызвать переданный callback мы просто завершаем выполнение. Тут меня не уволили, не депримировали. проблему нашли в течении пары минут после первого обращения мерж с фиксом еще пара минут. Дольше доставлялись изменения на прод, но это совсем другая история. Общее время простоя около 20 минут.
Делается через конфиг сервис контейнера. Условно мы говорим когда встречаешь этот интерфейс то для этого класса прикинь эту реализацию, а для этого вот эту.
Если не ошибаюсь то в ларе конструкция $container->when(кому требуется)->needs(что требуется)->give(тут уже что прокидываем)
В симфони через аргументы в конфиге.
К сожалению точный код не могу накатать, с телефона читал статью.
А какая может быть аргументация? Компания в которой есть свой it отдел, по какой-то причине нанимает человека после курсов и даёт ему сразу переписывать всё и вся без тз, которое он должен сформулировать на своё усмотрение, остальная же команда занимается правками багов, звиздежом попахивает.
У меня к автору несколько вопросов
кто в компании отвечает за конечный результат
есть ли хоть один сотрудник который имеет экспертизу и понимает каков должен быть конечный результат, понимает качество написаного когда и его масштабируемость после написания MVP?
кто общается с бизнесом выявляя потребности, боли и хотелки текущего состояния проекта? При этом проводя попутную аналитику?
насколько крупен проект, сколько транзакций (продаж) в месяц через ИМ, насколько крупен каталог? нужен ли вообще компании интернет магазин или он как во времена доткомов лишь бы был?
Но и у фулстека есть что-то от утки. Утка и ходит, и летает, и плавает, но все делает хреново. Как по мне лучше быть отличным специалистом в узкой области, чем по чуть чуть во многих.
Я правильно понимаю, вы пришли все пушистые, продали клиенту сопровождение и обслуживание, проработали маркетинговую компанию, судя по приросту заказов неплохую, но не удосужились собрать хоть какую-то статистику по производительности системы, посмотреть что куда ходит у вас, сколько запросов в БД на странице, не? Не говорю даже про какое либо минимальное нагрузочное тестирование.
А судя из текста у вас есть БД, в ней таблица раздутая по размерам с непонятными логами и это у вас не вызвало ни малейшего вопроса?
Мне просто интересен ход ваших действий при приёмке проекта в работу.
Мама я тимлид. Стоит прочесть, книга не даёт глубоких знаний, но она даёт понимание нужно ли тебе это, и если да то есть подсказки что ещё почитать и в какую сторону двигаться
Если вам понадобилось пооверять инициализированна ли переменная - поздравляю у вас повышеная цикломатическая сложность и стоит пересмотреть код.
То же и к проверке пропсов в объектах, где еще хоть както пииемлимо это если объектом управляешь не сам, а получаешь от вендора, но опять же рефлексия.... буееее
Статья из разряда "как делать не стоит".
9 лет стажа != 9 лет опыта
Занимаюсь наймом и проведением тех собесов последние три года. За прошлый год провел под сотню собесов и насмотрелся на таких "сеньоров-помидоров" (10-15 лет стажа) которые по резюме Лев Толстой, а по факту не могут ответить даже на базовые вопросы, на которые должен знать ответ даже джун. Причем я ни когда не спрашиваю того, чего бы не пригодилось в работе на требуемую вакансию.
С этими тремя ролями такая же путаница возникает как и с техлид, тимлид и менеджер разработки. Все зависит от размера компании и от того какие смыслы компария вкладывает в эти роли. По факту это может быть как один человек, так и 3. Очень часто в небольших компаниях на одного человека сгружают обязанности всех трех ролей и зовут его гордо тимлид.
Зачем? Чтобы войтивайти было легче.
Программист-вкатывальщик 2036 год:
Ну а какого совета вы ожидали от вчерашнего джуна, который сегодня стал "мидлом"?
Проблемы в позициях мидла и выше растут из того что люди путают что стаж != опыт (я проработал N лет, пора бы уже и ачивку сеньора на себя навешать, и не важно что кандидат перекладывал все эти N лет JSONчики) и забивают своими говнооткликами и такими же резюме открытые вакансии, работадатель в свою очередь идет на ухищрения что бы отсеять таких деятелей, от чего страдают реально скиловые кандидаты.
Я пошел немного другим путем когда переделывал формат тестового. Поскольку одна из задач это проведение ревью (а еще очень любят в резюме указывать что хорошо читаю и понимаю чужой код, могу пердложить оптимальный вариант) тестовое именно на проведение ревью и переписать имеющийся код.
В исходном варианте 14 файлов, бизнесово значимых 5. Имеется задача, которая была дана изначально разраблтчику и список условностей.
Задание для тестового звучит так - проведите ревью передоставленного кода, напишите замечания и по каким причинам их стоит исправить, предоставте исправленный вариант кода согласно проведенного ревью и вашего видения.
Что могу сказать - многие плохо читают задание видят только "сделать ревью и исправить". Редкий кандидат напишет о пртчинах изменений. Почему это важно:
есть куски кода где была ошибка, его полностью переписывают, без указания причин
есть пару логических ошибок, при иправлении которых хотелось бы посмотреть на ход мысли и понимание почему нужно сделать так
иногда полностью все переписывают и вот тем более хотелось бы посмотреть на причины принятия решений.
Про ошибки в исходном коде: архитектурные, логияеские и есть 2 критически где упадем с фаталом, одна из них при опредкленных условиях, эти видны при просмотре кода.
Про ИИ - его прям в 90% случаев вид сразу же. Таким кандидатам я отказываю с формулиоовкой что это сгенерированно нейросетью. Остальным расписываю их ошибки и указываю на значемые не исправлемые в рамках тз.
Про размеры команды. Я руководитель бэкенд разработки, в подчинении 5 команд, 23-25 разработчиков.
У меня из текста возникает вопросы
сколько ресурса лидов и технарей тратится при таком подходе?
сколько человек просебесите что бы нанять сеньора или лида с рынка?
испытательный срок как еще один этап - какой % его пооходят?
Ещё не приходилось реализовывать идемпотемптность, но всегда у меня возникает вопрос - по каким тригерам клиент должен генерировать новый ключ?
Хехех. Вспомнил пару своих эпичных фэйлов, после одного меня все таки уволили.
Когда еще только начинал работать программистом работал в компании которая занимается продажей инструмента. Ни о каких CI/CD и прочих прелестях доставки изменений на прод и слыхать не слыхивал, да и понятий таких тогда еще не было. Под конец рабочего дня мне надо было выкатить изменения и в частности накатить миграции. Но я же решил перестраховаться и захотел сделать перед этим дамп базы, но то ли уставший, то ли просто затупил и вместо того что бы в вести в консоли mysqldump ввожу mysql -u -p < dump.sql и просто наливаю дамп который был сделан утром((( Как итог похерилось около 300 заказов, которые были сделаны за день через сайт, а на основе их ночью формируются заявки поставщикам, наряды на доставку, запускаются еще какие-то процессы. До полуночи с менеджерами сидели восстанавливали заказы по отбивкам из почты. Следующим днем меня уволили.
Второй факап случился несколько лет назад. Работал в компании которая разрабатывает продукт как для своего пользования (важный момент), так и продает его на рынок, как saas решение. Понадобилось затащить на прод профилирование, не спрашивайте почему)))), выбор пал на xhprof, был написан функционал который в качестве одного из аргументов принимает callback который по сути и выполняет весь рантайм приложения, и в коде было нечто вроде
Через 5 минут после релиза клиенты начинают обрывать телефоны техподдержки, сыпать письмами в почту что ничего не работает и вместе приложения видят белый экран.
В свою очередь мы в офисе понять ничего не можем, у нас все корректно открывается все работает. А проблема оказалось в том, что под сам сайт было выделено 5 нод, на одну, с офисного IP, идет трафик собственно с офиса, на остальные четыре распределятся остальной. И xhprof был установлен только на той, на которую ходят сотрудники компании и на стйджах, поэтому все тесты прошли нормально и задача уехала в прод. Ну и вся проблема ясна из кода, в первом пресловутом if'е вместо того что бы вызвать переданный callback мы просто завершаем выполнение. Тут меня не уволили, не депримировали. проблему нашли в течении пары минут после первого обращения мерж с фиксом еще пара минут. Дольше доставлялись изменения на прод, но это совсем другая история. Общее время простоя около 20 минут.
Делается через конфиг сервис контейнера.
Условно мы говорим когда встречаешь этот интерфейс то для этого класса прикинь эту реализацию, а для этого вот эту.
Если не ошибаюсь то в ларе конструкция
$container->when(кому требуется)->needs(что требуется)->give(тут уже что прокидываем)
В симфони через аргументы в конфиге.
К сожалению точный код не могу накатать, с телефона читал статью.
Для этого есть lazy load
Зависимости не будут инстанцироваться при старте приложения, а только когда требуются.
А какая может быть аргументация?
Компания в которой есть свой it отдел, по какой-то причине нанимает человека после курсов и даёт ему сразу переписывать всё и вся без тз, которое он должен сформулировать на своё усмотрение, остальная же команда занимается правками багов, звиздежом попахивает.
У меня к автору несколько вопросов
кто в компании отвечает за конечный результат
есть ли хоть один сотрудник который имеет экспертизу и понимает каков должен быть конечный результат, понимает качество написаного когда и его масштабируемость после написания MVP?
кто общается с бизнесом выявляя потребности, боли и хотелки текущего состояния проекта? При этом проводя попутную аналитику?
насколько крупен проект, сколько транзакций (продаж) в месяц через ИМ, насколько крупен каталог? нужен ли вообще компании интернет магазин или он как во времена доткомов лишь бы был?
Ага, я в повседневности говорю именно СиЭлАй, тоже не вкурил сразу в чем цимес
И Кунгурская пещера на Урале, но не в УрФО. В Пермском крае она.
Но и у фулстека есть что-то от утки. Утка и ходит, и летает, и плавает, но все делает хреново. Как по мне лучше быть отличным специалистом в узкой области, чем по чуть чуть во многих.
Я правильно понимаю, вы пришли все пушистые, продали клиенту сопровождение и обслуживание, проработали маркетинговую компанию, судя по приросту заказов неплохую, но не удосужились собрать хоть какую-то статистику по производительности системы, посмотреть что куда ходит у вас, сколько запросов в БД на странице, не? Не говорю даже про какое либо минимальное нагрузочное тестирование.
А судя из текста у вас есть БД, в ней таблица раздутая по размерам с непонятными логами и это у вас не вызвало ни малейшего вопроса?
Мне просто интересен ход ваших действий при приёмке проекта в работу.
https://aws.amazon.com/ru/snowmobile/
И сейчас есть, только не грузовик, а, насколько я понял, специальный морской контейнер
Мама я тимлид.
Стоит прочесть, книга не даёт глубоких знаний, но она даёт понимание нужно ли тебе это, и если да то есть подсказки что ещё почитать и в какую сторону двигаться