Рефакторинг, просте та парне програмування Уривок із книги Роберта Мартіна «Чистий Agile»

Мы практикуем парное программирование, чтобы устранять блокеры в проектах, отбирать лучших кандидатов, онбордить новичков, делиться опытом и знаниями в команде. Эта практика также помогает оставаться социально активными и строить прочные межличностные отношения, живя в разных странах. Парное программирование — это активность, при которой два разработчика работают вместе над одной частью кода одновременно. Основная идея парного программирования — это обсудить, спланировать, обдумать и вдвоем реализовать лучшее решение, чем каждый из инженеров мог бы придумать в одиночку. Парное программирование способствует повышению качества кода, обмену знаниями, улучшению коммуникации и сокращению количества ошибок. Оно также способствует повышению производительности и уверенности в результатах благодаря непрерывному обратной связи и коллективному владению кодом.

Парное программирование возможно только при взаимном уважении и терпении. В то время как некоторые инженеры продолжают игнорировать парное программирование, думая, что это не стоит их усилий, у нашей команды противоположное мнение. Кроме того, для работы с кодом, при которой не нужен открытый браузер, удобно использовать ssh с tmux, особенно при низкой скорости интернета. Работая вместе и фокусируясь на одной задаче, разработчики не отвлекаются на Slack, почту, телефоны и прочее.

Навіщо потрібне парне програмування?

Это увеличивает вероятность выявления потенциальных проблем и улучшает общее качество программного продукта. Если мы говорим про действительно экспертов — то они пишут понятный код — это один парне програмування из важнейших показателей сеньорного уровня. Который (код), в общем-то требует только точечных пояснений, в нетривиальных местах, и для этого вполне достаточно получасового вок-тру митинга.

Давайте погрузимся в эту тему и развеем несколько мифов о парном программировании. Уже год успешно используем tuple.app , но даже Zoom + annotate делает дело. Обучать других это третий этап твоего обучения, ибо если ты видишь конкурентов в тех кого ты обучил, значит ты сам застрял в развитии. Если современное поколение айтишников тебе в принципе может составить конкуренцию, то проблема вероятно в тебе. Но если мозг нужно-таки включить, сконцентривоваться на проблеме… — с балластом, в виде требующего в это же время обучения нуба, проблему можно и вообще не решить.

Уникайте керування один одним

В течение сессии они периодически меняются ролями, обычно каждые полчаса, чтобы обеспечить равное распределение ответственности и вовлеченности каждого члена команды. Парное программирование особенно полезно в сложных или критически важных проектах, требующих высокой степени взаимодействия и совместной работы. Оно также может быть полезным для обучения новых членов команды, решения сложных проблем или повышения качества кода. Одним из ключевых преимуществ Гибкого потока работы в парном программировании является повышение качества кода. Совместная разработка позволяет обнаружить и исправить ошибки на ранних стадиях, благодаря тому, что два участника постоянно анализируют и контролируют работу друг друга.

На интервью говорили, что активно практикуют парное программирование на удаленном сервере при помощи tmux и vim. Я с обоими тулами, конечно же, на ты, но посмотрим что из этого выйдет. Вроде как они давно так работают, и им заходит. Занимаясь наймом https://deveducation.com/ и онбоардингом, в большинстве случаев я имею дело с опытными людьми уровня мидл и выше. Это справедливо, лишь для примитивного кода — который синьоры пишут, отключив мозг. Погонщик нужен в любом случае, потому что бумажки нужно заполнять.

Почему я выбираю парное программирование в удаленной команде

В сфере удаленной работы наличие хорошей пары может снизить вероятность ухода людей, поскольку они чувствуют себя более связанными с командой и, следовательно, с самой компанией. Например, на парной сессии мы показываем ребятам, которые только пришли в компанию или на проект, выдержки из документации. Со временем документация растет, и ее трудно прочесть и запомнить за один подход. Во время парного программирования я могу рассказать им вкратце о самом важном, сэкономив и их и свое время.

• Уже год успешно используем tuple.app , но даже Zoom + annotate делает дело.
• Парное программирование возможно только при взаимном уважении и терпении.
• Один из программистов, называемый «ведущим», управляет компьютером и фокусируется на деталях программирования.
• Это хорошо подходит для решения самых сложных проблем.
• Кроме того, для работы с кодом, при которой не нужен открытый браузер, удобно использовать ssh с tmux, особенно при низкой скорости интернета.
• Хорошо бы чтобы кто-то из пары умел работать в паре и знал про этот феномен.

Программирование и так рутинная дрянь, а тут ещё и бумажную работу бахнуть, и можно ехать в дурку. Парное программирование звучит, как два человека получают деньги, за то что может сделать один человек. Самый большой бонус программиста — это гибкое использование времени. Парное программирование — это сплошной стресс, напарники взаимно изнуряют друг друга. Больше 2 часов в день такой темп поддерживать просто невозможно. И это я еще экстраверт, бедным интровертам после такого и на лечение можно попасть.

Коллективное владение кодом

Кроме того, у нас появляется возможность быстрее решать блокеры и сложные задачи. Когда несколько человек работают над одной задачей, они чувствуют себя вовлеченными и причастными к кодовой базе. Все задействованные инженеры знакомы с разными частями продукта, а не только с теми, которые они создали лично. Сессия парного программирования создает идеальные условия для быстрой адаптации новых членов команды.

Парное программирование помогает как новичкам, так и долгожителям команды быстрее получать новые знания под руководством опытного инженера. В парном программировании обычно выделяют две роли – ведущего и наблюдателя. Ведущий активно пишет код, принимает решения и реализует идеи, а наблюдатель анализирует код, предлагает улучшения и задает вопросы. Роли могут переключаться между разработчиками в процессе работы. Я считаю, что, даже если мы потратим немного больше времени работая в паре, мы сэкономим как минимум столько же времени на этапах QA и review. Так как качество создаваемого кода в паре намного выше, а дефектов намного меньше.

Рефакторинг, просте та парне програмування. Уривок із книги Роберта Мартіна «Чистий Agile»

Но обучать работая «на дядю», вместо того чтобы педалить код? Если бы мне так хотелось обучать, пошёл бы в преподаватели. Да прям конкурентов обучают, мб вообще никого не обучать, на дворе дефицит кадров, будем вместо свежей крови, протухшим окорочкам зпшку поднимать. А потом сфера превратиться в типичный бизнес где заработали дядьки из 90х, а студент даже на практику их уломать не может, при том что готов батрачить бесплатно.

Проєктна вага коду

На моей практике 6 часов PP даже с регулярными перерывами — это уровень усталости в «мясо» даже для ветеранов PP. ПП отношусь плохо, первое что приходит на ум как разарабочику это не эффективно для заурядных задач которые уже поставлены «на рельсы» и надо «лабать». Потом не понятно как в двоем вести фикс багов, например?