Последние комментарии
Для меня эта страница - это удобный способ смотреть, что нового происходит в комментариях и сразу находить заметку, не заходя в админку. Думаю, она будет полезна и тебе.
Dmitry Romanenko
Наткнулся внезапно сегодня по теме
http://geektimes.ru/post/248156/
Missy
Подход исключительно для компаний где нереальная текучка кадров и важно сохранить абсолютную читаемость кода и понимание того что где. Ну и да только для компаний для которых в активное развитие вкладываться уже не нужно. Они и так успешные крупные супер компании которые могут хоть купаться в деньгах.
Но этот подход не разумен там где нужна эффективность работы. Где важно развивать компанию и иметь продуктивный с точки зрения затрат подход.
С точки зрения работодателя выбор таков:
Держать 5 программеров при обычном подходе и знать что за год они сделают 1 условный проект.
Или
Держать 30 программеров при описанном в статье подходе и знать что тот-же условный проект они сделают за 3 года.( и да на каждые 5 человек занятых "обычным" способом придется 30 занятых "парным программированием", вы ведь надеюсь не думали что этот способ заключается исключительно в посадке условно 2ух прогеров за один комп, это требует полной реорганизации работы и построения всех "рабочих структур" в компании)
Но каждая замена работника в первом случае будет означать +2 месяца ко времени разработки а во втором пройдет наземетно. Даже более того к концу 3го года во втором случае в разработке поучаствует более 100 человек за счет текучки кадров. Но время разработки какое было такое и останется и проект не пострадает.
jump
через год совместной работе в паре,просыпаешься такой утром на работу, а нас трое под одеялом я+жена+напарник,а возможно и не будет жены,просто пара....
Max
Работал в паре "крутых" компаний и там такой подход есть, ибо чистота кода для них первичный фактор. Плюсов на самом деле намного больше чем минусов. Так что это true/
Евгений
Все же не совсем понятно про одновременное написание кода? Пока один набирает код, а это по сути мысли программиста, другой смотрит что ли? Какое же в этом преимущество: работает один, а зарплату платить двоим? Вот если бы они одновременно вносили изменения в различные участи кода одного проекта, то дело другое. Получается, что в этом есть лишь небольшие преимущества организационного плана, которые здесь перечислены и на время разработки влияют лишь косвенно, в то же время это может оказаться и затратным: 2 зарплаты вместо одной, затраты на организацию рабочего места и оборудование для второго программиста. Уж если привлекать к одному проекту несколько сотрудников, то, к примеру, один бы занимался серверной частью, другой клиентской, третий отчетами и т.д. При этом работа велась бы одновременно, но изолировано, что ускорило бы общее время разработки, а все перечисленное тоже было бы, но может не в такой степени.
Dmitry Romanenko
Наверно дорого это будет выходить для работодателя платить за решение одной и той же задачи вдвое большему количеству программистов
CodeWarrior
Дичь
Михаил Фленов
Отличное уточнение, спасибо
eqr
Михаил,
чтобы в случае отсутствия Nickname возвращать LastName, достаточно сделать var smth = Nickname ?? LastName.
Смысл null-conditional operator в том, что обращение к LastName не бросит NullReference, если NickName нет (см. монада Maybe). Но в вашем примере вернется не "или LastName или NickName", а всегда LastName, просто иногда null.
(https://msdn.microsoft.com/en-us/magazine/dn802602.aspx)

dbat
Молодцы! Круто! Поддерживаю.