Мне в основном очень нравятся архитекторы в Microsoft. Некоторые более, чем другие, а некоторые — совершенно замечательные.
Одного из совершенно замечательных зовут Дэвид Блайс (David Blythe), и он архитект в Windows в области графики. Дядька раньше дизайнил OpenGL в SGI, писал по нему книжку, а сейчас вот работает в том числе над Direct3D. Дядька совершенно монструозный и замечательный. Я с ним говорил минут 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 ее дополняет, а никак не перечеркивает. Отзывы нужно слушать, понимать, и если возникает альтернатива лучше твоей первой идеи, не бояться брать эту альтернативу. То есть — коллективный разум таки действительно рулит. Решение, которое ты примешь не рассказав и не посоветовавшись — будет хуже. Но тем не менее, принимать решение — только тебе самому.
А у Дэвида это все — одной строчкой. Эх…
Одного из совершенно замечательных зовут Дэвид Блайс (David Blythe), и он архитект в Windows в области графики. Дядька раньше дизайнил OpenGL в SGI, писал по нему книжку, а сейчас вот работает в том числе над Direct3D. Дядька совершенно монструозный и замечательный. Я с ним говорил минут 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 ее дополняет, а никак не перечеркивает. Отзывы нужно слушать, понимать, и если возникает альтернатива лучше твоей первой идеи, не бояться брать эту альтернативу. То есть — коллективный разум таки действительно рулит. Решение, которое ты примешь не рассказав и не посоветовавшись — будет хуже. Но тем не менее, принимать решение — только тебе самому.
А у Дэвида это все — одной строчкой. Эх…
