Здравствуйте, Shmj, Вы писали:
S>Как вы думаете, кто-то еще использует т.н. парное программирование? Каков примерный процент использования?
Примерно около нуля, ибо эффективность "на рыло" выходит крайне низкая
Вторая пара глазьев полезна только когда какой то затык надо размотать, что случается крайне редко. В остальное время это пустая трата Вилли.
Здравствуйте, Shmj, Вы писали:
S>взаимном контроле — чтобы не захотелось ютюб смотреть вместо работы.
Мне кажется, это главная проблема. Я как-то пробовал, в целом плюсов много, работа реально идёт раз в 5 быстрей обычного, но ценой того, что по 5-6 часов в день программируешь. Для меня это сложно, я привык 2-3 часа, больше — уже невосполнимо устаю. При этом менеджеру же не объяснишь этого, он вообще считает, что программировать надо с 10 до 19, дай волю — так и на туалет бы повешал датчик времени. Поэтому в целом к такой практике отношусь положительно и считаю, что она реально увеличивает производительность и качество кода непропорционально, но вот такой вот логистический нюансик всё портит.
Здравствуйте, Shmj, Вы писали:
S>Как вы думаете, кто-то еще использует т.н. парное программирование? Каков примерный процент использования?
По-моему, оно полезно, когда расходы на оборудование сравнимы или превышают расходы на персонал.
С учетом того, что оборудование покупается один раз и надолго, а персоналу надо платить постоянно, плюс аредновать помещение, где сидит персонал, зарплаты должны быть какие-то совсем крошечные, чтобы этот подход имел смысл.
Здравствуйте, CreatorCray, Вы писали:
CC>Вторая пара глазьев полезна только когда какой то затык надо размотать, что случается крайне редко. В остальное время это пустая трата Вилли.
Вторую пару глазьев можно и позвать по мере надобности. Совершенно не обязательно, чтобы она всю дорогу сидела рядом и пыхтела.
Здравствуйте, CreatorCray, Вы писали:
S>>Как вы думаете, кто-то еще использует т.н. парное программирование? Каков примерный процент использования? CC>Примерно около нуля, ибо эффективность "на рыло" выходит крайне низкая
Хипстеры-мудаки (те, кто придумал термин) всё извратили.
Собери команду из нескольких реально самомотивированных друзей на интересный проект. Без начальства, без волокиты, без церберов, без всего ненужного. То есть, с максимальной эффективностью. Кстати, в качестве пруфа: именно так и устроена компания, где прибыль на рыло составляет мировой рекорд.
Посмотри, как они работают, и ты увидишь, что естественным путём люди изрядно времени проводят вдвоём-втроём за одним компом. Так удобно. Тут приходит хипстер-менеджер-мудак, и говорит: о, я вижу сидение вдвоём коррелирует с эффективностью. Так пусть все сидят вдвоём! Так и родилась вся эта чушь: парное программирование, TDD и прочая экстремальщина.
Здравствуйте, Alekzander, Вы писали:
A>Если бы меня пригласил совместно поработать кто-то, кто до этого успешно поставил на рельсы пару-тройку стартапов, я бы не спрашивал про какую-то там зарплату.
Ну я работал в таком стартапе
Вместе сидели только когда реально что то ну никак не вытанцовывалось.
Львиная же доля кода была написана как раз соло.
Здравствуйте, Pzz, Вы писали:
Pzz>По-моему, оно полезно, когда расходы на оборудование сравнимы или превышают расходы на персонал.
Там же дело не в оборудовании — а в поддержке кода, легкости смены исполнителя. А так же взаимном контроле — чтобы не захотелось ютюб смотреть вместо работы.
Ну и бывает что когда обсуждаешь — то решение приходит быстрее.
vsb> Поэтому в целом к такой практике отношусь положительно и считаю, что она реально увеличивает производительность и качество кода непропорционально, но вот такой вот логистический нюансик всё портит.
Обязательное взаимное ревью кода в принципе реализует плюсы парного программирования без его минусов.
Здравствуйте, peiv, Вы писали:
vsb>> Поэтому в целом к такой практике отношусь положительно и считаю, что она реально увеличивает производительность и качество кода непропорционально, но вот такой вот логистический нюансик всё портит.
P>Обязательное взаимное ревью кода в принципе реализует плюсы парного программирования без его минусов.
На ревью тратят раз в 10 меньше времени, чем на написание кода. Оно никак не может быть выполнено с тем же качеством.
Здравствуйте, Pzz, Вы писали:
Pzz>С учетом того, что оборудование покупается один раз и надолго, а персоналу надо платить постоянно, плюс аредновать помещение, где сидит персонал, зарплаты должны быть какие-то совсем крошечные, чтобы этот подход имел смысл.
А мне кажется, парное программирование имеет право на жизнь. Проще переключаться с задачи на задачу в таком мини-колективчике, котиков некогда лайкать, плюс есть такая проблема — часто идёшь по своей обычной канве и не рассматриваешь другие подходы, а вторая пара глаз сразу заметит, что ты что-то делаешь не очень, плюс хороший обмен опытом, плюс люди лучше ориентируются в проекте в итоге — либо сами писали, либо рядом сидели помогали, в общем, имхо, плюсы есть.
Вполне возможно, что выхлоп будет и побольше, чем от двух отдельных программистов
Я бы попробовал, часа по три в два подхода с перерывом на обед, и по домам. Ну и почаще пары менять. Или три часа в день — парное, три-четыре часа — соло. Буду начальником, попробую )))
Здравствуйте, vsb, Вы писали:
vsb>Мне кажется, это главная проблема. Я как-то пробовал, в целом плюсов много, работа реально идёт раз в 5 быстрей обычного, но ценой того, что по 5-6 часов в день программируешь. Для меня это сложно, я привык 2-3 часа, больше — уже невосполнимо устаю. При этом менеджеру же не объяснишь этого, он вообще считает, что программировать надо с 10 до 19, дай волю — так и на туалет бы повешал датчик времени. Поэтому в целом к такой практике отношусь положительно и считаю, что она реально увеличивает производительность и качество кода непропорционально, но вот такой вот логистический нюансик всё портит.
Ну, вот я бы на самом деле попробовал, при сокращении рабочего дня полностью до 5-6 часов
Здравствуйте, peiv, Вы писали:
vsb>> Поэтому в целом к такой практике отношусь положительно и считаю, что она реально увеличивает производительность и качество кода непропорционально, но вот такой вот логистический нюансик всё портит.
P>Обязательное взаимное ревью кода в принципе реализует плюсы парного программирования без его минусов.
Ну, раз забивать нельзя, будут делать вид, что делали ревью
Здравствуйте, vsb, Вы писали:
P>>Обязательное взаимное ревью кода в принципе реализует плюсы парного программирования без его минусов.
vsb>На ревью тратят раз в 10 меньше времени, чем на написание кода. Оно никак не может быть выполнено с тем же качеством.
И как часто это ревью проводить? Если раз в день — то можно весь день писать, да, оно работает, но решение не самое лучшее — можно было и проще написать, и быстрее, и производительнее. Но в целом — работает, день потрачен, и переписывать уже никто не будет. Ну, или будет, тогда день коту под хвост. А если раз в неделю или несколько дней ревьюить?
В общем, ерунду коллега написал. Ну, может и не совсем ерунду, но ревью довольно далеко от парного написания кода.
Я, кстати, когда -то баловался на спектруме асмом, а компа не было. Я зависал у приятеля раз-другой в неделю на полдня-день, и мы там и мой кода набивали, и его, и отлаживали вместе, и новое писали. В общем, на самом деле, не так и плохо.
Меня последнее время в программировании скукота напрягает. А парное программирование неплохо развлекает, после него есть просто ощущение, что прикольно и интересно провёл время.
Здравствуйте, Marty, Вы писали:
M>И как часто это ревью проводить? Если раз в день — то можно весь день писать, да, оно работает, но решение не самое лучшее — можно было и проще написать, и быстрее, и производительнее. Но в целом — работает, день потрачен, и переписывать уже никто не будет. Ну, или будет, тогда день коту под хвост.
Поэтому я и считаю, что лучше чаще бегать друг к другу во время написания, чем собачиться после.
Здравствуйте, Alekzander, Вы писали:
A>Собери команду из нескольких реально самомотивированных друзей на интересный проект. Без начальства, без волокиты, без церберов, без всего ненужного. То есть, с максимальной эффективностью. Кстати, в качестве пруфа: именно так и устроена компания, где прибыль на рыло составляет мировой рекорд.
Я б с радостью. Непонятно, из чего им зарплату платить...
Здравствуйте, Pzz, Вы писали:
A>>Собери команду из нескольких реально самомотивированных друзей на интересный проект. Без начальства, без волокиты, без церберов, без всего ненужного. То есть, с максимальной эффективностью. Кстати, в качестве пруфа: именно так и устроена компания, где прибыль на рыло составляет мировой рекорд.
Pzz>Я б с радостью. Непонятно, из чего им зарплату платить...
Это же мысленный эксперимент. И платить можно тоже мысленно.
Или просто убеди, что дело выгорит. Если бы меня пригласил совместно поработать кто-то, кто до этого успешно поставил на рельсы пару-тройку стартапов, я бы не спрашивал про какую-то там зарплату.
Здравствуйте, vsb, Вы писали:
vsb>Мне кажется, это главная проблема. Я как-то пробовал, в целом плюсов много, работа реально идёт раз в 5 быстрей обычного, но ценой того, что по 5-6 часов в день программируешь. Для меня это сложно, я привык 2-3 часа, больше — уже невосполнимо устаю.
Ну да, работнику это менее выгодно, видимо. Странно почему не используют работодатели — ведь такой хороший подход для них.
И наконец мы дошли до моббинг программирования или по-русски программирование толпой. Фактически это тоже самое, что и парное программирование, только людей может быть больше двух.
О парном программировании я бы хотел сказать то, что тот человек, который в данный момент времени ничего не набирает, не обязан быть ни экспертом, ни что-либо знать. По сути он может просто сидеть и молча пялиться в экран и этого будет достаточно для эффекта присутствия.
То есть вся эта теория, что один водитель, а другой штурман в парном программировании это не более, чем иллюзия, особенно если говорить о программировании толпой. В толпе может сидеть второй программист, и третий программист.
А может быть специалист в предметной области не умеющий программировать. Или руководитель проекта, директор компании, представитель другой компании, просто случайный человек.
Знания людей в этом случае могут взаимодополнять друг друга. Понятно, что сумма всех знаний всё равно должна равняться полноценному специалисту. А альтернатива этому совещания, согласования, слияние кода, встреча с техническими специалистами, документирование и так далее и тому подобное.
Плюс компании могут потребоваться взаимозаменяемые люди, а не уникальный специалист, который уволится от вас через пол года и тогда вашему проекту да.
Здравствуйте, SkyDance, Вы писали:
M>>а вторая пара глаз сразу заметит, что ты что-то делаешь не очень, плюс хороший обмен опытом
SD>Это при условии, что обе пар глаз имеют что-то между ушей. Сравнимого уровня. Потому что иначе получается совсем не парное программирование ни разу.
Здравствуйте, Pzz, Вы писали:
Pzz>Вторую пару глазьев можно и позвать по мере надобности. Совершенно не обязательно, чтобы она всю дорогу сидела рядом и пыхтела.
Какое ж это тогда пАрное?
Здравствуйте, Marty, Вы писали:
M>Меня последнее время в программировании скукота напрягает.
Мне скучно бывает только делать обязаловку в офисе.
А когда дома что нить для себя фигачишь то и поссать отойти надо себя заставлять и "а чойта за окном за зарево такое? А, это рассвет!" тоже случается.
Здравствуйте, CreatorCray, Вы писали:
M>>Меня последнее время в программировании скукота напрягает. CC>Мне скучно бывает только делать обязаловку в офисе. CC>А когда дома что нить для себя фигачишь то и поссать отойти надо себя заставлять и "а чойта за окном за зарево такое? А, это рассвет!" тоже случается.
Да, для себя не скучно. Но на это мало времени, всё больше обязаловка за деньги
Здравствуйте, CreatorCray, Вы писали:
A>>Если бы меня пригласил совместно поработать кто-то, кто до этого успешно поставил на рельсы пару-тройку стартапов, я бы не спрашивал про какую-то там зарплату. CC>Ну я работал в таком стартапе CC>Вместе сидели только когда реально что то ну никак не вытанцовывалось. CC>Львиная же доля кода была написана как раз соло.
Я же об этом и говорю.
Все проекты разные. Все люди разные. Все ситуации разные. Вы для своего сочетания нашли подходящую долю времени. Она оказалось вот такой. Ну и хорошо. У меня она была другой, да ещё и плавала. В начале проекта мы почти 100% времени поводили друг у друга. Потом почти 100% соло раш. Может, научились к тому времени коммуницировать. А может просто язык устал от трепотни.
Короче, если ты нанимаешь правильных собак, тебе не надо учить их лаять. А если нет — можешь их обвесить колокольчиками, нарядить в костюмчики, поставить парные будки, заставить всегда писать юнит-тесты до любого кода (что там ещё в XP было?)... кроме рычания и dogshit'а ничего не добьёшься.
Здравствуйте, Marty, Вы писали:
M>Вполне возможно, что выхлоп будет и побольше, чем от двух отдельных программистов
На личном опыте — качественное програмирование физических задач (моделирование, решение уравнений и т.п.) в одиночку невозможно.
В других науках думаю так же.
