Коллективный разум: How to
Я нашел в MS дядьку, с которого дико тащусь.
Его зовут Дэвид Блайс (David Blythe), и он архитект в Windows в области графики. Дядька раньше дизайнил OGL в SGI, писал по нему книжку, а сейчас вот архитектит в том числе D3D. Дядька совершенно монструозный и замечательный. Я с ним говорил минут 20 и просветлился больше, чем за два предыдущих месяца. Читал его гуидлайны про API design и опять же радовался.
Отрывок на сегодня:
"DESIGN BY COMMITTEE. Avoid design by committee. There should be a single person with final say in the design .... and this person should have good architectural experience and instincts."
Я еще не умею писать так лаконично, поэтому придется в многабукф.
Вот мне очень нравится Design Review и я всем его советую. Это когда перед тем как кодать что-то, надо об этом рассказать команде или еще кому, у кого есть время и понимание происходящего. Тебе обязательно наговорят кучу фидбека, вспомнят 10 тонких мест, о которых ты не подумал и предложат альтернатив. И часто окажется, что первая идея дизайна не идеальна, а может и вторая. Или неплоха, но нужно додумывать.
Если их фичи на тебя завязаны, то еще и посмотрят и прикинут как вы будете интегрироваться. Так как Design Review взаимный, то и ты будешь знать о той стороне. Кроме того, и знания людей о проекте расширяются и начинают больше пересекаться, и код твой понимать проще, и Code Review становится гораздо более осмысленным занятием.
Хорошо бы после этого обсуждения еще и записать основные принятые решения и почему. Конечно, с какой вам лично хочется детальностью, от детального Design Spec до коротенькой странички "overview and key decisions".
Точно так же, количество формальности в этом всем может быть совершенно разного порядка. От регулярных митингов до "Мужики, давайте заобсудим мою новую херовину".
Все это крайне полезно и обязательно нужно делать. Коллективный разум заруливает и побеждает.
И у этого всего только один catch - коллективное обсуждение не должно означать коллективных решений. Коллективный разум очень хорошо думает, но очень плохо принимает решения. Всегда должен быть один человек, который имеет право выбрать из предложенных альтернатив и их за и против. Понимая всю картину, осознавая все возможности, сказать "а вот с этим мы будем жить", "мы выбираем вот такой трейдофф", в конце концов, сказать "а вот на это мы положим хер".
Иначе - превратится в коллективную безответственность и бесконечные споры. Я это прямо видел своими глазами, и не я один.
Design Review - это очень хорошая и правильная вещь. Принцип Avoid Design by Committee ее дополняет, а никак не перечеркивает. Отзывы нужно слушать, понимать, и если возникает альтернатива лучше твоей первой идеи, не бояться брать эту альтернативу. То есть - коллективный разум таки действительно рулит. Решение, которое ты примешь не рассказав и не посоветовавшись - будет хуже. Но тем не менее, принимать решение - только тебе самому.
А у Дэвида это все - одной строчкой. Эх...
Crossposted to blog.gamedeff.com
Его зовут Дэвид Блайс (David Blythe), и он архитект в Windows в области графики. Дядька раньше дизайнил OGL в SGI, писал по нему книжку, а сейчас вот архитектит в том числе D3D. Дядька совершенно монструозный и замечательный. Я с ним говорил минут 20 и просветлился больше, чем за два предыдущих месяца. Читал его гуидлайны про API design и опять же радовался.
Отрывок на сегодня:
"DESIGN BY COMMITTEE. Avoid design by committee. There should be a single person with final say in the design .... and this person should have good architectural experience and instincts."
Я еще не умею писать так лаконично, поэтому придется в многабукф.
Вот мне очень нравится Design Review и я всем его советую. Это когда перед тем как кодать что-то, надо об этом рассказать команде или еще кому, у кого есть время и понимание происходящего. Тебе обязательно наговорят кучу фидбека, вспомнят 10 тонких мест, о которых ты не подумал и предложат альтернатив. И часто окажется, что первая идея дизайна не идеальна, а может и вторая. Или неплоха, но нужно додумывать.
Если их фичи на тебя завязаны, то еще и посмотрят и прикинут как вы будете интегрироваться. Так как Design Review взаимный, то и ты будешь знать о той стороне. Кроме того, и знания людей о проекте расширяются и начинают больше пересекаться, и код твой понимать проще, и Code Review становится гораздо более осмысленным занятием.
Хорошо бы после этого обсуждения еще и записать основные принятые решения и почему. Конечно, с какой вам лично хочется детальностью, от детального Design Spec до коротенькой странички "overview and key decisions".
Точно так же, количество формальности в этом всем может быть совершенно разного порядка. От регулярных митингов до "Мужики, давайте заобсудим мою новую херовину".
Все это крайне полезно и обязательно нужно делать. Коллективный разум заруливает и побеждает.
И у этого всего только один catch - коллективное обсуждение не должно означать коллективных решений. Коллективный разум очень хорошо думает, но очень плохо принимает решения. Всегда должен быть один человек, который имеет право выбрать из предложенных альтернатив и их за и против. Понимая всю картину, осознавая все возможности, сказать "а вот с этим мы будем жить", "мы выбираем вот такой трейдофф", в конце концов, сказать "а вот на это мы положим хер".
Иначе - превратится в коллективную безответственность и бесконечные споры. Я это прямо видел своими глазами, и не я один.
Design Review - это очень хорошая и правильная вещь. Принцип Avoid Design by Committee ее дополняет, а никак не перечеркивает. Отзывы нужно слушать, понимать, и если возникает альтернатива лучше твоей первой идеи, не бояться брать эту альтернативу. То есть - коллективный разум таки действительно рулит. Решение, которое ты примешь не рассказав и не посоветовавшись - будет хуже. Но тем не менее, принимать решение - только тебе самому.
А у Дэвида это все - одной строчкой. Эх...
Crossposted to blog.gamedeff.com