UML, чертежи, принципиальные схемы — ненужны?

Так вот нам рекомендовали забивать на доки в свете наличия работающего кода в конце каждой интерации продукта и организованого вербального knowledge sharing в команде.

Вы их неправильно поняли:

тренеры по Agile/scrum нам говорили, что следует смещать приоритеты от документации к работающему коду

смещать приоритет - не значит забивать

PS невербальный knowledge sharing это очень важный момент, упускать его в долгосрочное проекте - щемить себе яйца дверью без особой нужды

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

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

З.Ы. Не стараюсь выставить себя знающим как всё должно быть. Я просто рассказываю свой опыт, не более.

смещать приоритет - не значит забивать

Почти двухлетний опыт в проекте (да, вот такой маленький) говорит о том, что документировать стоит только краеугольные камни дизайна и не более. И UML в этом деле пока что не пригодился (я молчу про то, что вербальный knowledge sharing целиком решает эту задачу). Остальное документировать просто не стоит, т.к. все меняется, а неправильные доки в 10 раз хуже их отсутствия.

PS невербальный knowledge sharing это очень важный момент, упускать его в долгосрочное проекте - щемить себе яйца дверью без особой нужды

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

как спидометр соотносится с движением колес

user manual? :)

Не путайте сборку с изготовлением. Сборочный чертёж может и получится восстановить по готовому изделию, а чертежи отдельных деталей, скорее всего, нет. man допуски и посадки. Точность изготовления очень сильно влияет на стоимость.

Без чертежей современное производство просто невозможно, в отличии от программирования без UML.

UML язык годный для описания концепций, вот нафига его тащить на уровень реализации?

Ни разу не спец в UML, но как мне показалось он как раз ближе к уровню реализации. Все эти состоянии, отношения и тому подобное никак у меня с концептуальным уровнем не ассоциируются.

ЗЫ. Всегда хватало словесного описания + схем в вольной форме.

Можно долго спорить про применимость UML, но если сравнивать с «обычными» инженерными схемами, то самый большой фейл в том, что UML схемы, в отличии от инженерных, нельзя верифицировать. А все потому... что на UML нету никаких спецификаций. Да, схема моста является спецификацией для его сборки. Но есть спецификация на спецификацию - соблюдение физических ограничений вроде прочности и тому подобного. По идее, спецификацией для проекта является ТЗ. Но точная формальная постановка ТЗ обычно затруднительна. В тех проектах, где ТЗ хорошо формализовано, ясень пень все хорошо.

Резюмируя: в моем маленьком мирке все очень просто: задача поставлена формально <=> формально же может быть решена. Задача поставлена не формально <=> заказчик сам толком не знает что хочет => здравствуй «искусство» млять.

UML - это ООП. А ООП не нужен.

> UML - это ООП. А ООП не нужен.

Полуграмотные анонимусы, путающие методологию и средство выражения на ЛОРе не нужны.

Придурок, ООП (и OOD) именно как методология проектирования на хер не нужен. Как приятное дополнение к семантике какого либо языка - пусть себе живет, не жалко.

Идиот, не я заявил, что «UML - это ООП». И свои безосновательные пожелания о том что нужно и что не нужно можешь свернуть в тугую трубочку и засунуть себе по самые гланды.

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

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

и это все равно было бы дешевле, чем:

1. платить тебе зарплату, пока ты разбираешься с проектом

или

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

(как вариант, конечно, можно было бы его попросить документировать самое интересное перед увольнением, но нет гарантии, что он просто тупо бы не нагенерил того мусора, что генерят over 9000 UML eclipse plubins)

s/plubins/plugins/

Существует еще более дешевое решение. Есть такой фактор - Автобусное число. Так вот если оно близко к единице для некоторых частей системы, то руководство ССЗБ. Всего то нужно, что бы о любых аспектах системы знало хотя бы 2 человека. Для внутренних проектов (бесконечная разработка без сдачи проекта) можно жить обходясь минимум документации просто на основе «вербального knowledge sharing». И не нужно никого вылавливать на субботние посиделки.

> У меня был компилятор Си++. Но его нельзя было использовать - неэффективный код.

а хороший отладчик для ассемблера у тебя есть?

как бы там не ругали отладчик — он весьма полезен для тех случаев, когда проблема локализована (хотя бы с некоторой вероятностью) в < 1000 строках — т.е. например для отладки *алгоритмов* или сегфолтов

ну пусть даже и есть

тогда сишный код мог бы использоваться для:

1. локального документирования твоего асм-кода

2. юнит-тестов для нахождения различий между поведением асм-кода и сишного кода

си точно не нормальный, с++ с вставками, нагенеренными перловыми скриптами, еще как-то можно использовать

Таки это тебе нужно озвучивать свои специфические понятия.

перл в дебиане (не знаю как в МСВС или что там у вас) входил в состав системы

Package: perl-base
Essential: yes
Priority: required

причем он нужен на машине, где идет компиляция, а не целевой

и наконец питон сойдет вместо него (ничего волшебного в перле нет, но по удобству регекспов он, вероятно, все же номер 1)

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

Ради двух автоматов? У тебя DSL головного мозга.

дальнейшее для плохого с++-компилятора вряд ли имеет смысл, но ради дискуссии...

1. только *если* надо

2. ради 2 автоматов вполне можно написать до 10 регулярных выражений (а я говорил именно о таком, *тупом* расширении языка)

UML (в рамках данной дискуссии) - для другого.

для другого нужен хороший язык, а не UML

пока хорошего языка нет, можно обходиться нормальным с перл-препроцессингом

(кстати, это как раз и мешает мне как следует заняться хорошим языком)

Существует еще более дешевое решение. Есть такой фактор - Автобусное число. Так вот если оно близко к единице для некоторых частей системы, то руководство ССЗБ. Всего то нужно, что бы о любых аспектах системы знало хотя бы 2 человека. Для внутренних проектов (бесконечная разработка без сдачи проекта) можно жить обходясь минимум документации просто на основе «вербального knowledge sharing». И не нужно никого вылавливать на субботние посиделки.

+100.