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

[metaclass]

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

А вот оказывается, что так и делают:
К этому моменту я выкинул все свои диаграммы классов, за ненадобностью – зачем на них смотреть, если они давно уже в голове?

Comments

[raydac.livejournal.com]

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

[volodymir-k.livejournal.com]

Зависит от уровня CMM, принятого в компании. Иногда бывает, что компания крупная, а работают... на коленке. Но редко.

Начиная с CMM 3, каждый проект ведёт массив проектной документации в инфраструктуре, есть процедуры по поддержанию и т.п.

[gaperton.livejournal.com]

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

[http://users.livejournal.com/zubr_/]

Устаревает со страшной силой.
Трудно даже за актуальностью _названий_ методов уследить. Параметры, их назначение и выходные данные - про это вообще молчу.

Насобачился "точки входа" документировать и краткое содержание (без деталей в какой последовательности внутри всё вызывается).
Полезно "список features" иметь.

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

С удивлением обнаружил, что сам работаю по СММ минимум третьего уровня. Просто по-другому самому неприятно.
+1 к "документировать идею". Причем, подписываюсь, что документирование занимает больше времени с момента как только идея продумана до состояния "готово к кодированию".

[guamoka.livejournal.com]

Страшнее отсутствия документации только документация, написанная людьми, которые ее обычно не пишут, считая, что все заключено в коде и комментариях. Не зависимо от уровня человека как программиста, выражать мысли в документации как правило умеют сущие единицы. У людей реально сносит башню, и "документация" превращается в презентацию, хай-левел дизайн и спецификацию по классам и методам одновременно, причем, желательно все на одном листе. Люди реально не знают, что же требуется отразить "на бумаге", для каких целей это пишется, кто целевая аудитория и когда следует остановится.
ЗЫ. В этом плане поучительна книга Фаулера УМЛ Дистеллед на фоне фолиантов и справочников от Бутча и Ко:)

кстати

[alll]

Помимо всего прочего поддержание актуальной документации создаёт у начальства:
а) Иллюзию заменяемости исполнителя.
б) Недовольство замедленными темпами разработки.
Результат очевиден. ;)

[vp.livejournal.com]

А вот, кстати, еще пример разбирательства "по коду". Я постоянно на своей шкуре чувствую, когда за тобой потом изучаю то, что ты написал. И есть две вещи, которые замедляют "читабельность с первого раза" в 10 раз: это грамотно развязанный код с целью исключения зависимостей, когда 5 штук классов с наследованной дополняемой функциональностью, или опосредствованный обмен между классами через посредников (щину). Тут только бумагу в руки и рисовать :) Иначе фиг поймешь.

[blackyblack.livejournal.com]

Документировать код можно легко и безболезненно. Может быть это ООП так негативно влияет на архитектуру?
В целом же правило такое - чем выше уровень программы (или более обще - чем больше совокупная сложность модуля), тем более развёрнутый должна быть документация. Зависимость практически линейная, за исключением хитрых хаков на низком уровне.

[sergiej.livejournal.com]

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