?

Log in

No account? Create an account
November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

Читай код

Posted on 2009.05.03 at 16:01

Comments:


Денис Бесков
beskov at 2009-05-03 16:47 (UTC) (Link)
т.е. всё-таки архитектурная документация скорее нужна, чем нет?

и надо делать так, чтобы «лекции по архитектуре» разработчики прослушивали в первый месяц работы компании, а не через полгода?
Gaperton
gaperton at 2009-05-03 16:59 (UTC) (Link)
т.е. всё-таки архитектурная документация скорее нужна, чем нет?

- Common Design Principles - скорее нужна, чем нет. Это краткое описание "правильных" способов делать в системе разные вещи. Скажем, пользоваться вот такими смартпойнтерами, и для посылки сообщений - вот такими классами.

Однако, создание хорошего документа требует гораздо больше усилий, чем проведение лекции, и совершенно непонятно, насколько это оправдано делать "впрок", "на всякий случай". Учитывая относительно небольшой темп прихода новых сотрудников, по сравнению с макдональдсами, и того, что эти принципы могут поменяться, и документы потеряют актуальность.

Короче, документы, которые имеет смысл писать - должны быть маленькими.

и надо делать так, чтобы «лекции по архитектуре» разработчики прослушивали в первый месяц работы компании, а не через полгода?

- При выдаче задания, чтобы пошло впрок и не выветрилось из головы. В моем случае раньше чем через полгода было невозможно - мне надо было поехать в Штаты для того, чтобы послушать лекцию.
Денис Бесков
beskov at 2009-05-03 17:30 (UTC) (Link)
Ну вот тут как раз непонятно:

Неужели затраты на перевод «лекций по архитектуре» в Software Architecture Document больше, чем потери компании от того, что ряд разработчиков не знает архитектуры системы до личного контакта с архитектором (и выбрасывает таким образом свои человекогоды на ветер)?

Неужели промышленная высокопроизводительная система из 50Мб кода, живущая уже 10 лет, например, не стоит создания (и актуализации раз в полгода) архитектурного дока на 100 страниц?
Gaperton
gaperton at 2009-05-03 18:06 (UTC) (Link)
> Неужели затраты на перевод «лекций по архитектуре» в Software Architecture Document больше, чем потери компании от того, что ряд разработчиков не знает архитектуры системы до личного контакта с архитектором (и выбрасывает таким образом свои человекогоды на ветер)?

Этот вопрос поднимался неоднократно. Эти лекции - не пережевывание всем известных вещей, которые можно составить по разным источникам не понимая толком материала. Материал уникален и непрост. Как это правильно объяснить - большая методологическая проблема, и делается индивидуально. Материала на самом деле много. Как на практике поддерживать это в актуальном состоянии - непонятно. Рассчет показывал, что это экономически совершенно неоправданно.

В 1999 году офис в Москве был только что открыт, и всех новонанятых людей потоком отправляли в Штаты на стажировку. Задержка с посылкой меня объяснялась перегрузом корпоративной квартиры в Штатах. Каждый проходил обучение в контакте с теми специалистами, с которыми потом будут работать. Это - эффективнее. К тому же, потом всегда найдется человек в Москве, у которого можно спросить.

> Неужели промышленная высокопроизводительная система из 50Мб кода, живущая уже 10 лет, например, не стоит создания (и актуализации раз в полгода) архитектурного дока на 100 страниц?

Уже почти двадцать лет. Ответ на вопрос стоит или не стоит - как минимум неочевиден. Человеку, работавшему с крупной системой продолжительное время, это вполне понятно. Эти "архитектурные" документы - они из альтернативной реальности, существующей в головах менеджеров, не из разработки. В лучшем случае ими почти никто не пользуется, и от них мало вреда.

А в нормальной реальности рулят базы данных, а не документы. Например, трекеры с тикетами, и комментарии к коммитам в VCS.

Хотя, описание Common Design Principles, для подобных систем, вероятно, держать имеет смысл. Приравняв их по статусу к coding standard, и трактуя нарушение как ошибку на desgn review.
Gaperton
gaperton at 2009-05-03 19:29 (UTC) (Link)
Вообще, интересно следующее. В ВУЗах повсеместно используется для передачи знаний модель лекций и семинаров. Уже веками используется. Далеко не всегда лектор пишет учебник по своему курсу. Система достаточно эффективна.

Вопрос - почему эта же система не может работать для передачи знаний об архитектуре, учитывая, что архитектура приложения - меняется гораздо динамичнее тенденций преподавания в матанализе, целевая аудитория - несравнимо меньше, и эффект от "учебников" объективно мизерный? Откуда такая почти религиозная страсть к документированию? Я не могу этого понять, честно.
Gaperton
gaperton at 2009-05-03 19:32 (UTC) (Link)
> Вопрос - почему эта же система не может работать для передачи знаний об архитектуре

А система, меж тем, замечательно работает на практике. Я бы сказал, она на практике качественно превосходит модель, опирающуюся на документацию. Исключение составляет заказная разработка, где архитектурная документация является необходимым требованием. В данном случае, это разовая работа, и потеря актуальности документации произойдет уже у заказчика.
Денис Бесков
beskov at 2009-05-04 04:47 (UTC) (Link)
Документация, в свою очередь — это древнейший способ асинхронной передачи знаний (механизм коммуникации) от человека к человеку во времени и пространстве, если они оба не могут находиться в одной точке.

Понятно, что синхронная передача лучше, но, как вы сами уже поняли, в промышленной среде организовать её не так то просто, т.к. надо вовремя выявлять запросы на передачу знаний, накапливать их, организовывать встречу и т.д.
Gaperton
gaperton at 2009-05-04 10:38 (UTC) (Link)
Документация, в свою очередь — это древнейший способ асинхронной передачи знаний (механизм коммуникации) от человека к человеку во времени и пространстве, если они оба не могут находиться в одной точке.

Спасибо, я в курсе. Я вам все сказал о том, какую конкретно документацию я считаю полезной. Вы же говорите о какой-то абстрактной "документации" вообще. То есть - ни о чем.

Понятно, что синхронная передача лучше, но, как вы сами уже поняли, в промышленной среде организовать её не так то просто, т.к. надо вовремя выявлять запросы на передачу знаний, накапливать их, организовывать встречу и т.д.

Надо же, надо вовремя выявить запросы на передачу знаний. :) Вот ведь проблема. :) Это ж не так просто дотумкать, что человек, назначенный на новую тему, требует введения в нее :). Не иначе, как специального корпоративного паразита по "управлению знаниями" нанимать придется :).

При наличии в компании минимальной культуры предварительного проектирования, а также design и code review весь этот балшыт испаряется как дым. Тем более, что знания при такой схеме распространяются достаточно быстро, и в курс дела на месте может ввести любой тимлид за несколько часов, либо направить "запрос" куда следует. Знаете, как пиринговые сети работают, вроде BitTorrent? Вот и знания на самом деле так же распространяются, если создать благоприятную среду для их распространения.
Денис Бесков
beskov at 2009-05-04 04:51 (UTC) (Link)
Я опять же не понимаю, если архитектура — это ключевые и высокостабильные принципы организации системы, то как же она у вас «постоянно меняется»?

Это же прямо в определении архитектуры стоит — «решения, которые нельзя легко изменить».
Anatoli Stoyanovski
skyer at 2009-05-04 06:29 (UTC) (Link)
Пример с ВУЗами - другая ниша. Просто потому, что там люди учатся преподавать. Преподаватель, обученный преподавать и просто человек, пришедший рассказать о своих знаниях на интуиции - небо и земля. У нас на MBA есть и такие и такие, и это хорошо видно.

Разработчики же в целом слабо знакомы с наукой передачи знаний. Здесь чуть лучше ситуация в американской моделе преподавания, когда студент активно занят в подготовке собственных докладов и тренируется в структурировании своей подачи информации. Я у себя для этого пытаюсь каждую неделю проводить семинары. Это встречает интерес, но энтузиазма готовить презентации - минимум, хотя ребята все хорошие.

Поэтому для многих проектов ключевой ответ - не умеют, вот и не готовят. В результате масса неплохих проектов умирает от прихода людей в него, которые не смогли в нем разобраться (разумеется, нет и не может быть статистики сколько из них могли бы не умереть, будь они хорошо описаны)
alll
alll at 2009-05-03 20:31 (UTC) (Link)
> создание хорошего документа требует гораздо больше усилий, чем проведение лекции

Странно, что никто не догадался поставить пару-тройку видеокамер на одной из лекций. Или это тоже затратно-неэффективно?
Gaperton
gaperton at 2009-05-03 20:35 (UTC) (Link)
Это, кстати, было бы реально круто. Не знаю, почему не догадались тогда.
Gaperton
gaperton at 2009-05-03 20:36 (UTC) (Link)
Только надо было ставить HD камеры, которых тогда, в 99 году, не было. Чтобы снимать маркерную доску в нормальном разрешении.
alll
alll at 2009-05-03 20:57 (UTC) (Link)
Несколько обычных камер, каждая снимает свою часть доски.

Ну и приложить к лекции слайды, если, конечно, лектор был достаточно ленив, чтобы не рисовать все диаграммы на маркерной доске каждую лекцию. :)
Gaperton
gaperton at 2009-05-03 20:39 (UTC) (Link)
Идея, вообще, отличная. На всякий случай запомню, может еще пригодится.
Previous Entry  Next Entry