5 правил для код ревью
1. Есть вопрос — спрашивай. Цель код ревью — делать все изменения в кодовой базе проекта понятными каждому разработчику. Без вопросов в сомнительных местах добиться этого будет невозможно.
2. Цель изменений в коде должна быть понятна. Если вы отправляете свой код на ревью — о донесении этих смыслов должны позаботиться вы. Если вы проверяете чужой код, то должны убедиться, что понимаете, какую задачу он решает.
3. Изменения в коде должны быть минимальными. На каждый код ревью не должно приходиться больше 10–100 строк кода. В большинстве случае изменения на 1000 строк можно разбить на десятки понятных частей. Это же правило стимулирует регулярный (ежедневный) код ревью.
4. Наличие стандартов. В каждой команде должны быть чётко прописанные стандарты кода, чтобы каждый раз вам не приходилось спорить из-за банального написания переменных (типа camelCase или underscore_case).
5. Баланс. Вы не живём в идеальном мире и всегда будут те, кто получает удовольствие от код ревью, и те, кто ненавидит его. Учитывайте это и старайтесь быть уважительным и при создании новых изменений, и при просмотре чужих.
Источник: dev.to
#команда
1. Есть вопрос — спрашивай. Цель код ревью — делать все изменения в кодовой базе проекта понятными каждому разработчику. Без вопросов в сомнительных местах добиться этого будет невозможно.
2. Цель изменений в коде должна быть понятна. Если вы отправляете свой код на ревью — о донесении этих смыслов должны позаботиться вы. Если вы проверяете чужой код, то должны убедиться, что понимаете, какую задачу он решает.
3. Изменения в коде должны быть минимальными. На каждый код ревью не должно приходиться больше 10–100 строк кода. В большинстве случае изменения на 1000 строк можно разбить на десятки понятных частей. Это же правило стимулирует регулярный (ежедневный) код ревью.
4. Наличие стандартов. В каждой команде должны быть чётко прописанные стандарты кода, чтобы каждый раз вам не приходилось спорить из-за банального написания переменных (типа camelCase или underscore_case).
5. Баланс. Вы не живём в идеальном мире и всегда будут те, кто получает удовольствие от код ревью, и те, кто ненавидит его. Учитывайте это и старайтесь быть уважительным и при создании новых изменений, и при просмотре чужих.
Источник: dev.to
#команда
👍16❤3
Парное программирование
Это метод разработки, при котором два программиста работают над одним и тем же кодом, совместно решая задачи и проверяя качество.
Подход помогает улучшить навыки, коммуникацию и креативность разработчиков, а также повысить эффективность и качество продукта.
В статье рассказывается о преимуществах, недостатках и правилах парного программирования, а также даётся несколько советов, как его успешно применять на практике.
#советы #команда
Это метод разработки, при котором два программиста работают над одним и тем же кодом, совместно решая задачи и проверяя качество.
Подход помогает улучшить навыки, коммуникацию и креативность разработчиков, а также повысить эффективность и качество продукта.
В статье рассказывается о преимуществах, недостатках и правилах парного программирования, а также даётся несколько советов, как его успешно применять на практике.
#советы #команда
👍8
Фреймворк для парного программирования
Статья рассматривает парное программирование как важный инструмент для обучения начинающих специалистов.
Этот метод разработки программного обеспечения позволяет двум людям работать вместе для обмена опытом, решения проблем или обучения.
#статья #команда
Статья рассматривает парное программирование как важный инструмент для обучения начинающих специалистов.
Этот метод разработки программного обеспечения позволяет двум людям работать вместе для обмена опытом, решения проблем или обучения.
#статья #команда
5 правил для код ревью
1. Есть вопрос — спрашивай. Цель код ревью — делать все изменения в кодовой базе проекта понятными каждому разработчику. Без вопросов в сомнительных местах добиться этого будет невозможно.
2. Цель изменений в коде должна быть понятна. Если вы отправляете свой код на ревью — о донесении этих смыслов должны позаботиться вы. Если вы проверяете чужой код, то должны убедиться, что понимаете, какую задачу он решает.
3. Изменения в коде должны быть минимальными. На каждый код ревью не должно приходиться больше 10–100 строк кода. В большинстве случае изменения на 1000 строк можно разбить на десятки понятных частей. Это же правило стимулирует регулярный (ежедневный) код ревью.
4. Наличие стандартов. В каждой команде должны быть чётко прописанные стандарты кода, чтобы каждый раз вам не приходилось спорить из-за банального написания переменных (типа camelCase или underscore_case).
5. Баланс. Вы не живём в идеальном мире и всегда будут те, кто получает удовольствие от код ревью, и те, кто ненавидит его. Учитывайте это и старайтесь быть уважительным и при создании новых изменений, и при просмотре чужих.
Источник: dev.to
#простымисловами #команда
1. Есть вопрос — спрашивай. Цель код ревью — делать все изменения в кодовой базе проекта понятными каждому разработчику. Без вопросов в сомнительных местах добиться этого будет невозможно.
2. Цель изменений в коде должна быть понятна. Если вы отправляете свой код на ревью — о донесении этих смыслов должны позаботиться вы. Если вы проверяете чужой код, то должны убедиться, что понимаете, какую задачу он решает.
3. Изменения в коде должны быть минимальными. На каждый код ревью не должно приходиться больше 10–100 строк кода. В большинстве случае изменения на 1000 строк можно разбить на десятки понятных частей. Это же правило стимулирует регулярный (ежедневный) код ревью.
4. Наличие стандартов. В каждой команде должны быть чётко прописанные стандарты кода, чтобы каждый раз вам не приходилось спорить из-за банального написания переменных (типа camelCase или underscore_case).
5. Баланс. Вы не живём в идеальном мире и всегда будут те, кто получает удовольствие от код ревью, и те, кто ненавидит его. Учитывайте это и старайтесь быть уважительным и при создании новых изменений, и при просмотре чужих.
Источник: dev.to
#простымисловами #команда
⚡4👍2🤓2
Forwarded from Метод утёнка
Что на самом деле отличает джуна от сеньора?
В IT до сих пор любят мерить грейды в годах опыта: мол, если больше пяти лет в резюме — ты сеньор. Но в работе всё сложнее.
Александр Белькевич поделился с нами классным разбором о том, чем на самом деле отличается зрелый разработчик. Кстати, у него в канале ещё много другой полезной годноты.
💡 Senior — это человек, который думает шире своего редактора кода. Его задача сделать не просто «чтобы работало», он — видит последствия: как его правки скажутся на поддержке, на бизнесе, на конечных пользователях. И если нужно, он выберет не самое эффектное, но понятное решение.
🛠 Его выбор технологий всегда обоснован. Он не ставит очередной модный фреймворк просто потому что «новинка». Где-то он спокойно сверстает на jQuery — если так быстрее и дешевле, а где-то готов потратить время и внедрить сложную архитектуру.
👥 Senior думает про команду. Видит, где у коллег затыки, делится опытом, помогает расти, ревьюит тактично. И если у команды что-то не работает — берётся помочь, даже если формально это не его зона.
🔥 И да, он не бросает свои баги в проде. Если от него что-то упало — он чинит, пусть даже в пятницу вечером. Потому что понимает, что на том конце — живые люди, а не «кто-то там».
🧘 И, пожалуй, самое сложное — умение не писать код там, где его можно не писать. Senior умеет сказать «оставим как есть» — и это тоже ценно.
По сути, senior — это не про количество лет или модные слова в профиле. Это про зрелость: в мышлении, в отношениях с людьми, в умении видеть картину целиком.
А вы как считаете? Что ещё отличает сеньора?
#softskills #команда
В IT до сих пор любят мерить грейды в годах опыта: мол, если больше пяти лет в резюме — ты сеньор. Но в работе всё сложнее.
Александр Белькевич поделился с нами классным разбором о том, чем на самом деле отличается зрелый разработчик. Кстати, у него в канале ещё много другой полезной годноты.
💡 Senior — это человек, который думает шире своего редактора кода. Его задача сделать не просто «чтобы работало», он — видит последствия: как его правки скажутся на поддержке, на бизнесе, на конечных пользователях. И если нужно, он выберет не самое эффектное, но понятное решение.
🛠 Его выбор технологий всегда обоснован. Он не ставит очередной модный фреймворк просто потому что «новинка». Где-то он спокойно сверстает на jQuery — если так быстрее и дешевле, а где-то готов потратить время и внедрить сложную архитектуру.
👥 Senior думает про команду. Видит, где у коллег затыки, делится опытом, помогает расти, ревьюит тактично. И если у команды что-то не работает — берётся помочь, даже если формально это не его зона.
🔥 И да, он не бросает свои баги в проде. Если от него что-то упало — он чинит, пусть даже в пятницу вечером. Потому что понимает, что на том конце — живые люди, а не «кто-то там».
🧘 И, пожалуй, самое сложное — умение не писать код там, где его можно не писать. Senior умеет сказать «оставим как есть» — и это тоже ценно.
По сути, senior — это не про количество лет или модные слова в профиле. Это про зрелость: в мышлении, в отношениях с людьми, в умении видеть картину целиком.
А вы как считаете? Что ещё отличает сеньора?
#softskills #команда
❤🔥7👍2👾1
Forwarded from Метод утёнка
«Scrum-то какой!» — почему программисты не всегда в восторге от спринтов
Agile и Scrum давно стали стандартом, но на практике спринты часто критикуют — не из-за методологии, а из-за того, как они внедряются .
Автор статьи рассказал, что постановка спринтов по книге — это ещё не гарантия успеха. Когда команды буквально следуют коробочному Scrum, процветают торопливость, перегрузка формальностями и потеря фокуса на продукте. А ещё показал примеры компаний, которым помог не отказ от Agile, а изменение подхода специально под их ситуации.
#agile #scrum #команда
Agile и Scrum давно стали стандартом, но на практике спринты часто критикуют — не из-за методологии, а из-за того, как они внедряются .
Автор статьи рассказал, что постановка спринтов по книге — это ещё не гарантия успеха. Когда команды буквально следуют коробочному Scrum, процветают торопливость, перегрузка формальностями и потеря фокуса на продукте. А ещё показал примеры компаний, которым помог не отказ от Agile, а изменение подхода специально под их ситуации.
#agile #scrum #команда