FDS>Вопрос по неотстойному написанию: допустим мне нужно написать код перемножения двух матриц.
Вообще всегда критерием является практика. Если задача разовая и сделать надо быстро — можно и забить.
Но если этот исходник будет потом меняться — тут начинаются траблы, и чтобы написать правильно
— могут понадобиться еще одни мозги на 100% загрузки, что в широком обиходе называется "парное программирование". Чтобы двое полноценных можгов воспринимали задачу во всей ее полноте и стремились получить максимальную пользу (business value).
FDS>Я могу его написать 4 функциями, соответствующими AijBjk; AjiBjk; AijBkj; AjiBkj; FDS>Но это будет дублирование кода, причём почти copy-paste — то есть код — отстой
На чем пишем? Обобщенное программирование, вполне возможно, спасет отца русской демократии
FDS>Я могу написать его 1 функцией, с такими параметрами MatrixMul(A, B, TransposeA, TransposeB), заставив передавать в функцию параметры транспонирования матрицы — но это не удобно для использования
FDS>Можно вообще написать только внутреннее произведение и транспонировать матрицу — это не эффективно.
Первейший вопрос от меня как работающего с тобой в паре — имеет ли значение эффективность на текущем этапе работы над задачей, учитывая ВСЁ? очень много проблеми возникает, когда начинаешь заниматься эффективностью раньше, чем она того заслуживает.
Можно переформулировать вопрос — мы учимся писать эффективный код, используя эффективные численные методы, или мы решаем бизнес задачу?
Инами словами — что мы экономим — такты процессора или человеко-часы?
Вспомним IBM с его принципом "Машина должна работать, человек — думать".
FDS>А теперь представим себе, что это не просто матрица, а часть другой матрицы (это не надуманная задача). Тогда к каждой функции ещё надо будет прибавлять по два параметра — FDS>начальные и конечные индексы суммирования.
Первое, что приходит в голову — Граничный объект. Рефакторинг "Введение граничного объекта (объекта параметров)"
FDS>Этот код будет не читаемым и трудно написуемым — убедился на собственном опыте. И как это сделать не отстойно?
точно вторые мозги. хотя бы на 50% загрузки, если мало человек и часов...
FDS>В итоге я прихожу к самому удобному (я не шучу, я так и делал) варианту — когда нужно что-то перемножать я просто пишу код этого перемножения (цикл с двукратной вложенностью) прямо в код, без всяких вызовов. Получается, что с небольшими комментариями этот код — самый удобный для написания и чтения (ну, лично для меня) и вызывает наименьшее число ошибок в использовании (собственно, ошибки в использовании функции перемножения перестали появляться вообще).
FDS>Дык, во всех вариантах код — отстой. Во всех, я сам убедился (судя по этой статье). Может кто знает другой вариант?
Бороться и искать. Найти и рассказать всем (выложить в блог, если не лень ).
FR>>Может на западе у них нормально человека поучать через оскорбление, но мы похоже для таких высот демократии еще не дозрели.
FDS>Да, у нас за такие способы и по морде можно получить. И вообще, это не хорошо — получается автор статьи сразу ставит себя очень высоко — никто этого не любит, поэтому можно ждать очень много неконструктивной критики (в частности).
Не ставит. Читай преамбулу:
ВСА>Аннотация:
ВСА>Если Вы программируете как большинство, и даже, вероятно, все программисты (скромненько включая автора этой статьи), то ваш код — отстой. Возможно, не целиком; возможно, не всегда, но наверняка какая-то его часть и в какой-то момент времени.
FR>>>Нормальная реакция нормального человека на такое обращение "а не пошел бы ты на*** со своим поучениями"
M>>Смотрите линку на цитату из детской книги в моём посте
этого же треда
FR>совершенно другая тема, там про "заставить для его же блага", а тут "научить оскорбляя".
Вашими же словами и отвечу.
Статья ничему не учит, а "заставить..." читателя "...для его же блага" оторвать свою ... от уютного лона привычных представлений, ошибок и граблей, и начать искать пути эффективной борьбы с отстоем.
SS>>Согласен, мой код — отстой, согласно определениям статьи. И что дальше?
ANS>Дочитать статью до конца? Ответ в разделе "Итог".
Читал. Похоже на то, как если бы мне сосед сказал: "Знаешь, у тебя проблема с женой".
Не его это дело, какой у меня код, потому что у него нет проблем с моим кодом.
А то, что мой код — отстой, согласно определениям статьи, я не считаю своей проблемой.
IMHO. смайлики добавить по вкусу.
Re[3]: Тривиальная задача - как неотстойно написать?
Здравствуйте, moudrick, Вы писали:
FDS>>Вопрос по неотстойному написанию: допустим мне нужно написать код перемножения двух матриц.
M>Вообще всегда критерием является практика. Если задача разовая и сделать надо быстро — можно и забить. M>Но если этот исходник будет потом меняться — тут начинаются траблы, и чтобы написать правильно M>- могут понадобиться еще одни мозги на 100% загрузки, что в широком обиходе называется "парное программирование". Чтобы двое полноценных можгов воспринимали задачу во всей ее полноте и стремились получить максимальную пользу (business value).
К чему это?
FDS>>Я могу его написать 4 функциями, соответствующими AijBjk; AjiBjk; AijBkj; AjiBkj; FDS>>Но это будет дублирование кода, причём почти copy-paste — то есть код — отстой M>На чем пишем? Обобщенное программирование, вполне возможно, спасет отца русской демократии
Это "обобщённое программирование" и есть. Мне приходилось это реализовывать на Delphi, C++ и C#.
FDS>>Я могу написать его 1 функцией, с такими параметрами MatrixMul(A, B, TransposeA, TransposeB), заставив передавать в функцию параметры транспонирования матрицы — но это не удобно для использования
FDS>>Можно вообще написать только внутреннее произведение и транспонировать матрицу — это не эффективно. M>Первейший вопрос от меня как работающего с тобой в паре — имеет ли значение эффективность на текущем этапе работы над задачей, учитывая ВСЁ? очень много проблеми возникает, когда начинаешь заниматься эффективностью раньше, чем она того заслуживает.
M>Можно переформулировать вопрос — мы учимся писать эффективный код, используя эффективные численные методы, или мы решаем бизнес задачу? M>Инами словами — что мы экономим — такты процессора или человеко-часы? M>Вспомним IBM с его принципом "Машина должна работать, человек — думать".
Мы экономим человеко-часы сотрудника, который будет ждать, пока задача посчитается, то есть решаем реальную бизнес-задачу.
FDS>>А теперь представим себе, что это не просто матрица, а часть другой матрицы (это не надуманная задача). Тогда к каждой функции ещё надо будет прибавлять по два параметра — FDS>>начальные и конечные индексы суммирования. M>Первое, что приходит в голову — Граничный объект. Рефакторинг "Введение граничного объекта (объекта параметров)"
Честно говоря, не понимаю, как это сделать так, что бы написать неотстойны код. Поясните, пожалуйста, на примере (в смысле — код на естетсвенном языке)
FDS>>Этот код будет не читаемым и трудно написуемым — убедился на собственном опыте. И как это сделать не отстойно? M>точно вторые мозги. хотя бы на 50% загрузки, если мало человек и часов...
Зачем лишние мозги? если код трудночитаемый — он отстой, и лишние мозги тут не причём. Вы неправильно понимаете концепцию парного программирования — второй человек, фактически контроллёр и только потом — помошник
FDS>>В итоге я прихожу к самому удобному (я не шучу, я так и делал) варианту — когда нужно что-то перемножать я просто пишу код этого перемножения (цикл с двукратной вложенностью) прямо в код, без всяких вызовов. Получается, что с небольшими комментариями этот код — самый удобный для написания и чтения (ну, лично для меня) и вызывает наименьшее число ошибок в использовании (собственно, ошибки в использовании функции перемножения перестали появляться вообще).
FDS>>Дык, во всех вариантах код — отстой. Во всех, я сам убедился (судя по этой статье). Может кто знает другой вариант? M>Бороться и искать. Найти и рассказать всем (выложить в блог, если не лень ).
Вы хотели сказать — бороться и писать
Блога нет Я уже несколько лет разными способами пишу эту задачу и каждый раз не удовлетворён тем, что получилось.
Здравствуйте, moudrick, Вы писали:
FR>>>Может на западе у них нормально человека поучать через оскорбление, но мы похоже для таких высот демократии еще не дозрели.
FDS>>Да, у нас за такие способы и по морде можно получить. И вообще, это не хорошо — получается автор статьи сразу ставит себя очень высоко — никто этого не любит, поэтому можно ждать очень много неконструктивной критики (в частности).
M>Не ставит. Читай преамбулу:
M>
ВСА>>Аннотация:
ВСА>>Если Вы программируете как большинство, и даже, вероятно, все программисты (скромненько включая автора этой статьи), то ваш код — отстой. Возможно, не целиком; возможно, не всегда, но наверняка какая-то его часть и в какой-то момент времени.
Если этот человек бросился учить кого-то, значит он ставит себя выше других. По крайней мере, если он это делает такими методами. И преамбулы тут не помогут.
Здравствуйте, S-SH, Вы писали:
SS>>>Согласен, мой код — отстой, согласно определениям статьи. И что дальше?
ANS>>Дочитать статью до конца? Ответ в разделе "Итог".
SS>Читал. Похоже на то, как если бы мне сосед сказал: "Знаешь, у тебя проблема с женой". SS>Не его это дело, какой у меня код, потому что у него нет проблем с моим кодом. SS>А то, что мой код — отстой, согласно определениям статьи, я не считаю своей проблемой.
Да, это не его проблема. Это проблема того, кто Ваш код будет сопровождать/дорабатывать/изменять. Возможно, им окажетесь со временем Вы.
Если вы на 101,74% уверены, что Ваш код никогда не будет подвергаться сопровождению/доработке/изменению, то тогда статья и её контент не касаются этого кода.
Здравствуйте, moudrick, Вы писали:
M>Перепрошую. В реальной жизни начиная с некоторого момента требования к ПО изменяются быстрее, чем пишется его код. Потому имхо будущее большинства успешных продуктов — перманентный рефакторинг, ибо единственный приемлемый способ учитывать изменяющиеся требования к продукту. Каждый раз все с самого начала не напишешь.
У нас с вами разные реальности, похоже В нашей реальности, например, есть зафиксированный спискок фич, которые должны войти в текущую версию. Если в процессе разработки резко возникает необходимость в неизвестной ранее фиче, это всего лишь означает, что ПМ ее проворонил на стадии формирования списка фич. Далее, эта фича либо откладывается на следующую версию (если получится), либо поступает в разработку со сдвигом сроков сдачи. В любом случае, это проблема менеджемента — не разработчиков. Но я прекрасно понимаю, что в реальности довольно часто сдвига сроков не бывает, и что разгребать все это приходится разработчикам. То есть, хорошим разработчикам однозначно стоит быть к этому готовыми, да и получается частенько само (с TDD, рефакторингами и пр.). Но это совершенно не означает, что ПМ должен перманентно подкидывать такие задачки.
M>Т.е. рефакторить придется не потому что плохо рабоатет, а потому что надо быстро сделать так, чтобы учесть изменившиеся требования.
В хорошо спроектированном приложении эти изменения вносятся либо добавлением нового кода, либо незначительной модификацией существующего. А архитектуру на ходу рефакторить... Мы сейчас именно этим и занимаемся. Тот еще экстрим, уж поверьте. Да и не рефакторинг это уже, а тренировка саперов на настоящем минном поле.
If a shark stops swimming, it will die. Don't stop swimming, Mr. Mulder.
Every epic equalizer is iso (c)
ANS>Это так, но твоей проблемой будет чей-то код, с которым тебе прийдётся поработать и который отстойный по определениям этой статьи.
Интересно, являлся ли отстойным по определениям этой статьи код Chrysler Comprehensive Compensation, когда ее выкинули на помойку?
Предполагаю, что нет.
Хотя вопрос можно считать риторическим.
Здравствуйте, moudrick, Вы писали:
M>В варианте для нашего личного использования у нас был прямой глагольный перевод, который звучал так — "Почуму ваш код сосёт". Или даже — "Почему твой код сосёт". Но такая грубость, конечно, неприемлема на " the best russian-languaged resource for developers", как я описал RSDN в письме с запросом к автору на публикацию перевода.
А что такое "прямой глагольный перевод"? Может все же стоило поискать информацию об этимологии идиомы suck?
В тех же Проблемах перевода, по-моему уже обсуждали.
Re[4]: Тривиальная задача - как неотстойно написать?
M>>Вообще всегда критерием является практика. Если задача разовая и сделать надо быстро — можно и забить. M>>Но если этот исходник будет потом меняться — тут начинаются траблы, и чтобы написать правильно M>>- могут понадобиться еще одни мозги на 100% загрузки, что в широком обиходе называется "парное программирование". Чтобы двое полноценных можгов воспринимали задачу во всей ее полноте и стремились получить максимальную пользу (business value).
FDS>К чему это?
Что именно?
FDS>>>А теперь представим себе, что это не просто матрица, а часть другой матрицы (это не надуманная задача). Тогда к каждой функции ещё надо будет прибавлять по два параметра — FDS>>>начальные и конечные индексы суммирования. M>>Первое, что приходит в голову — Граничный объект. Рефакторинг "Введение граничного объекта (объекта параметров)" FDS>Честно говоря, не понимаю, как это сделать так, что бы написать неотстойны код. Поясните, пожалуйста, на примере (в смысле — код на естетсвенном языке)
К сожалению, не получилось найти готового примера. Но хорошие примеры точно есть в книге «Рефакторинг» Мартина Фаулера
(Fowler's "Refactoring"). Если где-то поблизости от Вас имеется экземпляр, рекомендую обратиться именно к нему.
FDS>>>Этот код будет не читаемым и трудно написуемым — убедился на собственном опыте. И как это сделать не отстойно? M>>точно вторые мозги. хотя бы на 50% загрузки, если мало человек и часов...
FDS>Зачем лишние мозги? если код трудночитаемый — он отстой, и лишние мозги тут не причём. Вы неправильно понимаете концепцию парного программирования — второй человек, фактически контроллёр и только потом — помошник
Это где же такое написано и/или сказано?
Второй человек — активный участник, который может в нужный момент перехватить управление на себя и стать первым.
Или Вы считаете штурмана папссивным контролером?
В реальном парном программировании далеко не всегда получается так, что тот, кто за рулём, тот и тормозит...
FDS>>>В итоге я прихожу к самому удобному (я не шучу, я так и делал) варианту — когда нужно что-то перемножать я просто пишу код этого перемножения (цикл с двукратной вложенностью) прямо в код, без всяких вызовов. Получается, что с небольшими комментариями этот код — самый удобный для написания и чтения (ну, лично для меня) и вызывает наименьшее число ошибок в использовании (собственно, ошибки в использовании функции перемножения перестали появляться вообще).
FDS>>>Дык, во всех вариантах код — отстой. Во всех, я сам убедился (судя по этой статье). Может кто знает другой вариант? M>>Бороться и искать. Найти и рассказать всем (выложить в блог, если не лень ). FDS> Вы хотели сказать — бороться и писать
Именно искать. В процессе написания, естественно
M>>В варианте для нашего личного использования у нас был прямой глагольный перевод, который звучал так — "Почуму ваш код сосёт". Или даже — "Почему твой код сосёт". Но такая грубость, конечно, неприемлема на " the best russian-languaged resource for developers", как я описал RSDN в письме с запросом к автору на публикацию перевода.
B>А что такое "прямой глагольный перевод"?
Это мой экспромт-неологизм. Термин не является общепринятым даже среди меня, но надеюсь, он понятен и понят однозначно
>Может все же стоило поискать информацию об этимологии идиомы suck? B>В тех же Проблемах перевода, по-моему уже обсуждали.
FDS>Если этот человек бросился учить кого-то, значит он ставит себя выше других. По крайней мере, если он это делает такими методами. И преамбулы тут не помогут.
Не согласен. "Поучений" здесь меньше всего. Это лишь констатация факта. Вы это можете признать, а можете не признать. Это Ваш выбор. Выбирайте с умом.
Re[5]: Тривиальная задача - как неотстойно написать?
Здравствуйте, moudrick, Вы писали:
M>>>Вообще всегда критерием является практика. Если задача разовая и сделать надо быстро — можно и забить. M>>>Но если этот исходник будет потом меняться — тут начинаются траблы, и чтобы написать правильно M>>>- могут понадобиться еще одни мозги на 100% загрузки, что в широком обиходе называется "парное программирование". Чтобы двое полноценных можгов воспринимали задачу во всей ее полноте и стремились получить максимальную пользу (business value).
FDS>>К чему это? M>Что именно?
То, что выше Кстати, есть проекты в которых парное программирование не приемлемо технически (или экономически)
FDS>>>>А теперь представим себе, что это не просто матрица, а часть другой матрицы (это не надуманная задача). Тогда к каждой функции ещё надо будет прибавлять по два параметра — FDS>>>>начальные и конечные индексы суммирования. M>>>Первое, что приходит в голову — Граничный объект. Рефакторинг "Введение граничного объекта (объекта параметров)" FDS>>Честно говоря, не понимаю, как это сделать так, что бы написать неотстойны код. Поясните, пожалуйста, на примере (в смысле — код на естетсвенном языке)
M>К сожалению, не получилось найти готового примера. Но хорошие примеры точно есть в книге «Рефакторинг» Мартина Фаулера
(Fowler's "Refactoring"). Если где-то поблизости от Вас имеется экземпляр, рекомендую обратиться именно к нему.
Где-то поблизости нету. Я имею ввиду — представьте своё видение решения описанной мной задачи на естественном языке, оформелнном в виде кода. Я думаю, Фаулер об этой задаче и не заикался, к тому же я и сам могу привести примеры к этому правилу, только я не понимаю, как вы собираетесь его применять к моей задаче.
Есть группа параметров, естественным образом связанных друг с другом.
Замените их объектом.
Где тут группа параметров?
FDS>>>>Этот код будет не читаемым и трудно написуемым — убедился на собственном опыте. И как это сделать не отстойно? M>>>точно вторые мозги. хотя бы на 50% загрузки, если мало человек и часов...
FDS>>Зачем лишние мозги? если код трудночитаемый — он отстой, и лишние мозги тут не причём. Вы неправильно понимаете концепцию парного программирования — второй человек, фактически контроллёр и только потом — помошник M>Это где же такое написано и/или сказано? M>Второй человек — активный участник, который может в нужный момент перехватить управление на себя и стать первым. M>Или Вы считаете штурмана папссивным контролером? M>В реальном парном программировании далеко не всегда получается так, что тот, кто за рулём, тот и тормозит...
1. Я и не говорю, что второй программист не может стать в некоторый момент первым, а потом отдать кодирование назад, и так постоянно
2. Второй программист — не штурман. Второй программист не пассивный контролёр, а активный, Смысл правила заключается в том, что второй человек помогает оформить задумку первого и выявляет в ней ошибки и неточности. В любом случае, парное программирование существует для предотвращения ошибок, а не для того, что бы решать более трудные задачи
3. Да, тормозит обычно тот, кто за клавиатурой, и только по мнению тех, кто не за ней
Здравствуйте, moudrick, Вы писали:
FDS>>Если этот человек бросился учить кого-то, значит он ставит себя выше других. По крайней мере, если он это делает такими методами. И преамбулы тут не помогут.
M>Не согласен. "Поучений" здесь меньше всего. Это лишь констатация факта. Вы это можете признать, а можете не признать. Это Ваш выбор. Выбирайте с умом.
1. Я не употреблял слово "поучения" — у него другой смысловой оттенок.
2. Это статья пытается подействовать на читателя обучающе — то есть пытается научить его писать не отстойный код или, по крайней мере, научить его понимать, что код отстойный.
M>>Перепрошую. В реальной жизни начиная с некоторого момента требования к ПО изменяются быстрее, чем пишется его код. Потому имхо будущее большинства успешных продуктов — перманентный рефакторинг, ибо единственный приемлемый способ учитывать изменяющиеся требования к продукту. Каждый раз все с самого начала не напишешь. K>У нас с вами разные реальности, похоже В нашей реальности, например, есть зафиксированный спискок фич, которые должны войти в текущую версию.
Реальность у всех одинаковая. Восприятие разное. У некоторых ограничивается собственным рабочим столом. У некоторых своим рабочим кабинетом. А некоторые все-таки стремятся к большему.
K>Если в процессе разработки резко возникает необходимость в неизвестной ранее фиче, это всего лишь означает, что ПМ ее проворонил на стадии формирования списка фич.
Ага, давайте спишем все на ПМ.
Насколько часто формируется этот список фич?
K>Далее, эта фича либо откладывается на следующую версию (если получится), либо поступает в разработку со сдвигом сроков сдачи.
На сколько?
K>В любом случае, это проблема менеджемента — не разработчиков.
Ага, давайте опять все спишем на ПМ. У него голова (читай — зарплата) большая — пусть думает. А ты сам не боишься оказаться на его месте?
K>Но я прекрасно понимаю, что в реальности довольно часто сдвига сроков не бывает, и что разгребать все это приходится разработчикам. То есть, хорошим разработчикам однозначно стоит быть к этому готовыми, да и получается частенько само (с TDD, рефакторингами и пр.).
Ну вот вы же сами и показали, что мое восприятие ближе к реальности, чем Ваше.
K>Но это совершенно не означает, что ПМ должен перманентно подкидывать такие задачки.
Традиционная методика разработки ПО. Существует и дает иногда неплохие результаты. Имеет право на существование. Не является гибкой и потому неспособна решать "гибкие" задачи.
Кстати, в XP тоже есть некий порядок в планировании имплементации фич. Но в силу "Small Releases" ими можно гибче управлять, чаще добавлять/изменять без ущера качеству разрабатываемого продукта. Частота зависит от длительности итерации. Итерации обычно короткие — неделя или две. Подкидывать можно перманентно, где перманентно означает — в начале итерации.
M>>Т.е. рефакторить придется не потому что плохо рабоатет, а потому что надо быстро сделать так, чтобы учесть изменившиеся требования. K>В хорошо спроектированном приложении эти изменения вносятся либо добавлением нового кода, либо незначительной модификацией существующего.
А где гарантия, что эти изменения/добавления ничего существующего не сломали?
Это бывает даже при хорошем проектировании. Вспомните законы Мерфи, это обязательно случится.
Что делать? После cosmetic improvements отдавать всё армии тестеров, чтобы еще раз все прогнали по графу use-case-ов?
Поверьте, в agile-технологиях не брезгуют хорошим проектированием. Agile-методики не отрицают, а дополняют хорошее проектирование. А хорошее проектирование, кстати, включает в себя Unit-тестирование. Как правило — в виде неотъемлемой части.
K>А архитектуру на ходу рефакторить... Мы сейчас именно этим и занимаемся. Тот еще экстрим, уж поверьте. Да и не рефакторинг это уже, а тренировка саперов на настоящем минном поле.
Самое время рассмотреть возможность применения методик XP. Я серьёзно.
Re[6]: Тривиальная задача - как неотстойно написать?
M>>>>Вообще всегда критерием является практика. Если задача разовая и сделать надо быстро — можно и забить. M>>>>Но если этот исходник будет потом меняться — тут начинаются траблы, и чтобы написать правильно M>>>>- могут понадобиться еще одни мозги на 100% загрузки, что в широком обиходе называется "парное программирование". Чтобы двое полноценных можгов воспринимали задачу во всей ее полноте и стремились получить максимальную пользу (business value). FDS>>>К чему это? M>>Что именно? FDS>То, что выше Кстати, есть проекты в которых парное программирование не приемлемо технически (или экономически)
Там много всего краями упмянуто. Если речь только о парном программировании и его невозможности — что ж. Придется работать одному. За двоих. Как — Вам решать самому.
FDS>>>>>Этот код будет не читаемым и трудно написуемым — убедился на собственном опыте. И как это сделать не отстойно? M>>>>точно вторые мозги. хотя бы на 50% загрузки, если мало человек и часов... FDS>>>Зачем лишние мозги? если код трудночитаемый — он отстой, и лишние мозги тут не причём. Вы неправильно понимаете концепцию парного программирования — второй человек, фактически контроллёр и только потом — помошник M>>Это где же такое написано и/или сказано? M>>Второй человек — активный участник, который может в нужный момент перехватить управление на себя и стать первым. M>>Или Вы считаете штурмана папссивным контролером? M>>В реальном парном программировании далеко не всегда получается так, что тот, кто за рулём, тот и тормозит... FDS>1. Я и не говорю, что второй программист не может стать в некоторый момент первым, а потом отдать кодирование назад, и так постоянно FDS>2. Второй программист — не штурман. Второй программист не пассивный контролёр, а активный, Смысл правила заключается в том, что второй человек помогает оформить задумку первого и выявляет в ней ошибки и неточности. В любом случае, парное программирование существует для предотвращения ошибок, а не для того, что бы решать более трудные задачи
Для того, чтобы подать идею юнит-теста к тому, что пишет рулевой — что именно и как именно следует затестить.
Простая задача? Тогда скажите, как надо юнит-тестить код к Вашей задаче?
Какие еще более трудые задачи Вы имели в виду?
Кроме того, есть такое понятие code review, Если практикуется парное программирование, практика code review становится перманентной, не мешая при этом всем тем задачам, которые отметили Вы в качестве задач, решаемых парным программированием.
FDS>3. Да, тормозит обычно тот, кто за клавиатурой, и только по мнению тех, кто не за ней Каждый мнит себя стратегом, видя бой со стороны (с) знаменитый поэт.
).
Вы хотели сказать — бороться и писать
Самое время рассмотреть возможность применения методик XP. Я серьёзно. 
