Наверное не ново, но для меня откровение:
Вычитал у Брюса Эккеля про такой прием экстремального программирования, как "парное программирование" . Коротко- суть в том, что одну программу должны писать 2 программиста. Один кодит; второй думает, анализирует логику, проверяет на логические ошибки и т.д. Когда 1-й устает кодить или 2-й думать они меняются ролями.
Кто что об этом думает?
PS:
Лично мне не данную ситуацию представить тяжело…
13 ноября 2007 в 2:05
но это все равно разделение задач, как я понял, парное программирование, это выполнение абсолютно всей работы вместе, но поочередно. В принципе так можно проекты и 24 non stop писать, вот только где еще 25 час найти на все остальное
9 ноября 2007 в 15:05
Разногласия в способах реализации, на самом деле, не так страшны. Страшно то, что некоторые программист "патологически" не приемлют реализацию другим способом. Но это как раз один из самых ценных показателей профессионального уровня, вкупе с умением работать в команде.
> Несколько вариантов: вместе думаем архитектуру, затем кто-то пишет "мозги" кто-то пишет интерфейс, или кто-то полностью все проектирует, доводит все решения, а другой пишет это и просто консультируется о деталях.
Насколько я сталкивался, то сначала оба разрабатывают "архитектуру", а потом один пишет "мозги", а другой "интерфейс". Через "пару дней" (новая итерация) снова возвращаемся к архитектуре (уточнения, дополнения, изменения в дизайне, требованиях, функционале), после чего уже первый пишет "интерфейсы", а второй "мозги".
9 ноября 2007 в 13:00
Множественная личность — психический феномен, при котором человек обладает двумя или более различными личностями, или эго-состояниями. Каждая альтер-личность в таком случае имеет собственные паттерны восприятия и взаимодействия с окружающей средой. Людям с множественной личностью определяют диагноз «диссоциативное расстройство идентичности», или «расстройство множественной личности». Данное явление известно так же под названием «расщепление личности».
8 ноября 2007 в 14:03
2 Дмитрий Гайдамович
Да, конечно, личные противоречия людей не уладить разговорами, да и если у двух программистов слишком разные подходы к реализации одних и тех же задач, то договориться им будет проблематично (сам сталкивался по работе). Но это не значит, что обсужденй проводить не нужно – все не все, но хотябы часть разногласий в видении реализации уладить удастся.
8 ноября 2007 в 11:01
8 ноября 2007 в 9:00
<боюсь что за разговорами будет проходить большая часть времени.>
Так и должно быть, сперва всё обсуждается, чтобы противоречий в команде не было, а потом реализуется.
P.S.
Лучше проектированием вместе занимайтесь – одна голова хорошо, а две лучше.
7 ноября 2007 в 20:03
Всегда занимался парным программированием… со своим вторым Я. Ты его знаешь лучше любого человека и он тебя знает, с коммуникациями проблем тоже не возникает (общаемся телепатически мыслями). Но уже 2 недели друг предлагает заняться совместной разработкой проекта. Я всячески увиливаю (натура у меня такая наверное), но понимаю, что опыт совместной работы в команде (пусть даже из 2 людей) бесценен. Это сегодня программу пишешь один, а завтра уже пишешь в команде, послезавтра – распределяешь задачи в этой команде (если есть профессиональный рост). Все же склоняюсь к мнению, что стоит попробовать, и думаю как? Несколько вариантов: вместе думаем архитектуру, затем кто-то пишет "мозги" кто-то пишет интерфейс, или кто-то полностью все проектирует, доводит все решения, а другой пишет это и просто консультируется о деталях. Долгое время не знал как решить проблему с именованием переменных и функций (потом идея пришла при вставке куска "чужого" кода делать переименование и т.д.) просто на самом деле единственная проблема в коммуникациях, боюсь что за разговорами будет проходить большая часть времени.
22 октября 2007 в 13:01
ну и каким местом аутсорс коробочных продуктов (фирма X в Индии пишет продукт, фирма Y в Штатах оборачивает в коробку и продает клиентам) мешает внедрению гибких технологий?
22 октября 2007 в 4:02
> чтобы объяснить каким-нибудь индусам что нужно сделать (и чтобы они при этом это правильно сделали) займёт вдвое больше времени, чем если написать прогу самому.
при этом будет затрачено время двух людей (объяснятеля и индуса). помоему проще чтобы был один программист, чем два таких человека.
Ещё "меньше" времени потребуется, если весь проект будет делать один человек – сам для себя. Ничего никому объяснять не надо.
> и вообще, какой смысл распределять на кучу народу задачу, которую может сделать один человек? просто для галочки, что используются "гибкие технологии"?
Распределение задач и "гибкие технологии" разве где-то связаны?
Задачи распределяются, потому что быстрее, экономически выгоднее, или просто технически невозможно делать всё в одном месте "одним" человеком.
А когда, к тому же, ещё и существуют значительное количество маленьких компаний, которые заявляют "напишем всё что угодно на Java (к примеру)", то иногда, довольно часто выгоднее потратить время на составление развёрнутой документации по требованиям, и скинуть в туже Индию в такую компанию. Пуская делают.
А "гибкие технологии", как раз, не позволяют так поступать. Потому что гибкие технологии подразумевают постоянное взаимодействие с разработчиков с заказчиком. И никакие "аутсорсеры" не смогут постоянно принимать участие в обсуждениях с этим самым заказчиком результаты очередной итерации, и что ещё заказчик решает уточнить в своих требованиях, имея на руках уже частично работающую систему.
А то что "весь мир" работает на аутсорсерах, как раз, лишний раз свидетельствует о том, что "весь мир" к гибким технологиям только пресматривается. И встретить их можно только в маленьких небольших коллективах. Тем более, далеко не каждый заказчик готов выделить человека, который знаком с заказом настолько, что сможет квалифицированно работать с командой разработчиков, и постоянно обсуждать необходимые дополнения к уже работающей системе. А запуск системы в гибком программировании происходит уже после нескольких стартовых итераций, когда основной каркас системы будет собран.
21 октября 2007 в 22:05
я говорю не про "клиента", а про "юзера".
он ещё не знает, что будет существовать какая-то программа, и соответственно не может никак влиять на процесс разработки.
чтобы объяснить каким-нибудь индусам что нужно сделать (и чтобы они при этом это правильно сделали) займёт вдвое больше времени, чем если написать прогу самому.
при этом будет затрачено время двух людей (объяснятеля и индуса). помоему проще чтобы был один программист, чем два таких человека.
и вообще, какой смысл распределять на кучу народу задачу, которую может сделать один человек? просто для галочки, что используются "гибкие технологии"?
21 октября 2007 в 22:00
Так вот ситуация, когда "конкретный юзер платит за конкретное решение" – это и есть та самая ситуация, когда "проект уже есть, есть всё, что с ним связано, и требуется только написать "сортировку пузырьком", чтобы всё работало как надо". Да, "пузырёк" может оказаться сложным, и не каждому программеру под силу.
Собственно, и доход таких программеров целиком и полностью зависит, насколько они "гуру" в этой области, насколько быстро они могут накодить любые, поставленные перед ними, задачи. Это и есть та самая модель водопада. Где-то там решили, что нужна вот такая вот функциональность, и сбросили её решения куда-нибудь в Индию.
Но весь вопрос в том, что "вопрос функциональности" принимается не на уровне "желание клиента", а на анализе того, что конечный клиент хочет получить в качестве "обработанных программой данных". И, собственно, какая необходима функциональность для получения конечного результата из исходных данных, решает не клиент, а проектировщики.
Хотя, конечно, есть и исключения из правила. Когда клиент хочет, чтобы у него была не только самая модная и самая быстрая машина, но и целый том технических и функциональных требований, как оно должно быть сделано. Но в таком случае, "клиент" уже выступает в роли проектировщика, и ищет он как раз "кодеров", которые всё это сделают.
Но речь-то мы тут ведём о гибких методах разработки. Т.е. когда клиент постоянно сотрудничает с "командой разработчиков" с самого начала, и когда требование о необходимости замены "системного диалога открытия/сохранения файлов" логично вписывается в ту структуру, концепцию систему, которую желает получить клиент.
И если какой-то отдел получает только конкретные задачи по реализации, то это значит, что гибкие технологии до этой организации ещё не дошли. Потому что они строяться не снизу вверх (внедрим кусочки на местах, а потом и всю организацию перестроим), а сверху вниз. Гибкое программирование – это совершенно другой подход к созданию конечного продукта. И применение его методов где-то внутри "водопада" очень напоминает попытку переписать программу, написанную функциональным программированием в ООП, путём организации "классов" – контейнеров функций, которые эти функции как-то логически объединяют (модульное программирование).
21 октября 2007 в 20:00
если абстрагироваться от конкретной операционной системы, то можно вообще ничего не писать
юзеру эти теоретические изыскания глубоко фиолетовы. ему нужен конретный результат, за который он и платит деньги.
я же уже сказал – я говорю о реальных задачах, а не о теории.
"не программа, а патч к ОС" – хорошая отмаза
тем не менее этот "патч к ОС" – это всё-таки программа. набор инструкций процессора. и писать её должен программист.
21 октября 2007 в 18:02
Если абстрагироваться от конкретной операционной системы, то теоретически эта задача не решаема. Так как какая-нибудь ОС может не иметь механизмов для установки hook'ов на свои вызовы. А в таком случае, это уже не программа, а патч к ОС, который заменяет один системный диалог на другой. Ну а работу диалога легко можно имплеменитровать в рамках ООП, где любое действие в этом диалоге реализуется через его соответствующий метод, изменяя его состояние.
А на счёт реальных задач. Скажем, какая-нибудь веб-система (просто мне это ближе). CMS или веб-магазин. Какая-нибудь биллинговая система, ну, или что-нибудь ещё…
Сколько ты перечислишь таких систем (платных или бесплатных), которые построены на принципах ООП? Системы, где есть псевдо-ООП не катят (т.е. функции тупа раскиданы по каким-то классом, где класс – это некое хранилище функций).
21 октября 2007 в 14:02
ну объекты-объектами, но и какой-то полезный код помимо "взаимодействия объектов" в программе всё-таки должен быть (собственно – внутренности методов классов).
например – как ты нарисуешь схему программы, которая заменяет системный диалог сохранения/открытия файлов на свой, кастомный (имеется в виду – system wide, для всех прог)?
и причём здесь вообще ООП?
так что надо меньше теоретизировать, и больше смотреть на конкретные, реально существующие задачи.
21 октября 2007 в 4:04
> не понимаю, какой смысл держать толпу народу, которая ничего не умеет.
надеюсь, что в россии такого не будет, как в америке или европе.
Удивлю, но такой рабочей силы и у нас в стране предостаточно. Теже PHP-программисты (которые натягивают сайты на какую-нибудь CMS-ку + верстают понемногу). Теже Java-джуниоры, которых берут компании М пачками, чтобы те писали несложные программные модули. Зарплата таких монстров за редчайшими исключениями превышает $1,000. Да, и, собственно, по уровню задач, серьёзным проектированием заниматься не требуется. И, в то же время, применять к этим задачам гибкие технологии (парное программирование, в частности) – то же самое, что писать на объектах проект на 200-500 строк кода. Можно, но смысла особого в этом нет.
Нет, конечно, в рамках обучения этому процессу, можно этим заниматься, но только в рамках обучения. Иначе – это пустая трата времени (и денег).
Плюс, скажем, ещё лет пять назад, в нашей стране, профессионально объектным программрованием занимались не многие. А компании, которые пытались внедрить гибкие технологии можно было пересчитать по пальцам. И вся проблема в том, что гибкое программирование построено исключительно на объектной идеологии. И с процедурным программированием там делать нечего. А найти людей, которые любую поставленную перед ними (более-менее) серьёзную задачу будут решать исключительно в объектном поле даже сейчас не так-то просто. А уже методология ООП, как раз, смещает акцент от реализации (алгоритмы) на проектирование (схемы, классы). А оттуда, уже, как следствия идут, например, теже, Страустроповские "центральная строчка блока кода должна быть самой информативной" (цитата в моей интерпретации). Т.е. акценты расставляются не на алгоритмы, а на смысл преобразования. И пускай получается вызов десятков методов разных классов для этого преобразования, но зато логически код отражает именно то, что задумано при проектировании.
21 октября 2007 в 1:02
язык – это в любом случае "средство реализации своих идей", но это не значит, что нужна "низко квалифицированная рабочая сила".
не понимаю, какой смысл держать толпу народу, которая ничего не умеет.
надеюсь, что в россии такого не будет, как в америке или европе.
21 октября 2007 в 0:01
Так называемые "кодеры" появились не вчера. Это следствие когда-то всеобъемлющей методологии водопада в разработке. Во времена "гуру Си" и др. Так как их знания были очень востребованы, чтобы с ходу, применяя нестандартные решения, исправлять ляпы проектировщиков.
А сейчас с развитием CASE-средств и всё большей ориентацией на
вопросы проектирования (и постоянным возвратам к перепроектированию), т.н. "кодеры" рассматриваются как низко квалифицированная рабочая сила. Потому что очень часто их легко могут заменить эти самые case-средства. И "гуру языка" требуются только в каких-нибудь отделах низкоуровневой оптимизации (т.е. маленький сектор рынка).
Ну а, собственно, те, кто привык уже работать с case-средствами. Привык рассматривать задачу на мета-языках, привык прорабатывать нюансы взаимодействия объектов не в коде, а "на бумаге", то для того главное – это удобный и умный инструментарий, а не крутой и гибкий язык программирования. Соответственно, такой программист никогда не станет "мега-гуру" в каком-нибудь языке. Потому что для него он – всего лишь, средство реализации своих идей.
20 октября 2007 в 22:03
2Ваня Григорьев:
по-твоему существование т.н. "кодеров" – это нормальная ситуация?
20 октября 2007 в 16:05
> конкретная пара программистов сперва разрабатывает архитектуру скелета своего модуля, потом реализует его, смотрит на результат, отдаёт тестировщикам, снова смотрит на результат, наращивает функционал (снова посторение архитектуры и кодирование) и так далее.
Т.е. конкретная пара программистов работает не только кодерами, но ещё и архитекторами, квалити-тестерами и пр. Причём в полном объёме. Так как работают они над всем проектом, только циклически. Возможно, у нас это итак.
Но на Западе, где любой работник за каждый лишних пункт в должностной инструкции запросит соответственно дополнительную компенсацию, я очень сильно сомневаюсь, что существует значительное количество компаний, которые содержат таких "универсалов", соответственно, за бешенные деньги. Хотя идеология гибкого программирования пришла именно оттуда.
> Бесспорно, но это не обязывает прописывать всё до начала написания кода – схемы классов и базы данных легко генерируются по готовому коду, а современные средства документирования кода (например, xml-комменты в C# и javadoc) позволяют быстро составить докуметацию, описывающую код.
Бесспорен и обратный процесс. По качественно составленным схемам классов и их взаимодействия, довольно качественно генерится код, который нуждается только в небольших изменениях. Но мы не будем здесь обсуждать CASE-средства.
Речь у нас шла о том, что на этапе одной итерации (которая, как раз, и происходит по модели водопада) определяется требования к данному кусочку проекта, создаётся дизайн, проектирование, и как финальная часть, написание конечного кода и тестирование на соответствие требованиям.
И в такой схеме под "парную" работу лучше всего вписывается именно проектирование. Если проектировщику удобнее оперировать не UML, а C# или Java, и постоянно проверять свои "дизайнерские" решения – его право. Но на деле, проектирование происходит на "листе бумаги", а не "в программном коде".
И совсем другая история, когда два программиста садятся писать код по таким схемам, и у них сразу же возникают вопросы по тому, как, описанные в этих схемах, классы будут взаимодействовать. И начинают заниматься "проектированием на программном коде". А это следствие того, что этап проектировки был сделан халтурно. И кодеры занимаются не своей работой.
P.S. Тут речь не идёт о том, что идеология гибкого программирования не подходит для написания кода. Речь только о "парном программировании". И пользу я от него вижу только тогда, когда "проектировка" и "написание кода" объеденены по времени и месту. Возможно, от недостатка кадров в проекте, или от компетенции руководства проекта, которые считают, что все проблемы проектирования (на таком маленьком участке проекта, итерация) надо решать по ходу написания кода.
P.P.S. Может спросим у Олега Андреева (который пишет видеоплеер для вконтакта), как они разрабатывали его. Набрасали примерные схемки, моделки, связи и начали писать код, по ходу дела, разбираясь с тем, как же всё оно должно быть связано, чтобы функционировало так, как надо?
Или же сначала разработали более-менее полную модель того, как оно должно функционировать, решили все спорные нюансы, а потом запрограммировали эти схемы в код?
20 октября 2007 в 14:04
Очень удобно писать "в паре". Но в тех случаях когда заняты проэктом, который интересен обоим программерам.
Обычно просто проэкт делим на части, и каждый занимается только своей частью. Конечно без заглядывания в код напарника не обходится, интересно все-таки)
19 октября 2007 в 21:04
2 Ваня Григорьев
Вообще, маршрут ТЗ -> архитектура -> кодирование без возвратов к предыдущим стадиям, когда мегаархитектор прописывает всё от и до и за программистами остаётся только набивка тел методов логикой, является водопадной моделью и подходит (IMHO) для решения ограниченного круга задач, потому что в процессе разработки всегда встречаются непредвиденные грабли (заказчик новые требования прислал, обнаружилось что ранее спланированная версия реализации не подходит по каким-либо критериям и т.п.).
В большинстве случаев, используется циклическая модель, при которой стадии планирования, кодирования и тестирования повторяются по кругу.
В таком случае с применением парного программирования всё будет выглядеть примерно так:
конкретная пара программистов сперва разрабатывает архитектуру скелета своего модуля, потом реализует его, смотрит на результат, отдаёт тестировщикам, снова смотрит на результат, наращивает функционал (снова посторение архитектуры и кодирование) и так далее.
При чём тут парное программирование? А при том, что вдвоём они выработают лучшие решения – каждый смотрит поразному и предлагает свои решения, он их обсуждают, спорят и в итоге приходят к решениям, устраивающим обоих (в большинстве случаев, коллективные решения оказываются лучше, чем решения выработанные одним человеком).
Ещё один плюс того, что один пишет, второй смотрит, а потом они меняются в том, что 1 – со стороны ошибки видны лучше (у смотрящего глаз "незамылен" и 2 – продуктивно программировать в течение продолжительного времени не получится, устаёшь и начинаешь делать тупые ошибки, а смена мест за клавиатурой позволяет отдохнуть.
<Сложные алгоритмы можно решать на уровне мета-программирования.>
Намой взгляд, в коде решать сложные задачи тоже удобно – можно постепенно наращивать алгоритм, попутно проверяя результаты.
<Опыт растёт вместе с количеством решённых задач, а не от наблюдения за их решением.>
Поскольку напарники периодически меняются, оба будут принимать участие в решении задачи и написании кода.
<Если программисты обладают заметно разным уровнем, то тогда один будет работать за двоих>
Самому приходилось приходилось работать в паре с человеком на порядок превосходящим меня по уровню знаний и должен сказать, что профессиональный уровень быстро растёт – через некоторое время я разбирался в его коде, понимал идеии, которые он вкладывал в код и мог спокойно писать в том же ключе, что и он.
<следовательно, должен быть разный уровень вознаграждения>.
Никто не спорит, что уровень зарплаты должен зависеть от профессиональных навыков, но это тут не при чём – у напарников совсем необязательно должена быть одинаковая ЗП.
<Схемы и архитектура являются неотъемлемой частью проектной документации.>
Бесспорно, но это не обязывает прописывать всё до начала написания кода – схемы классов и базы данных легко генерируются по готовому коду, а современные средства документирования кода (например, xml-комменты в C# и javadoc) позволяют быстро составить докуметацию, описывающую код.
19 октября 2007 в 17:03
1. Сложные алгоритмы можно решать на уровне мета-программирования.
2. Опыт растёт вместе с количеством решённых задач, а не от наблюдения за их решением.
3. Если программисты обладают заметно разным уровнем, то тогда один будет работать за двоих (следовательно, должен быть разный уровень вознаграждения). Если уровни примерно равны, то они сравняются (в рамках данного проекта) уже за один день совместной работы.
4. Схемы и архитектура являются неотъемлемой частью проектной документации. Соотвественно, если их нет, или они не соответствуют коду – то техрайтеры начинают заново делать то, что делали в своё время программисты. Что не есть гуд. Работа должна делаться один раз.
Вообще, в моём представлении. Написание конкретной реализации конкретной вещи на конкретном языке программирования – это небольшая часть работы программиста. Основное время он тратит на решение "архитектурных" задач на мета-языках. Если это не так, и программист исключительно только пишет код – то это кодер, и никто другой. Если же ему ещё приходиться заниматься проектированием по ходу реализации – это следствие отсутствия архитектора в данной системе разработки. И кодер "за бесплатно" работает ещё и архитектор с "бесплатным" качеством такой работы.
19 октября 2007 в 7:03
Ответ – будет продуктивным при реализации относительно сложных алгоритмов,тк вторая голова будет быстрее искать мелкие ошибки, неизбежные при написании сложного кода. + в случае разницы между уровнями программистов – она будет снижаться.А в хорошей компании профессиональный рост сотрудников дб не менее важен, чем выполнение проекта.
Кроме того у меня сложилось впечатление что ты смешиваешь проектирование (схемы или другие варианты придумывания архитектуры) и написание проектной документации (которая действительно важна при передаче кода).Так вот вторую должны писать техрайтеры и ровно тогда, когда описываемая функциональность закончена и находится в стадии тестирования.
18 октября 2007 в 13:02
Евгений, у меня складывается впечатление, что у тебя, предложенная мной, схема не вписывается в идеологии итеративной разработки. Почему?
Неужели при разделении процесса на итерации, всю работу выполняет "один-два" человека.
Процесс написание остаётся тем же самым. Задача разбивается на много маленьких подзадач, которые можно и должны быть быстро реализованы до стадии "конечного кода". Но эти подзадачи решаются по "стандартной" схеме: проектирование-реализация-тестирование. И если в результате решения этих подзадач мы получаем только готовый протестированный код, но не имеем никакой "проектной" документации, то такой код через 6-12 месяцев можно будет выкинуть на помойку. Дешевле будет написать заново, чем разбираться в реализации.
Соответственно, имеем 2 формальных этапа "гибкой" разработке. Первая – общий дизайн системы, на основе которого выделяются маленькие подзадачи. Второй – реализация подзадач. И при необходимости, возврат к первому этапу.
И если проектировка происходит в уме (почти в уме) одного-двух программистов, которые работают целиком над всем проектом – это одно. Но если организации работы предполагает передачу части проекта другим программистам, то проектная документация должна на 95% соответствовать реализации. И это и определяет квалификацию программистов, которые способны работать по проекту/разрабатывать "проект" того, что они реализуют. Более того, это ещё и контроль за своей (или со стороны) деятельностью программиста.
Собственно, весь вопрос в том, что насколько "продуктивным" будет сидение двух программистов при кодировании классов, если до этого этими двумя программистами были нарисованы схемки, реализуемых ими, классов и все спорные вопросы были решены на этапе мета-программирования?
17 октября 2007 в 13:00
есть проблема связанная с тем, что нельзя нарисовать идеальную архитектуру в схемах с первого раза.
То что ты предлагаешь – называется waterfall. Сначала все рисуется в схемах, потом условные индусы реализуют методы, тупо забивая несложный код.
Уже в 80х годах стало известно, что эта схема неэффективна. Потому что проектировщики далеки от реализации. Они рисуют "идеальную" структуру – но как только оно попадает в код – могут возникнуть проблемы. Проблемы как быстродействия, так и банально "неудобный дизайн". Не бывает идеальных проектировщиков которые все предвидели и вообразили в уме готовый код.Как минимум в процессе проектирования должен быть человек, который будет все реализовать и может сказать – "вот тут будет херня, эту вещь нормально написать нет возможности".
Как только случается мелкая ошибка, изменение которой приводит к перелопачиванию хорошей доли схем – в сроки уже не вписаться.
Мир давно перешел к итеративной разработке, когда этапы проектирования, разработки и тестирования занимают некое фиксированное время (1 итерация) и потом все повторяется, все работают сообща и быстро исправляют ошибки. Опять таки создано куча методологий развития этого процесса – agile development и прочие.
Схемы могут быть полезным инструментом – но они никак не могут быть стержнем процесса, его краеугольной частью.
Я уж не говорю что в приведенной тобой схеме развитие личностей, делающих неквалифицированную работу, минимально.
17 октября 2007 в 2:02
Схемы не "синхронизированные" с кодом – время, потраченное в пустую.
> а чего делать когда на этапе написания кода выясняется что "вот эта и эта фигня вообще не нужны а вот эта жутко тормозит"?
1. "Вот эта фигня, вообще, не нужна" должно решаться на этапе проектирования. А не тогда, когда пишется код класса, и программиста осеняет, что эта функция-член "нах не нужна". Её необходимость – дело "проектировщика".
2. Ну а задачи по оптимизации – это, вообще, "полноценный" проект. И оптимизация здесь и сейчас потому-что так, вроде бы, эффективнее – есть зло.
Ну, вообще, мы разговариваем, возможно, о разных уровнях организации работы программистов.
Одно дело, когда программистам скидывают ТЗ, и они, судя по "сложности" задачи, либо занимаются рисованием примерных схемок, либо сразу начинают писать код.
И совсем другое дело, когда есть проектировщики, и есть кодеры. Одни работают над проектом, разрабатывают классы и пр., а другие делают простую "неквалифицированную" работу. Либо, эти две должности совмещаются.
Во втором случае, XP – удобная и легко встраиваемая вещь. В первом – получается использовать только какие-то кусочки, и часто в извращённом виде. Вроде один пишет код, а второй, за его спиной, судорожно думает, "а может всё надо по-другому реализовать в этом месте…"
16 октября 2007 в 14:04
2 Ваня Григорьев
а чего делать когда на этапе написания кода выясняется что "вот эта и эта фигня вообще не нужны а вот эта жутко тормозит"? Опять возвращаемся к начальному этапу – рисованию схем?
Схемы хороши только в одном случае – когда они всегда синхронизированы с кодом.
16 октября 2007 в 11:04
Схемы можно рисовать только когда проект долгосрочный и времени дофигищи, а гогда сроки маленькие на разрисовку всего и вся тратить драгоценные часы не получается – расписываются основные идеи и архитектурные решения, а детали придумываются уже по ходу дела.
У XP есть ещё один плюс – по методологии пары должны периодически меняться и это приучает писать код, понятный не только 2 напарникам, но и всё другим, кто потенциально может над ним потом работать.
16 октября 2007 в 0:00
Не знаю, как у вас, но в моей практике, если задача не уровня "это надо представить так, а это преобразовать так и всё", то "схемки" рисуются всегда. Более того, рисуются не только классы, но их то, как они взаимодействуют. И вся работа идёт, в основном, в этом "проектировочном русле".
А что касается реализации методов, то, если это какая-то научная математическая работа – или в этом роде – то не спорю. Над конкретной реализацией можно и нужно думать несколькими головами. Но это должно происходить до написания кода.
В остальных случаях, особенно, когда взаимодействия классов хорошо "прорисованы" реализация этих функций-членов настолько топорная, что с ней справляются даже автоматические генерилки кода. И на такую работу голову второго программиста тратить глупо.
15 октября 2007 в 12:04
2 Иван Григорьев
<Но все эти живые примеры объединяет то, что у этих людей не было реальных "висящих на стене перед глазами" схем того, что они пытаются реализовать.>
Схемы рисуются не всегда, да и даже если они есть, то описывают они классы и методы, а конкретную реализациюметодов приходится придумывать программистам
14 октября 2007 в 0:04
"если ставить в пару разнополых программистов – то КПД вообще до нуля упадёт"
А вот я с этим ни разу не согласен!
Парное программирование – рулезз! Независимо от пола и возраста. Само собой, что нужно общаться на одном языке и на одном уровне. А КПД – в любом случае выше, чем у одиночки. Хотя бы потому, что в две головы имеют больше шансов заполучить полезную идею…
13 октября 2007 в 21:02
У меня, конечно, опыт парного программирования не большой, но тот что имеется наводит меня на мысль, что действительная польза от него есть только в работе по проектированию. Т.е. когда два программиста сидят, и занимаются схемами (UML или что-то другое).
Практической выгоды в написании кода одним, и наблюдением за этим процессом вторым я не вижу. Кроме того, что через довольно короткий срок оба будут писать код пользуясь схожими соглашениями по оформлению.
Потому что из правильно составленных диаграмм классов, их взаимосвязей и пр. логично следует их имплементация. И наблюдать за этим "чисто техническим и часто автоматизированым процессом" довольно не продуктивно.
Хотя, честно, то встречал людей, которые именно пишут код вместе. Один пишет, а другой советует, что "вот так вот" написать будет лучше. Но все эти живые примеры объединяет то, что у этих людей не было реальных "висящих на стене перед глазами" схем того, что они пытаются реализовать.
11 октября 2007 в 16:00
Честно говоря, не сказал бы, что второй быстро втянется настолько, чтобы быть полноправным партнером первого. Он, конечно, станет гораздо круче чем был, но мозги не пересадишь.
По крайней мере, я такого не наблюдал.
Хотя, если дело именно в опыте, а не в общем уровне интеллекта, то очень возможно.
11 октября 2007 в 14:03
2 Дмитрий Гайдамович
<Но непонятно как внедрить эту методу на постоянной основе в отделе, где каждый штатный сотрудник имеет отдельное место, отдельный комп, задания формируются тоже конкретным людям, не парам.>
Просто при работе в паре напарники сидят за компом одного из них (за чьим конкретно – по договорённости), а задания выдаются именно парам
- Вася с Петей будуь делать интерфейс, а Миша с Димой доступ к БД
<Если все рассядутся по парам, будет выглядеть весьма странно…>
Нормально, хотя с непривычки может и странно.
2 Илья M@ilZ Константинов
<но программисты должны быть примерно одного уровня – иначе один будет думать за двоих>
Необязательно, второй глядя на код более опытного и получая от него советы быстро втянется и поднимет свой уровень.
11 октября 2007 в 11:02
Интересный метод, но программисты должны быть примерно одного уровня – иначе один будет думать за двоих, а это уже явно не парное программирование.
11 октября 2007 в 0:00
Это полезно, особенно если нужно быстро написать что-то на стыке подсистем, которые делались этими двумя людьми. Этот develop case начальство даже поощряет. Но непонятно как внедрить эту методу на постоянной основе в отделе, где каждый штатный сотрудник имеет отдельное место, отдельный комп, задания формируются тоже конкретным людям, не парам. Если все рассядутся по парам, будет выглядеть весьма странно… Как в том анекдоте, тут всю систему менять надо. Интересно в этом плане посмотреть, как организовано рабочее пространство группы XP, в книжке у Бека про это есть. К сожалению, большинство PM отнюдь не "болеют" идеями экстремального программирования, как их не обрабатывай. Так и выходит: новички приходят, "лепят" что-то ужасное, лидер не резиновый, многое пропускает, unit testingнарод не жалует, потому что мало кто знает, контроль качества "вешается", сроки летят и т. д. и т. п., извините за истерику
8 октября 2007 в 12:01
Делали один проект параллельно с моим наставником, с одной стороны есть существенные плюсы, он был по опытней меня, он замечал ошибки на уровне логики, я замечал ошибки более простые ошибки и заодно существенно быстро шел процесс обучения. Ну и работать было не скучно…
7 октября 2007 в 20:03
Ой. Алиночка, я ни в коем случае не наговариваю на эту превысокоэффективную технику. я просто имею ввиду что при некоторых особенностях партнеров может сложится, так сказать 'коллапс'. И ничего более.
С уважением.
7 октября 2007 в 14:00
Да, от пары много зависит. Эффективнее всего решаются сложные задачи, над которыми обычно тупишь часа по три прежеде чем писать код, а в паре, как правило, сразу начинаешь что-то писать и через три часа у тебя всё работет. Короче, скорость вырастает в разы. Да и соблаз слазить в интренет или проверить почту сразу отпадает. Но бывают и такие задачи, над которыми двоим просто грех сидеть. Второму просто скучно. Кстати, по XP пары должны меняться. При таких раскладах опыт в команде передаётся не хуже вируса
Всё вышесказаное проверено в коммерческих разработках и применяется и по сей день.
7 октября 2007 в 12:01
to Игорь Коноплянко, ну вот, опыта не было, а наговариваете почем зря…никуда ничего не падает, идеи генерятся лучше, да и кодить при желании получается не плохо=) проверено на примере курсовых
27 сентября 2007 в 22:02
Парное программирование- это на самом деле здорово…но только если вы хорошо знаете напарника…а если это не так, то это кошмар))
26 сентября 2007 в 15:02
Ага, туда же анекдот:
В отеле в трех номерах – физик, инженер и математик. У всех троих что-то загорается в номере.
Инженер выскакивает в коридор, берет огнетушитель и быстренько тушит пожар.
Физик выскакивает в коридор, берет огнетушитель, пару минут что-то считает и тушит пожар за минимальное время с минимальным расходом пены и оптимальным углом наклона огнетушителя.
Математик выскакивает в коридор, видит огнетушитель, восклицает "Решение существует!" и спокойно возвращается в номер.
26 сентября 2007 в 0:04
у меня опыт ? да вы мне льстите )) я вообще с девушек вижу только в университете ))
Вспомнил анекдот:
"Студент-экономист разговаривает со студентом-математиком.
CЭ: слушай, у тебя девушка есть ?
СМ: нет.
CЭ: а как же так ты без девушки то ?
СМ: а мне достаточно знать где её можно найти…"
25 сентября 2007 в 18:04
Игорь Коноплянко)
вижу опыт был))))
КПД падает когда за одним компутером))))
25 сентября 2007 в 16:03
Александр Зло Пинский написал:
А чего нервничать? На экране же код, а не порнуха
ахахах))) +1
25 сентября 2007 в 16:03
"второй нервничать что кто-то вечно подглядывает в его код."
Это комплексы, пройдет )
25 сентября 2007 в 16:02
to Олег Андреев
Ну чтоже вы так невнимательно читаете:) Я же сказал "…в тупом кодинге УЖЕ РАЗРАБОТАННОГО…" А вы пишите "РАЗРАБОТКА пользовательского интерфейса — это не кнопульки раскидать".
Я это прекрасно знаю и понимаю, и на интерфейс уходит гораздо больше времени чем на все остальное. Я имел в виду когда тебе уже приносят готовый дизайн макет с полностью расписанной логикой поведения.
Закодить такое это действительно "просто раскидать кнопульки" и думать там почти ненадо.
25 сентября 2007 в 15:00
"а второй нервничать что кто-то вечно подглядывает в его код."
А чего нервничать? На экране же код, а не порнуха
25 сентября 2007 в 14:00
"второй нервничать что кто-то вечно подглядывает в его код."
И вы не познали дао парного программирования =)
25 сентября 2007 в 13:05
Один все равно будет балду пинать. а второй нервничать что кто-то вечно подглядывает в его код. Зачем?
25 сентября 2007 в 12:02
"если задача состоит в тупом кодинге уже разработанного пользовательского интерфейса"
Вы еще не постигли дао парного программирования =) Разработка пользовательского интерфейса — это не кнопульки раскидать, это очень сложная задача. Видеоплеер для контакта делался парным программированием: я писал и предлагал решения, Паша Дуров критиковал и тоже предлагал решения, я критиковал его решения, и так итерации длились до 99,9%-й удовлетворенности. Сейчас еще кучу всего нужно доделать, так что "уже разработанным" интерфейс мне не кажется до сих пор.
25 сентября 2007 в 8:01
Кирилл Кринкин полностью с вами согласен, если задача состоит в тупом кодинге уже разработанного пользовательского интерфейса то от парного программирования толку маловато будет, а для сложных задач самое то
) Один думает второй реализует, также действует взаимный контроль и взаимная критика, что в итоге увеличивает качество. Не раз пробовал, очень доволен.
25 сентября 2007 в 1:01
очень эффективный метод. проверял. сложные баги обнаруживаются в момент написание или чуть раньше. скорость проектирования ( оно тоже парное ) сильно возрастает. если весь проэкт пишется по такой методике, то это приводит к тому что все программисты знают весь код.
25 сентября 2007 в 0:01
Иногда при решении какой нить задачи, я нередко захожу в тупик… в такие моменты я однозначно знаю что делать: срочно связываюсь с вот этим чувачком //vkontakte.ru/profile.php?id=381101. Вместе обсуждаем проблему, и в 95% случаев находим решение. Идея “одна голова хорошо, а две еще” лучше рулит))). Но это касаетсяобсуждения логики задачи. В классическом "парном программировании" никогда не участвовал.
24 сентября 2007 в 22:02
PP – вещь. в разы быстрее пишем)
24 сентября 2007 в 21:02
Критика зря, — сложные задачи решаются на ура… Правда, сознаюсь коллега по паре должен быть "своим в доску".. (бывает ли иначе в программистском коллективе?)
24 сентября 2007 в 21:00
хмм. если ставить в пару разнополых программистов – то КПД вообще до нуля упадёт. =) поэтому нужен третий, который будет кодить ! Triada ProgrammingTM
24 сентября 2007 в 20:05
pair programming рулит, однозначно
24 сентября 2007 в 20:03
Пробовал, в полевых условиях… при написании курсача =)
Что характерно стычки были за место у клавиатуры, а не за рядом.
Моё мнение: применимо когда обоим реально интересно и есть над чем подумать. Рутинная программерская работа в таком режиме конечно не очень пойдёт. Думаю былоб охрененно полезно в таком режиме делать первоначальные наброски всех б/м самомтоятельных модулей составом старший разработчег/разработчик которому писать, ток начальство не проникаецца
24 сентября 2007 в 19:05
Работал по такой методике. Довольно полезно – человек, смотрящий со стороны лучше замечает ошибки – у него глаз не "замылен", плюс вдвоём идеи хорошо генерируются и всегда есть с кем посоветоваться, плюс приучает писать понятный код. Главное при таком подходе периодически меняться, а то некоторые любят захватить клавиатуру и кодить сами, а напарнику через некоторое время такое положение дел наскучивает и он начинает плевать в потолок.
Но, как и во всём, тут нужно без фанатизма – если сроки поджимают, то двум программистам выгоднее распараллелиться и работать над разными частями проекта, чем вдвоём работать над одним и тем же.
2 Константин Kos Башаркевич
"Да вообще бывет нужно использовать какой-нибудь из нескольких приемов прагроммирования (к примеру), хорошо если мнения этих 2х программистов совпадают, а если нет …? )"
Если мнения не совпадают, то происходит обсуждение и выбирается вариант, устраивающий обоих.
24 сентября 2007 в 18:04
это когда денег на второй компьютер не хватает
24 сентября 2007 в 18:03
Есть. Но я кроме скайпа/аськи ничем таким не пользовался. Думаю, что шарить экран все-таки нужно, а по сети это будет не очень оперативно.
Вот здесь обсуждают, что лучше, сеть или личное общение:
//groups.google.com/group/ror2ru/browse_thread/...
24 сентября 2007 в 18:02
По моему, в парном программировании главное не "проверка кода другого программиста", а поочерёдный подход к проектированию.
Пока один пишет код, другой продолжает работать над деталями системы. Потом, первый возвращается к проекту, и оба изучают то, что наваял второй в проекте. Потом второй начинает реализовывать новую "консенсусную" частьпроекта, а первый начинает думать над другими деталями… И так далее. Итерация за итерацией.
И парное программирование подразумевает достаточно высокий уровень знаний языка программирования, на котором реализуется проект у обоих программистов.
24 сентября 2007 в 16:04
А какие средства есть для поддержки парного программирования, я имею ввиду, зачем сидеть за одной машиной, пусть каждый сидит за своей, но пишут код совместно в какой-нибудь multiuser vim/eclipse/idea/… (аналог gobby, но для программистов) и разговаривают вживую или по "скайпу". Вопрос в том есть ли этот multiuser vim/eclipse/idea/…?
24 сентября 2007 в 15:05
Константин Kos Башаркевич: "неизвестно че еще за тебя накодят"
Отчасти поэтому парное программирование и придумали. Один пишет, другой вникает и контролирует.
24 сентября 2007 в 15:03
По мне так лучше сначала несколько человек пишут подробный план, который бы достаточно четко определял метод реализации задачи, а дальше по ситуации.. кто-то пишет или делят на части и пишут, уж как удобнее, но вот план хорошо бы обсудить)
24 сентября 2007 в 15:01
имхо это очень применимо при разработке интерфейсов. А вот когда ты изучаешь API какого-нить Project Server и по-тихоньку кодишь, наблюдателю скучно.
24 сентября 2007 в 14:04
Хорошая методика, но как и каждая должна примерятся к ситуации. Иногда нужна и полезна, иногда только помешает – вобщем, главное без фанатизма, как обычно
24 сентября 2007 в 14:01
очень хороший метод…
24 сентября 2007 в 14:00
- В компании с кем-нибудь я начинаю гораздо быстрее генерировать идеи
- А писать – медленнее и мне постоянно неудобно, что я вот пишу, а человек тут сидит рядом и места себе не находит, поэтому я начинаю всячески комментировать свою деятельность, задавать вопросы в воздух, чтобы человеку хотя бы был над чем подумать – в результате пишу медленнее и хуже.
Но это потому, что это не было целенаправленным pair programming, просто иногда так получалось. Может, если бы мы договорились "час я, час ты", то таких тараканов бы не было и все было бы прекрасно.
24 сентября 2007 в 13:04
так никогда не делал. работали всегда XXX человек, разделяя задачу на маленькие части, и потом сливаю все в единое целое.
24 сентября 2007 в 13:03
Я работал так. Очень здорово. Но в некоторых случаях нужно "тупо кодить" и "наблюдателю" становится скучно.
24 сентября 2007 в 13:03
Это если печать лень, тогда да можно приминить
А так … помоему все лучше делать самому – неизвестно че еще за тебя накодят. Да вообще бывет нужно использовать какой-нибудь из нескольких приемов прагроммирования (к примеру), хорошо если мнения этих 2х программистов совпадают, а если нет …? )
24 сентября 2007 в 13:02
Есть такое чудо.
Удобно для обучения младших коллег или новичков в программировании.