Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 17
Вам честно написать? Во-многом выглядит как конспект вводной лекции по код стайлу проекта, записанный джуном.
Пулл реквесты, Коммиты — правила оформления обычно определенны на проекте, в-первую очередь они должны быть в принятом в команде/проекте формате. У синьеора уже есть понимание как они должны оформляться, джуну в первую очередь нужно очень внимательно читать/слушать о код стайле и смотреть как другие оформляют таски, пулл реквесты и коммиты. Любые правила код стайла в отрыве от принятых в команде джуну скорее помешают.
Странные у вас задачи, если 20 минут для них много, типичные самостоятельные таски это часы, дни, иногда недели. Может это о первоначальный анализ? Тут есть другая проблема, дергая каждые 20 минут лидов, вы их заманаете за день-другой. Поэтому всегда должен быть баланс, многие лиды предпочтут, чтобы вы потратили в 2-3 раза больше времени на первые задания, но сделали сами. Не потому что такие вредные, а потому что единственный путь вырасти из джунов или хотя бы стать опытным джуном как можно больше делать и решать самому. С другой стороны, зависать часами и днями над ерундовой задачей тоже плохо. И прежде чем, что-то реализовывать тратя много времени, лучше джуну все-таки рассказать о своей задумки более опытному товарищу.
Очень опасный совет, корпоративные правила могут очень жестко наказывать за раскрытия внутренних ссылок на стороних ресурсах.
Вы про merge? Спорный совет. Возможности мержей в IDE или консоле обычно значительно выше, чем в вебинтерфесе Github и Gitlab.
Не то, чтобы это не правильно, но во-первых, тут нужно быть увереным, что ваш способ лучше и для коллеги, часто путают свои вкусы с обьективно лучшим решением (особенно часто грешат джуны). Во-вторых, говорить о недостатках в работе стоит аккуратно и ненавязчиво, не все коллеги могут адекватно воспринимать критику, а взаимопонимание в команде чаще важнее нескольких процентов производительности.
P.S. Вы молодец, что попытались описать свои знания и опыт, но многое из описанного все-таки довольно специфичные правила работы и код стайл на вашем проекте и совсем не обязательно они подойдут начинающему на другом проекте.
Пулл реквесты, Коммиты — правила оформления обычно определенны на проекте, в-первую очередь они должны быть в принятом в команде/проекте формате. У синьеора уже есть понимание как они должны оформляться, джуну в первую очередь нужно очень внимательно читать/слушать о код стайле и смотреть как другие оформляют таски, пулл реквесты и коммиты. Любые правила код стайла в отрыве от принятых в команде джуну скорее помешают.
Не тратьте больше 20 минут на решение типичных или слишком сложных проблем, это не эффективно. Скорее всего, если вы не нашли правильный подход быстро, решение не очевидно. Просите помощи у коллег, включая лид-разработчиков.
Странные у вас задачи, если 20 минут для них много, типичные самостоятельные таски это часы, дни, иногда недели. Может это о первоначальный анализ? Тут есть другая проблема, дергая каждые 20 минут лидов, вы их заманаете за день-другой. Поэтому всегда должен быть баланс, многие лиды предпочтут, чтобы вы потратили в 2-3 раза больше времени на первые задания, но сделали сами. Не потому что такие вредные, а потому что единственный путь вырасти из джунов или хотя бы стать опытным джуном как можно больше делать и решать самому. С другой стороны, зависать часами и днями над ерундовой задачей тоже плохо. И прежде чем, что-то реализовывать тратя много времени, лучше джуну все-таки рассказать о своей задумки более опытному товарищу.
если нет — сокращайте с помощью git.io и bit.ly,
Очень опасный совет, корпоративные правила могут очень жестко наказывать за раскрытия внутренних ссылок на стороних ресурсах.
Правильная практика слияния изменений — использовать веб-интерфейс систем хранения исходного кода как Github и Gitlab.
Вы про merge? Спорный совет. Возможности мержей в IDE или консоле обычно значительно выше, чем в вебинтерфесе Github и Gitlab.
работу коллеги можно сделать лучше — говорите ему об этом
Не то, чтобы это не правильно, но во-первых, тут нужно быть увереным, что ваш способ лучше и для коллеги, часто путают свои вкусы с обьективно лучшим решением (особенно часто грешат джуны). Во-вторых, говорить о недостатках в работе стоит аккуратно и ненавязчиво, не все коллеги могут адекватно воспринимать критику, а взаимопонимание в команде чаще важнее нескольких процентов производительности.
P.S. Вы молодец, что попытались описать свои знания и опыт, но многое из описанного все-таки довольно специфичные правила работы и код стайл на вашем проекте и совсем не обязательно они подойдут начинающему на другом проекте.
Я вас услышал, спасибо за фидбек.
У меня была фокус группа, не только с джуниоров, я опрашивал на очевидность и полезность материала — получил хорошую оценку. Решил выложить в открытый доступ.
- Про «20 минут» и правда надо написать больше и яснее, про баланс.
- Про сокращенные ссылки — только просто шаринг коллегам и вряд ли корпоративные сервисы не требуют авторизации на корпоративную почту.
- Про мердж — правильно ставить блокировку на слияние в дефолтные ветки, поэтому без веб-интерфейса (после код-ревью и CI) не получится смерджить.
- Про гработу коллеги — правда, надо уточнить.
У меня была фокус группа, не только с джуниоров, я опрашивал на очевидность и полезность материала — получил хорошую оценку. Решил выложить в открытый доступ.
Я и не говорил, что статья бесполезная, но ИМХО не стоит использовать так много «must», I think, I recommend, you should намного лучше.:) Если бы вы просто описывали правилиа код стайла, которые приняты на вашем проекте и которые вы считаете разумными, без уточнения, что ими должны пользоватеся все и всегда — возражений бы особо не было.
За несколько десятков проектов и 15 лет опыта я видел столько разных правил оформления, что вообше не верю в возможность каких-то универсальных общих для всех правил. Но в принципе, как некоторые рекомендации для джунов ваши правила вполне могут быть полезными.
За несколько десятков проектов и 15 лет опыта я видел столько разных правил оформления, что вообше не верю в возможность каких-то универсальных общих для всех правил. Но в принципе, как некоторые рекомендации для джунов ваши правила вполне могут быть полезными.
Про сокращенные ссылки — только просто шаринг коллегам и вряд ли корпоративные сервисы не требуют авторизации на корпоративную почту.
А я не соглашусь. Логи СКВ — это не шаринг, это КОНТРОЛЬ версий. И лог должен быть понятен и доступен и через 5 лет, и через 10. А эти ваши сокращатели ссылок — сколько они «живут»?.. Сколько раз я встречал сокращённые мёртвые ссылки… К счастью, не в логах СКВ, потому простительно, но раздражало…
Поставьте свой внутренний шорткатер как часть инфраструктуры. Полно удобных и бесплатных. Можно вообще даже встроить в какой-то сервис автоматом — есть плагины.
спасибо, но я предпочитаю «контроль»…
сокращатели же ссылок «прячут» часть информации из сообщения коммита (и они — лишняя точка отказа)
мне нравится иметь максимально полную информацию из текста коммита (это также камешек в сторону «только номеров из багтрекера»)
сокращатели же ссылок «прячут» часть информации из сообщения коммита (и они — лишняя точка отказа)
мне нравится иметь максимально полную информацию из текста коммита (это также камешек в сторону «только номеров из багтрекера»)
Спасибо за статью, сам пришёл почти ко всем вышеперечисленным правилам с опытом.
Единственное — я не сторонник длинных комментариев в системе контроля версий. Для себя выбрал такой формат: {Номер бага в системе баг-трекинга}: Модуль — Краткое описание того, что сделано (1-2 предложения) — ссылка (если необходимо). Пример: TESTPROJ-112: Accounting — Add new accounting type
Ещё важный пункт — документация. Документируйте всё — даже то, что кажется очевидным на момент написания. Если вернётесь к этой задаче через 2 года, то очевидное может забыться… Особенно это касается того, что может быть сконфигурировано…
Единственное — я не сторонник длинных комментариев в системе контроля версий. Для себя выбрал такой формат: {Номер бага в системе баг-трекинга}: Модуль — Краткое описание того, что сделано (1-2 предложения) — ссылка (если необходимо). Пример: TESTPROJ-112: Accounting — Add new accounting type
Ещё важный пункт — документация. Документируйте всё — даже то, что кажется очевидным на момент написания. Если вернётесь к этой задаче через 2 года, то очевидное может забыться… Особенно это касается того, что может быть сконфигурировано…
Ещё одно моё правило, которое сильно мне помогает в работе:
Если задача больше чем на 2 часа работы, то перед выполнением нужно разбить её на подзадачи. Это даёт нескольно важных преимуществ:
— Позволяет ощутить прогресс выполения (помогает в самомотивации и не даёт опустить руки)
— Позволяет не скакать по задаче, а решать её мелкими блоками
— Легко сказать процент выполнения задачи менеджеру/заказчику
— Помогает в проектировании, т.к. в ходе разбиения вспоминаешь кучу связанных вещей и продумываешь всё…
Если задача больше чем на 2 часа работы, то перед выполнением нужно разбить её на подзадачи. Это даёт нескольно важных преимуществ:
— Позволяет ощутить прогресс выполения (помогает в самомотивации и не даёт опустить руки)
— Позволяет не скакать по задаче, а решать её мелкими блоками
— Легко сказать процент выполнения задачи менеджеру/заказчику
— Помогает в проектировании, т.к. в ходе разбиения вспоминаешь кучу связанных вещей и продумываешь всё…
Не тратьте больше 20 минут на решение типичных или слишком сложных проблем, это не эффективно.
Честно говоря, сомнительный совет. Если решение находится быстро, это еще не гарантирует его верности и/или эффективности.
Многие решения «тяп-ляп», которые в дальнейшем приходится переделывать, рождаются из стремления быстро сгенерировать что-то на «вдохновении» мозговым штурмом и идти дальше.
Очень сильно не хватает пункта «выучите уже наконец английский и перестаньте использовать кальку с русского realization (три значения: comprehension — «понимание», fulfillment — «достижение», sale — «продажа [за деньги]») вместо правильного implementation (одно значение, которое соответствует русскому «воплощать»)».
Блин, каждого первого джуна переучивать приходится.
Блин, каждого первого джуна переучивать приходится.
иметь повелительное наклонение.
Ticket-295: Add base cat interface and British cat realization
Вот кстати меня всегда интересовал вопрос. Я обычно коммит-сообщения пишу в прошедшем времени, что было пофикшено: "Исправлен баг". Но также много встречал и в настоящем, в том числе и в этой статье: "Исправление бага". Как все же правильней?
Я встречал в настоящем, в прошлом и будущем (если тикеты), более того бывает вместо глаголов просто существительные, бывает народ не парится и пишет по-разному. На самом деле, это как код стайл языка в одном языка записывают переменную как catInterface, в другом как cat_interface, в третьем СatInterface и т.д. Какой правильный? Все они правильные, это спор табов против пробелов, какие правила на проекте/команде/языке приняты — так и правильнее. ИМХО.
Вот тут отличный пост про это с доходчивым объяснением, зачем и почему chris.beams.io/posts/git-commit
Вот тут отличный пост про это с доходчивым объяснением, зачем и почему chris.beams.io/posts/git-commit
Ticket-295: Add base cat interface and British cat realization
Если уж делать самодокументирующиеся, почему бы сразу не сделать несколько разделов, вместо Ticket писать bugfix-123, feature-351, update-504
Если у вас есть багтрекер, то в commit message вообще можно одну строчку и оставлять — номер тикета и краткое описание. А детали — уже в багтрекере.
> Срез личного опыта: разработка, пулл реквесты, коммиты, софт скиллы
Что выпадает из ряда — это «разработка», когда есть всё, чтобы переходить переходить к девелопменту.
Что выпадает из ряда — это «разработка», когда есть всё, чтобы переходить переходить к девелопменту.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Срез личного опыта: разработка, пулл реквесты, коммиты, софт скиллы