Comments 40
Какой интересный у вас класс задач. Неужели, это обязанность тимлида - обучать сотрудников основам работы с git'ом? Разве это не задача HR и собеседующих?
Как мне кажется, слепая печать, git и навыки хоть какого-то программирования входят в базовый перечень для любого причастного к компьютерам, вместе с умением читать и писать.
Прошу прощения, что не по теме. Слепая печать — настолько важна?
Она не является критической, и, в принципе, я могу себе представить человека, который очень хорош в ИТ, но печатает медленно, но, скорее, как исключение.
Проблема в том, что для класса задач скорость работы с устройствами ввода прямо транслируется в скорость работы. Если вы запрос в гугл печатаете в три раза дольше, чем средний человек, то вы теряете ~5% эффективности (потому что чтение результатов занимает больше времени).
Но если вы, например, в консоли, то медленная и неэффективная навигация на 90% транслируется во время за консолью. Чтобы быстро работать в консоли нужно смотреть на экран. Чтобы быстро работать в IDE (что vscode, что vim, что emacs), нужно смотреть на экран, причём быть глубоко в контексте (потому что представляемые данные имеют смысл только в контексте нажатых кнопок, и иногда важны не данные, а их изменение). Если вы глаза от экрана отводите при печате, то вы катастрофически теряете контекст.
У меня лично при работе над фунциональностью контекст в голове, а не на экране монитора. Притом не в виде конкретных ключевых слов и форматирвания в IDE, а гораздо более абстрактно.
При дебаге, возможно, некоторое смещение в сторону IDE с watches (если она позволяет) или к чтению логов.
Зачем мне при этом скорость стенографистки/машинистки — непонятно.
Бесспорно, слепая печать добавляет некоторый комфорт в некоторых ситуациях, например, при написании документации, переписке в чатиках(хотя, в рабочих лучше всё-таки обдумывать написанное), нг написание кода/дебаг/рефакторинг — это не про N символов в секунду.
Я не в соревновании учавствую, где первый запушивший изменения получает премию, а другие грустно уходят домой без ужина, а в коллективе работаю с некоторым прицелом на качество(хотя бы декларируемым).
У вас контекст в голове и на экране. Если бы вам не нужна информация с экрана для обновления контекста, вы бы могли печтать неглядя на экран вообще.
Ближайший grep, ctrl-p в vscode, tab в шелле и т.д. - и вы ждёте что-то на экране. Если вы взгляд отводите, у вас разрушается контекст.
При чтении чужого кода нужно очень много печатать (если только вы не относитесь к людям, которые начинают читать проект с automake.mk, потому что это первый файл по алфавиту), и потеря этого контекста снижает продуктивность. Грубо говоря, если у вас при чтении документа отобрать Ctrl-F, вы всё равно его прочитаете, но, возможно, дольше и не так хорошо.
Зачем мне при этом скорость стенографистки/машинистки — непонятно.
Для дополнительного комфорта. Ну и программист не только код пишет, а еще всякие issue, комментарии. Я на русском давно печатаю вслепую, на английском полностью стал вслепую год назад. И комфорт увеличился (а еще у меня клава без надписей).
Я не в соревновании учавствую, где первый запушивший изменения получает премию, а другие грустно уходят домой без ужина, а в коллективе работаю с некоторым прицелом на качество(хотя бы декларируемым).
Это не важно: участвуйте вы в них или нет. Скорость еще более актуальна для старых языков с многословным синтаксисом (Java), причем если код пишется не в IDE. И при разработки реально возникают мысли о том, что вообще-то не охота столько писать, особенно если печатаешь медленно. Приходит прокрастинация, сроки откладываются. Так что да, слепая печать влияет на продуктивность, как и используемая IDE.
Есть проблема когда берем аутстафф или подряд. И эта проблема у всех студий. Как показала практика последнего полугодия количество битрикс разрабов на рынке уменьшилось кратно. Волей неволей приходится снижать требования к кандидатам, и компенсирвать регламентами, т.к. кем-то надо делать
А вы не думали о переходе на более современный и разумный стек, на который перешли высококвалифицированные разработчики?
переход на голанги и ноды не имеет отношения к "высокой" квалификации. это лишь мода.
отнюдь, невозможно быть разработчиком на "современном стеке" и не знать git ибо git является неотъемлимой частью инфраструктуры этих стеков а вот в битриксе получается можно его не знать
Переход с bitrix на любой универальный язык программирования - это большой левелап, даже если это нода.
Более того, вчитайтесь в то, что я написал. "на более современный и разумный стек, на который перешли высококвалифицированные разработчики". Я не говорю, что надо переходить на какую-то конкретную технологию.
Я говорю, что в свете "упал уровень разработчиков на bitrix" надо посмотреть, куда ушли с bitrix те, у кого уже есть хороший уровень базовых знаний. Может быть, это перспективное направление? Чем более хороший специалист, тем больше он неравнодушен к технологиям, с которыми он работает. Это с начинающими можно играть в "могу копать, могу не копать". Хороший профи хоть и может, но не хочет некоторые технологии, и выбирая из двух офферов с одинаковой зарплатой, очевидно пойдёт туда, где технологии привлекательнее. Привлекательнее чем что? Чем Bitrix, карл!
Есть b24, который не перекрыть другими стеками. Можно делать в несколько раз дороже (именно раз) на более современном стеке
Как мне кажется, слепая печать, git и навыки хоть какого-то программирования входят в базовый перечень для любого причастного к компьютерам, вместе с умением читать и писать.
Git - это одна из десятков используемых систем контроля версий, поэтому кажется странным приравнивать знание git к умению читать и писать. К примеру, я работал с различными системами контроля версий начиная с 1999 года, а с git познакомился только через 20 лет, в 2019 году.
Английский язык - один из более чем 2500 тысяч языков мира, но все IT'шники должны владеть им.
Git - ровно так же. Не умеешь git, страдаешь и люди в работе с тобой страдают. Возможно, где-то там до сих пор кто-то пользуется cvs, но в целом, git победил. Вы можете владеть ещё какими-то системами, но знать git - обязаны. Ровно так же, как знание армянского, французского и ещё одного языка предков не освобождает вас от знания английского.
А как вы десяток насчитали? Даже если есть и другие, то Git явно доминирует, он испольузется почти везде. Даже bitbucket забросили свой mercurial. И важна не только СКВ, но и инфраструктура вокруг нее.
Так что не соглашусь — знание Git в настоящее время является необходимым для специалиста уровня выше Middle.
Одним только собесом не решить проблемы, которые возникают при работе с системой контроля версий
Доставкой изменений на бой занимается тимлид на проекте или его старший программист проекта. Также неплохо было бы настроить CI/СD
В нашем полном регламенте помимо тех, кому дано право изменять боевой сервер — прописано и разрешенное для деплоя время. Мы исключили возможность обновлений перед выходными в конце дня, а плановый деплой разрешен только в первой половине рабочего дня.
Печаль. 2021й год на дворе, а вы вручную "доставляете" изменения. И для этого ещё и отдельные ветки "staging" и "main". И каким же образом достигается Continuous Delivery, если между коммитом и деплоем в продакшн столько "вахтёров"?
Любой разработчик знает, что существуют задачи (особенно, если ты работаешь один как фрилансер или в небольшой студии, в которой «один проект — один ответственный») когда можно работать без гита
Видимо, я какой-то фейковый разработчик. Даже работая в одиночку, системя контроля версий приносит пользу: быстрый откат изменений; просмотр истории изменений (вида "ой, а что это я там менял, что у меня всё сломалось?"); собственно, сам контроль версий исходного кода (вида "надо тут эту фичу назад вернуть, раньше было лучше"). В некоторых вариациях, это деплой одной командой или мониторинг "а не закинули нам какого скрипта лишнего?".
Как по мне, единственно допустимый вариант не использовать систему контроля версий - одноразовый скрипт (который действительно запустился раз и его тут же можно удалять).
Это какой-то бюрократизм головного мозга...
> После выполнения наработок необходимо сделать git pull в текущую ветку из ветки stage (в некоторых случаях master) удаленного основного репозитория и тем самым предотвратить появление конфликтов в удаленном репозитории.
В GitHub это решается галочкой "Require branches to be up to date before merging". Неужели в GitLab нет ничего подобного?
Отписать тимлиду или старшему на проекте, если он отвечает за сливания, чтобы проверил работу и принял merge request, либо отправил на доработку.
Зачем, если уже запросили его code review?
Если вам приходится работать с существующим кодом в файле и этот код не правильно отформатирован, то в случае, когда мы будем делать доработку и отформатируем весь код файла, в коммите будет не понятно — что именно изменилось.
Решается однократным рефакторингом и введением линтера.
Правила именования веток
Зачем? Время жизни веток должно быть максимум несколько дней (а лучше < 1 дня). У вас несколько миллионов разработчиков, и поэтому возникают конфликты имен?
И т.д. Большая часть ваших проблем, похоже, решается нормальной настройкой инструментов, а не написанием регламентов.
согласен за исключением пункта времени жизни ветки.
для большого монолита (мы же не только про сайты говорим) нет возможности часто делать раскатку на прод и поэтому собираются большие релизы. которые могут быть и раз в неделю, но цикл жизни отдельной доработки (и, соответственно, ветки для неё) может доходить до 3 месяцев.
прекрасно знаю что это не best practice и надо уходить и от монолитности и увеличивать частоту релизов и т.д. и т.п. но мы работаем с тем что есть, а это не всегда идеальные условия.
Если это именно ветка для release candidate, то да, время жизни может быть больше. Нехорошо, но таковы реалии. И да, к ним можно (и даже нужно) определить правила наименования (и сделать их protected). Но это будет несколько веток вида release-v*
Но если feature-branch живет по несколько месяцев (и это настолько "нормально" в компании, что придумывают под это дело специальные регламенты наименования), то в консерватории что-то сильно не так.
Я полагаю, что на сегодняшний день, даже если устраиваешься в компанию на должность junior-разработчика - обязательным пунктом должно быть "знание git" хотя бы на базовом уровне наряду со знанием языка.
А зачем это в случаях, когда в компании используется другая система контроля версий?
Гит - не что-то особо страшное. Изучить на базовом уровне - несколько часов, если специалист таки специалист.
А если таки в компании используется гит, то достаточно каждому новопринятому выдавать шпаргалку с принятыми в компании правилами использования гит (они, внезапно, могут сильно отличаться в разных компаниях), которую просто не забыть снабдить примерами команд. Дальше сам разбпрется. А если не разберется, то его квалификация вызывает сильные сомнения.
Я так понимаю,все статьи про git сейчас минусят...
Не судите по статье, что в компании, где я работаю, из стеков технологий используется только Bitrix. Так сложилось, что порог вхождения в Bitrix не особо высок. Это и достижение Bitrix и его недостаток. И именно с Bitrix разработчиками чаще всего приходится решать проблемы с системой контроля версий
Я знаю, что GIT не единственная система контроля версий. Плюс-минус все работает одинаково. Когда новый человек приходит в компанию, то при наличии опыта работы с любой системой контроля версий не составляет труда переключиться на GIT. Мы используем именно GIT
В любом технологическом процессе должна присутствовать стандартизация и унификация. Без неё бы не создавались доступные по бюджету товары и услуги
Как тимлиду обучить распределенную команду работать с Git