Хабр Курсы для менеджеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 77
Спасибо за статью, но мне кажется, нет каких-то простых вопросов, которые можно задать и узнать что за человек. На вопрос можно ответить правильно / неправильно. Что-то упустить, или наоборот - рассказать все достаточно полно. Но ведь тут как - пока не попробуешь с человеком поработать, не узнаешь, что за специалист перед тобой.
Кандидат может на 1-й вопрос ответить "Я!" и ошибиться (что для тимлида, конечно, не очень), но при этом, с большим энтузиазмом относиться к работе, брать на себя ответственность и предлагать решения. Для меня перечисленные качества важнее понимания принципа командной ответственности и подстраховки(их в конце концов легко объяснить).
Более того, если вы составили список "контрольных" вопросов и кандидат ответил не так. Это еще не значит, что он ответил неправильно. Возможно у него другой опыт, он побывал в других ситуациях. А возможно, и ваш собственных ответ, на ваш же вопрос неидеален.
Да, согласен, в идеале лучше поработать с человеком и посмотреть в деле.
Но на этапе найма у нас всегда есть ограничение по времени, поэтому приходится проводить первоначальный "скрининг".
Для меня эти вопросы не про "правильный" ответ, а про то, как человек думает и как раскрывает ситуацию. Обычно на практике ответы довольно хорошо читаются между строк.
"Возможно у него другой опыт, он побывал в других ситуациях." - да, все так, именно поэтому такие вопросы использую не как "контрольную", а как способ понять модель мышления кандидата и чего от него ожидать в работе.
Да, но как правило, мало волнуют ситуации, когда человек побывал в других ситуациях, подбор в команду осуществляется исходя из тех ситуаций, в которых оказывается команда, поэтому вопросы обычно подстраиваются именно под нужды команды, поэтому выберут того, кто на этапе собесов создаст о себе более удобное впечатление, из-за этого могут отсеяться действительно хорошие специалисты, но которым понадобилось бы время для адаптации
Кто отвечает за задачу?
У кого есть административный ресурс. Комплименты Я-модели заканчиваются там, где ответственный, проактивный, неперекладывающий сотрудник упирается в невозможность осуществления необходимых изменений из-за линейности своей должности.
Команда отвечает за результат. А роль тимлида — сделать так, чтобы команда могла его добиться.
Понятно. Здравствуй, коллективная ответственность!
А) не работать там где для решения своих должностных обязанностей (доставка работающего функционала) мешает "линейная структура"
Б) донести до "линейных" окружающих, что все таки бизнес это не пансионат для содержания менеджеров а комбайн по производству денег. Софт скиллы, все такое
Не линейная структура, а линейная должность в иерархической структуре. Где бы ни работал, как только начинается кризис, все скатывается в ответственность без полномочий. Ну собственно, да, потом уходишь и ищешь новое место.
На линейной должности есть полное право требовать зрелую экосистему менеджмента и выстроенную среду условий для выполнения чисто технической работы, не заморачиваясь на риски, проблемы, убытки и миссию бизнеса.
"упирается в невозможность осуществления необходимых изменений из-за линейности своей должности."
Да, согласен, неприятная и сложная ситуация. На практике помогают идеи из моделей внедрения изменений: искать точки влияния, союзников и постепенно расширять зону ответственности.
Если вдруг нужна будет помощь - пишите в директ, попробую помочь.
Команда отвечает за результат.
Здравствуй, коллективная ответственность!
Не совсем так. Тимлид отвечает за результат команды (выполнение всех задач), а разработчик отвечает за поставленные лично ему задачи. Всегда можно построить процесс так, чтобы у каждого его фрагмента был ответственный. Важно то, что роль тимлида включает ответственность "за всё" (в пределах команды) и возможность смены исполнителя задачи, а роль разработчика не имеет отвественности за всю команду.
Хотя да, в некоторых организациях бывает, что члены команды разработки несут коллективную ответственность за косяки ближайших коллег, менеджеров, других отделов, коммерческого и генерального директоров и т.д., а тимлид не имеет полномочий делать даже замечания команде, но это некая нездоровая организация процесса.
Тоже глаз зацепился. Коллективная ответственность может легко стать безответственностью. Тоже коллективной. Это хорошо видно в крупных организациях. Первый случай у автора.
Но при этом схема отвечает разработчик, лид обеспечивает условия. Лид становится узким местом. Лид заболел/ушёл в отпуск/уволился - работа встала. Такое себе. Поэтому бы перефразировал. Коллективная ответственность. Но прежде - ответственность исполнителя.
как бы вы оценили разработчика ядра Linux, который не пишет unit-тесты?
Как очень крутого разработчика :)
В случае низкоуровневых разработчиков точно своей отдельный контекст и стоит придумывать другую систему вопросов.
Хорошо, низкоуровневые – отдельный контекст. А разработчик распределённых систем, который верифицирует корректность через TLA+ и chaos engineering?
А вот тут думаю вопросы хорошо подходят. Если в ответе будет про TLA+ и chaos engineering, то это хорошее начало обсуждения для понимания инженерной зрелости.
но ваш вопрос в статье конкретно про unit-тесты, а не про практики верификации в целом.
если разработчику распределённых систем, практикующему TLA+ и chaos engineering, задать вопрос “пишете ли вы unit-тесты”, то он ответит “нет”, потому что TLA+ это принципиально иной инструмент совершенно иного уровня инженерии.
и получается, что проблема не в кандидате, а в вопросе?
Я бы с удовольствием заменил вопрос на более общий, если есть удачный вариант - пожалуйста, поделитесь.
вы предлагаете мне остаться в том же подходе – заменить одну редукцию на другую, но проблема не в том, что выбран неудачный инструмент, а в самом подходе: редуцировать оценку инженерной зрелости до одного вопроса или до использования одного инструмента.
unit-тесты – частный случай; TLA+ – частный случай; chaos engineering – частный случай.
а вот зрелость это не владение конкретным инструментом, а способность выбрать адекватный инструмент под контекст.
Как отражал в статье, это начало разговора, а не полная замена.
Хочется на скрининге заранее понимать, кто более перспективный. Пока из вашего ответа не понял как тогда лучше систему выстраивать?
Понимаю, что текущие вопросы неидеальные, но точно заинтересован в поиске более эффективных подходов.
обратите внимание на то, что вы сами сказали: “хочется на скрининге заранее понимать, кто более перспективный”.
вот это и есть ядро проблемы: вы продолжаете искать редукцию (один-два вопроса, которые за минуты дадут полноценную оценку) уже после того, как её ограниченность была обоснована, ещё и от меня просите более другую/правильную “серебряную пулю” в рамках этой же редукции.
именно поэтому вам и сложно понять, как выстраивать систему: потому что система – это не два вопроса.
инженерная зрелость многомерна, контексты различаются, и попытка свести оценку к быстрому фильтру неизбежно будет приводить к потере тех, кого вы сами выше назвали “очень крутыми”.
Со всем, что вы писали, согласен, но в реальности просто нет времени досконально разбираться с каждым кандидатом. Могу даже поверить, что предложенные автором вопросы дают лучшую предсказательную силу, чем алгоритмические, архитектурные и интервью на знание ЯП.
Последний раз, когда я собеседовал разработчика, он очень плохо отвечал на вопросы — и по ЯП, и по архитектуре. И обратная связь от других интервьюеров была на троечку. Тем не менее, взяли его, потому что все остальные были еще хуже, а еще и ставку у нас могли забрать. В итоге разработчик разобрался в первую неделю с довольно большим проектом, никого не отвлекает лишними вопросами, пишет хороший код.
В идеале бы брать на тестовый период в пару месяцев и смотреть, как кандидат справляется, но мир далёк от идеала. Поэтому то, что предлагает автор статьи, имеет право на жизнь.
вы сами только что описали идеальный контрпример: кандидат провалил интервью, но оказался сильным.
это подтверждает, что любые вопросы на интервью, включая предложенные автором, имеют слабый предсказательный характер качества реальной работы человека.
а “нет времени на точность” это аргумент за честное признание ограничений метода, а не за то, что метод работает 🤷🏻♂️
Вопрос же не в том, как найти способ исключить false positive и false negative, а как эффективнее получить предсказание, затратив меньше времени.
а “нет времени на точность” это аргумент за честное признание ограничений метода, а не за то, что метод работает 🤷🏻♂️
А разве кто-то утверждал, что какой-то метод отбора не имеет ограничений?
эффективность предсказания имеет смысл, когда предсказание хотя бы положительно коррелирует с результатом.
метод, который систематически отсеивает сильнейших (negative selection), – это не “менее точный, зато быстрый”, это антипредсказание.
быстро получить антипредсказание – не эффективность, а антиэффективность.
А разве кто-то утверждал, что какой-то метод отбора не имеет ограничений?
автор нигде не упомянул ограничения.
заголовок: “скажут о разработчике и тимлиде больше, чем техническое интервью”.
текст: “корреляция оказалась удивительно высокой”.
ни одного указания на ограничения до тех пор, пока на них не указали в комментариях.
метод, который систематически отсеивает сильнейших
Если бы это было доказано, то вы были бы правы. Но ни вы, ни я не знаем, какая эффективность предсказания у подхода из статьи, а какая у собеседований, как в FAANG.
текст: “корреляция оказалась удивительно высокой”.
Видимо, это эмпирический вывод автора.
negative selection не нуждается в доказательстве – он уже продемонстрирован в этой дискуссии самим автором (разработчик ядра – “очень крутой”, но по его фильтру с unit-тестами не проходит).
при этом вы принимаете “корреляция оказалась удивительно высокой” как эмпирический вывод – без данных, без выборки, без метрик, но от меня же требуете доказательств, в то время как от автора достаточно слова “видимо”.
это двойной стандарт, обнуляющий вашу аргументацию.
negative selection не нуждается в доказательстве
Если ваша цель — опровергнуть тезис: “метод Х позволяет гарантированно определить, подходит кандидат или нет“, то конечно, это легко опровергнуть. Но никто этот тезис не произносил. А вот ваш тезис как раз догматический:
это подтверждает, что любые вопросы на интервью, включая предложенные автором, имеют слабый предсказательный характер качества реальной работы человека
Мы не знаем, любые или не любые. Можно только сказать, что “какие-то вопросы имеют слабый предсказательный характер “. Но вы пишете “любые“, потому что пришли к этому эмпирически — и при этом упрекаете автора в эмпирике. Вот это тоже двойной стандар.
Каждый сам решает, что брать от статьи. Я давно заметил, что отбор по типу FAANG — неэффективный. Вопросы про тесты и ответственность мне нравятся. Даже если кандидата спросят, использует ли он Unit-тесты, а он ответит, что нет, и на этом разговор не продолжится, — это проблема коммуникации с двух сторон. И интервьюер должен спросить: “а как вы гарантируете качество кода“, и кандидату бы хорошо ответить не односложно сразу.
И по поводу статьи: не должен же автор писать тут ветвление всех вариантов диалога с кандидатом. Он показал, как можно начать диалог и на что обратить внимание.
Если ваша цель
это булверизм (вы приписываете мне цель и спорите с ней, а не с предоставленным мною аргументом).
Никто этот тезис не произносил
заголовок статьи: “скажут больше, чем техническое интервью”; тезис в заголовке тезисом не является?
по поводу обвинения в догматичности на базе слова “любые”: моё утверждение было выводом из вашего же примера – ваш кандидат провалил интервью, но (внезапно!) “разобрался в первую неделю с довольно большим проектом, никого не отвлекает лишними вопросами, пишет хороший код”.
Проблема коммуникации с двух сторон
вопрос автора более чем конкретный: “пишете ли вы unit-тесты?”.
ответ инженера, не пишущего unit-тесты: “нет”, и это не проблема коммуникации, это проблема вопроса.
Он показал, как начать диалог
он показал “больше, чем техническое интервью”, и это его заголовок, не мой, а подключение очередной уловки (булверизм) лишь подчёркивает исчерпание логоса
заголовок статьи: “скажут больше, чем техническое интервью”; тезис в заголовке тезисом не является?
Тезис “скажут больше, чем технические интервью“ не равно “скажут точно“. Вы подменили понятие на “точно не скажут“ и доказываете, что неверно. А этого никто и не имел в виду изначально. Вопрос о том, скажут ли больше или меньше, остаётся открытым.
по поводу обвинения в догматичности на базе слова “любые”: моё утверждение было выводом из вашего же примера
Это же всего лишь один пример. Мы не можем говорить про “любые“.
ответ инженера, не пишущего unit-тесты: “нет”, и это не проблема коммуникации, это проблема вопроса.
Мне хочется, чтобы разработчик был умнее, чем нейросеть с промптом “отвечай“ односложно. Я сам разработчик до сих пор и часть моей ответственности — разобраться, что от меня хотят. Поэтому и считаю, что вопросы автора имеют право на жизнь.
Я предлагаю закончить дискуссию, пусть каждый возьмёт от статьи, что хочет, или не берёт ничего.
“Скажут больше” и “систематически отсеивают сильнейших” – взаимоисключающие утверждения.
фраза “скажут точно” появилась именно у вас, следовательно и подмена тезиса тоже у вас.
А этого никто и не имел в виду изначально.
очередная итерация булверизма со сверхобобщением – защитывается как комбо 🎳
ваш пример с кандидатом был аргументом, пока работал в вашу пользу, и стал “всего лишь одним примером”, когда из него сделали вывод противоречащий вам.
третье применение двойного стандарта в течении дискуссии это уже паттерн.
Разработчик должен быть умнее
отличный пример перекладывания ответственности на кандидата за бинарный вопрос, который кандидат не конструировал.
Я сам разработчик
argumentum ad verecundiam
дискуссию закончить согласен.
Тут, на самом деле, нет противоречий. Редукция необходима, так как сложность системы, с которой происходит взаимодействие (нанимаемый сотрудник, со всеми его знаниями и опытом), не позволяет за короткое время (интервью) исследовать её полностью. Приходится ограничиваться моделью, которая априори проще оригинала, и, соответственно, имеет ограничения применения. Т.е. ключ к эффективному использованию подхода автора - понимание, что его “два вопроса” - это модельный эксперимент, и соответствующая модель имеет ограничения. Ну и, конечно, совсем здорово - понимать, в чём ограничения, как оценить применимость модели, и какие модели использовать в случае, когда эта не работает ;)
вы описали ровно то, чего у автора не было: понимание ограничений модели, оценка применимости, альтернативные модели для случаев, когда эта не работает. всё это выяснилось только в ходе обсуждения.
проблема не в том, что редукция существует, а в том, что она была подана как универсальный инструмент для достижения качественного результата.
конкретное ограничение этой конкретной модели – negative selection: автор сам признал, что разработчик ядра, не пишущий unit-тесты, – “очень крутой” (при этом забавно, что бедолага с TLA+ и chaos engineering уже не был крутым), но по его фильтру этот кандидат не проходит.
модель, которая систематически отсеивает сильнейших, это не просто модель с ограничениями, это модель с дефектом в основе.
Ответ: Unit тесты не пишем, для проверок используем такой-то подход. И описываешь TLA+ и chaos engineering
У нас в компании с тестами так: надо бы, да всё не до них. Начальство не даёт команду, а разработчикам недосуг этим заниматься. Если выделить разработчику отдельный день на написание тестов, чтобы улучшить кодовую базу, то кто будет за это платить? Нужно ведь как-то выбить деньги с заказчика под такую деятельность. Да и вообще, пусть сперва кто-то проведёт обучение, покажит хорошие примеры, что стоит тестировать, что не стоит, а что нужно сперва отрефакторить, только потом тестировать.
У меня, например, есть несколько boolean-значений, которыми жонглирует сервер, я в зависимости от этого вывожу всякие предупреждения или блоки на странице. Мне тестировать, вариант "если eventStarted == true, то блок event показан"? Но v-if="eventStarted" и так гарантирует это. Это всё равно что тестировать работоспособность vue. А тестировать правильное сочетание всех этих флагов — задача бэкенда, он отвечает за текущее состояние (я предлагал заменить пачку флагов одним строковым значением, обозначающим текущее состояние в целом, но уже поздно делать такие крупные изменения).
Короче, я без понятия, что мне можно было бы протестировать. Разве что вариант "сервер почему-то не прислал поле X у объекта", а то бывает такое, что я в типах записал поле как обязательное, а бэкендер решает его вообще не присылать, если там пустая строка.
Наверное, стоит начать не с "напишите тесты", а с "устройтесь на работу, где вашей задачей будет не просто вывести html-блок с данными или отправить поля формы в API".
Стоило начать с объяснения, что такое "отвечать за задачу". Типа, кого накажут, если задача будет закрыта, время списано, а оно всё равно не работает как просили? Смотря какой заказчик. Орать он будет на менеджера. Но если это не ключевой заказчик, то менеджер передаст разработчикам, что не всё починилось, надо передалть. А если заказчик ключевой, то менеджер передаст то же самое, только с использованием матерных слов. Наказания вряд ли будут. Ну а какие наказания? Понизят часовую ставку? Куда уж ниже? Перестанут в рабочее время отпускать в ветеринарку или отвезти мать к зубному? Себе же хуже сделают.
Не совсем понял, как ответ "хорошего тимлида": "у каждой задачи есть ответственный", помог бы в первом случае, когда задачу перекидывают. Бывает, что такое перекилывание возникает даже не между командами в рамках компании, а между компаниями, когда 1 линия поддержки (а,может, ещё и вторая) реализуется заказчиком программного продукта
Интересный вопрос. И вот тут как раз и возникает та самая ситуация. Если никто не возьмет на себя ownership проблемы, то пользователь так и будет с проблемой. Если тикет не закрывать, а позвать тимлида помочь с кросс-командной проблемой / проблему с другими организациями - это уже здорово и хорошее решение.
В блоке про тимлида - то, что он возьмет на себя решение проблем - это здорово. Ответ - "Я", это хороший ответ. Но поверх этого ответа важно, чтобы он умел себя масштабировать. Чтобы не в одно лицо решать все проблемы, а чтобы подключаться только в тех ситуациях, где без его помощи не справляются.
закрыли свою задачу с формулировкой: «Проблема не у нас»
Очень удобно наверное перекладывать ответственность с фирмы на кандидата, которого в первый раз видите. Довольно лживая статья получилась.
Ни один нормальный человек не будет брать ответственность за то, над чем он не имеет контроля. Если команда девопсов закрыла тикет, и не нашлось человека способного сказать "да вы охренели что ли?" - то каким же магическим образом человек с улицы должен брать на себя какую то "ответственность" за их действия?
То же самое и к юнит тестам относится. Где то есть отдельная команда тестеров, и разработчик уж точно не должен их писать. Где то применяется test-driven development, и внезапно, разработчик опять не сам пишет тесты. Ну а если юниты у вас начал писать лид (наверное на созвонах это делает) - то тут вообще комментировать - только портить. Понаберут ЧСВшных эйчаров, потом волшебника гудвина ищут.
за автора рад :) но чутка не дожал до сути - суть этих "простых" вопросов в том что бы понять "а будет ли мне комфортно работать с данным человеком" (потому и нет на них "правильных" ответов)
и имхо это лучшая стратегия найма, при чем для обеих сторон.
сложность же в том что это не универсальные вопросы, и каждому придётся формулировать свои, с "чужими" не выйдет, тк ответа не поймёшь (ответ то неформальный) - собственно что мы и видим в комментариях - очень много жуют формальных моментов, а по сути ничего
автору благ и удач!
По мне это просто какие то завышенные ожидания или человек сам себе просит соврать. (От большинства обычных работодателей, когда сам обычный а хочешь о го го го)
Большинство компаний не платят работнику 100 тыщ долларов в год. И ждать что ваш проект является для него чем то сакральным ради которого будут радеть и переживать как за родной ну такое себе. Поэтому для меня ответ "Я отвечаю только за свою область, сферу и уровень" полностью нормальный.
Да чисто по человечески если работодатель хороший, с которым в средним можно особо не напрягаться и норм(имено норм не кучу золото, но и не миску супу) платит, но когда надо напрячься - берёшь и хотя бы стараешься. Ладно. Но это не прям обязанность.
По второму это не универсально. Чем проще организация - тем меньше бюджеты. Вот у меня в сфере "обычных сайтов" - зачастую вообще тестировщика даже нет. Ему платить нечем)) Ну какие тут юнит тесты ещё. Потом когда кто-нибудь наткнётся попробуем починить))
Странное чувство. Мне не нравится как сформулировано. Но по сути я вроде со всем согласен
Очень сильно зависит от процессов в компании.
На хороших процессах- спору нет, а вот с плохими - нюанс на нюансе.
По unit-тестам плохие процессы очень сильно бьют.
Если задачу надо было начать решать позавчера, вчера получили описание задачи, сегодня прилетели новые правки по требованиям (тестировщики только сегодня их вычитали), а завтра релиз…
То тесты получится писать хорошо если на железобетонную логику, ту, которая не поменяется по прихоти менеджмента.
Те же паршивые процессы напрочь убивают ответственность за баги. Иной раз приходится строить звездолеты на настолько зыбком фундаменте, что удивляешься, что оно хоть как-то работает. Начинаешь расковыривать какой-нибудь баг, а там наслоения вторпродуктов такие, да еще от давно уволившихся ребят, что прямо теряешься. Кто виноват в данном случае? Нанятый вчера специалист, или система, в рамках которой выстроены такие процессы?
Как завуалированно переносится ответственность, с “хорошего менеджера” (который как раз должен был настроить эти процессы взаимодействия и поделить ответственности) на “плохого инженера” (который якобы должен выполнить работу менеджера, по мнению автора).
В идеальном мире все так, ответственность несёт исполняющий, раз он взялся, тут спору нет. Но если человек называется менеджером (лидом, пм), то будет добр - создай условия, чтобы такого в принципе не возникало.
Так же как и инженер - вряд ли будет спрашивать у менеджера: “как сделать это, а как то”. Это его зона ответственности, и чем меньше он отвлекается на ошибки менеджмента - тем эффективнее работает.
Описанный 2 пример с backend разработчиком - будет работать по умолчанию, если условием для “отфутболивания” задачи будут не просто “у нас все работает”, а “у нас все протестировано и вот результат”.
Дальше - задача управляющего проектом(командой) решить в каком же месте оно тогда могло сломаться, с кого спрос и где архитектурная проблема.
Про первую ситуацию из первого вопроса. Если тикет гуляет по кругу, а команды по сути перекладывают друг на друга ответственность, то проблема в такой компании явно не на уровне сеньора, а на уровне организации работы. Так же, почему-то не была упомянута команда тестировщиков, которая и должна воспроизвести баг. Понимаю, что хотел сказать автор, но ответил бы на первый вопрос немного иначе. За все задачи, что поступают мне ответственен я, пока они не будут выполнены, либо пока на 100% не буду уверен, что проблема не в моей зоне ответственности, после чего передам тикет с подробным описанием ресёрча и всеми обоснованиями, предположениями, тестами. Чего буду в подобных ситуациях ждать и от коллег, а не просто "у нас всё хорошо, ищите сами", я то найду, но если выяснится, что проблема всё же на строне коллег выйдет неприятный момент.
Касаемо тестов. Ответ в наших реалиях очень простой. Без git и unit тестов даже разработка пет проектов невозможна. Это базовый минимум в наши дни, особенно с приходом llm, которые программисты любят использовать, но не особо любят ревювить их код. Без тестов, проект сейчас просто невозможно адекватно поддерживать вдолгую. Какую бы вы замороченную и идеальную архитектуру не выбрали и какую бы навороченную инфру вокруг неё не выстроили, без тестов это превратиться со временем в кучу малу.
Имхо, но эти вопросы сейчас валидны для всех. Я мидл разработчик и это 2 базовых вопроса, которые и джунам задают.
Мне кажется сейчас в принципе актуальнее вопрос про ответственность, потому что именно за неё мы получаем зп. Контракт с бизнесом очень прост. Бизнес платит деньги нам не за писульки кода, а за ответственность стабильной работы созданных по запросу бизнеса решений. Всем плевать, что вы использовали лучшие практики. Если что-то не работает спрашивают с нас. Да да, капитан очевидность, но вы даже не представляете, как много людей не понимают этой простой истины. Бизнес не будет слушать про, то что json'ы пользователю не приходят из-за особенностей вашей же выстроенной архитектуры, он найдет вместо вас тех, кто сделает так, чтобы json'ы приходили, если вы не хотите нести за это ответственность.
Да ладно)) 10+ лет в веб-программировании. Ни на одном сайте не было юнит тестов, да и мерзкий ГИТ к счастью большая редкость. Мне иногда кажется что статьи на хабре про ИТ это как с другой планеты. С большим отрывом от массового народного продукта)) Я объясняю это спецификой аудитории хабра, что большая часть обычных ИТ специалистов тут не сидят, т.к. работаю ради зарплаты и им интереснее другие темы танки, сериалы и т.д. Соответственно их мнение мало представлено. Из за чего картина в сфере сильно искажается.
Платят за то что могут себе позволить. У работодателей, как и у нас есть градация. Мощные богатые действительно часто могут попытаться и преуспеть в найме основном горячих, мотивированных, очень квалифицированных, стремящихся развиваться сотрудниках.
А вот середнячки не могут себе такое позволить их основной рабочий состав - это работающие за зарплату без лишний инициативы и желания развиваться сотрудники(не стоит путать с полными неумехами и неспособными контролировать свою лень лодырями в ситуациях предельно ясных кто и что должен сделать, от них действительно стоит избавиться). Поэтому нытьё про ответственность тут не проканает, да можно потом уволить какого-нибудь середнячка, но скорей всего на его место придёт такой же если не хуже, которому еще и осваиваться фиг знает сколько времени надо.
Однако и середнячки ещё ничего. А бывают ещё хуже работодатели. Те вообще пусть радуются и спасибо скажут что хоть что то работает))
Когда разработка работает без системы контроля версий - это не "массовый народный продукт", а "дно разработки". Бэкапы исходников скриптами, ручные объединения правок... Так лет 20-30 назад делали, за это время можно было внедрить git, в котором это автоматизировано общепринятым способом.
И большинство разработчиков всё-таки и git используют, и юнит-тесты пишут, даже на начальном уровне, что уж говорить о "середнячках". Да, есть очень простые проекты, где тесты не нужны, есть модули систем, где они малоприменимы, но обычно тесты полезны.
Системы контроля версий и есть то самое дно, зло и угнетатор. Для разработчика точно. Это как покакать и вместо того чтобы просто подтереться и помыть руки. Начинаешь в тетрадку записывать. Какашка отправлена, бумага получена. Ужас и жесть какая то. НЕНАВИЖУ!!! Не буду я вместо нормального cntrl+s в нотпаде++ вводить какую тучу галимых консольных команды и плясать с бубном просто чтобы сохранить свой код.
У меня вообще есть теория. Что это Гитлера в аду черти жарили. А он такой отпустите меня реинкарнировать я снова людям поднасру. Вот он взял и придумал это исчадие ада назвав в честь себя сокращено "Гит" программистам на мучения.
Все эти джуны, мидлы, сеньоры. Даже в одной конкретной области часто имеют расплывчатые границы и сложно куда то однозначно отнести человека. Чего уж говорить про разные сферы. Мидл в программировании ракет и мидл в народном производстве обычных сайтов. Ну это разные планеты.Чтобы ими оперировать.
Вот за 12 лет, я поведал где то 100-200 сайтов изнутри. 0 юнит тестов на них. И где то около 10 был этот какогит. И дело даже не столько в сложности проектов, сколько в бизнес модели. Не готовы заказчики обычных сайтов платить в полтора два раза больше за хорошо оттестированный код. Проще этот баг потом поправить когда кто-нибудь обнаружит. Поэтому у меня к юнит тестам нет неприязни в отличии от гита. Если из-за того что Гиту я показываю фиги, где на собеседованиях меня не взяли или давили. Да и то куда меньше проблем чем из за того же незнания CSS. То про юнит тесты ни разу никто не спросил.
Ну я конкретно в веб разработке поменьше, лет 6, до этого был в десктоп разработке + администрирование сетей/серверов. Причём я буквально тот самый создатель "массового продукта", потому что пишу в основном под wordpress и laravel на php, сейчас немного вкатываюсь в go.) У меня как раз много проектов сейчас скопилось, где git и автотесты не использовали и они с годами превратилось в legacy ад. Хороший пример сайты на wordpress. Сам по себе wp очень плохо поддаётся покрытию тестов. С git ещё ладно, можно вынести в репозитории отдельные плагины, чтобы не тащить всё на сервера, какого-нибудь github. Я специально для этого создал даже небольшую composer библиотеку, что основана на основе шаблонного метода (да, да, да сейчас тут на хабре мне расскажут, что нужно было DDD пихать, а я такое видел, и вообще делать плагин для wp на миркросервисах иначе не тру архитектура) и позволяет создавать плагины в ООП стиле, отделяя бизнес логику от wp приколов, по типу action filter и прочего. Правда моя библиотека тоже кривая, но лучше, чем ничего.) Надо бы её довести до ума как-нибудь.
Так вот, даже моя кривая библиотека позволила покрывать тестами код wp плагинов и это облегчило жизнь, убрав огромное количество плавающих багов. В wp они не редкость, где action в action в filter с кучей transients. А теперь представьте, что со всем этим нужно подружить нейросеть и чтобы она ничего не сломала.) К слову, о нейросетях, сейчас все агентные нейронки, по типу claude, codex и т.д., не просто так создают папочку project_name.worktree с отдельной git веткой внутри и не удаляет её после apply.) Codex вон вообще работает через github создавая самостоятельно PR.
Касаемо тестов, ну вот недавно у меня была задача написать десяток сложных медицинских калькуляторов, где расчёт шёл не просто по формуле, а с использованием разных медицинских таблиц и особенностей расчётов, интерпретаций ответов исходя из научных статей. Конечно, все расчёты для калькуляторов были изолированы друг от друга, но без покрытия тестов, я не представляю, как бы этот проект закрыл. Учитывая, что калькуляторы могут использовать одни и те же таблицы, а нейронка, чтобы подогнать ответ обожала их немного менять, либо если запретить им строго менять, они делали "хаки", т.е. пытались подогнать например округлением или интерполяцией под ответ. Но когда есть десяток тестов с 100-1000 кейсами основанных на эталонных данных, уже мухлевать ей было сложно. Поэтому и говорю, что не представляю как сейчас делать проекты без git и unit тестов. Причём unit тесты это один из типов тестов, которых намного больше, но unit имхо это базовый минимум) Тем-более, что сейчас можно тестами покрывать проект "лениво" при помощи тех же нейронок. Да, так лучше не делать, но это лучше, чем ничего.) Главное следить чтобы не было галлюцинаций наподобие assert(true, true), нейронки такое любят 😂.
В общем, советую попробовать применить у себя в проектах хотя бы unit тесты. Поначалу будет непривычно, но потом вы даже не представляете, как вам это жизнь облегчит, даже если вы ведёте один проект и один программист на нём, который идеально его знает.)
Вот и странно. Если вы, как и я делаете "массовый народный продукт". То откуда там юнит тестирование? Я пытался это представить. Вот прихожу такой я и говорю работодателю сделаю ваш интернет магаз за 100 тыщ и 4 недели без всяких прибамбасов. Приходите вы и говорите. Сделаю тот же сайт но за 150 тыщ и 6 недель или даже 200 тыщ и 8 недель. Зато в отличии от Андрюхе у вас будет меньше багов. И что вы думаете? Выберут меня. Т.к. жирные баги сами заметят мне на правку отправят. А что то на каком то редком устройстве или при каких то исключительных действиях работать не будет с их точки зрения ни очень то и проблема чтобы переплачивать. Ну а за 100 тыщ с юнит тестированием типа смысла нет делать. Зачем с большой квалификацией и объемом труда (при условии что в основе мы равны) меньше денег получить какой вам смысл?
Сказать что на качество кода. Качество всмысле "понимания другими людьми и возможность модифицировать его" юнит тесты как то влияют тоже не могу. Гит? Ну может больше. Но тоже не вверху списка. Куда важнее опыт и способности программиста непосредственно в самом продукте. Чел 12 лет кодирующий конкретно в этом CMS и решающий конкретно эти задачи, но не использующий ГИТ в любом случая лучше чем другой использующий ГИт но значительно меньше работавший в данной CMS и не решавший эти задачи. (Это вообще самое главное для проекта). Потом насколько большая была текучка. В идеале если человек создал сайт и всю жизнь его кодит. А если там сменилось за 5 лет 20 разработчиков, то никакой ГИТ не поможет, точнее лучше 20 разрабов с гитом, чем 20 без гита, но еще лучше 1 без гита)) На третьем месте насколько продукт типовой. Легче нафигачить плохого кода в какой-нибудь редкой и объемной области чем обычной корзине в товарами. И лишь где то в конце списка по влиянию на качество кода будет Гит. Т.к. он особо ничего не даёт. Зато сильно мучает программиста. Добыть старый код, есть резервные копии. В РЕДКИХ случаях один программист перезатёр код другого. Бывает это жизнь. Мне проще снова его написать чем КАЖДЫЙ РАЗ вместо обычного cntrl+s вот эту вот всю бороду проделывать.
Мне проще снова его написать чем КАЖДЫЙ РАЗ вместо обычного cntrl+s вот эту вот всю бороду проделывать.
Ну как бы типичный размер ваших проектов понятен, да.
Касаемо цен. Что unit, что git это не какая-то фича сайта, это инструменты для более удобной разработки. Ни один заказчик не будет платить деньги за юнит тесты. Это нужно для того, чтобы не было моментов, когда "одно чинишь, другое ломается", а в последнее время, чтобы ещё и нейронки в узде держать. Здесь вопрос не в цене разработки, а в грамотном использовании инструментов. Всё равно, что говорить "есть Андрюха, который сделает вам сайт за 100 тыс. уложившись в 4 недели, а есть кто-то, кто напишет его за 80 тыс. не используя IDE, в блокноте на чистом html с supabase или вообще соберёт на тильде, почему нет." Так же тестирование и git очень помогают при поддержке. Если вы фрилансер, понятно, что вам дело до будущего проекта нет. Склепали, как-то сдали, а что там будет дальше с проектом не важно, но если работать с постоянными заказчиками, то они явно не будут слушать отговорки про "одно чиню, другое ломается".
> Чел 12 лет кодирующий конкретно в этом CMS и решающий конкретно эти задачи, но не использующий ГИТ в любом случая лучше чем другой использующий ГИт
Если чел 12 лет работает с CMS, то поверьте у него уже сформировался pipeline работы. У него есть как git, чтобы банально там хранить и разворачивать свои боллерплейты, плюс хранить свою кодовую базу. У него есть инструменты под юнит тестирование, инструменты под быстрый деплой, автоматическое создание плагинов и даже инструменты под создание тех же тестов, без нейронок. Все программисты, что работают с чем-то определённым имеют под свои задачи стек инструментов, многие из которых сами же и написали, для упрощения и ускорения своей же работы. И возьмут скорее такого человека, что отрицает использование базовых инструментов разработки.
> А если там сменилось за 5 лет 20 разработчиков, то никакой ГИТ не поможет, точнее лучше 20 разрабов с гитом, чем 20 без гита, но еще лучше 1 без гита))
Как раз поможет. Потому что новые программисты будут видеть все изменения и историю работы старых программистов, а не просто дали доступ к vds или вообще архивом сайт в лс кинули и типа копайся, а какие там подводные камни, какая специфика, та пофиг. Тыж программист, разберёшься до обеда.
> Зато сильно мучает программиста. Добыть старый код, есть резервные копии. В РЕДКИХ случаях один программист перезатёр код другого. Бывает это жизнь.
Нуу, я тоже так с ним мучаюсь, прямо не могу =Д Ну да передавать архивами код между программистами или сразу работать в проде это намного удобнее, чем сделать несколько коммитов.
> . Мне проще снова его написать чем КАЖДЫЙ РАЗ вместо обычного cntrl+s вот эту вот всю бороду проделывать.
Ну во-первых, ctrl+s git не отменяет, коммиты делают по смысловым задачам, а не на каждое нажатие ctrl+s. Во-вторых git вообще нужен для другого. Ну и в третьих, разве переписывание одного и того же кода, это не сизифов труд? Так же вы уверены, что замечаете все изменения за коллегами?
Банальный пример для чего нужен гит. Допустим вы работаете над проектов вдвоём. У каждого есть тестовое окружение (потому что вдвоём на проде одновременно работать это бред, банально коллега, что-то поменял, вышла ошибка ищешь её в своём коде и таких казусов много возникает), вот вы что-то сделали с сайтом, коллега сделал с сайтом вы 2 архива скинули друг другу. Как будете их "склеивать" в один проект? Ручками вместе? Git такие вопросы позволяет решать быстро. Ну хорошо, допустим работаете над сайтом одни. Допустим даже не используете нейронки, что обожают на каждой итерации менять код и из рабочего проекта делать не рабочий. Git позволяет возвращаться к ранним комитам или удалять все текущие изменения, что позволяет экспериментировать не ломая код и не засерая всё закомменченным кодом, например ища баги. Уже молчу про то, что при помощи серверов репозиториев, как например github, можно автоматизировать очень многие вещи и вместо того, чтобы делать бэкапы кода в архивах заливать его на проду через ssh или sftp, после каждых обновлений, это можно всё автоматизировать до нажатия пары кнопок.
В общем, я не понимаю претензии к гит и юнит тестам. Их не то чтобы сложно использовать, это базовые инструменты разработки. Можно ли без них писать код и даже делать проекты? Да, можно, есть небольшие проекты, которым они не нужны. Но делать, без них уже средние проекты с поддержкой в долгую, конечно можно, но зачем если с ними удобнее и проще?
Касаемо качества кода, я имел ввиду, что код проще контролировать при помощи git да не обязательно его, есть много и других систем контроля версий, просто git в связке с github/gitlab более популярны. С git меньше шансов, что ошибки будут незамеченными или что совместная разработка приведёт к коллапсу архивов в лс или аду на проде.
Если подытожить, любой говнокод, покрытый тесами и запакованный в git репозиторий, будет лучше для поддержки, чем best practice код, который не покрыт тестами и отдаётся архивом. Потому что, на практике best practice код может вполне иметь много багов, просто не таких явных.
Как то все в кучу смешалось. Редактор кода - это вообще чисто дело вкуса кому какой больше нравится. Разные CMS Или фреймворки - это уже разный основной функционал сайтов по факту. Т.е. он за 80 тыщ предлагает другой сайт по факту чем я за 100. Возможно стоит согласится, может нет. Но это совсем другая ситуация о которой я писал человеку выше. Где сайт "одинаковый" на одном и том же CMS просто его покрыт юнит тестами мой нет. Как юнит тесты спасут от потенциальных негативных эффектов в других областях? Да ни как они возникнут или нет. Вы сами признаете ни один заказчик за юнит тесты не заплатит. А за что он тогда заплатит? За то что с юнит тестами редких багов (что их вообще не будет гарантировать даже с юнит тестами нельзя, а плохо написанные тесты вообще фиг знает насколько эффективны) чем у меня без них? Так заказчику обычных сайтов пофиг на такое. Я всякие проекты делал. Всмысле и те которые сдал - забыл. Так и над которыми потом годами трудился. И ни какой гит мне для этого не нужен. Мой код он же мне и так родной))
<--плюс хранить свою кодовую базу.
Правильно за 12 лет много всякого полезного написано что в хозяйстве пригодится. Но при чём тут Гит? Если доступы имеются просто зашёл и глянут, если нет, то перед тем как их поменяли себе на комп сохранил и всё. А временное коментирование кода пока ищешь баг - это прям кошмар кошмар)) Резервные копии все равно делает автоматом хостинг или серверный админ. Вообще не мои сложности.
Вот имено небольшие и средние проекты удобнее делать сразу на проде или общем деве без всех этих приблуд. Нормально по человечески открывая, сохраняя и перенося файлы. Проверяя на глазок, ну либо в ручную тестировщиком на средних.
<!-- Потому что новые программисты будут видеть все изменения и историю работы старых программистов
Там другой контекст был. Типа Гит/Без Гита чуть ли не ключевой фактор качества итогового результата. А я еще накидал более важным. Один из которых текучка. Если там 19 челов постоянно туда сюда по себя меняли и даже в Гит писали, то разобраться в трехтомовой истории почти не посильно.
<!--Если подытожить, любой говнокод, покрытый тесами и запакованный в git репозиторий, будет лучше для поддержки, чем best practice код
Категорически не согласен. Говнокод есть говнокод. Его история, это как история наркомана, ну нафиг разбираться как он до такой жизни дошёл и что с этим делать. Тесты покажут что всё плохо пациенту скора кранты, ну спасибо. Но если все плохо, то и без юнит тестов видно)) Качественный код от опытного специалиста я же и без ГИТа пойму. Ну а не явные баги. И что? Это же не высокобюджетная сфера ИТ гигантов. Где любой баг - беда, особенно неизвестный. В сфере обычных сайтов по другому. Жирный и очень плохой и так обнаружат программисты, менеджеры, заказчик, сайт админы и их поправят. А какой-нибудь редкий, не значительный. Да пофигу на него. И что важно не программистам, а самому заказчику.
Да всё смешалось в кучу, поэтому давайте разобьём все на подтемы.
1) Пример с ценой.
Здесь вообще какое-то недопонимание, поэтому скажу кратко. Git, Github, Unit тесты, это не функционал движка или фреймворка. Это такие же инструменты, как и IDE. Это не фишки сайта, а инструменты, которые позволяют разработчикам более эффективно создавать сайт (и не только сайты просто в контексте примера).
2) Для чего вообще Git и Unit тесты нужны?
Читая ваши комментарии мне кажется вы плохо понимаете, зачем вообще нужны эти инструменты и как они работают. Я не буду писать лекции это ни к чему.
Git, Github (да любая система контроля версий), полезен, даже для пет проектов без использования нейронок. Нужен помимо ведения истории изменения кода, для многих вещей. Например, откат кода (без залегания в бэкапы брр, я так делал последний раз наверное лет 10 назад), ко всем зафиксированным состояниям, что часто полезно. Быстрый деплой, возможность создания веток для того чтобы иметь, например несколько вариантов проектов, между которыми можно переключаться по нажатию одной кнопки. И это я за CI/CD молчу, которые поверьте встречаются и в небольших конторах довольно часто. В плане работы в команде, гит это базовый инструмент без которого работа сведётся либо к коллапсу архивов в лс, либо к вечным ошибкам 500 на проде. Про кодовую базу так же гитхаб просто удобнее. Хранить доступы ко всем серверам проектов или просто иметь папочку на диске можно, но как человек, который имел несколько пк, часто переезжал, это просто неудобно. По итогу, у меня есть папки с древними проектами, чуть ли не со студеньчества на hhd, но если бы я не перетащил всё в гитхаб или хотя бы в облако, то умер бы hhd, проектам можно сказать пока. Кстати то что можно быстро развернуть проект на разных устройствах это тоже плюс. Тут же можно упомянуть ваш пример с текучкой. Работая, через проду, если есть текучка кадров, вам придется дать доступ к проде для всех 20 программистов, которые могут по незнанию или специально всё поломать на уровне сервера. Github позволяет допускать программистов только до исходников, а иногда только до определенной его части, например если человеку надо доработать поагин, зачем ему доступ к коду всех плагинов сайта? Бизнесу это важно, уж поверьте.
Unit тесты. Вы сказали фразу, что при говнокоде тесты покажут мол "пациент сдох", у вас странное представление о тестах, как о инструменте для анализа работы кода. Но, автотесты (unit или другие) это не про анализ кода, а скорее про контракт в разработке. Пример в контексте интернет-магазина. Допустим мы пишем тест для функции расчета цены в корзине, мы фактически создаём правило, даже скорее закон, что корзина при таком вводном наборе данных, будет считать определенным образом. Следовательно, если мы меняем в коде, что-то связанное с корзиной, например функцию расчета стоимости товара, то запустив тесты мы увидим нарушили наши изменения метод расчёта цены в корзине или нет. Именно поэтому говнокод, покрытый юнит тестами, лучше отличного кода, но без них. Потому что код с нормальным покрытием тестами легко отрефакторить ничего не поломав.
3) Сложность.
Если честно не понимаю, почему вы считаете эти инструменты разработки сложными. Тот же git встроен везде и создание коммитов буквально занимает пару кликов. Git вообще не сложный на уровне рядового пользователя. Касаемо тестов, они так же не сложные в использовании. Могут возникнуть сложности в настройке, но она проводится разово для проекта. Тесты писать тоже не сложно, а с нейронкой это ускоряется в разы. Вы же описываете это так, словно работа с гитом, это что-то на уровне настройки кубера например или поднятия сервера с нуля под один проект.
П.С Если опять подытожить, то эти инструменты при грамотном использовании позволяют нормально работать почти с любыми проектами, а не на глазок.
П.П.С. Правильно понимаю, что вы дебагерами тоже не пользуетесь на бэке, раз всё правите в проде? Просто интересно.
1) Эффективнее в смысле "быстрее, удобнее"? Так нет, это всё дополнительные действия разработчику. Быстрее и удобнее это про ЛЛМ? Да и то не так сильно мне помогает, как в интернете пишут. "Качественнее"? Да, особенно юнит тесты. Насколько эффективнее в соотношения "цена/качества"? Как будто не супершибко. Опытные разработчики и менеджеры, контентщики, сеошники, заказчик тоже смогут обеспечить приемлемое качество, в то время как обширно покрыть юнит тестами это большой кусок работы, а значит стоимости.
2) Вы описываете очень редкие случая нужны в Гите. Типа все на компе пропало, а гитлаб спас. Можно не на компе, на яндекс диске держать если очень хочется, понятно что там не самые новые версии будут, но главное основа будет. Откат кода? В ручную зашёл, что то закометнил что то добавил как раньше было и вопрос решился. И вообще обычно нужно же не просто откатиться а имено понять и починить баг. А как его чинить если откатишь? Как раз таки последний код нужно поправить так чтобы заработало.
Ок знаю бывают серьезные проблемы, когда имено нужно ОТКАТИТЬ111. Тогда да резервная копия. Гитом удобнее развернуть прошлый код чем парится с резервной копией, возможно согласен. Однако это абсолютно нивелируется тем что резервные копии сами автоматом создаются. А с гитом мучаться надо постоянно вручную. Тыщу раз ради 1-го такого чуть более удобного отката. Совсем не окупается))
Текучка в 20 программистов это почти всегда кабзец проекту или очень плохое его качество. Куда хуже чем неиспользования Гита. И вообще есть масса вариантов запороть проект куда сильнее чем не использовать Гит.
3) Теперь про юнит тесты. В них есть смысл, так действительно бывает поправил что то одно, хоть как то это проверил возможно напрямую связанное, а что то не очевидное бац, поломалась. Автотесты от этого как то защитят (не гарантировано, но лучше как то чем ни как).
Однако тут есть два момента. Первый. Мне не может быть сайт больше нужен чем клиенту. Там ни такие уж огромные бюджеты выделяются. (Когда большие то нанимают тестировщика и это всё уже его задачи). Поэтому если я сделал какие то вещи на сайте. Как то глянул не заметил. Написал что "готово смотрите", остальное написали "спасибо" и всё на этом. То чего на меня пенять. Были бы очень заинтересованы сами посмотрели бы или на тестировщика дали. Второй я называю "Естественная эволюцию нахождения багов"))). По ней даже если никто особо не контролирует результат. Самые плохие, жирные, критические баги очень быстро всплывут сами и постучаться в окно. Более же незаметные они и менее разрушительные для сайта.
4) Конечно Гит сложен и не удобен. Эти ветки, комиты, чекауты, пуши, геты. ГОСПОДИ ПОМИЛУЙ если случится конфликт. Все же редко, но бывает что один и тот же файл в двоем отоварили. Так то мне пофигу не беда заново свой код написать, но просто написать, а не вот это вот всё...((( Про сложность написания юнит тестов вообще не скажу. Т.к. даже ни разу не спрашивали у меня такое на работе. Но вряд ли оно пыщ пыщ и готово))
5) Не эти инструменты усложняют, утяжеляют и удлиняют разработку продукта, ради не везде актуальных преимуществ. Хотя я конечно признаю, что нормально делать "на глазок" в сфере "обычных сайтов" может быть неприемлимо в других. Например предложи я так программировать в банковской сфере мне б ответили "Андрюша ты че с дуба рухнул, иди отседа пока цел)))" и были бы правы. Но там не тут))
6) Какие еще такие дебагеры?)) print.r(); console.log(); и log.txt с другими логами вот все мои дебагеры))
Эти ветки, комиты, чекауты, пуши, геты. ГОСПОДИ ПОМИЛУЙ если случится конфликт
В ветках нет ничего сложного. Переключение между ветками — это тоже всего одна команда. В пуше-то какая сложность? Будто по FTP/rsync файлы не нужно отправлять. Точно так же нужно. Только там придётся найти, какие из 5000 файлов менялись, каждый в свою директорию отправить, либо ждать, пока rsync проверит дату и размер каждого из этих файлов. А можно просто запушить все изменения в гит. git commit -a (если новых файлов не было) сам найдёт всё, что менялось, вы напишете комментарий, зачем вы их поменяли, и отправите как единое целое.
В конфликтах какая проблема? Видите две версии кода — решаете, какой из них новее, или как их объединить, чтобы вышло правильно. По FTP конфликтов не бывает да, там просто затирается всё, что делал другой разработчик. Точно так же можно сделать git push --force.
Тезисно отвечу на вопросы и моменты.
Эффективнее в смысле "быстрее, удобнее"? Так нет, это всё дополнительные действия разработчику.
Настройка IDE и проекта тоже дополнительные действия разработчику. По сути так можно сказать о любом инструменте для программирования.
Да, особенно юнит тесты. Насколько эффективнее в соотношения "цена/качества"? Как будто не супершибко.
В том-то и дело, что тестирование и git это про разработку, а не фичи сайта. Как и писал ранее, ваша логика странная. Так же можно сказать, например о IDE, насколько эффективнее в соотношении "цена/качество"? Как-будто не намного, ведь можно писать код в блокноте. Более того скажу, что например unit тесты обычно запускают под dev окружением, а не держат их на проде. Здесь вопрос в том, что есть проект на 100к и есть 2 программиста. Один напишет сайт в блокноте, а другой с использованием ide, git и тестами, причём сделают это они за одну цену. Только версия проекта от первого программиста будет со временем проблемной и будет обрастать багами, а версия второго программиста будет более стабильной и устойчивой к изменениям.
Опытные разработчики и менеджеры, контентщики, сеошники, заказчик тоже смогут обеспечить приемлемое качество, в то время как обширно покрыть юнит тестами это большой кусок работы, а значит стоимости
Т.е. вместо того, чтобы сделать свой код более устойчивым к багам, лучше переложить отсветственность поиска багов на всех коллег в полть до контент менеджеров? К слову, опытный тестировщик, всё-равно покроет тестами ваш проект, только не интегрированными. Мануальное тестирование уже давно не актуально. Касаемо сложности, вы сказали что с юнит тестами не работали, так почему вы считаете покрытие кода тестами сложной и обширной задачей? Вы сами решаете, как и что покрывать. Часто достаточно покрыть тестами критические места в коде, чтобы уже избежать огромного количества ошибок при будущих изменениях. И раз тут тема про отсветственность, то вам не кажется, что если ваш код будет постоянно выдавать много багов, которые даже до заказчика доходят минуя тестировщика и sео, то у кабан кабанынчей вполне могут быть к вам вопросы? Я всё понимаю, баги есть всегда при разработке, но не настолько же массовые, что они буквально повсюду. И вот тут встаёт вопрос, кто всё же бизнесу выгоднее, человек, что использует те же unit тесты и пытается предотвратить большинство багов заранее или тот, кто их не использует чиня одно ломая другое из-за чего баги ловят постоянно все, от sео до контент менеджеров заказчика?
понятно что там не самые новые версии будут, но главное основа будет
У меня буквально если бы не гитхаб, проекты разросаны по нескольким облакам, устройствам и дискам, в разных версиях. Гитхаб решает эту проблему, у вас всегда проекты последних версий под рукой. Так что это не какой-то редкий случай. Я не все свои старые проекты занёс в гитхаб, надо бы будет всё занести и то каждый раз удивляюсь, когда нахожу старый проект на диске с мыслью "о, я даже такое делал когда-то". Гитхаб хоть как-то это позволяет систематизировать. Так же я гит использую не только для кода. Например с ним очень удобно делать сборки модов для игр, потому что сразу видно какие моды заменяют файлы друг друга и можно очень быстро находить конфликты модов. Так же у меня obsidian со статьями заметками и т.д. подключён к гитхабу, что очень удобно. Так же у меня не раз бывали случаи до использования github, когда на основе одного плагина я писал разный функционал и потом приходилось искать в какой версии, сделан был нужный функционал. В гитхаб это были бы 2 разные ветки или просто один плагин с накопленным функционалом из проектов.
Откат кода? В ручную зашёл, что то закометнил что то добавил как раньше было и вопрос решился. И вообще обычно нужно же не просто откатиться а имено понять и починить баг. А как его чинить если откатишь? Как раз таки последний код нужно поправить так чтобы заработало.
Да, про то и речь. Если всё править на проде, то придётся вечно комментировать код, везде спамить print и им подобными командами и после нахождения и исправления бага, весь этот мусор с тестов по памяти удалять. С Github я могу спокойно при поиске бага удалять код, переписывать до неузнаваемости файлы, мусорить print и логгерами, писать любые тестовые инъекции, после того, как я пойму в чём причина бага и что надо поправить, даю команду "Отменить изменения" и меняю только то, что нужно для исправления бага и мне не нужно за собой подчищать код. Касаемо откатов, у меня часто бывали истории, когда просили убрать фичу с сайта, а потом "ой можете вернуть мы передумали, но с исправлениями". Я просто откатывался к нужному убранному функционалу, вспоминал, что там вообще было после чего возвращал её на сайт со всеми нужными изменениями.
Касаемо же резервных копий, то они сохраняют весь сайт, а не только его исходный код. Бэкапы нужны для быстрого восстановления сайта в целом. Хотя лично я в последнее время сохраняю в основном бд, потому что исходники есть в гитхаб и сайт восстановить не проблема, плюс место на vds экономится.
И вообще есть масса вариантов запороть проект куда сильнее чем не использовать Гит.
Как передать исходники и дать возможность менять проду без прямого доступа к ней по ssh ftp? Может способ и есть, но зачем, если самый просто это github.
Все же редко, но бывает что один и тот же файл в двоем отоварили. Так то мне пофигу не беда заново свой код написать, но просто написать, а не вот это вот всё...(((
Вы так уверенны, будто сможете найти, где именно коллега затёр ваш код. Это не так просто отследить вручную и пропустить такой момент легко. Как раз гит позволит все подобные конфликты показать и решить их довольно просто. Есть код ваш, есть код коллеги. Вы же в любом случаете сделаете это даже в ручном режиме или вы когда переписываете свой код, затираете код коллег?
Например предложи я так программировать в банковской сфере
Если взять наш пример с интернет-магазином. При неверном расчёте цен, скидок, налогов и т.д. так же можно нарваться на неприятности. Особенно если это не интернет-магазин с 1 заказом в неделю, а более менее средний. Я это к тому, что отрицать использование инструментов, там, где они будут полезны, странная позиция.)
Я думаю вы рано или поздно сами придёте к использованию обсуждаемых нами инструментов.) В любом случае, вам этого желаю искренне, потому что по описанию вашей работы, это поможет вам её упростить.)
П.С. Если уж разрабатываете в проде, то надеюсь вы хоть используйте pulsar с этим плагином https://packages.pulsar-edit.dev/packages/ftp-remote-edit или что-то подобное, а не кидаете файлы через FileZilla или scp) Очень советую эту связку, до того, как начал гитхаб использовать сам с ней активно работал, только тогда вместо pulsar был atom. Ну pulsar это fork atom.)
Не знаю, что есть в pulsar, но я для этих целей пользовался sshfs. У меня виндовых серверов не было, а ssh-доступ был.
1) Верно. Поэтому я использую обычный Notepad++
2) Не понимаю. Почему у опытного программиста, особенно типовой проект, от которого не требуется стоять на голове. Должен обязательно скатиться в уровень "плохо". Когда опыт говорит обратное. Я согласен что с тестировщиками (про гит не согласен) качество существенно лучше, работать удобнее, было где сравнить. Да и баги что важно прилетают не в окно по голове, а культурно до прода. Однако и сказать что без профессионального тестирования качество обязательно "ужасно" нельзя.
3) Если на проекте нет специального существующего для этого специалиста тестировщика. То с чего-й то программист обязательно за него ответственным автоматически становится???! Нет, конечно. Ответственность делится на всех.
4) Для отладки кода в файле есть комментарии, cntrl+z cntrl+y cntrl-x cntrl+v, в конце концов можно просто в отдельную вкладку временно перенести потом вернуть. Это обычный рабочий процесс непосредственно в данный промежуток времени. Не понимаю ради небольших преимуществ постоянно с гитом мучаться все равно.
5) Для сборки модов для игр есть удобный лаунчер Mod Manager
6) Да я уверен что найду, какой код затёр второй разработчик. Это же не так происходит, что через полгода он взял открыл мой файл и чето затёр, а я не знаю. Такое может быть, но скорей всего он делал это осмысленно для чего то. Речь идёт имено об одномоментном редактировании файла. А значит есть фокус на этот файл и на задачи которые он решает.
7) Ни разу за карьеру у меня никто никого за баги не увольнял.Т.е. если прям там массово ничего не работает это серьезная проблема, но она скорей всего объясняется тем что человек неопытный и плохо разбирается в основной теме. Тогда да могут с ним расстаться, а могут и помочь джуну дать более легкие проекты(все таки люди же). Основная причина почему расставились с персоналам. Это он вообще на работу забивал, ни делал, или требовал много денег за проект и за каждую мелкую доработку чтоб платили. За баги же и даже за отказ от развития ни одного разработчика на моей памяти ещё не уволили.
8) При неверном расчёте цен, скидок, налогов и т.д. так же можно нарваться на неприятности. Во-первых вероятно это быстро заметят. Чтобы нанесло большой ущерб. Во-вторых если есть тестировщик неприятности будут у него, а если то все равно не у меня, сами виноваты что его нет.
9) Неее 12 лет без Гита жил и дальше до старости так же буду. Четенько без прибамбасов))
10) Спасибо. Отложил в закладки. Если будет как то много работы по сайту. Попробую поставлю. Если всё автоматом будет происходить и облегчит работу. То ваще реальное большое спасибо!! От ЛЛМок я тоже нос крутил. А как попробовал тот же режим ИИ в Гугле помогает, пусть и чудеса не творит. Мне нравятся инструменты, которые вообще не требуют ничего для их использования, а просто бери и делай как всегда.
За все задачи, что поступают мне ответственен я, пока они не будут выполнены, либо пока на 100% не буду уверен, что проблема не в моей зоне ответственности, после чего передам тикет с подробным описанием ресёрча и всеми обоснованиями, предположениями, тестами.
Очень классная формулировка 👍
Как раз хорошо видно подход: довести до результата, а не просто передать дальше.
А что если в случае ответа "Я за всё отвечаю" от сильного разработчика, вышестоящий увидит угрозу своему креслу и отклонит кандидата под другим предлогом?
Все сильно зависит от этапа на котором находится задача и на разных этапах граница ответственности может размываться.
Когда задача проходит ревью, когда задача уходит в тестирование и даже когда залетает в прод. Ответ «Я», на мой взгляд, не совсем корректен, всё зависит от выстроенного процесса.
Скорее не согласен. Как раз пытался подсветить, что наша главная цель, чтобы конечный клиент получил решение своей проблемы. А попытка ограничить свою зону маленьким куском - заканчивается обычно тем, что тикеты просто закрывают без решения.
В данном случае, если организация высокобюджетная, такой ситуацией должен заняться лично вручную тимлид. Применить свои технические навыки хотя бы до момента точного определение кто должен заняться этим вопросом и как. Либо вообще нужен ещё один сотрудник для решения таких вопросов.
Ещё есть варианты с объявлением награды тому кто справиться. В конце концов просто забить на баг это тоже тоже выход, если сфера низкобюджетная и таких других клиентов десятки.
Однако жаловаться на то что сотрудники не хотят воспринимать любую проблему вне прямой зоны ответственности как личную. Как будто самый худший.
Вопросы для разведения полемики, имхо
Цель их крутая - понять как человек мыслит, а не какие технологии знает, за это респект.
СТРЕЛА АРИМАНА
Иван Антонович Ефремов - среди огромного количества фундаментальных открытий, сделанных в самых различных областях - ввел понятие т.н. "Стрелы Аримана". Которое он определял как: "...тенденцию плохо устроенного общества с морально тяжелой ноосферой умножать зло и горе." В результате чего "...каждое действие, хотя бы внешне гуманное, оборачивается бедствием для отдельных людей, целых групп и всего человечества...".
На самом деле открытие "Стрелы Аримана" - это само по себе фундаментальный скачок в понимании процессов социальной динамики, невероятно важное понятие, которое само по себе стоит целых трактатов и монографий "на тему этики". (А Ефремов вводит его походя, как часть приключенческого романа!) Хотя, конечно, постфактум кажется, что это же элементарно! Это же просто выводится из законов диалектики: "...Идея, провозглашающая добро, имеет тенденцию по мере исполнения нести с собой все больше плохого, становиться вредоносной..." Ну да, отрицание отрицания в чистом виде!
Однако ДО Ефремова подобные вопросы мало кто рисковал поднимать. (Ну да, как же это может быть: зло порождается добром! Это же противоречит всем обыденным "истинам". Хотя на самом деле именно то, что противоречит этим обыденным истинам, и является верным.) Но теперь, после того, как "Час Быка" не просто написан и опубликован, но и прочитан "любым образованным человеком", стоит только удивляться тому, что указанное вспоминается так редко!
Лично мои аргументированные ответы на вопросы:
Я (бэкенд, в основном крупные банки) отвечаю за задачу в области технической реализации, здравого смысла при даблчеке аналитики и качестве (если QA не нашли баг, то проблема не в QA, а в моём коде всё же). Я не могу отвечать за фронт и бизнесовые решения при всём желании - сроки всегда сжатые и играть на всех ролях я просто не успею, хотя такой опыт тоже был вне банков. За настройку инфры могу отвечать частично, тут уже есть место для обсуждений.
Зависит от сроков и количества задач. Если сроки не горят - могу сделать тестовое покрытие, если горят - более приоритетно сделать задачу
Хорошие ответы!
Почему хорошие ответы:
1) Взяли на себя ответственность за свою часть. Это очень хороший сигнал.
2) Фраза "в области здравого смысла" - это прямо топ и с такими людьми и хочется работать.
3) Показали, что есть опыт - брать на себя ответственность.
4) Показали какие ограничения у вас есть. (Что очень логично, чтобы бэк хорош в бэке, не во фронте и в бизнес части).
5) Показали, что умеете писать тесты.
Уважаемый @sg4tech
А как бы вы оценили если бы вам на ваш второй вопрос задали контр-вопрос "Используете ли вы TDD в связке например со spec-kit?" Интересует именно ваше мнение?
Огромный проект. Много команд: мобильные, бэкенд, инфраструктура, ПОДДЕРЖКА, АНАЛИТИКИ, ТЕСТИРОВАНИЕ.
Но некому:
пройтись по логам, воспроизвести сценарий
Конечно же, лучший кандидат - это бэкендер) Всегда крайний. А получает как фронты и девопсы, хотя единственный знает, как устроена вся система end2end.
У покрытия юнит тестами есть 2 стороны. Первая - это повышение надёжности и сопровождаемости кода, тут бесспорно. Но на этом по сути и всё. Дальше идут недостатки:
Увеличение времени написания кода. Тут, конечно, не всё однозначно. Если участок кода - это алгоритм, который не укладывается легко в голове разработчика, то юнит тесты наоборот ускорят процесс. Но чаще всего код простой, вида, возьми отсюда, положи сюда, дёрни этот сервис, дёрни тот. Юнит тесты такого кода превращаются в сплошные моки, которые потом задолбаешься сопровождать. Например, в стартапе с 1-2 сеньёрами покрытие юнит тестами всего и вся только похоронит стартап. Так что it depends.
Вносить изменения сложнее, если они меняют интерфейсную часть, не говоря уже о серьёзных переделках.
Юнит тесты на UI - это отдельный вид извращенства.
Ещё есть такая проблема, что программист пишет юнит тесты формально, т.е. чтобы только был прогон всех строчек кода, но при этом тесты сами по себе не имеющие самостоятельного смысла. Например, тест, проверяющий, что метод контроллера вызывает метод сервиса. Да, логчино, что такой вызов должен быть, но такой тест даёт всего-лишь ложное покрытие, не проверяющее ни какой логики работы метода (т.е. формально весь код метода выполняется и помечается в coverage report, но по факту можно изменить кучу мест в этом методе, лишь бы не трогать вызов сервиса, и тогда сломанный метод будет вполне себе проходить все тесты).
Не исключаю того, что чем больше проект и программистов на нём, тем больше смысла в том, чтобы делать всё под одну гребёнку (тащить все best practices), потому-что разбираться с каждым по-отдельности сложно, но не нужно считать это применимым всегда и везде, нужно более рационально подходить. Иногда рациональнее отвёркой вкрутить несколько саморезов, чем пытаться впихнуть шуруповёрт.
Когда-то ввел на проекте, где была подобная проблема с перекладыванием багов друг на друга, очень простое правило. Если к тебе прилетел рандомный баг. Твой-не твой, без разницы. Ты можешь его отправить кому хочешь и хоть сразу. Но если вдруг, в итоге, выясняется что баг был твой и ошибку допустил именно ты, а баг ты кому-то отправил и сам не дожал - автоматическое депримирование. Мотивация разбираться в проблеме, вместо того чтобы перекидывать мяч, выросла и проблем больше не возникало.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Два вопроса, которые скажут о разработчике и тимлиде больше, чем техническое интервью