Ну как и среди программистов, много подобных специалистов, за которыми часто приходиться переделывать, но это не отменяет того факта, что среди программистов много хороших специалистов. Так же с любой сферой) Мой посыл заключается в том, что программирование не должно быть уделом избранных, оно должно быть повсеместным, но как и с другими специальностями, должны быть специалисты и обычные люди/любители. При этом это никак не исключает отсутствие на рынке плохих специалистов и умелых самоучек любителей.)
Однако, хороший специалист сантехник может работать далеко не только с локальными системами в квартирах или домах, но и с более сложными и глобольными системами. Как например специалист электрик, может работать с высоковольтными сетями, а обычный любитель нет, даже если он идеально умеет делать проводку в доме. Т.е. разница в этом. Тоже самое и с программистами. Обычный человек без профильных знаний не сможет создать даже при помощи самых крутых нейронок средней/большой проект с долгосрочной поддержкой и развитием. Максимум, что он создаст - прототип. В этом разница и она никак не отменяет наличие в сфере людей, которые имеют мало опыта например, но считают себя более компетентными, чем они есть на самом деле. Это обыденность везде)
Я относительно недавно попросил написать похожий скрипт у gpt и он вполне себе справился с написанием скрипта. Там же ничего сложного нет, такие любой программист сам напишет легко и подобными скриптами/прогами весь интернет завален, на которых нейронки и обучали в своём большинстве (на опен сорс проектах).
Что? Т.е. обычный скрипт склейки файлов будет виноват в утечке данных? Я надеюсь это уже просто шутки пошли. Потому что с таким подходом можно, что угодно на фантазировать.)
Но сможет он например по ним сделать join или сделать update одним по полям другого? Нейронка такие скрипты пишет спокойно.
Касаемо того, что говнокод, так с обычных людей и спроса нет. Они вправе говнокодить себе простой софт для автоматизации своих задач, как угодно и на чём угодно. Да хоть на миллионах ифов с O(n^4). Если это работает и решает их задачи, то и пофиг, они не программисты.
Так же ничего особенного не поменялось. Раньше ксеждый студент писал кучу мелких скриптов, что выкладывал на open code или github. Почти все подобные скрипты написаны были ещё со времён дельфи и вин форм. Просто сейчас их даже искать не надо, gpt напишет за 1-2 запроса.
Если приводить аналогию. Каждый из нас в какой-то степени разбирается в электрике и сантехнике, но при этом электрики и сантехники никуда не делись и для них наши бытовые потуги "я сам всё сделаю", выглядит так же, как для нас говнокод, но кому не пофиг, если работает нормально? Это не энтерпрайз, где надо обновлять код вдолгую и архитектура обширная)
Касаемо саасопокалипсиса, то это закономерно и случилось бы в любом случае. Ещё Стив Джобс говорил, что каждый должен научиться программировать. Понятно, что на базовом уровне, для решения своих задач и эта мысль правильная. Сейчас просто программирование на базовом уровне стало доступно большинству. Большие и даже средние проекты без знаний и навыков не сделаешь, но вот автоматизация рутинных задач нейронкам по плечу.
Касаемо саас. Те что несут в себе что-то полезное на рынке останутся. Те проекты которые были навайбкожены в 23-24 годах умрут. Так же останутся популярны АИ сервисы какое-то время, хотя уже сейчас многие пишут свои клиенты для тех же локальных нейронок. Это к тому, что будут популярны вдолгую именно ai инструменты, а не просто чатики.
1) Если человек прислал в тестовом код от которого смердит, то зачем вообще его на собес звать? Чтобы "играючи с азартом", за счёт него самоутвердиться? На найм и так много времени уходит. Если человек не подходит - не стоит тратить время ни его, ни своё. Это моя позиция, она может быть не эффективная, но все мы не без минусов.
2) Автор описал вайбкодеров двух типов, за которых всё делает клод и они вообще не понимают, что там нейронка понаписала, либо те, что крипипастят из gpt и так же не понимают контекста. Я согласен, что такие специалисты посредственные, но вопрос у меня в том, что зачем вообще было тратить на них время? Чтобы написать потом статью, какие вайбкодеры неумехи? Думаю это не для кого ни секрет. Даже для них самих. Многие вайбкодеры нашли себя в других областях, где контроль качества кода не так важен.
Человек может нести ответственность только за тот код, который он понимает.
Программист несёт ответственность за любой код в проектах его зоны ответственности и не важно понимает он его или нет. Если я завтра на работе навайбкожу какой-нибудь софт например на плюсах, которые плохо знаю и этот код повлечёт за собой проблемы, то отвечать за него буду я. Потому что кабан кабанычам на мои оправдания в виде: "это косяк нейрнки", будет плевать и это правильно. Нейронки - это инструмент и ответственность за выбор инструмента и контроль качества своей работы несёт работник. Если инструмент проблемный, то вопрос к работнику зачем он его вообще использовал. Решил этот момент уточнить)
Всё это ерунда, компаниям с резюме, что фильтруют кандидатов при помощи нейронок (часто не самых лучших), нужно отсылать только инструкцию по варке пельменей. 😎
Причём тут зп, название компании, количество этапов.
Дело конкретно в вашей статье под которой комментарий и отношении к кандидатам.
Человек ещё на работу не устроился, а у вас уже отношение к нему, как к говну, которое можно отсеять "с азартом". При этом в тех. вопросах вообще нет никакой конкретики, как llm можно использовать в разработке для реального повышения производительности при контроле качества, а так же с чем нейронки справляются хорошо, а где быстре и лучше писать код ручками. Это обширная тема, которой только тут на хабре посвещено много статей.
Я согласен с тем, что программист несёт ответственность за свой код и неважно написал он его вручную или нейронкой, но это не повод считать людей, которые умеют грамотно использовать нейронки в энтерпрайз разработке, вторым сортом.
Далее, может конечно мне показалось, но у вас как-будто проявляется высокомерие. Мол смотрите холопы, мы тут в Германии! Мидла 5+ лет опыта ищем и над вайбкодерами смеёмся. Понимать надо. Я работал на заграничные фирмы и находящиеся в Германии в том числе. Таких людей на хабре много, это ни для кого не панты уже давно. Может мне конечно показалось, но первое впечатление было таким.
Если смоделировать ситуацию, придя лично к вам на собес, увижу предвзятое отношения с высока, странные тех. вопросы и желение от меня поскорее играюче избавиться. Я бы понимал, что в случае трудоустройства, пришлось бы все делать не для эффективного решения задач, а для решения их, как бы вам это нравилось. Конечно хозяин барин, но зачем мне это терпеть?
Собственно, лично у меня ваша статья вызвала такие впечатления. Может они ошибочны, но я ответил на ваш вопрос именно про себя, т.к. изначально писал про себя.
Честно, как нормальный мидл, к автору этой статьи работать не пошел бы. Собственно поэтому наверное и были вайбкодеры одни, т.к. нормальные специалисты просто скипали вакансию на уровне собеса.
2) Про бюджеты согласен, но понимаете, здесь всё упирается в главную тему нашего спора. Вы утверждаете, что git и unit это сложно, долго и дорого, но на деле эти инструменты сейчас более доступные. На вордпресс например есть насколько помню плагин, который чуть ли не из админки позволяет делать юнит тесты. Да извращение, но такое есть. Касаемо git, то во многом дело привычки. Он не замедляет разработку, как вам может показаться.
4) Ну смотря как использовать, но думаю точно не навредит)
5) Ну да, Nexus же и создал Vortex) Сборки создавать можно не спорю, я скорее про те игры, которых на Nexus нет.)
6) Тут важный момент для понимания. Git и Unit не являются чудо инструментами, что отменяют опыт и скил. Нет. Плохой программист может хоть кубер под сайт визитку на cms поднимать, ему это не поможет.) Это как раз всё в дополнении к тому что вы описали. Я и не пытался сказать, мол "если программист не опытный или косячный, то Git из него сделает сеньора 20 лет стаж")
7) Как я и пишу, юнит тесты сильно помогают в долгую дистанцию, но вы и так согласились с этим ранее.
8) Так-то и ваша в том числе. Не допускать баги до прода, это обязанность всей цепочки IT отдела.) Кабан кабаныч не будет разбираться, кто там из вас "первый начал", люлей выдаст всем)
9) Система, которую вы описали она никак не вообще не мешает или не противоречит Git. Git ближе к сэйвам в играх, если проводить аналогию, в то время как cntrl+z, cntrl+y, cntrl+s это скорее игровые механики. Т.е. это просто разный уровень работы с кодом. Не в плане профессионализма, а в плане взаимодействия. Если cntrl+z, cntrl+y это очередь изменений, а cntrl+s просто сохранение файла, то git это про сохранение состояния множества файлов и историй изменений. Или вы думаете я cntrl+z, cntrl+y, cntrl+s в работе не использую? Ещё как использую и гит использую тоже)
2) Для опытного программиста с типовым проектом, не будет проблемой использовать git, как и покрыть его тестами, только если время прямо совсем не поджимает.)
3) Тестировщик проводит более глобальное тестирование, он не пишет интеграционные тесты, т.к. тестировщик не должен лезть в код, что логично.) Юнит тесты это именно про стабильную работу кода и про уменьшение багов при внесении множества изменений на протяжении долгого времени.
4) Я не совсем понимаю, в чём именно состоят мучения если git и github, буквально имеют UI приложения и интегрированы во все IDE. Даже для notepad++ есть плагин, что интегрирует git (забавно): https://github.com/alansbraga/NPPGit Вся работа сводится буквально к нажатию нескольких кнопок в UI.
5) Mod Manager вещь хорошая, тот же Vortex от Нексуса например, но они поддерживают не все игры. Плюс Mod Manager'ы не дают такого функционала, как Git. Я буквально могу сделать например несколько веток одной и той же сборки модов, с некоторыми изменениями в каждой и переключаться между ними моментально.
6) Обычно в разработке правят код не в одном файле, а в нескольких, особенно если это не спагетти код в одном фале на 1000+ строк кода. Просто не совсем понимаю, зачем вообще такое держать в голове, если можно автоматизировать и быть спокойным.
7) Я и говорю про моменты, когда багов прямо очень много и они критические. Баги же бывают разные. Есть критические (не верный расчёт цен в той же корзине при определённых условиях), есть не особо то и важные (как например лагающий стиль кнопки). Юнит тесты позволяют меньше допускать именно критических багов при разработке с дальнейшими доработками и нововведениями.
8) Если в вашем примере, ошибка в коде и она не явная, то проблемы будут не у тестировщика. Точнее спросят и с него и с вас. Т.к. тестировщик отдаст тикет с этим багом вам обратно.
Вроде как вопросов осталось меньше, они касаются в основном, git. Я вот честно не понимаю, чем он вас так отпугивает.
Эффективнее в смысле "быстрее, удобнее"? Так нет, это всё дополнительные действия разработчику.
Настройка 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.)
Всё описано верно, только я не понимаю одного. Во всех подобных статьях говорят, что ИИ любит когда в контенте есть видео/аудио/интерактив. Некоторые даже пишут, что видео проекты по типу GPT воспринимают лучше. Однако, это не совсем так. В основе любой описанной нейросети находится LLM, которая умеет работать только с текстом. Нейросети ищут информацию в интернете при помощи классических инструментов. Для ИИ ссылка на видео в вашем контенте, вообще ни о чём не говорит. Т.е. тот же gpt не будет переводить всё видео в текст и как-то его анализировать. Тоже самое с аудио или интерактивом (например мини игра с рендером в canvas). Если с ютубом такое может проканать, потому что он сам делает субтитры и некоторые проекты могут иметь такой функционал, но большинство его всё же не имеют.
Следовательно, очень желательно под каждым не текстовым контентом добавлять описание, субтитры (если видео/аудио небольшое). Для картинок обязательно alt.
Это очень важная информация, которую нужно проговаривать.
Да всё смешалось в кучу, поэтому давайте разобьём все на подтемы.
1) Пример с ценой.
Здесь вообще какое-то недопонимание, поэтому скажу кратко. Git, Github, Unit тесты, это не функционал движка или фреймворка. Это такие же инструменты, как и IDE. Это не фишки сайта, а инструменты, которые позволяют разработчикам более эффективно создавать сайт (и не только сайты просто в контексте примера).
2) Для чего вообще Git и Unit тесты нужны?
Читая ваши комментарии мне кажется вы плохо понимаете, зачем вообще нужны эти инструменты и как они работают. Я не буду писать лекции это ни к чему.
Git, Github (да любая система контроля версий), полезен, даже для пет проектов без использования нейронок. Нужен помимо ведения истории изменения кода, для многих вещей. Например, откат кода (без залегания в бэкапы брр, я так делал последний раз наверное лет 10 назад), ко всем зафиксированным состояниям, что часто полезно. Быстрый деплой, возможность создания веток для того чтобы иметь, например несколько вариантов проектов, между которыми можно переключаться по нажатию одной кнопки. И это я за CI/CD молчу, которые поверьте встречаются и в небольших конторах довольно часто. В плане работы в команде, гит это базовый инструмент без которого работа сведётся либо к коллапсу архивов в лс, либо к вечным ошибкам 500 на проде. Про кодовую базу так же гитхаб просто удобнее. Хранить доступы ко всем серверам проектов или просто иметь папочку на диске можно, но как человек, который имел несколько пк, часто переезжал, это просто неудобно. По итогу, у меня есть папки с древними проектами, чуть ли не со студеньчества на hhd, но если бы я не перетащил всё в гитхаб или хотя бы в облако, то умер бы hhd, проектам можно сказать пока. Кстати то что можно быстро развернуть проект на разных устройствах это тоже плюс. Тут же можно упомянуть ваш пример с текучкой. Работая, через проду, если есть текучка кадров, вам придется дать доступ к проде для всех 20 программистов, которые могут по незнанию или специально всё поломать на уровне сервера. Github позволяет допускать программистов только до исходников, а иногда только до определенной его части, например если человеку надо доработать поагин, зачем ему доступ к коду всех плагинов сайта? Бизнесу это важно, уж поверьте.
Unit тесты. Вы сказали фразу, что при говнокоде тесты покажут мол "пациент сдох", у вас странное представление о тестах, как о инструменте для анализа работы кода. Но, автотесты (unit или другие) это не про анализ кода, а скорее про контракт в разработке. Пример в контексте интернет-магазина. Допустим мы пишем тест для функции расчета цены в корзине, мы фактически создаём правило, даже скорее закон, что корзина при таком вводном наборе данных, будет считать определенным образом. Следовательно, если мы меняем в коде, что-то связанное с корзиной, например функцию расчета стоимости товара, то запустив тесты мы увидим нарушили наши изменения метод расчёта цены в корзине или нет. Именно поэтому говнокод, покрытый юнит тестами, лучше отличного кода, но без них. Потому что код с нормальным покрытием тестами легко отрефакторить ничего не поломав.
3) Сложность.
Если честно не понимаю, почему вы считаете эти инструменты разработки сложными. Тот же git встроен везде и создание коммитов буквально занимает пару кликов. Git вообще не сложный на уровне рядового пользователя. Касаемо тестов, они так же не сложные в использовании. Могут возникнуть сложности в настройке, но она проводится разово для проекта. Тесты писать тоже не сложно, а с нейронкой это ускоряется в разы. Вы же описываете это так, словно работа с гитом, это что-то на уровне настройки кубера например или поднятия сервера с нуля под один проект.
П.С Если опять подытожить, то эти инструменты при грамотном использовании позволяют нормально работать почти с любыми проектами, а не на глазок.
П.П.С. Правильно понимаю, что вы дебагерами тоже не пользуетесь на бэке, раз всё правите в проде? Просто интересно.
Касаемо цен. Что 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 код может вполне иметь много багов, просто не таких явных.
Ну я конкретно в веб разработке поменьше, лет 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% не буду уверен, что проблема не в моей зоне ответственности, после чего передам тикет с подробным описанием ресёрча и всеми обоснованиями, предположениями, тестами. Чего буду в подобных ситуациях ждать и от коллег, а не просто "у нас всё хорошо, ищите сами", я то найду, но если выяснится, что проблема всё же на строне коллег выйдет неприятный момент.
Касаемо тестов. Ответ в наших реалиях очень простой. Без git и unit тестов даже разработка пет проектов невозможна. Это базовый минимум в наши дни, особенно с приходом llm, которые программисты любят использовать, но не особо любят ревювить их код. Без тестов, проект сейчас просто невозможно адекватно поддерживать вдолгую. Какую бы вы замороченную и идеальную архитектуру не выбрали и какую бы навороченную инфру вокруг неё не выстроили, без тестов это превратиться со временем в кучу малу.
Имхо, но эти вопросы сейчас валидны для всех. Я мидл разработчик и это 2 базовых вопроса, которые и джунам задают.
Мне кажется сейчас в принципе актуальнее вопрос про ответственность, потому что именно за неё мы получаем зп. Контракт с бизнесом очень прост. Бизнес платит деньги нам не за писульки кода, а за ответственность стабильной работы созданных по запросу бизнеса решений. Всем плевать, что вы использовали лучшие практики. Если что-то не работает спрашивают с нас. Да да, капитан очевидность, но вы даже не представляете, как много людей не понимают этой простой истины. Бизнес не будет слушать про, то что json'ы пользователю не приходят из-за особенностей вашей же выстроенной архитектуры, он найдет вместо вас тех, кто сделает так, чтобы json'ы приходили, если вы не хотите нести за это ответственность.
В то время, как tg давно создал mini app и полноценную экосистему внутри своего приложения, мах завёз ботов без какой-либо тех. поддержки, доступных не всем, так ещё и работающих криво судя по комментариям.
Имхо, но если уж быть турбопатриотом, то даже вк выглядит намного лучше в этом плане, потому что он имеет свою устоявшуюся годами экосистему с ботами и аналогом mini app, а так же нормальным саппортом и документацией и главное даже в нём создание ботов доступно всем.
Если что, не пиарю вк (потому что его современные владельцы создали макс), просто говорю какое же говно вам пытаются скормить взамен тг и других мессенджеров. Честно, учитывая какое отношение к максу у народа, я бы просто его уже закрыл и не мучил. Но учитывая, что макс принадлежит, вроде как сынку Кириенко и что на нём наверное пилят огромные бабки, никто ничего сворачивать не собирается.
Я пробежался по комитам и есть ощущение, что проект полностью навайбкожен. Ничего против использования в программировании нейронок не имею, но такое ощущение, что автор в целом плохо разбирается в программировании. Отсюда и вск вышеописанные проблемы. Хотя, могу ошибаться.
Ну как и среди программистов, много подобных специалистов, за которыми часто приходиться переделывать, но это не отменяет того факта, что среди программистов много хороших специалистов. Так же с любой сферой) Мой посыл заключается в том, что программирование не должно быть уделом избранных, оно должно быть повсеместным, но как и с другими специальностями, должны быть специалисты и обычные люди/любители. При этом это никак не исключает отсутствие на рынке плохих специалистов и умелых самоучек любителей.)
Однако, хороший специалист сантехник может работать далеко не только с локальными системами в квартирах или домах, но и с более сложными и глобольными системами. Как например специалист электрик, может работать с высоковольтными сетями, а обычный любитель нет, даже если он идеально умеет делать проводку в доме. Т.е. разница в этом. Тоже самое и с программистами. Обычный человек без профильных знаний не сможет создать даже при помощи самых крутых нейронок средней/большой проект с долгосрочной поддержкой и развитием. Максимум, что он создаст - прототип. В этом разница и она никак не отменяет наличие в сфере людей, которые имеют мало опыта например, но считают себя более компетентными, чем они есть на самом деле. Это обыденность везде)
Я относительно недавно попросил написать похожий скрипт у gpt и он вполне себе справился с написанием скрипта. Там же ничего сложного нет, такие любой программист сам напишет легко и подобными скриптами/прогами весь интернет завален, на которых нейронки и обучали в своём большинстве (на опен сорс проектах).
Что? Т.е. обычный скрипт склейки файлов будет виноват в утечке данных? Я надеюсь это уже просто шутки пошли. Потому что с таким подходом можно, что угодно на фантазировать.)
Но сможет он например по ним сделать join или сделать update одним по полям другого? Нейронка такие скрипты пишет спокойно.
Касаемо того, что говнокод, так с обычных людей и спроса нет. Они вправе говнокодить себе простой софт для автоматизации своих задач, как угодно и на чём угодно. Да хоть на миллионах ифов с O(n^4). Если это работает и решает их задачи, то и пофиг, они не программисты.
Так же ничего особенного не поменялось. Раньше ксеждый студент писал кучу мелких скриптов, что выкладывал на open code или github. Почти все подобные скрипты написаны были ещё со времён дельфи и вин форм. Просто сейчас их даже искать не надо, gpt напишет за 1-2 запроса.
Если приводить аналогию. Каждый из нас в какой-то степени разбирается в электрике и сантехнике, но при этом электрики и сантехники никуда не делись и для них наши бытовые потуги "я сам всё сделаю", выглядит так же, как для нас говнокод, но кому не пофиг, если работает нормально? Это не энтерпрайз, где надо обновлять код вдолгую и архитектура обширная)
Касаемо саасопокалипсиса, то это закономерно и случилось бы в любом случае. Ещё Стив Джобс говорил, что каждый должен научиться программировать. Понятно, что на базовом уровне, для решения своих задач и эта мысль правильная. Сейчас просто программирование на базовом уровне стало доступно большинству. Большие и даже средние проекты без знаний и навыков не сделаешь, но вот автоматизация рутинных задач нейронкам по плечу.
Касаемо саас. Те что несут в себе что-то полезное на рынке останутся. Те проекты которые были навайбкожены в 23-24 годах умрут. Так же останутся популярны АИ сервисы какое-то время, хотя уже сейчас многие пишут свои клиенты для тех же локальных нейронок. Это к тому, что будут популярны вдолгую именно ai инструменты, а не просто чатики.
1) Если человек прислал в тестовом код от которого смердит, то зачем вообще его на собес звать? Чтобы "играючи с азартом", за счёт него самоутвердиться? На найм и так много времени уходит. Если человек не подходит - не стоит тратить время ни его, ни своё. Это моя позиция, она может быть не эффективная, но все мы не без минусов.
2) Автор описал вайбкодеров двух типов, за которых всё делает клод и они вообще не понимают, что там нейронка понаписала, либо те, что крипипастят из gpt и так же не понимают контекста. Я согласен, что такие специалисты посредственные, но вопрос у меня в том, что зачем вообще было тратить на них время? Чтобы написать потом статью, какие вайбкодеры неумехи? Думаю это не для кого ни секрет. Даже для них самих. Многие вайбкодеры нашли себя в других областях, где контроль качества кода не так важен.
Программист несёт ответственность за любой код в проектах его зоны ответственности и не важно понимает он его или нет. Если я завтра на работе навайбкожу какой-нибудь софт например на плюсах, которые плохо знаю и этот код повлечёт за собой проблемы, то отвечать за него буду я. Потому что кабан кабанычам на мои оправдания в виде: "это косяк нейрнки", будет плевать и это правильно. Нейронки - это инструмент и ответственность за выбор инструмента и контроль качества своей работы несёт работник. Если инструмент проблемный, то вопрос к работнику зачем он его вообще использовал. Решил этот момент уточнить)
Всё это ерунда, компаниям с резюме, что фильтруют кандидатов при помощи нейронок (часто не самых лучших), нужно отсылать только инструкцию по варке пельменей. 😎
Причём тут зп, название компании, количество этапов.
Дело конкретно в вашей статье под которой комментарий и отношении к кандидатам.
Человек ещё на работу не устроился, а у вас уже отношение к нему, как к говну, которое можно отсеять "с азартом". При этом в тех. вопросах вообще нет никакой конкретики, как llm можно использовать в разработке для реального повышения производительности при контроле качества, а так же с чем нейронки справляются хорошо, а где быстре и лучше писать код ручками. Это обширная тема, которой только тут на хабре посвещено много статей.
Я согласен с тем, что программист несёт ответственность за свой код и неважно написал он его вручную или нейронкой, но это не повод считать людей, которые умеют грамотно использовать нейронки в энтерпрайз разработке, вторым сортом.
Далее, может конечно мне показалось, но у вас как-будто проявляется высокомерие. Мол смотрите холопы, мы тут в Германии! Мидла 5+ лет опыта ищем и над вайбкодерами смеёмся. Понимать надо. Я работал на заграничные фирмы и находящиеся в Германии в том числе. Таких людей на хабре много, это ни для кого не панты уже давно. Может мне конечно показалось, но первое впечатление было таким.
Если смоделировать ситуацию, придя лично к вам на собес, увижу предвзятое отношения с высока, странные тех. вопросы и желение от меня поскорее играюче избавиться. Я бы понимал, что в случае трудоустройства, пришлось бы все делать не для эффективного решения задач, а для решения их, как бы вам это нравилось. Конечно хозяин барин, но зачем мне это терпеть?
Собственно, лично у меня ваша статья вызвала такие впечатления. Может они ошибочны, но я ответил на ваш вопрос именно про себя, т.к. изначально писал про себя.
Честно, как нормальный мидл, к автору этой статьи работать не пошел бы. Собственно поэтому наверное и были вайбкодеры одни, т.к. нормальные специалисты просто скипали вакансию на уровне собеса.
2) Про бюджеты согласен, но понимаете, здесь всё упирается в главную тему нашего спора. Вы утверждаете, что git и unit это сложно, долго и дорого, но на деле эти инструменты сейчас более доступные. На вордпресс например есть насколько помню плагин, который чуть ли не из админки позволяет делать юнит тесты. Да извращение, но такое есть. Касаемо git, то во многом дело привычки. Он не замедляет разработку, как вам может показаться.
4) Ну смотря как использовать, но думаю точно не навредит)
5) Ну да, Nexus же и создал Vortex) Сборки создавать можно не спорю, я скорее про те игры, которых на Nexus нет.)
6) Тут важный момент для понимания. Git и Unit не являются чудо инструментами, что отменяют опыт и скил. Нет. Плохой программист может хоть кубер под сайт визитку на cms поднимать, ему это не поможет.) Это как раз всё в дополнении к тому что вы описали. Я и не пытался сказать, мол "если программист не опытный или косячный, то Git из него сделает сеньора 20 лет стаж")
7) Как я и пишу, юнит тесты сильно помогают в долгую дистанцию, но вы и так согласились с этим ранее.
8) Так-то и ваша в том числе. Не допускать баги до прода, это обязанность всей цепочки IT отдела.) Кабан кабаныч не будет разбираться, кто там из вас "первый начал", люлей выдаст всем)
9) Система, которую вы описали она никак не вообще не мешает или не противоречит Git. Git ближе к сэйвам в играх, если проводить аналогию, в то время как cntrl+z, cntrl+y, cntrl+s это скорее игровые механики. Т.е. это просто разный уровень работы с кодом. Не в плане профессионализма, а в плане взаимодействия. Если cntrl+z, cntrl+y это очередь изменений, а cntrl+s просто сохранение файла, то git это про сохранение состояния множества файлов и историй изменений. Или вы думаете я cntrl+z, cntrl+y, cntrl+s в работе не использую? Ещё как использую и гит использую тоже)
2) Для опытного программиста с типовым проектом, не будет проблемой использовать git, как и покрыть его тестами, только если время прямо совсем не поджимает.)
3) Тестировщик проводит более глобальное тестирование, он не пишет интеграционные тесты, т.к. тестировщик не должен лезть в код, что логично.) Юнит тесты это именно про стабильную работу кода и про уменьшение багов при внесении множества изменений на протяжении долгого времени.
4) Я не совсем понимаю, в чём именно состоят мучения если git и github, буквально имеют UI приложения и интегрированы во все IDE. Даже для notepad++ есть плагин, что интегрирует git (забавно): https://github.com/alansbraga/NPPGit Вся работа сводится буквально к нажатию нескольких кнопок в UI.
5) Mod Manager вещь хорошая, тот же Vortex от Нексуса например, но они поддерживают не все игры. Плюс Mod Manager'ы не дают такого функционала, как Git. Я буквально могу сделать например несколько веток одной и той же сборки модов, с некоторыми изменениями в каждой и переключаться между ними моментально.
6) Обычно в разработке правят код не в одном файле, а в нескольких, особенно если это не спагетти код в одном фале на 1000+ строк кода. Просто не совсем понимаю, зачем вообще такое держать в голове, если можно автоматизировать и быть спокойным.
7) Я и говорю про моменты, когда багов прямо очень много и они критические. Баги же бывают разные. Есть критические (не верный расчёт цен в той же корзине при определённых условиях), есть не особо то и важные (как например лагающий стиль кнопки). Юнит тесты позволяют меньше допускать именно критических багов при разработке с дальнейшими доработками и нововведениями.
8) Если в вашем примере, ошибка в коде и она не явная, то проблемы будут не у тестировщика. Точнее спросят и с него и с вас. Т.к. тестировщик отдаст тикет с этим багом вам обратно.
Вроде как вопросов осталось меньше, они касаются в основном, git. Я вот честно не понимаю, чем он вас так отпугивает.
sshfs крутая штука но на винде вроде не работает, если сидеть на линуксе, то офигенная вещь.
Pulsar просто IDE по типу VScode.)
Тезисно отвечу на вопросы и моменты.
Настройка 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.)
Всё описано верно, только я не понимаю одного. Во всех подобных статьях говорят, что ИИ любит когда в контенте есть видео/аудио/интерактив. Некоторые даже пишут, что видео проекты по типу GPT воспринимают лучше. Однако, это не совсем так. В основе любой описанной нейросети находится LLM, которая умеет работать только с текстом. Нейросети ищут информацию в интернете при помощи классических инструментов. Для ИИ ссылка на видео в вашем контенте, вообще ни о чём не говорит. Т.е. тот же gpt не будет переводить всё видео в текст и как-то его анализировать. Тоже самое с аудио или интерактивом (например мини игра с рендером в canvas). Если с ютубом такое может проканать, потому что он сам делает субтитры и некоторые проекты могут иметь такой функционал, но большинство его всё же не имеют.
Следовательно, очень желательно под каждым не текстовым контентом добавлять описание, субтитры (если видео/аудио небольшое). Для картинок обязательно alt.
Это очень важная информация, которую нужно проговаривать.
Да всё смешалось в кучу, поэтому давайте разобьём все на подтемы.
1) Пример с ценой.
Здесь вообще какое-то недопонимание, поэтому скажу кратко. Git, Github, Unit тесты, это не функционал движка или фреймворка. Это такие же инструменты, как и IDE. Это не фишки сайта, а инструменты, которые позволяют разработчикам более эффективно создавать сайт (и не только сайты просто в контексте примера).
2) Для чего вообще Git и Unit тесты нужны?
Читая ваши комментарии мне кажется вы плохо понимаете, зачем вообще нужны эти инструменты и как они работают. Я не буду писать лекции это ни к чему.
Git, Github (да любая система контроля версий), полезен, даже для пет проектов без использования нейронок. Нужен помимо ведения истории изменения кода, для многих вещей. Например, откат кода (без залегания в бэкапы брр, я так делал последний раз наверное лет 10 назад), ко всем зафиксированным состояниям, что часто полезно. Быстрый деплой, возможность создания веток для того чтобы иметь, например несколько вариантов проектов, между которыми можно переключаться по нажатию одной кнопки. И это я за CI/CD молчу, которые поверьте встречаются и в небольших конторах довольно часто. В плане работы в команде, гит это базовый инструмент без которого работа сведётся либо к коллапсу архивов в лс, либо к вечным ошибкам 500 на проде. Про кодовую базу так же гитхаб просто удобнее. Хранить доступы ко всем серверам проектов или просто иметь папочку на диске можно, но как человек, который имел несколько пк, часто переезжал, это просто неудобно. По итогу, у меня есть папки с древними проектами, чуть ли не со студеньчества на hhd, но если бы я не перетащил всё в гитхаб или хотя бы в облако, то умер бы hhd, проектам можно сказать пока. Кстати то что можно быстро развернуть проект на разных устройствах это тоже плюс. Тут же можно упомянуть ваш пример с текучкой. Работая, через проду, если есть текучка кадров, вам придется дать доступ к проде для всех 20 программистов, которые могут по незнанию или специально всё поломать на уровне сервера. Github позволяет допускать программистов только до исходников, а иногда только до определенной его части, например если человеку надо доработать поагин, зачем ему доступ к коду всех плагинов сайта? Бизнесу это важно, уж поверьте.
Unit тесты. Вы сказали фразу, что при говнокоде тесты покажут мол "пациент сдох", у вас странное представление о тестах, как о инструменте для анализа работы кода. Но, автотесты (unit или другие) это не про анализ кода, а скорее про контракт в разработке. Пример в контексте интернет-магазина. Допустим мы пишем тест для функции расчета цены в корзине, мы фактически создаём правило, даже скорее закон, что корзина при таком вводном наборе данных, будет считать определенным образом. Следовательно, если мы меняем в коде, что-то связанное с корзиной, например функцию расчета стоимости товара, то запустив тесты мы увидим нарушили наши изменения метод расчёта цены в корзине или нет. Именно поэтому говнокод, покрытый юнит тестами, лучше отличного кода, но без них. Потому что код с нормальным покрытием тестами легко отрефакторить ничего не поломав.
3) Сложность.
Если честно не понимаю, почему вы считаете эти инструменты разработки сложными. Тот же git встроен везде и создание коммитов буквально занимает пару кликов. Git вообще не сложный на уровне рядового пользователя. Касаемо тестов, они так же не сложные в использовании. Могут возникнуть сложности в настройке, но она проводится разово для проекта. Тесты писать тоже не сложно, а с нейронкой это ускоряется в разы. Вы же описываете это так, словно работа с гитом, это что-то на уровне настройки кубера например или поднятия сервера с нуля под один проект.
П.С Если опять подытожить, то эти инструменты при грамотном использовании позволяют нормально работать почти с любыми проектами, а не на глазок.
П.П.С. Правильно понимаю, что вы дебагерами тоже не пользуетесь на бэке, раз всё правите в проде? Просто интересно.
Касаемо цен. Что 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 код может вполне иметь много багов, просто не таких явных.
Ну я конкретно в веб разработке поменьше, лет 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% не буду уверен, что проблема не в моей зоне ответственности, после чего передам тикет с подробным описанием ресёрча и всеми обоснованиями, предположениями, тестами. Чего буду в подобных ситуациях ждать и от коллег, а не просто "у нас всё хорошо, ищите сами", я то найду, но если выяснится, что проблема всё же на строне коллег выйдет неприятный момент.
Касаемо тестов. Ответ в наших реалиях очень простой. Без git и unit тестов даже разработка пет проектов невозможна. Это базовый минимум в наши дни, особенно с приходом llm, которые программисты любят использовать, но не особо любят ревювить их код. Без тестов, проект сейчас просто невозможно адекватно поддерживать вдолгую. Какую бы вы замороченную и идеальную архитектуру не выбрали и какую бы навороченную инфру вокруг неё не выстроили, без тестов это превратиться со временем в кучу малу.
Имхо, но эти вопросы сейчас валидны для всех. Я мидл разработчик и это 2 базовых вопроса, которые и джунам задают.
Мне кажется сейчас в принципе актуальнее вопрос про ответственность, потому что именно за неё мы получаем зп. Контракт с бизнесом очень прост. Бизнес платит деньги нам не за писульки кода, а за ответственность стабильной работы созданных по запросу бизнеса решений. Всем плевать, что вы использовали лучшие практики. Если что-то не работает спрашивают с нас. Да да, капитан очевидность, но вы даже не представляете, как много людей не понимают этой простой истины. Бизнес не будет слушать про, то что json'ы пользователю не приходят из-за особенностей вашей же выстроенной архитектуры, он найдет вместо вас тех, кто сделает так, чтобы json'ы приходили, если вы не хотите нести за это ответственность.
В то время, как tg давно создал mini app и полноценную экосистему внутри своего приложения, мах завёз ботов без какой-либо тех. поддержки, доступных не всем, так ещё и работающих криво судя по комментариям.
Имхо, но если уж быть турбопатриотом, то даже вк выглядит намного лучше в этом плане, потому что он имеет свою устоявшуюся годами экосистему с ботами и аналогом mini app, а так же нормальным саппортом и документацией и главное даже в нём создание ботов доступно всем.
Если что, не пиарю вк (потому что его современные владельцы создали макс), просто говорю какое же говно вам пытаются скормить взамен тг и других мессенджеров. Честно, учитывая какое отношение к максу у народа, я бы просто его уже закрыл и не мучил. Но учитывая, что макс принадлежит, вроде как сынку Кириенко и что на нём наверное пилят огромные бабки, никто ничего сворачивать не собирается.
Я пробежался по комитам и есть ощущение, что проект полностью навайбкожен. Ничего против использования в программировании нейронок не имею, но такое ощущение, что автор в целом плохо разбирается в программировании. Отсюда и вск вышеописанные проблемы. Хотя, могу ошибаться.