Здравствуйте, Sinix, Вы писали:
V>>Это фундаментальные инженерные процессы, которые относятся не только к разработке ПО. Ничего нового они не выдумали, но собираются упорядочить уже имеющееся. Так же неплоха ориентация на полноту методологии, в отличие от всяких модных-однобоких.
S>Эта бла-бла-грамма выше ещё больший сфероконизм чем паттерны от GoF.
Паттерны от GoF никакой не сфероконизм. Это сборник уже имеющихся на тот момент полезных практик. Полезность GoF — в попытке упорядочить эти практики, классифицировать и дать им именования, некий "алфавит". Любая предметная область начинается с терминологии и в этом плане заслуга GoF отнюдь не сфероконическая.
S>А тут всё заканчивается ИБД + кучей трюизмов, они не станут теорией всего, как ты их на глобус не натягивай.
Блин, иногда хочется коллегам сказать "заткнись и внимай". ))
Какой в опу глобус? Ничего нового я у них не увидел, но увидел попытку обобщить имеющееся. Я в разные годы отсылал коллег к 19-м и 34-м ГОСТ-ам. Почему? Не секрет, что в любой более-менее серьезной конторе полно своих правил по организации рабочего процесса. Зачастую эти правила рождаются в муках, путём проб и ошибок. Знаешь, как военный устав всегда писался кровью и только кровью реальных людей. В этом смысле ГОСТ-ы, RUP, MSF были (и есть) таким же "уставом, писанным кровью".
Например, одно дело опытные разработчики с 15-20-летним стажем, другое дело — команда из относительно молодых спецов, которая будет вынуждена запарывать проекты вовсе не из-за недостаточной технической подготовки, а именно из-за недостаточной организационной. Современный разработчик обычно очень хорошо знает, что делать на стадии макетирования и технического эксперимента, знает как решать конкретные технические вопросы, но плохо представляет себе весь процесс разработки программных систем уровня выше мелких (по современным меркам) проектов. Т.е., "чуйка" и техническая подготовка зачастую плохо работают в командах из более 5-ти человек. По многим вопросам происходит "буксование" только из-за того, что нет опытного управленца, которому можно доверить хотя бы 20 спецов.
Так вот, все эти ГОСТ-ы, RUP-ы и то, что я видел по ссылке — это попытка уменьшить влияние человеческого фактора на процесс разработки ПО. Мне довелось в начале своей карьеры поучаствовать в разработке программных систем по 19-м ГОСТ-ам, — проникся. Отпадает надобность во внешнем "кнуте и прянике" в виде достаточно опытной в управлении личности, который должен разбираться с тараканами каждого конкретного разработчика. Это как методичка к курсовому проекту, например, где для студента расписан необходимый план работ. И что мне больше всего импонировало, что эта "методичка" не исключает так любимых всеми нами стадий решения тех самых "вкусных" технических проблем. Наоборот, она помогает всем этим наработкам не трансформироваться в "работу в стол", а жесткая привязка к итеративности процесса не позволяет слишком увлечься "любимой задачей".
S>Универсальные полные тяжеловесные методики мы уже проходили 15 лет назад. Популярность msf, rup и прочих uml-driven как бы намекает, что не надо так делать.
Тем не менее, эти методологии появились не из воздуха, это реальные "циркуляры", по которым была осуществлена разработка очень больших программных систем. MSF и RUP очень близки, MSF даже тяжеловесней RUP, они обе хороши тем, что обладают полнотой, т.е. описывают полный цикл разработки, начиная от "наколенных" поделок, а так же обладают неплохой масштабируемостью, т.е. подходят как командам из 2-х человек, так и командам из 20-ти человек.
(UML здесь никаким боком от слова вообще, это из разряда "слышал звон, да не знаю, где он".)
S>Они все как одна сыпятся на самом нижнем уровне из-за чрезмерной детализации и оверменеджмента.
Наоборот, эти методологии появились как результат борьбы с микроменеджментом (особенно ярко это наблюдается в MSF), чтобы над каждым разработчиком не стоял дядя-PM и не говорил ему каждый день, что ему делать дальше. Это просто "методички" по самоорганизации процесса разработки ПО.
S>Перспектива на сегодня если и есть за чем, то за скрещиванием процессного подхода сверху и управляемого бардака снизу. Читай, kanban, lean, и кадавры из тяжеловесной биз-аналитики и любого agile-подхода. Но нет, мы снова будем пытаться свести в систему носки и капусту, просто потому, что можем
RUP и MSF не могут быть противопоставлены Agile, потому что являются надмножеством практик из Agile, т.е. включают их в себя полностью (кроме таких вещей из XP, как "парное программирование" — это слишком субъективная хрень, т.е. сильно зависимая от человеческого фактора практика, которая работает далеко не для всех "пар").
Извини, но весь этот пост говорит о том, что ты не удовлетворил свою эрудицию ни разу даже по такой вещи, которую неявно рекламируешь, — по Agile. Сама постановка вопроса "противопоставление Agile и MSF" говорит о том, что тебе не стоило высказываться по этой теме до изучения азов MSF в том числе. Цимус в том, что одна из популярных Agile на сегодня — это MSF Agile, которую используют в самой MS.
Более того, Agile Manifestoне включает в себя каких-либо практик и был составлен практиками, использующими РАЗНЫЕ методологии разработки ПО. Это просто набор советов для расстановки приоритетов в рамках ЛЮБОЙ законченной методологии проектирования. Медитировать до просветления, как грится.
Даже взять SCRUM — его можно рассматривать как урезанный по артефактам RUP, где из всего RUP оставили, собственно, итеративную часть разработки. Это ВСЁ. Т.е. это ЧАСТЬ методологии, но не вся она, т.к. она не обладает полнотой, т.к. описывает лишь часть жизненного цикла ПО. Еще можно вспомнить наши 19-е и 34-е ГОСТ-ы, которые тоже предоставляли возможность разного по уровню "углубления" в подробности методологии. Т.е. при том, что "общий рисунок" по ГОСТ-ам оставался тем же, некоторые стадии могли быть реализованы с произвольной (т.е. необходимой для каждого конкретного случая) глубиной.
И да, возвращаясь с кабжу. Чем мне сразу импонирует SEMAT — это "иерархической" моделью представления модели методологии. Сорри, это не масло маслянное, а именно так. Начиная от самых общих штрихов, от каркаса самого процесса, по каждой детали можно углубляться в подробности настолько, насколько это требуется. Т.е., я ожидаю от ЭТОЙ попытки, наконец, возможность изучать "методичку" ровно с такой степенью подробности, которая будет соответствовать "размеру" разрабатываемого ПО, и не более. Думаю, именно с этой целью товарищи и подошли к станку на этот раз.
Если у них это в итоге выгорит — они покроют как бык корову все эти ГОСТ-ы, MSF, RUP и семейство Agile, по понятным причинам.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, craft-brother, Вы писали:
CB>>Показалось разумным. Размышляю о применении в своих проектах, анализирую риски. Хотелось бы привлечь коллективный разум.
M>Раз уж ты с этим разбирался, можешь рассказать в двух словах в чем суть?
Лучше, конечно смотреть первоисточники.
Но если коротко. Независимо от метода Scrum/RUP/… /водопад определены семь инвариантов, которые общие для всех программных систем – альфы. Между инвариантами определены зависимости (см. рис.).
Каждый инвариант в процессе жизненного цикла программной системы имеет набор последовательных состояний. Например, альфа Стейкхолдеры имеет следующий набор состояний:
• Выявлены
• Представлены
• Вовлечены
• В согласии
• Удовлетворены развертыванием системы
• Удовлетворены работой системы
Разработаны чек-листы, которые позволяют в каждый момент экспертно оценить в каком состоянии находятся все альфы. Имея текущее состояние мы можем сравнить между собой прогресс во всех проектах независимо от методов и технологий. Кроме того, зная очередное требуемое состояние альфы, мы понимаем, что надо сделать чтобы туда попасть.
Здравствуйте, craft-brother, Вы писали:
CB>Показалось разумным. Размышляю о применении в своих проектах, анализирую риски. Хотелось бы привлечь коллективный разум.
Раз уж ты с этим разбирался, можешь рассказать в двух словах в чем суть?
Здравствуйте, craft-brother, Вы писали:
CB>А что-то про SEMAT тут никто еще не написал? Исправляем.
Пока как-то напоминает "как нам обустроить рабкрин".
☑ организация
☑ филиалы
☑ доклады
☐ результат
UPD
The primary authors of the articles and founders of the initiative are ... and Dr. Ivar Jacobson, one of the co-creators of the Unified Modeling Language and the Unified Process
Безотносительно к самому методу (не читал) — не нравится мне название. Единая Теория, да еще и всего программирования. Видимо, после того, как она будет создана, развитие программирования должно прекратиться — что тут еще развивать, если есть единая теория всего ?
With best regards
Pavel Dvorkin
Re[5]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, vdimas, Вы писали:
V>Так вот, все эти ГОСТ-ы, RUP-ы и то, что я видел по ссылке — это попытка уменьшить влияние человеческого фактора на процесс разработки ПО.
Влажная мечта плохого руководителя — собрать группу говнокодеров и говноменеджеров, и с помощью магического процесса разработки получить от них годный продукт.
Плохая новость — это не работает. Вообще никогда не работает.
Вот тут более молодые "космонавты" (в смысле: русскоязычные программисты, который живут и работают вне России, мотаются по миру, рассуждают, что правильно и полезно) делятся впечатлениями от использования конкретных технологий: http://razbor-poletov.com/
(Java у них проходит в качестве связующей нити.)
Re[3]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, craft-brother, Вы писали:
CB>Разработаны чек-листы, которые позволяют в каждый момент экспертно оценить в каком состоянии находятся все альфы. Имея текущее состояние мы можем сравнить между собой прогресс во всех проектах независимо от методов и технологий.
Так ведь и в RUP была точно такая-же модель жизненного цикла проекта вместе с четкими рекомендациям как измерять состояние проекта и как проходить отдельные этапы. Вплоть до того какие вопросы аналитик должен задавать в процессе сбора требований и UML диаграмм принятия решений.
CB>Кроме того, зная очередное требуемое состояние альфы, мы понимаем, что надо сделать чтобы туда попасть.
Неочевидное утверждения. Я знаю что в проекте, условно, бардак, я знаю что в проекте должен быть, условно, порядок, но это никак не приближает меня к знанию о том что конкретно нужно делать чтобы из бардака сделать порядок.
Re[5]: SEMAT – Единая Теория Всего Программирования?
V>Паттерны от GoF никакой не сфероконизм. Это сборник уже имеющихся на тот момент полезных практик. Полезность GoF — в попытке упорядочить эти практики, классифицировать и дать им именования, некий "алфавит". Любая предметная область начинается с терминологии и в этом плане заслуга GoF отнюдь не сфероконическая.
В своё время — да. На сегодня любые попытки использовать паттерны "как есть" неизменно кончаются лютым фейлом типа этого
(всю тему целиком тоже можно посмотреть). Потому что или игнорируем особенности языка-фреймворка (и вместе с водой выплёскиваем ребёнка), или от паттернов остаются только названия, да и то их постоянно путают.
V>Какой в опу глобус? Знаешь, как военный устав всегда писался кровью и только кровью реальных людей. В этом смысле ГОСТ-ы, RUP, MSF были (и есть) таким же "уставом, писанным кровью".
Не катит. Потому что SEMAT пытается слепить в один том "взвод, отделение, танк" и "батальон, рота" (про ч.1 не будем, ибо гриф).
Тот же "стейкхолдер предъявляет требования" скрывает под собой принципиально разные подходы, от проверкой кодом в тру-agile через верификацию моделью в DDD к традиционной аналитике в "тяжёлых" методиках. Как их можно в один инвариант запихивать?
V>Так вот, все эти ГОСТ-ы, RUP-ы и то, что я видел по ссылке — это попытка уменьшить влияние человеческого фактора на процесс разработки ПО.
Не работает Я наблюдал и каноничнейший сертифицированный RUP, рассыпавшийся именно из-за следования процессам, и самоорганизацию из бардака в процессы, вполне укладывающиеся в CMMI3. Единственная корреляция — уровень адекватности принимающего решения. Т.е. тот самый человеческий фактор.
V>(UML здесь никаким боком от слова вообще, это из разряда "слышал звон, да не знаю, где он".)
Нее, ты видимо забыл первые выступления-статьи-конференции на тему RUP+UML == наше всё. Один в один было. И универсальность, и генерация всего по диаграммам, и one meth fith all. Туда не то что UML — CORBA приплетали. Закончилось тем, что классический UML мы видим разве что в сопроводительной документации (всё-таки то, что обычно рисуют на досках тянет разве что на "по мотивам UML"). А "старые" методики остались только в учебниках, ибо MSF сегодня и MSF 20 лет назад — две оччень большие разницы. Хотя судя по этому:
RUP и MSF не могут быть противопоставлены Agile, потому что являются надмножеством практик из Agile, т.е. включают их в себя полностью
ты сейчас про современные версии, а не про оригиналы времён расцвета Розы? Тогда всё правильно, кроме того, что речь вообще-то шла про каноничные "бронебойные" методики.
V> Т.е., я ожидаю от ЭТОЙ попытки, наконец, возможность изучать "методичку" ровно с такой степенью подробности, которая будет соответствовать "размеру" разрабатываемого ПО, и не более. Думаю, именно с этой целью товарищи и подошли к станку на этот раз.
Ты_не_поверишь. Ровно то же самое мне рассказывали про RUP EUP лет эдак двенадцать назад. Не помогло.
Re[2]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, __kot2, Вы писали:
__>по-моему делать всеобьемлющую систему и ждать, что на этот раз ей начнут пользоваться хорошо подпадает под определение безумия
Стопроцентное попадение
Среди авторов — Ивар Якобсон (один из застрельщиков UML). Про определение безумия по Энштейну, думаю, напоминать не надо
Re[3]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, craft-brother, Вы писали:
CB>Лучше, конечно смотреть первоисточники.
CB>Но если коротко. Независимо от метода Scrum/RUP/… /водопад определены семь инвариантов, которые общие для всех программных систем – альфы. Между инвариантами определены зависимости (см. рис.).
Вот на стрелочке "стейкхолдер предъявляет требования" все уже обычно и начинает сыпаться.
Re[4]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, landerhigh, Вы писали:
L>Эта будет уже 100500 попытка "упорядочить". Хотя на деле все уже идет под откос на фазе "стейкхолдер формирует требования", причем дело даже не в анекдотичном "он сам не знает, чего хочет".
А что-то про SEMAT тут никто еще не написал? Исправляем.
Знакомлюсь с SEMAT – Software Engineering Method and Theory.
Вот несколько заголовков немногочисленных для наших медиа статей о SEMAT.
Развернётся ли SEMAT на сто миллионов программистов?
SEMAT – вторая революция в программной инженерии?
Наука программировать — средство от катастроф.
Показалось разумным. Размышляю о применении в своих проектах, анализирую риски. Хотелось бы привлечь коллективный разум.
Определение из Википедии
SEMAT (Software Engineering Method and Theory) is an initiative to reshape software engineering such that software engineering qualifies as a rigorous discipline. The initiative was launched in December 2009 by Ivar Jacobson, Bertrand Meyer, and Richard Soley.
At the start of the initiative the founders wrote a call for action statement and a vision statement. The initiative was envisioned to be a multi-year effort working in parallel to bridge the gap between the developer community and the academic community and create a community giving value to the whole software community.
Предыстория
В сентябре 2009 года Ивар Якобсон, Бертран Мейер и Ричард Соули выступили с инициативой SEMAT, основы которой они изложили в своей книге The Essence of Software Engineering: Applying the SEMAT Kernel. Идею тройки поддержали такие гуру программирования, как Барри Боэм, Эд Йордан, Скотт Амблер, Ларри Константин и Билл Куртис. В работу над SEMAT включились корпорации ABB, SAAB, IBM и Samsung.
Смотрим
Доклад Ивара Якобсона в Гугле. Dr. Ivar Jacobson — The Essence of Software Engineering: the SEMAT Approach
Доклад Бориса Позина в МГУ. SEMAT. К теории программной инженерии. Состояние и направления развития Б.А. Позин д.т.н., профессор, Председатель SEMAT Russian Chapter
Здравствуйте, __kot2, Вы писали:
__>по-моему делать всеобьемлющую систему и ждать, что на этот раз ей начнут пользоваться хорошо подпадает под определение безумия
Ну когда-то никто не спрашивал, пользоваться ГОСТ-ами или нет. Положено и баста. ))
Re[2]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, craft-brother, Вы писали:
PD>Безотносительно к самому методу (не читал) — не нравится мне название. Единая Теория, да еще и всего программирования. Видимо, после того, как она будет создана, развитие программирования должно прекратиться — что тут еще развивать, если есть единая теория всего?
Это фундаментальные инженерные процессы, которые относятся не только к разработке ПО. Ничего нового они не выдумали, но собираются упорядочить уже имеющееся. Так же неплоха ориентация на полноту методологии, в отличие от всяких модных-однобоких.
Re[3]: SEMAT – Единая Теория Всего Программирования?
V>Это фундаментальные инженерные процессы, которые относятся не только к разработке ПО. Ничего нового они не выдумали, но собираются упорядочить уже имеющееся. Так же неплоха ориентация на полноту методологии, в отличие от всяких модных-однобоких.
Ты серьёзно? Эта бла-бла-грамма выше ещё больший сфероконизм чем паттерны от GoF. Те хоть отголосок практической применимости имеют (имели). А тут всё заканчивается ИБД + кучей трюизмов, они не станут теорией всего, как ты их на глобус не натягивай.
И да, я наконец вспомнил, что мне всё это дело отчаянно напоминает.
Универсальные полные тяжеловесные методики мы уже проходили 15 лет назад. Популярность msf, rup и прочих uml-driven как бы намекает, что не надо так делать.
Они все как одна сыпятся на самом нижнем уровне из-за чрезмерной детализации и оверменеджмента.
Перспектива на сегодня если и есть за чем, то за скрещиванием процессного подхода сверху и управляемого бардака снизу. Читай, kanban, lean, и кадавры из тяжеловесной биз-аналитики и любого agile-подхода. Но нет, мы снова будем пытаться свести в систему носки и капусту, просто потому, что можем
Re[3]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, vdimas, Вы писали:
V>Это фундаментальные инженерные процессы, которые относятся не только к разработке ПО. Ничего нового они не выдумали, но собираются упорядочить уже имеющееся.
Эта будет уже 100500 попытка "упорядочить". Хотя на деле все уже идет под откос на фазе "стейкхолдер формирует требования", причем дело даже не в анекдотичном "он сам не знает, чего хочет".
Re[6]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, petr_t, Вы писали:
V>>Так вот, все эти ГОСТ-ы, RUP-ы и то, что я видел по ссылке — это попытка уменьшить влияние человеческого фактора на процесс разработки ПО.
_>Влажная мечта плохого руководителя — собрать группу говнокодеров и говноменеджеров, и с помощью магического процесса разработки получить от них годный продукт. _>Плохая новость — это не работает. Вообще никогда не работает.
Я не могу комментировать чьи-то мечты. Описанная тобой ситуация ни разу не новость. Гораздо обидней, когда собираются спецы, а проект заваливают. Подсказка сработала или опять мимо?))
Re[4]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, beyv, Вы писали:
B>Думаю значение математики сильно преувеличено, наверное самими математиками B>В жизни ведь не всё дискретно.
Математика тоже не вся дискретная
Re[8]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, landerhigh, Вы писали:
L>Банальным 110301 теорию управления и автоматику преподают так, что с автоматами проблем в принципе нет.
Там только ТАУ/САУ дают более глубоко, что к теории автоматов никаким боком.
L>Мои многолетние наблюдения, в том числе и за рубежом, показывают, что тру-программеров, окончивших CS специальность
Мои наблюдения западных коллег показывают, что вообще непонятно, чему там учат программистов. Языкам и библиотекам, походу.
L>способных самостоятельно реализовать нечто выходящее за рамки двух состояний, и при этом не наворотить кошмара в коде, практически не существует. Тут тебе и ад в собственно реализации, и state explosion, и превращение КА в генератор, и недостижымые и тупиковые состояния, и чаще всего все это вместе взятое.
А у нас многие программисты имеют непрофильное образование. Просто программирование здесь заметно лучше кормит (в сравнении с другими инженерными дисциплинами) и многие в итоге переучиваются на программеров, от физиков/математиков до радиотехников.
Re[6]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, Sinix, Вы писали:
S>ты сейчас про современные версии, а не про оригиналы времён расцвета Розы? Тогда всё правильно, кроме того, что речь вообще-то шла про каноничные "бронебойные" методики.
Здравствуйте, vdimas, Вы писали:
S>>ты сейчас про современные версии, а не про оригиналы времён расцвета Розы? Тогда всё правильно, кроме того, что речь вообще-то шла про каноничные "бронебойные" методики.
V>Кстате, вспомнил про неплохой давний пост коллеги насчет "предварительного проектирования": V>"Бронебойные методики" были выработаны на больших (по тем временам) проектах.
Так я в хорошем смысле про бронебойные методики, "тяжёлый — значит надёжный"(c). При употреблении по месту, конечно. А вот с этим были баальшие проблемы, ибо тот самый ореол универсальной методики. Вплоть до попыток организовать курсы по RUP в виде "группа просто работает по RUP, организуясь в процессе". Мне в этом дурдоме повезло не участвовать, но рассказов наслушался.
Мне честно лень спорить, тем более что разговор вообще ушёл от "как оно было в прошлый раз на практике" к "как оно должно быть, в этот раз у них всё получится". Пока я не увидел ни одного принципиального отличия, те же грабли, те же люди.
Re[8]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, AndrewVK, Вы писали:
V>>Я не могу комментировать чьи-то мечты. Описанная тобой ситуация ни разу не новость. Гораздо обидней, когда собираются спецы, а проект заваливают. Подсказка сработала или опять мимо?)) AVK>Само существование этого сайта как бы намекаэ, что не все так печально, не?
Дык, "заваленный проект" — это не потому, что люди оказались в принципе неспособны его сделать (такого практически не бывает), а потому что не вложились в сроки/деньги. А так-то любой проект, при желании, можно довести до ума. Особенно дотационный какой-нить, опен-сорс или как этот сайт — интересу ради.
Re[3]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, craft-brother, Вы писали:
CB>Лучше, конечно смотреть первоисточники.
CB>Но если коротко. Независимо от метода Scrum/RUP/… /водопад определены семь инвариантов, которые общие для всех программных систем – альфы. Между инвариантами определены зависимости (см. рис.).
Неожидано. ))
Прям как RUP и наши ГОСТы 80-х годов.
Возврат к истокам? ))
Re[3]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, craft-brother, Вы писали:
CB>А что-то про SEMAT тут никто еще не написал? Исправляем.
Люди никогда не создадут ни единого бога, ни единой валюты ни единого аудиовидео-формата, ни всеобщего счастья.
Забудьте за слово "Единая". Да ещё и теория
Re[6]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, Sinix, Вы писали:
V>>Паттерны от GoF никакой не сфероконизм. Это сборник уже имеющихся на тот момент полезных практик. Полезность GoF — в попытке упорядочить эти практики, классифицировать и дать им именования, некий "алфавит". Любая предметная область начинается с терминологии и в этом плане заслуга GoF отнюдь не сфероконическая. S>В своё время — да. На сегодня любые попытки использовать паттерны "как есть" неизменно кончаются лютым фейлом типа этого
(всю тему целиком тоже можно посмотреть). Потому что или игнорируем особенности языка-фреймворка (и вместе с водой выплёскиваем ребёнка), или от паттернов остаются только названия, да и то их постоянно путают.
Ну я сам регулярно выступаю против "проектирования от паттернов". Т.е. выступаю не против них самих, а против бытующего одно время заблуждения об их всегомущей силе, что, мол, если архитектура построена сплошь на паттернах, то она уже неплоха. По мне это тоже, что заявлять, что если некий говнотекст использует некий популярный алфавит, то он заведомо шедевр... вот что-то типа этого.
V>>Какой в опу глобус? Знаешь, как военный устав всегда писался кровью и только кровью реальных людей. В этом смысле ГОСТ-ы, RUP, MSF были (и есть) таким же "уставом, писанным кровью". S>Не катит. Потому что SEMAT пытается слепить в один том "взвод, отделение, танк" и "батальон, рота" (про ч.1 не будем, ибо гриф).
Ничего не понял по теме. Могу сказать лишь по твоей аналогии — современный мотострелковая бригада имеет всё перечисленное (ты еще забыл гаубичные батальоны, зенитные батальоны, батальоны связи и материального обеспечения) и "всё это" обязательно "слеплено" в одну "единицу" согласно Уставу.
Зачем вообще нужен Устав? Чтобы каждый командир не придумывал свои организационные "велосипеды", только и всего. В этом смысле RUP и MSF — полноценные "уставы".
S>Тот же "стейкхолдер предъявляет требования" скрывает под собой принципиально разные подходы, от проверкой кодом в тру-agile через верификацию моделью в DDD к традиционной аналитике в "тяжёлых" методиках. Как их можно в один инвариант запихивать?
ХЗ, чтобы не плодить сущности, вестимо. Как можно присваивать одно и то же звание командиру аэромобильной бригады и мотострелковой? )) Одна из них действует "тяжеловесным фронтом", а другая в стиле "тру-agile".
Я думаю, что ты попытался прицепиться к интуитивно понятному, а это заявка на поражение в споре, т.к. критиковать стоит интуитивно непонятное.
V>>Так вот, все эти ГОСТ-ы, RUP-ы и то, что я видел по ссылке — это попытка уменьшить влияние человеческого фактора на процесс разработки ПО. S>Не работает Я наблюдал и каноничнейший сертифицированный RUP, рассыпавшийся именно из-за следования процессам, и самоорганизацию из бардака в процессы, вполне укладывающиеся в CMMI3. Единственная корреляция — уровень адекватности принимающего решения. Т.е. тот самый человеческий фактор.
Ну, дык, степень подготовленности командира никто не отрицает. Если человек идиот, ему никакой Устав не поможет. Только Устав тут не при чем, заметь. Это не всемогуттер, это просто циркуляр, подсказка, методичка, сборник практик и выработанных опытом других людей ограничений. Более того, в современной разработке тебе "ничего не будет", если ты не блюдешь устав, поэтому, сложновато оценить — действительно ли устав кривой, или люди только делали вид, что блюли устав, а сами только просиживали штаны и проедали бабло? В армии ведь тоже бывает — вроде, всё по Уставу, а нихрена не делается. "Итальянская забастовка" хорошо описывает причины того, почему порой даже самые лучшие практики не работают в некоторых конкретных командах. Я наблюдал в реальной жизни САБОТАЖ коллег, когда их, болезных, "заставляли" делать не то, что им бы хотелось. Согласись, что тут никакая организация процесса не поможет, если сам человек делает всё, чтобы завалить собственную работу.
V>>(UML здесь никаким боком от слова вообще, это из разряда "слышал звон, да не знаю, где он".) S>Нее, ты видимо забыл первые выступления-статьи-конференции на тему RUP+UML == наше всё.
Я ничего не забыл и сам тогда критиковал именно такую постановке вопроса, что, мол, одно наличие UML порешает все проблемы. Конечно, это наивно. Но так же наивно думать, что графические нотации не нужны вовсе. Эти нотации, примененные к месту, — очень даже гут. Для меня UML — это лишь некое семейство языков графических нотаций, не более. Вот так к нему и надо относится. По букварю с одними картинками читать научиться невозможно, согласен, но когда букварь вообще без картинок — автор дебил. )) И это я еще не прошелся по ЛЮБОЙ более-менее вменяемой документации на программные системы, там без графической нотации ваапще никак. Правда, не всегда используется именно UML, но для специалиста с хоть какой-то подготовкой это и не принципиально.
S>Закончилось тем, что классический UML мы видим разве что в сопроводительной документации
А я регулярно вижу графические нотации в документация для разработчика, а это отнюдь не "сопроводительная документация". Этот тот самый "артефакт проектирования" согласно UP.
S>А "старые" методики остались только в учебниках, ибо MSF сегодня и MSF 20 лет назад — две оччень большие разницы. Хотя судя по этому: S>
S>RUP и MSF не могут быть противопоставлены Agile, потому что являются надмножеством практик из Agile, т.е. включают их в себя полностью
S>ты сейчас про современные версии, а не про оригиналы времён расцвета Розы? Тогда всё правильно, кроме того, что речь вообще-то шла про каноничные "бронебойные" методики.
Ты серьезно? Ты возьмешься сейчас показать мне место в этих методологиях, где есть требование "проектировать в UML"?
Роза — лишь инструмент, автоматизирующий разработку и поддержку артефактов проектирования. Артефакты не обязаны быть ТОЛЬКО графическими. Именно за этим я послал тебя в предыдущем абзаце — попытаться найти такое требование.)) Не ищи, не найдешь. А составлять представление о RUP через Розу — но это уже за гранью добра и зла. Это всё-равно что составлять представление о фотографировании по Фотошопу, хотя последний (или его аналог) нужен в 99% случаев в современной фотографии.
Ну и еще такой момент, для составления текстовой документации полно текстовых процессоров и без Розы.
V>> Т.е., я ожидаю от ЭТОЙ попытки, наконец, возможность изучать "методичку" ровно с такой степенью подробности, которая будет соответствовать "размеру" разрабатываемого ПО, и не более. Думаю, именно с этой целью товарищи и подошли к станку на этот раз. S>Ты_не_поверишь. Ровно то же самое мне рассказывали про RUP EUP лет эдак двенадцать назад. Не помогло.
Кому не помогло? Для "водопадной" разработки UP — это наиболее естественный процесс до сих пор. Его используют в военке, космосе, авиации, при разработке финансовых систем и т.д.
Фишка в том, что ВСЕ более-менее крупные системы разрабатываются по "водопаду". Но при разработке различных подсистем (особенно GUI пользователя или внешнего программного интерфейса/АПИ), зачастую используют классику Agile, т.е. происходит акцент на итерации через фидбэк от конечных пользователей/заказчиков или даже просто тестеров, их эмулирующих. Характерно тут то, что UP не запрещает и никак не конфликтует с такой расстановкой "акцентов" на некоем этапе разработки.
Knowledge and Skills:
Software development projects.
Strong familiarity with all aspects of software requirements, design, implementation, testing, deployment, and maintenance.
Strong familiarity with RUP (Rational Unified Process) and Agile software methodologies.
Re[2]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, beyv, Вы писали:
CB>>А что-то про SEMAT тут никто еще не написал? Исправляем. B>Люди никогда не создадут ни единого бога, ни единой валюты ни единого аудиовидео-формата, ни всеобщего счастья. B>Забудьте за слово "Единая". Да ещё и теория
Странно. А у дискретной математики получилось. Не сразу, но вышло в итоге и было признано. ))
И даже есть "Единая" теория функциональных систем, на которое ныне всё зиждется в нашей профессии и разделы которой читают прямо в ВУЗ-ах.
Re[3]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, vdimas, Вы писали:
V>Странно. А у дискретной математики получилось. Не сразу, но вышло в итоге и было признано. )) V>И даже есть "Единая" теория функциональных систем, на которое ныне всё зиждется в нашей профессии и разделы которой читают прямо в ВУЗ-ах.
Думаю значение математики сильно преувеличено, наверное самими математиками
В жизни ведь не всё дискретно.
Вы уверены что 1 + 1 = 2? Да, для двух спичек это верно — если сложить одну и одну спички получим две спички, а для двух капель воды это неверно, если сложить две капли воды получим одну каплю воды logic_error
Здравствуйте, vdimas, Вы писали:
V>Странно. А у дискретной математики получилось. Не сразу, но вышло в итоге и было признано. )) V>И даже есть "Единая" теория функциональных систем, на которое ныне всё зиждется в нашей профессии и разделы которой читают прямо в ВУЗ-ах.
Так уж и все?
До сих пор встретить реализацию КА, в которой в процессе разработки/допиливания до рабочего состояния не случилось пары-тройки state explosion, практически невозможно.
Re[7]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, petr_t, Вы писали:
V>>Гораздо обидней, когда собираются спецы, а проект заваливают. _>Видел я и такое. Как правило, когда спецы ударяются в какую-нибудь секту Теорию Разработки. Или оказываются спецами только на словах.
Не на словах. Просто "спецы" могут увлечься, могут проигнорировать составление и следование планам и графикам и т.д.
Re[4]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, landerhigh, Вы писали:
L>До сих пор встретить реализацию КА, в которой в процессе разработки/допиливания до рабочего состояния не случилось пары-тройки state explosion, практически невозможно.
Так это проблема теории или проблема людей, составивших схему неэквивалентного требуемому автомата?
Re[9]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, vdimas, Вы писали:
L>>До сих пор встретить реализацию КА, в которой в процессе разработки/допиливания до рабочего состояния не случилось пары-тройки state explosion, практически невозможно.
V>Так это проблема теории или проблема людей, составивших схему неэквивалентного требуемому автомата?
Говорят, что теория без практики мертва. Тут именно такой случай. Формализация КА через понятия вроде алфавита, функции перехода и прочие <псевдо>научные понятия, вещь хорошая, когда нужно рассматривать парсеры или прочие абстрактные автоматы в вакууме. Только этот шум наливает столько воды, что большинство программистов банально теряют способность увидеть за разрабатываемый ими алгоритмом простой КА. Из простой и очень понятной концепции сделали неизвестно что неизвестно зачем.
Но на деле у инженеров не-программерских специальностей с КА дела обстоят на порядки лучше.
Re[6]: SEMAT – Единая Теория Всего Программирования?
L>Но на деле у инженеров не-программерских специальностей с КА дела обстоят на порядки лучше.
Бред сивой кобылы. Была специальность 2201, сейчас 220100, там с автоматами полный порядок. Более того, только на этой специальности преподают КА на должном уровне. Ни на какой другой специальности такого всеобъемлющего изучения этой дисциплины банально нет по программе.
Re[7]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, vdimas, Вы писали:
L>>Но на деле у инженеров не-программерских специальностей с КА дела обстоят на порядки лучше.
V>Бред сивой кобылы. Была специальность 2201, сейчас 220100, там с автоматами полный порядок. Более того, только на этой специальности преподают КА на должном уровне. Ни на какой другой специальности такого всеобъемлющего изучения этой дисциплины банально нет по программе.
Бред сивой кобылы. Банальным 110301 теорию управления и автоматику преподают так, что с автоматами проблем в принципе нет. Это если не упоминать всяких АСУТП и прочих, где изучают PLC и промавтоматизацию, где КА — это вообще основа всего.
Мои многолетние наблюдения, в том числе и за рубежом, показывают, что тру-программеров, окончивших CS специальность, способных самостоятельно реализовать нечто выходящее за рамки двух состояний, и при этом не наворотить кошмара в коде, практически не существует. Тут тебе и ад в собственно реализации, и state explosion, и превращение КА в генератор, и недостижымые и тупиковые состояния, и чаще всего все это вместе взятое.
Re[8]: SEMAT – Единая Теория Всего Программирования?
Не хочешь поделиться опытом, хотя бы в двух словах. Применяли ли НКА вместо ДКА, например? Или, как в классике, насильно вводили "эквивалентные процессы", то бишь, разбивали автомат на подавтоматы, то бишь, отказывались от конечности автомата, получая почти МТ в итоге? ))
Re[10]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, petr_t, Вы писали:
V>>Просто "спецы" могут увлечься, могут проигнорировать составление и следование планам и графикам и т.д. _>Плох тот спец, у которого планирование работы и инкрементальная разработка не стали привычкой.
ЧТД. Вот тебе база UP.
Сам с собой споришь. ))
Re[9]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, vdimas, Вы писали:
V>Не хочешь поделиться опытом, хотя бы в двух словах.
В реализации КА на мейнстримовых ЯВУ существуют две проблемы. Первая — это собственно нахождение приемлимого подхода к реализации КА с более чем двумя-тремя состояниями. Вторая — собственно в понимании того, что именно есть КА.
V>Применяли ли НКА вместо ДКА, например?
В нашей предметной области (не парсеры, а именно физические автоматы — роботы, исполнительные устройства, разнообразные сервисы и прочий полтергейст) НКА в принципе не должны применяться, но после анализа кода часто оказывалось, что реализован был именно НКА, что являлось ошибкой и причиной трудноуловимых багов.
V>Или, как в классике, насильно вводили "эквивалентные процессы", то бишь, разбивали автомат на подавтоматы, то бишь, отказывались от конечности автомата, получая почти МТ в итоге? ))
Вообще-то разбитие КА на подавтоматы — это один из простых способов его минимизации и избегания State Explosion.
На самом деле проблема тут очень проста. Каждый раз делается одна и та же ошибка — начинают реализовывать автомат, не имея диаграммы состояний (таблицы переходов, алфавита с функцией переходов и т.п., называй как удобно) перед глазами. Сложность реализации КА на ЯВУ ведет к тому, что наличие КА в коде становится крайне неочевидным, а логика его — размазанной по коду. Обычно таблица переходов в коде просто отсутствует. Затем, вследствие отсутствия структуры изначального автомата, при отладке попытке заставить все это работать начинается все вышеописанное — превращение ДКА в НКА, а то и в самовозбуждающийся генератор, и state explosion.
Исправлять проблему state explosion в имеющемся коде, который уже вышел в продакшен — это большой нуегонафиг. Был случай, когда коллега, получивший от другого подразделения некий код, основывающийся на КА, решил выяснить, почему именно дальнейшее расширение и поддержка этого кода застопорились. Написал простой парсер и скормил его plantuml. Получил диаграмму одного автомата с 90 состояниями. И хотя эквивалентные процессы из этой диаграммы стали очевидными, стало понятно, что рефакторинг в данном случае будет синонимом полного переписывания с нуля.
Наличие же поддерживаемой в актуальном состоянии диаграммы стейтов рядом с кодом обычно помогает избежать этих проблем. Фреймворки, в которых таблица переходов существует в коде явно, тоже являются хорошим подспорьем — мы в итоге выработали свой похожий на бустовский FSM подход.
Re[11]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, petr_t, Вы писали:
V>>ЧТД. Вот тебе база UP. V>>Сам с собой споришь. ))
_>Черта с два. Пара простых практических правил, которым надо следовать — совсем не то же самое, что талмуд правил и вагон бюрократии.
Здравствуйте, landerhigh, Вы писали:
V>>Не хочешь поделиться опытом, хотя бы в двух словах. L>В реализации КА на мейнстримовых ЯВУ существуют две проблемы. Первая — это собственно нахождение приемлимого подхода к реализации КА с более чем двумя-тремя состояниями. Вторая — собственно в понимании того, что именно есть КА.
Странно, странно.
V>>Применяли ли НКА вместо ДКА, например?
L>В нашей предметной области (не парсеры, а именно физические автоматы — роботы, исполнительные устройства, разнообразные сервисы и прочий полтергейст) НКА в принципе не должны применяться, но после анализа кода часто оказывалось, что реализован был именно НКА, что являлось ошибкой и причиной трудноуловимых багов.
Ясно. Но жаль, жаль. Если предметная область позволяет явно выделить "промежуточные" состояния от "конечных", то на промежуточных вполне допустима неоднозначность и весь аппарат НКА в полный рост. Да, именно в парсерах это самая мощная на сегодня техника.
V>>Или, как в классике, насильно вводили "эквивалентные процессы", то бишь, разбивали автомат на подавтоматы, то бишь, отказывались от конечности автомата, получая почти МТ в итоге? ))
L>Вообще-то разбитие КА на подавтоматы — это один из простых способов его минимизации и избегания State Explosion.
И способ потери контроля над его детерминированностью. ))
L>На самом деле проблема тут очень проста. Каждый раз делается одна и та же ошибка — начинают реализовывать автомат, не имея диаграммы состояний (таблицы переходов, алфавита с функцией переходов и т.п., называй как удобно) перед глазами.
А, ну это при более 7-ми состояний и более двух десятков переходов — амба, ес-но. Тогда и говорить не о чем. Текстовое описание уже трудноверифицируемое в итоге.
А как представляли КА? Обязательно ли граф переходов, или допустимы регулярные выражения? Например (просто делюсь), в одной из разработок было удобней проектировать ДКА на основе регулярных выражений (не тех, которые regexp в Перле/JS и т.д., а именно класс грамматик). Входным сигналам был назначен алфавит и на основе этого алфавита были введены "пути" для целевых состояний. Удобным получилось то, что в этом случае доступен весь аппарат минимизации целевого КА по состояниям/переходам, а так же по кодированию самих состояний.
L>Сложность реализации КА на ЯВУ ведет к тому, что наличие КА в коде становится крайне неочевидным, а логика его — размазанной по коду.
Это смотря как реализовать. Например, на ЯВУ удобно реализовать более мощный Мили, чем Мура. Как раз ООП-паттерн "State" — это про Мили.
L>Обычно таблица переходов в коде просто отсутствует.
Есть несколько популярных техник реализаций КА в ЯВУ. Таблица переходов, не смотря на удобство кодогенерации, не самая удачная. (Но, фактически, единственный вариант, когда автомат задан прямо в коде в виде исходного НКА, во время старта программы этот НКА преобразуется в ДКА, минимизируется, кодируется и получается в виде таблицы). Хождение "автомата" по таблице переходов — это классика интерпретации, т.е. когда программа выполняет данные. На switch/case + goto получаются до полутора-двух раз более более шустрые автоматы. В этом случае "курсором" состояния является не специально выделенная переменная, а положение указателя команд в автоматной процедуре.
L>Затем, вследствие отсутствия структуры изначального автомата, при отладке попытке заставить все это работать начинается все вышеописанное — превращение ДКА в НКА, а то и в самовозбуждающийся генератор, и state explosion. L>Исправлять проблему state explosion в имеющемся коде, который уже вышел в продакшен — это большой нуегонафиг. Был случай, когда коллега, получивший от другого подразделения некий код, основывающийся на КА, решил выяснить, почему именно дальнейшее расширение и поддержка этого кода застопорились. Написал простой парсер и скормил его plantuml. Получил диаграмму одного автомата с 90 состояниями. И хотя эквивалентные процессы из этой диаграммы стали очевидными, стало понятно, что рефакторинг в данном случае будет синонимом полного переписывания с нуля.
Ну я так и думал, что такое писали околопрограммисты. Профильные специальности гоняют по автоматам последние 3 года обучения.
L>Наличие же поддерживаемой в актуальном состоянии диаграммы стейтов рядом с кодом обычно помогает избежать этих проблем.
Не обязательно UML, порой удобней старый добрый граф переходов, особенно когда нет иерархии состояний или "разрывов".
L>Фреймворки, в которых таблица переходов существует в коде явно, тоже являются хорошим подспорьем — мы в итоге выработали свой похожий на бустовский FSM подход.
Цена такому "фреймворку" — полторы сотни строк темплейтного кода. Например, в одной из реализаций я принял за "курсор" состояния адрес ф-ии, которая вычисляет следующее состояние + текущий выход. Эдакая разновидность паттерна "State", где CurrentState-интерфейс содержал всего одну ф-ию, и вся кухня в итоге выродилась до, собственно, адреса этой ф-ии. Для отладки это оказалось большим бонусом, кста.
Re[11]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, vdimas, Вы писали:
V>Ясно. Но жаль, жаль. Если предметная область позволяет явно выделить "промежуточные" состояния от "конечных", то на промежуточных вполне допустима неоднозначность и весь аппарат НКА в полный рост. Да, именно в парсерах это самая мощная на сегодня техника.
НКА в таких случаях — мина замедленного действия.
L>>Вообще-то разбитие КА на подавтоматы — это один из простых способов его минимизации и избегания State Explosion.
V>И способ потери контроля над его детерминированностью. ))
Вот не согласен, хотя и правда — запутаться проще простого.
L>>На самом деле проблема тут очень проста. Каждый раз делается одна и та же ошибка — начинают реализовывать автомат, не имея диаграммы состояний (таблицы переходов, алфавита с функцией переходов и т.п., называй как удобно) перед глазами.
V>А, ну это при более 7-ми состояний и более двух десятков переходов — амба, ес-но. Тогда и говорить не о чем. Текстовое описание уже трудноверифицируемое в итоге.
Больше трех, на самом деле.
V>А как представляли КА? Обязательно ли граф переходов,
Нужен паттерн State. С явной таблицей переходов.
L>>Сложность реализации КА на ЯВУ ведет к тому, что наличие КА в коде становится крайне неочевидным, а логика его — размазанной по коду. V>Это смотря как реализовать. Например, на ЯВУ удобно реализовать более мощный Мили, чем Мура. Как раз ООП-паттерн "State" — это про Мили.
Паттерн State — штука хорошая, но не решает проблему таблицы переходов.
L>>Обычно таблица переходов в коде просто отсутствует. V>В этом случае "курсором" состояния является не специально выделенная переменная, а положение указателя команд в автоматной процедуре.
можно использовать корутины. Но тут нужно сильно бить себя по рукам, чтобы избежать соблазна затолкать всю логику КА в одну процедуру. Но мы пользуем темплейты, примерно тем же способом, как ты ниже описал — быстрее не бывает.
V>Ну я так и думал, что такое писали околопрограммисты. Профильные специальности гоняют по автоматам последние 3 года обучения.
Вот не угадал. Еще раз, по моим наблюдениям — нормальную реализацию КА с большей вероятностью сделают инженеры не-программерских специальностей.
L>>Наличие же поддерживаемой в актуальном состоянии диаграммы стейтов рядом с кодом обычно помогает избежать этих проблем. V>Не обязательно UML, порой удобней старый добрый граф переходов, особенно когда нет иерархии состояний или "разрывов".
Дело в том, что можно скрестить doxygen с plantuml. Диаграмма состояний описывается прямо в комментариях к коду и попадает в документацию автоматически. Программисты техподдержки долго ссали кипятком по всем направлениям, увидев такое чудо.
L>>Фреймворки, в которых таблица переходов существует в коде явно, тоже являются хорошим подспорьем — мы в итоге выработали свой похожий на бустовский FSM подход. V>Цена такому "фреймворку" — полторы сотни строк темплейтного кода. Например, в одной из реализаций я принял за "курсор" состояния адрес ф-ии, которая вычисляет следующее состояние + текущий выход.
В правильной реализации вычислять следующее состояние в рантайме вообще не требуется — все известно в компайл тайм. Бонусом выступают бесплатные проверки компилятором того, что автор не забыл обработать входной сигнал и машина не содержит дублирующих переходов. Ну а наличие явно определенной в коде таблицы переходов вообще бесценно — моментально вправляет мозги любому ее увидевшему.
V>Эдакая разновидность паттерна "State", где CurrentState-интерфейс содержал всего одну ф-ию, и вся кухня в итоге выродилась до, собственно, адреса этой ф-ии. Для отладки это оказалось большим бонусом, кста.
Адреса этой функции или же адреса объекта, описывающего и обрабатывающего состояние. Я первую реализацию делал для ардуинки, получив оверхед по памяти в один указатель.
А вот отлаживать КА нам после внедрения юнит-тестирования и шаблонного фреймворка больше не пришлось ни разу.
Здравствуйте, landerhigh, Вы писали:
V>>А как представляли КА? Обязательно ли граф переходов, L>Нужен паттерн State. С явной таблицей переходов.
Спорно насчет "нужен". Если у тебя автомат Мура, то интерфейс CurentState будет пуст.
Далее, чем мне зачастую не нравится State. Дело в том, State удобен только для реализации той части функциональности автомата Мили, когда текущий выход автомата зависит от текущего состояния. В этом случае ф-ии интерфейса CurrentState являются теми самыми функциональными преобразователями входных сигналов в выходные, зависимые от состояния. Пока что всё ОК. Но беда в том, что программисты зачастую помещают логику вычисления следующего состояния в этот же CurrentState, в итоге в одном методе получается мешанина из двух независимых функций: функции текущего "поведения" и ф-ии вычисления следующего состояния.
L>>>Сложность реализации КА на ЯВУ ведет к тому, что наличие КА в коде становится крайне неочевидным, а логика его — размазанной по коду. V>>Это смотря как реализовать. Например, на ЯВУ удобно реализовать более мощный Мили, чем Мура. Как раз ООП-паттерн "State" — это про Мили.
L>Паттерн State — штука хорошая, но не решает проблему таблицы переходов.
Не обязательно переходы должны быть в виде явной таблицы. Раздели State на два состояния: первое пусть отвечает за "поведение", второе — за следующее состояние. Для их связки тебе надо будет создать некий транспорт — искусственные сигналы (в некоей кодировке), которые вырабатывает первый State для второго, т.е. кодирует некий "алфавит" сводя разнотиповые "внешние сигналы" к одному типу-коду из "алфавита". В этом случае становится возможным отдельно тестировать тот State, который отвечает за поведение и отдельно, отвечающий за переходы. Эта конструкция имеет право на жизнь при сильно разреженной таблице переходов, т.е. когда от каждого состояния в среднем оч мало переходов в следующие.
L>можно использовать корутины. Но тут нужно сильно бить себя по рукам, чтобы избежать соблазна затолкать всю логику КА в одну процедуру.
В случае корутин — да запросто. Опять же, техника корутин оправдана только при push распространении воздействий (обработка событий, например), в этом случае никакой паттерн State не нужен.
V>>Ну я так и думал, что такое писали околопрограммисты. Профильные специальности гоняют по автоматам последние 3 года обучения. L>Вот не угадал. Еще раз, по моим наблюдениям — нормальную реализацию КА с большей вероятностью сделают инженеры не-программерских специальностей.
Ну знач разные наблюдения.
L>>>Наличие же поддерживаемой в актуальном состоянии диаграммы стейтов рядом с кодом обычно помогает избежать этих проблем. V>>Не обязательно UML, порой удобней старый добрый граф переходов, особенно когда нет иерархии состояний или "разрывов".
L>Дело в том, что можно скрестить doxygen с plantuml. Диаграмма состояний описывается прямо в комментариях к коду и попадает в документацию автоматически. Программисты техподдержки долго ссали кипятком по всем направлениям, увидев такое чудо.
Спасибо за наводку.
Re[13]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, vdimas, Вы писали:
V>Спорно насчет "нужен". Если у тебя автомат Мура, то интерфейс CurentState будет пуст.
Паттерн State вообще имеет очень опосредованное отношение к КА. Он просто отображает состояние некоей сущности. У нас, например, поведение некоего мощного объекта зависит от его текущего состояния.
V>Но беда в том, что программисты зачастую помещают логику вычисления следующего состояния в этот же CurrentState, в итоге в одном методе получается мешанина из двух независимых функций: функции текущего "поведения" и ф-ии вычисления следующего состояния.
Эта "беда" фиксится довольно просто — CurrentState просто не имеет возможности вычислить и установить следующее состояние (интерфейс не позволяет), но может подать входной сигнал.
L>>>>Сложность реализации КА на ЯВУ ведет к тому, что наличие КА в коде становится крайне неочевидным, а логика его — размазанной по коду. V>>>Это смотря как реализовать. Например, на ЯВУ удобно реализовать более мощный Мили, чем Мура. Как раз ООП-паттерн "State" — это про Мили.
L>>Паттерн State — штука хорошая, но не решает проблему таблицы переходов.
L>>можно использовать корутины. Но тут нужно сильно бить себя по рукам, чтобы избежать соблазна затолкать всю логику КА в одну процедуру. V>В случае корутин — да запросто. Опять же, техника корутин оправдана только при push распространении воздействий (обработка событий, например), в этом случае никакой паттерн State не нужен.
Согласен.
L>>Вот не угадал. Еще раз, по моим наблюдениям — нормальную реализацию КА с большей вероятностью сделают инженеры не-программерских специальностей.
V>Ну знач разные наблюдения.
У меня подозрение, что профильных программистов настолько закормили парсерами и формальными автоматами, что они банально за деревьями леса не видят.
Re[4]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, beyv, Вы писали:
... B>Вы уверены что 1 + 1 = 2? Да, для двух спичек это верно — если сложить одну и одну спички получим две спички, а для двух капель воды это неверно, если сложить две капли воды получим одну каплю воды logic_error
Не в математике проблема, а в том, что кто-то не думаючи перегрузил оператор сложения для капель воды. Тут нужно использовать оператор "слияние".
Re[13]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, vdimas, Вы писали:
V>Я не могу комментировать чьи-то мечты. Описанная тобой ситуация ни разу не новость. Гораздо обидней, когда собираются спецы, а проект заваливают. Подсказка сработала или опять мимо?))
Само существование этого сайта как бы намекаэ, что не все так печально, не?
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, craft-brother, Вы писали:
CB>А что-то про SEMAT тут никто еще не написал? Исправляем.
Можно я тут чутка пофлужу? Проскроллил пост по диагонали и вспомнил, что бы когда-то такой прекрасный сайт, назывался пиши-код-[beep].рф (к сожалению, на территории .РФ его давно заблокировали и с тех пор домен протух). Ну, по крайней мере англоязычный вариант сохранился.
Re[9]: SEMAT – Единая Теория Всего Программирования?
V>Дык, "заваленный проект" — это не потому, что люди оказались в принципе неспособны его сделать (такого практически не бывает), а потому что не вложились в сроки/деньги. А так-то любой проект, при желании, можно довести до ума. Особенно дотационный какой-нить, опен-сорс или как этот сайт — интересу ради.
Угу, вообще технически сложных задач не бывает. Бывает недостаток времени и отсутствие воли.
CB>А что-то про SEMAT тут никто еще не написал? Исправляем. >Единая Теория Всего Программирования
Это не теория программирования, это теория управления процессом проектирования
программирования. или, если просто, то проектный менеджмент.
ошибка перевода. software engineering — общий процесс, программирование только одна фаза этого процесса. >Within software engineering, programming (the implementation) is regarded as one phase in a software development process. http://en.wikipedia.org/wiki/Computer_programming
так что для программирования нужно что-то более мелкое по охвату (но не мелко-мягкое )) ).
Если нам не помогут, то мы тоже никого не пощадим.
Я наблюдал и каноничнейший сертифицированный RUP, рассыпавшийся именно из-за следования процессам, и самоорганизацию из бардака в процессы, вполне укладывающиеся в CMMI3. Единственная корреляция — уровень адекватности принимающего решения. Т.е. тот самый человеческий фактор.
