Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 63
Да простят меня приверженцы XP и прочих методологий, я просто оставлю это тут…
Можно делать ЭТО и в паре. Неужели вы никогда не звали никого на помощь, чтобы рядом с вами поседели, а вы объяснили в чем проблема?
Поседели от вашего кода :)
Делали и не только в паре. Несомненно эффект наблюдателя играет свою роль, но это мало относится к тем правилам, которые были описаны Кентом Беком и другими. Главная проблема же заключается в том, что после увеличения частоты появлений на слуху трендовых словечек (читай agile, scrum, xp, kanban...) начинаются неизбежные попытки доказать (в первую очередь самому себе), что мы тоже доросли и разбираемся в том как правильно организовать процесс разработки. Ты начинаешь внимательно изучать труды основоположников методологий, может быть даже посещать конференции и слушать доклады тренеров, а этих хитрецов сейчас пруд пруди и далее применять это все на практике, попутно навязывая всем кому не лень. В некоторых случаях тебе даже кажется, что это приносит профит и ты горд и удовлетворен. Но погоня продолжается, т.к. ты узнаешь что в другой команде применяется, со слов рассказчиков, более эффективный подход и ты изучаешь дальше… а потом осознаешь, что все это раньше называлось адекватностью и здравым смыслом, а сейчас — эджайлом, который тем самым принес больше вреда, чем пользы и время можно было потратить на изучение материалов, относящимся к практикам разработки или на отдых.
Вот потом программисты которые толком то и не знакомы с экстремальным программирование, скрамами и CI начинают материть эти подходы.
Есть такое. Обычно, все, кто матерят (которых я знаю), даже и не представляют процесса.
Типичный диалог:
— Что это за г… нокд? Почему два разных интерфейса слили в один просто собрав методы первого и второго, несмотря на то, что они пересекаются?
— Это мы объединяли быстро, не было времени. (по ТДД)
Т.е. юнит-тесты были? нет. Не говоря о том, что писать раньше кода. Рефакторинг был? Нет.
Зато ТДД в сознаниях — источник г… нокодов.
Пытаешься объяснить, что код нужно писать и проектировать на ходу, на здесь и сейчас, а у людей клин сразу: как можно так писать, мы уже сталкивались, получаются костыли и говнокод — нужно обязательно продумывать архитектуру, гибкость и т.д.
И на счет манифеста «пишите код, бл… ть». Пишут код все. Но по разному. Я в паре не работал. Скорее всего это дает свой эффект. Но дело не в методологиях управления, а в навыках проектирования и кодирования. В навыках определения, что нужно прямо сейчас, в навыках рефакторинга — определения, в какой вид код должен быть приведен, чтобы соответствовать точно тому, что нужно сейчас. Моделировать предметную область. Понимать, что является реализацией, хитростью, а что является отражением требований. Это навыки именно кодирования. Методологиями управления эти пробелы не закроешь.
А работа в паре, видимо, способствует всего лишь овладению этими навыками. Т.е. учебе за счет работодателя. И если это делает работу эффективнее, даже параллельно с учебой, то почему нет — хорошая технология.
Но по-моему, эффективнее было бы, если бы книг побольше с разобранными примерами было, описывающими необходимые навыки.
Типичный диалог:
— Что это за г… нокд? Почему два разных интерфейса слили в один просто собрав методы первого и второго, несмотря на то, что они пересекаются?
— Это мы объединяли быстро, не было времени. (по ТДД)
Т.е. юнит-тесты были? нет. Не говоря о том, что писать раньше кода. Рефакторинг был? Нет.
Зато ТДД в сознаниях — источник г… нокодов.
Пытаешься объяснить, что код нужно писать и проектировать на ходу, на здесь и сейчас, а у людей клин сразу: как можно так писать, мы уже сталкивались, получаются костыли и говнокод — нужно обязательно продумывать архитектуру, гибкость и т.д.
И на счет манифеста «пишите код, бл… ть». Пишут код все. Но по разному. Я в паре не работал. Скорее всего это дает свой эффект. Но дело не в методологиях управления, а в навыках проектирования и кодирования. В навыках определения, что нужно прямо сейчас, в навыках рефакторинга — определения, в какой вид код должен быть приведен, чтобы соответствовать точно тому, что нужно сейчас. Моделировать предметную область. Понимать, что является реализацией, хитростью, а что является отражением требований. Это навыки именно кодирования. Методологиями управления эти пробелы не закроешь.
А работа в паре, видимо, способствует всего лишь овладению этими навыками. Т.е. учебе за счет работодателя. И если это делает работу эффективнее, даже параллельно с учебой, то почему нет — хорошая технология.
Но по-моему, эффективнее было бы, если бы книг побольше с разобранными примерами было, описывающими необходимые навыки.
Бинго.
Не только навыками, а также обеспечивает быстрое вливание в команду нового человека.
Я думаю, что это самый логичный случай использования парного программирования.
При этом новичок пишет код, а наблюдатель корректирует и отвечает на вопросы.
А работа в паре, видимо, способствует всего лишь овладению этими навыками.
Не только навыками, а также обеспечивает быстрое вливание в команду нового человека.
Я думаю, что это самый логичный случай использования парного программирования.
При этом новичок пишет код, а наблюдатель корректирует и отвечает на вопросы.
Это самый большой плюс от парного программирования. Все остальное вполне можно заменить техникой и технологией написания кода.
Это слишком упрощённый взгляд на ПП.
На самом деле самый большой плюс от ПП в том, что оно поддерживает высокую сконцентрированность практически весь рабочий день и стимулирует программистов обсуждать (а значит, продумывать) проблему до того, как начинать её делать. Это только теоретически «можно заменить техникой», а на практике — фиг там.
На самом деле самый большой плюс от ПП в том, что оно поддерживает высокую сконцентрированность практически весь рабочий день и стимулирует программистов обсуждать (а значит, продумывать) проблему до того, как начинать её делать. Это только теоретически «можно заменить техникой», а на практике — фиг там.
Продолжительная высокая концентрация приводит к более сильной усталости, что приведет к ухудшению качества кода, снижению мотивации и удовлетворенности от результатов труда. Нужно очень аккуратно следить за количеством стресса от парного программирования, чтобы держать эффективность труда на должном уровне.
Обсуждения — норма в мире XP. Зачастую, интерфейсы и особенности реализации обсуждаются коллективом до того, как пары приступят к реализации. Если вы этого не делаете, то стоит перестраивать процесс разработки.
Обсуждения — норма в мире XP. Зачастую, интерфейсы и особенности реализации обсуждаются коллективом до того, как пары приступят к реализации. Если вы этого не делаете, то стоит перестраивать процесс разработки.
Высокая концентрация — это вопрос самоорганизации. У меня, например, в большинстве случаев очень высокая сконцентрированность — и не потому, что я прямо себя заставляю или какой-то идеальный, а просто когда не отвлекаюсь. Само собой происходит. Если выключить все отвлекающие вещи и войти в ритм, то и не представляю, что ПП заставит меня еще больше концентрироваться.
Когда есть задачи и когда они не десятиминутные, то бывает так увлекаешься, что оторваться тяжело на «бытовые» нужды )))
Обсуждение — хорошо. Если не отвлекает. Чужой взгляд тоже дает эффект. Потому как много раз замечал: вроде всё понимаю ясно и делаю всё, кажется, верно, но если рядом другой человек и он спросит «почему так», то замечаю свои ошибки. Да и вообще-то, я пишу код не для себя. И если другому человеку не понятно, это сигнал, что код объективно непонятный.
Это хорошо, только непонятно, будет ли пара работать эффективнее, чем по одному. Даже если немного качественнее, но два человека тратили время.
Когда есть задачи и когда они не десятиминутные, то бывает так увлекаешься, что оторваться тяжело на «бытовые» нужды )))
Обсуждение — хорошо. Если не отвлекает. Чужой взгляд тоже дает эффект. Потому как много раз замечал: вроде всё понимаю ясно и делаю всё, кажется, верно, но если рядом другой человек и он спросит «почему так», то замечаю свои ошибки. Да и вообще-то, я пишу код не для себя. И если другому человеку не понятно, это сигнал, что код объективно непонятный.
Это хорошо, только непонятно, будет ли пара работать эффективнее, чем по одному. Даже если немного качественнее, но два человека тратили время.
> Если выключить все отвлекающие вещи и войти в ритм
:) Вот-вот. Если. В том-то и фокус, что это «если» далеко не всегда случается. А с ПП всегда.
А в остальном всё так, да.
Ну вот, мой опыт показывает, что пара будет работать эффективнее. Код много качественнее, решения много проще.
:) Вот-вот. Если. В том-то и фокус, что это «если» далеко не всегда случается. А с ПП всегда.
А в остальном всё так, да.
Ну вот, мой опыт показывает, что пара будет работать эффективнее. Код много качественнее, решения много проще.
Да элементарно выключить )) У нас компания об этом позаботилась. Закрыли любые меседжеры и внешнюю почту. Хабр забыли. Если бы еще сюда не заходил, был бы полный идеал. Но сюда стараюсь заходить до работы или после.
И по себе знаю, какая мука работать отвлекаясь. Устаешь гораздо больше от такого, чем концентрация и работа.
в оригинале было:
"...Their method is «pair programming»—where two people share one desk and one computer. One person is the «driver,» controlling the keyboard and typing in code. The other «navigates,» monitoring design and scanning for bugs."
так что — " не читайте до обеда советских газет" (с)
"...Their method is «pair programming»—where two people share one desk and one computer. One person is the «driver,» controlling the keyboard and typing in code. The other «navigates,» monitoring design and scanning for bugs."
так что — " не читайте до обеда советских газет" (с)
>Каждый из партнеров придерживается своих стандартов кодирования, что вызывается бурные дискуссии и ужасно отформатированный код.
За это жестоко надо карать независимо от методики. Должен быть выработанный командный стандарт, которого все придерживаются.
За это жестоко надо карать независимо от методики. Должен быть выработанный командный стандарт, которого все придерживаются.
Да, просто вопрос в том, как будет проходить адаптация этих стандартов. Бывает, что всем рассылается документ, где они описаны, можно парами программировать, можно просто проявить адекватность и всей командой его принять. Как говорил, парное программирование здесь может быть как инструмент для адаптации.
Я немного про другое) Не имеет смысла вырабатывать этот стандарт в таких спорах. Это говорит о незрелости команды. Он должен быть (любым способом) выработан до начала работы над проектом.
Конечно, есть случаи, когда это неприминимо — я как-то занимался портированием уже написанного кода с одной платформы на другую (мобильные телефоны), но там вопросы _своего_ стиля и не возникали — нам приходил код начиная от пересыпанного си-измами, заканчивая чуть ли не индусским. После такого «разнообразия» к любому стилю относишься спокойно)
Конечно, есть случаи, когда это неприминимо — я как-то занимался портированием уже написанного кода с одной платформы на другую (мобильные телефоны), но там вопросы _своего_ стиля и не возникали — нам приходил код начиная от пересыпанного си-измами, заканчивая чуть ли не индусским. После такого «разнообразия» к любому стилю относишься спокойно)
Как на счет варианта, когда вы пришли на другой проект, а там другие стандарты?
Если это разработка нашей же команды (в которой принят единый стандарт), то выходит они нарушили соглашение, а значит надо дать по шапке.
Если же код писали другие люди, то тут уж как получится, я чужой код пытаюсь менять на наши стандарты, по мере правок того или иного модуля.
По поводу стандартов в команде — мы собрались всем отделом и обсудили что да как, поспорили немного, но в итоге пришли к единому способу кодирования. А вот все новые члены команды уже ставятся перед фактом.
Если же код писали другие люди, то тут уж как получится, я чужой код пытаюсь менять на наши стандарты, по мере правок того или иного модуля.
По поводу стандартов в команде — мы собрались всем отделом и обсудили что да как, поспорили немного, но в итоге пришли к единому способу кодирования. А вот все новые члены команды уже ставятся перед фактом.
Да, это интересно. А сколько человек у вас в команде? И сколько проектов идет одновременно?
Например, у нас на каждом проекте свои стандарты кодирования, которые исходят в основном от тимлида.
Например, у нас на каждом проекте свои стандарты кодирования, которые исходят в основном от тимлида.
У нас команда небольшая, потому все так гладко прошло.
Но если в разных командах приняты разные стандарты, то это уже не стандарты, а бардак.
ИМХО конечно же, но я бы приложил усилия чтобы этого избежать.
Но если в разных командах приняты разные стандарты, то это уже не стандарты, а бардак.
ИМХО конечно же, но я бы приложил усилия чтобы этого избежать.
А зачем этого избегать? Вот у нас идет сейчас 6 проектов, два из которых достались с уже написанным кодом. Стандарты кодирования на всех проектах разные, но внутри проекта все придерживаются единого.
Есть ли смысл продавливать в каждую команду общие стандарты?
Есть ли смысл продавливать в каждую команду общие стандарты?
А какой вообще смысл от стандартов?
В моем понимании стандарты нужны, чтобы любой разработчик мог читать чужой код как свой. А так если кого-то перекинут в другую команду, то по началу он будет испытывать дискомфорт, или вообще в порывестрасти будет писать код по стандартам другой команды.
В итоге на выходе каша и плохо читаемый код.
В моем понимании стандарты нужны, чтобы любой разработчик мог читать чужой код как свой. А так если кого-то перекинут в другую команду, то по началу он будет испытывать дискомфорт, или вообще в порыве
В итоге на выходе каша и плохо читаемый код.
А если разработчик не пойдет в другую команду, то все усилия по распространению общего на всю компанию стандарта будут напрасны.
Даже если он и пойдет в другую команду, то к стандартам привыкает довольно быстро, главное что внутри проекта они едины.
Даже если он и пойдет в другую команду, то к стандартам привыкает довольно быстро, главное что внутри проекта они едины.
Ну это все довольно спорный вопрос, не будем холиварить :)
Я считаю если это стандарт, то он должен быть единым стандартом для всех.
Я считаю если это стандарт, то он должен быть единым стандартом для всех.
Да, есть общие критерии качества кода, общие рекомендации. Например, есть msdn.microsoft.com/en-us/library/czefa0ke(v=vs.71).aspx
Просто дело в том, что в каждом проекте они может слегка отличаться. Я понял вашу позицию и у нас тоже так было, когда мы все делали один проект. Но с размерами начинаются небольшие изменения, которые кстати не доставляют проблем.
Просто дело в том, что в каждом проекте они может слегка отличаться. Я понял вашу позицию и у нас тоже так было, когда мы все делали один проект. Но с размерами начинаются небольшие изменения, которые кстати не доставляют проблем.
В моем понимании стандарты нужны, чтобы любой разработчик мог читать чужой код как свой.
Неверно.
Стандарт нужен для того, чтобы было представление о стиле кодирования.
Также он создает некоторое уважение к стандарту.
И, наконец, позволяет с помощью автоматизированных средств приводить код к единообразию, если, например, при копировании съехали отступы.
А еще иногда стандарты кодирования позволяют избегать конкретных ошибок — сам стиль кодирования нивелирует вероятность появления подобных ошибок.
P.S. Холивар по copy_n_paste оставим в стороне, ладно?
>Как на счет варианта, когда вы пришли на другой проект, а там другие стандарты?
В этом варианте нужно вспомнить пословицу «В чужой монастырь со своим уставом не ходят» и подстроиться под стиль команды.
В этом варианте нужно вспомнить пословицу «В чужой монастырь со своим уставом не ходят» и подстроиться под стиль команды.
>Да, просто вопрос в том, как будет проходить адаптация этих стандартов. Бывает, что всем рассылается документ, где они описаны...
А создать файл стиля и установить всем в IDE — не? Не знаю, как там в остальных, но в Эклипсе это делается в несколько кликов. После чего он будет «помогать» не только во время написания, правильно расставляя отступы и прочее, но и позволяет привести к устаноленному стилю сразу весь файл при помощи магической комбинации Ctrl+Shift+F.
А создать файл стиля и установить всем в IDE — не? Не знаю, как там в остальных, но в Эклипсе это делается в несколько кликов. После чего он будет «помогать» не только во время написания, правильно расставляя отступы и прочее, но и позволяет привести к устаноленному стилю сразу весь файл при помощи магической комбинации Ctrl+Shift+F.
Прверено на себе, процесс написания кода становится оч ржачным, эффект несомненно есть. Единственный минус — эти двое мешают остальным, потому что постоянно говорят и делают это громко и бороться с этим бесполезно.
Да-да :)
Ну есть множество вариантов: уединиться в митинг-руме (при условии что есть ноут например), работать вечером, когда офис пустой ну и много вариантов. Не считаю это проблемой.
Вообще парное программирование это забавно, но продуктивность повышается не больше чем на 50%, по сути затрачивая те же человеко-часы выходит больше времени, нежели если бы оба программиста занимались одним и тем же. Только в некоторых ситуациях (когда надо сделать быстро и качественно и на человеко-часы плевать к примеру) этот подход имеет право на жизнь. Но это сугубо мое мнение и оно может не соответствовать истине.
Вообще парное программирование это забавно, но продуктивность повышается не больше чем на 50%, по сути затрачивая те же человеко-часы выходит больше времени, нежели если бы оба программиста занимались одним и тем же. Только в некоторых ситуациях (когда надо сделать быстро и качественно и на человеко-часы плевать к примеру) этот подход имеет право на жизнь. Но это сугубо мое мнение и оно может не соответствовать истине.
Когда у нас братом появился один компьютер на двоих нам просто пришлось практиковать именно эту методику. И это реально работало! Но хочу заметить что у нас на двоих был не только компьютер: у нас был общий интерес, мотивация, а самое главное одинаковый уровень знаний!
Я считаю что эта техника не применима для производства программного обеспечения. Очень трудно будет найти «пару» с теми же параметрами: мотивация, интерес, уровень знаний…
Я помню как мы радовались когда решали любую задачку… Это было просто офигенно… Спасибо что напомнили )
Я считаю что эта техника не применима для производства программного обеспечения. Очень трудно будет найти «пару» с теми же параметрами: мотивация, интерес, уровень знаний…
Я помню как мы радовались когда решали любую задачку… Это было просто офигенно… Спасибо что напомнили )
PS: Сейчас у нас один большой стол с двумя компьютерами. И хотя мы пошли по разным направлениям, я в веб а он в системное программирование, мы продолжаем обсуждать и дополнять идеи друг-друга, а самое главное ценить результаты… Никакой другой коллектив не даст мне такого «чувство локтя» как семейный. В прямом смысле )
Могу заверить, что уровень знаний не обязательно должен быть таким уж одинаковым. Совсем недавно парнокодили с коллегой, он лучше меня знает тонкости и плюшки RoR, а я лучше него знаю JS. В итоге — у нас вышла продуманная, красивая архитектура и реально полезный обмен опытом.
Постоянно практикую работу в паре. Потому что кроме этого варианта больше нет нормального способа передавать знания между работниками. Но это требует гораздо больших затрат усилий, чем работа в одиночку.
В универе принимал участие в олимпиадах ACM, там работали втроем за одной машиной. Действительно помогает сконцентрироваться, когда кто-то рядом следит за кодом. Но постоянно в таком режиме работать очень тяжело.
В универе принимал участие в олимпиадах АСМ. Парного программирования реально было очень мало. Парный анализ и поиск решения — это да. А когда идея ясна вбивать чаще проще одному, чтобы сэкономить второму время на решение еще одной задачи.
Меня в парном программировании больше всего смущает как раз отсутствие потока. Мне щас скажут, что мы, конечно, делали неправильное парное программирование, но я реально не представляю сколько нужно это «тренировать», чтобы был «парный поток». И я очень удивлен 8-му пункту статьи, для меня в этом месте наоборот большой минус.
Меня в парном программировании больше всего смущает как раз отсутствие потока. Мне щас скажут, что мы, конечно, делали неправильное парное программирование, но я реально не представляю сколько нужно это «тренировать», чтобы был «парный поток». И я очень удивлен 8-му пункту статьи, для меня в этом месте наоборот большой минус.
Я просто не мог не оставить это здесь. Лучший видео курс по парному программированию от Bitbucket:
.
.
Мы в нашей фирме используем парное программирование, и могу подтвердить, что это действительно отлично работает. В общем-то, никаких секретов здесь нет: оно просто поддерживает высокую сконцентрированность практически весь рабочий день.
Хочу сказать, что данный метод хорошо подходит не только для программирования. Нетривиальные моменты в системном администрировании тоже лучше работают в парном методе. Тут, разумеется, не «ревью», а человек, который во-первых остановит от глупости, во-вторых подскажет что делать дальше.
Причина простая: у одного кусок мозга занят кнопками. Второй видит картинку чуть больше на расстоянии и имеет больше ресурсов на то, чтобы просто перебирать варианты. Если первый, замерший на пару минут, создаёт стресс «чего ждёшь?», то второй может минуту молчать, обдумывая какой-то тонкий момент.
Плюс критический взгляд со стороны мешает халтурить.
Причина простая: у одного кусок мозга занят кнопками. Второй видит картинку чуть больше на расстоянии и имеет больше ресурсов на то, чтобы просто перебирать варианты. Если первый, замерший на пару минут, создаёт стресс «чего ждёшь?», то второй может минуту молчать, обдумывая какой-то тонкий момент.
Плюс критический взгляд со стороны мешает халтурить.
Да, ещё, по поводу исследовательских задач. Как раз в них, как мне кажется, парный вариант куда более интересный и эффективный. Потому что тут идёт не просто «code review», но и совместное обдумывание решения или вариантов/причин существования проблемы.
Столько раз было — «а посмотри-ка ты в (...), может там будет (...)» — и иногда так и было. Экономя при этом часы и часы бесплотных попыток.
Столько раз было — «а посмотри-ка ты в (...), может там будет (...)» — и иногда так и было. Экономя при этом часы и часы бесплотных попыток.
Никогда не пытался внедрить эту практику в своей команде, но это происходит само собой регулярно. Вот примерный юз-кейс:
— %Username%, можешь глянуть? Что-то я не врублюсь.
— Ну ка… ээээ, да ты олень, все не так! Вот это сюда, а эту чушь вообще нахер сотри…
<прошло минут 10 >
— Ну вот, смотри как круто вышло!
— Ага
— %Username%, можешь глянуть? Что-то я не врублюсь.
— Ну ка… ээээ, да ты олень, все не так! Вот это сюда, а эту чушь вообще нахер сотри…
<прошло минут 10 >
— Ну вот, смотри как круто вышло!
— Ага
Парное программирование также работает удаленно, используя связку Skype + VSAnywhere.
Больше всего понравилось описание анти-паттернов.
Я бы добавил еще парочку:
Халявщик: работает только один разработчик, второй тихо сидит рядом и просто думает о своем или даже спит.
Совершенный код: разработчики слишком увлекаются теоретическими обсуждениями макро- и микро- архитектур, тратя на это времени гораздо больше чем требуется.
Я бы добавил еще парочку:
Халявщик: работает только один разработчик, второй тихо сидит рядом и просто думает о своем или даже спит.
Совершенный код: разработчики слишком увлекаются теоретическими обсуждениями макро- и микро- архитектур, тратя на это времени гораздо больше чем требуется.
Лет 10 назад пробывали мы этим заниматься, причём в области программирования для встроенных систем.
Не знаю как со скоростью, но что код получается чище и ошибок меньше, это точно!
Хочу только заметить, что Экстремальное программирование не ограничивается только работой в парах. В него много чего ещё входит, например написание тестов до начала программирования.
Не знаю как со скоростью, но что код получается чище и ошибок меньше, это точно!
Хочу только заметить, что Экстремальное программирование не ограничивается только работой в парах. В него много чего ещё входит, например написание тестов до начала программирования.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Экстремальное программирование: Pair Programming