metaclass | Программистское мракобесие

Как бы это сказать, одного то, чтобы не писать документации, недостаточно для того, чтобы сделать хороший продукт в течении 10 лет :). И написания документации для этого тоже недостаточно, ибо наличие документации (тем более - в актуальном состоянии) само по себе тут вообще не причем и существенного вклада в успех не дает. Зато способствует созданию и поддержанию иллюзии, что вы делаете все "правильно", у вас _якобы_ все под контролем, и у вас все получится, потому, что уровень CMMI зело большой :).

А вообще, всякого рода dоxygen-ы рулят, потому что генерятся из кода. И описания Common Design Principles в виде кратких документов - тоже рулят, хотя бы потому, что их соблюдение может быть проверено на design review, и они редко меняются.

Но больше всего рулит понятно написанный, хорошо структурированный, и по делу комментированный код, с содержательными комментариями к коммитам. Сюрприз, правда? :) Если этого нет, то можно удокументироваться до полусмерти, толку все равно будет ноль. А если есть - то документирование добавляет незначительное количество ценности.

Культ Карго, в общем, косит наши ряды. Меж тем, практика различных open source проектов, в том числе и крупных, скорее подтверждает вышесказанное, чем иллюстрирует декларации CMMI. Разработка ПО не является строго определенным процессом, наподобие линейки по приготовлению гамбургеров макдональдса, где точность соблюдения "технологии" и процесса гарантирует вам качество результата.

У нас зачастую бывает как раз наоборот. Сам IBM PC появился в результате того, что соответствующую группу в IBM освободили от необходимости следовать внутрикорпоративным процессам, "с целью ускорения разработки". Что уж тут говорить :).

"наподобие линейки по приготовлению гамбургеров макдональдса" - а чем разработка ПО принципиально отличается, если там тоже есть некоторые типовые работы? Да и отличать надо - инновационные разработки и "повседневные"...

Тем, что разработка - empiric process, а не defined process. В случае empiric process точность соблюдения технологии и процесса не гарантирует результата в принципе, потому, что какие бы "типовые" работы не были. Потому, что все они сопряжены с решением проблем, способ решения которых повлияет на структуру результата, и результат определяется не соблюдением технологии, а человеческим вкладом и личными качествами исполнителей.

Это, собственно, основы process theory. Еще примеры занятий, где встречается empiric process - разработка новых моделей автомобилей, и военное дело. Нет никакой технологии, точное соблюдение которой позволит выиграть войну, это достаточно очевидно. Хотя бы потому, что вклад боевого духа войск к прочим факторам оценивается многими специалистами как 3 к одному.

Точно также Вы можете посадить кучу идиотов под CMMI Level 5, и не получить на выход ничего ценного. Или получить продукт, вызывающий зевоту на рынке. В этом разница.

"разработка новых моделей автомобилей" - так ведь я же написал, что для инновационных проектов (задач) нужен немного свой подход
"военное дело" - т.е. уставы и руководства вообще не имеют право быть в военном деле? все можно выиграть только "силой духа"? :)
"Вы можете посадить кучу идиотов под CMMI Level 5, и не получить на выход ничего ценного" - ну уж я этим заниматься не буду. :) и рекомендовать это делать никому не буду. CMMI я порекмендую применять именно в том объеме и в том виде, которые позволят получать более предсказуемый (по бюджету, качеству и т.д. - тут уж выбор - дело частное) результат

> так ведь я же написал, что для инновационных проектов (задач) нужен немного свой подход

Любой проект по разработке ПО сопряжен с решением проблем, и является в той или иной степени "инновационным". Проект по внедрению готового ПО - нет.

> "военное дело" - т.е. уставы и руководства вообще не имеют право быть в военном деле? все можно выиграть только "силой духа"? :)

Не понимаю, из каких моих слов можно сделать такой вывод, не подключая фантазии. Уставы и руководства имеют весьма посредственное отношение к содержательной части планирования военных действий, и к выигрышу в войне, так же как и соблюдение coding standard не поможет сделать коммерчески успешный продукт. Речь не о них.

> "Вы можете посадить кучу идиотов под CMMI Level 5, и не получить на выход ничего ценного" ну уж я этим заниматься не буду. :) и рекомендовать это делать никому не буду.

Это я привел для иллюстрации того, чем разработка ПО отличается от изготовления гамбургера. Соблюдение технологии не _гарантирует_ вам успеха. Таких гарантий у вас нет и быть не может.

> CMMI я порекмендую применять именно в том объеме и в том виде, которые позволят получать более предсказуемый (по бюджету, качеству и т.д. - тут уж выбор - дело частное) результат

Тезис CMMI про снижение рисков при повышении уровня - как минимум спорен, и многие уважаемые и опытные специалисты его не разделяют, см. аргументацию по этому поводу Тома ДеМарко в Peopleware в качестве примера. Это при том, что те же люди сходятся на том, что критерии зрелости CMMI, в целом, неплохая штука, основанная на best practices.

более предсказуемый (по бюджету, качеству и т.д. - тут уж выбор - дело частное) результат

Скажите, это действительно ВЫБОР? Предсказуемость одного измерения результата достигается за счет другого?

Порекомендуете ли Вы CMMI при целевой функции вида "не очень дорого И достаточно качественно"?

"Порекомендуете ли Вы CMMI при целевой функции вида "не очень дорого И достаточно качественно"?"

В этом случае на CMMI надеятся бесполезно, имхо. Там может быть "очень дорого и качественно" или "очень дорого и можно пользоваться".

(no subject)

(Anonymous) - 2009-05-06 11:21 (UTC) - Expand

Под "выбором" я имел в виду следующее. Любые изменения (в процессах, вообще в организации дел) должны проводится ради решения конкретных проблем и (или) улучшения имеющегося (в т.ч. предсказуемости каких-либо (!) показателей, примеры которых я и привел). И этот принцип должен действовать независимо от того, что из моделей, методологий вы собираетесь внедрять. Хоть CMMI, хоть Scrum, хоть XP, хоть еще чего.

Любые изменения сами по себе затратны. Но это, прежде всего, инвестиции, результат использования которых и надо потом определить. Если не оценить результат - это бессмысленные изменения. Если используете CMMI в качестве базы - определитесь: чего вы хотите добиться этим. Потом сопоставьте ожидаемые затраты и сопоставьте: дорого это или нет. Многое в затратах, связанных с внедрением CMMI, занимают официальные мероприятия и подготовка к ним. Если же официальный "публичный" рейтинг вам не важен, то затраты на внедрение будут не на много больше, чем любой другой методологии или модели.

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

Запиши идею в коде или комментарии к коммиту. В чем проблема-то? Все равно от нее ничего не останется после пары лет поддержки. Твою изначальную идею изменят еще десять раз, исправляя дефекты и докручивая фичи. А глядя в код, про то, что ты оказывается именно это когда-то описал и задокументировал - просто никто не вспомнит.

А вот комментарий к коммиту - как раз прочитают, когда посмотрят код в режиме annotate и найдут источник правки. Причем, заметь, как только твой код будет переписан, и описание мысли перестанет быть актуальным, волшебным исчезнет и ссылка на твой коммит в режиме annotate.

Это в особенности касается больших проектов. Исходя из опыта.

На предыдущей работе тоже делали систему, очень похожую на вашу: трейдерское приложение для инвестиционного банка. Система развивается с 96 года, вроде, и функционирует до сих пор. Архитектура, конечно, совсем убогая, потому что на этом проекте не было такого талантливого архитектора. Строчек кода -- 2-3 миллиона.
Так вот, основным источником инфы являлись именно комменты к коммитам, коду и тикеты в трекинговой системе. Поэтому я согласен, что в долгоживущих системах информативнее сам код, чем документация по нему

> Все равно от нее ничего не останется после пары лет поддержки. Твою изначальную идею изменят еще десять раз, исправляя дефекты и докручивая фичи.

Микрософт пишет довольно сложные программы. ОС там несколько штук, наборы приложений, офисные пакеты, сервера... Вот интересно, почему у них и дока есть, и актуальная, и программами миллионы пользуются? Магия, не иначе. И даже слухи есть, что некоторые программы даже заранее планируют и описывают интерфейсы! Волшебство, не правда ли?

Ты понимаешь разницу между пользовательской документацией и проектной? Или для тебя это одно и то же? Когда обратишь внимание на эту разницу, волшебства вдруг не станет.

Ты видел их внутреннюю, проектную документацию? Ну конечно не видел, откуда тебе. А вот знакомые из группы MS SQL мне говорили, что у них при переписывании MS SQL c 6.5 на 7.0 не было даже спецификации. Вместо нее был сам 6.5. Волшебство, не правда-ли?

> Ты понимаешь разницу между пользовательской документацией и проектной?

для некоторых систем этой разницы нет

> Ты видел их внутреннюю, проектную документацию? Ну конечно не видел, откуда тебе.

1. Давайте на "Вы".
2. Я говорю про MSDN. Очень сомневаюсь, что его пишут после программеров отдельные писатели, анализируя код. Таки писателей в общем-то не найти.
3. О подобной проектной документации есть описания.

Кроме того, хочу обратить твое внимание на маленькую деталь. Я говорю о продукте на этапе поддержки и развития, когда ему уже лет 5. И о проблемах поддержания документации в актуальном состоянии. Сложно этого не заметить, цитируя фразу
> Все равно от нее ничего не останется после пары лет поддержки.
Или если очень хочется, то можно?

А ты в курсе, что микрософтовские оси и продукты немного постарше будут? Что новые обычно поддерживают старые интерфейсы? Ты почитай что-нибудь про WinXP, википедию хотя бы. Книжку купи какую-нибудь. Узнаешь, что кроме оси, у них офис и сервера уже лет 15 как развиваются. И они их документируют. Разговоры "какой-то друг-уборщик из микрософт сказал, что у них нету" это конечно пять.

Я тут тебе ещё нашёл ссылки про микрософт:
http://msdn.microsoft.com/en-us/library/ms978007.aspx
http://msdn.microsoft.com/en-us/architecture/bb469938.aspx
Английский-то хоть знаешь, не надо переводить?

(Имитирую patronizing style. Не нравится небось, а? А не надо было использовать -- я мог бы нормально поговорить.)

(Имитирую patronizing style. Не нравится небось, а? А не надо было использовать -- я мог бы нормально поговорить.)

То, как ты отвечаешь - мне с самого начала не понравилось. А сейчас - ты ничего не "имитируешь", ты просто хамишь. Нормальному человеку не надо поводов, чтобы нормально поговорить. Если бы ты в принципе мог что-нибудь сказать по существу - ты бы давно сказал, не кривляясь и прикрываясь тем, что ты что-то не "имитируешь".

(no subject)

volodymir-k.livejournal.com - 2009-05-15 23:52 (UTC) - Expand

(no subject)

gaperton.livejournal.com - 2009-05-16 09:00 (UTC) - Expand

Микрософт может себе это позволить, я думаю, у них система допиливается в реалтайме только для особо важных клиентов, а до этого никто никуда не спешит в стиле "некогда документировать - код писать надо" :)

> а до этого никто никуда не спешит в стиле "некогда документировать - код писать надо"

"Писать код" в общем-то никогда не надо. Есть проблемы нервов у исполнителей, есть проблемы мозга у бизнеса, бывают проблемы простого неумения и незнания, "как делается документация". Но вообще писать программы срочно очень редко бывает реально надо.

(no subject)

metaclass.livejournal.com - 2009-05-06 06:01 (UTC) - Expand

Так и есть. Но я документирую идею только в виде кратких заметок и ровно до тех пор, пока код не придет в production-ready состояние, потому что после того уже обычно документирование будет отнимать слишком много времени и толком ничего не принесет. Или будет отставать от кода сильно.

Да я не то, чтобы совсем не хочу писать документацию. Наоборот, хотелось бы вести дела более культурно. Но на практике получается, что единственное время, когда ее реально писать - это во время проектирования и до начала писания кода, и документировать приходится высокоуровневые архитектурные решения, чтобы самому их не забыть :)

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

Если цель документа - зафиксировать общее понимание некоторых вещей в группе людей - хорошо. Кто будет читать - понятно, цель - понятна, решаемая проблема - понятна, способ использования понятен, и самое главное, понятен срок актуальности и жизни документа - в топку его после того, как все закодировано в соответствии с пониманием. Вернее сказать, в архив. Вряд ли кто-то его еще раз откроет.

Если самому не забыть - то можно в свободной форме, на листочке писать закорюки. Даже лучше.

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