сеньор поставил мне ультиматум

Блочная схема хороша для описания state machine. Для прочих случаев ее удобство не столь очевидно

Шо, JS-кодер небось?

Действительно. Позволь вопрос, что за язык? Хотя, в той же вебне это тоже вполне распространённая практика… Нет, ну всё же? И вообще, такое нужно указывать в тегах.

И раз уж ты тут откровенничаешь, ещё вопрос, самому не стыдно?

А код - сам по себе схема. И прочитать его всё равно проще, чем эту вермишель из стрелок.

Следует правильно выбрать уровень абстракции, чтобы не вермишелить и уместиться в 1 лист A3/A4 с запасом.

Рисовать схему перед писанием кода - всё равно что положить еду в тарелку и ходить вокруг неё, прежде чем садиться есть.

Видимо, не встречалось сложных объектов, требующих соответствующего подхода.

tikz хорош гибкостью. В tikz/pgf даже графики можно строить (правда, если графиков в тексте дофига, то лучше таки их отдельно нагнуплотить, иначе скорость компиляции текста будет совсем никакущей)!

Это был наброс.

Я сам в топике примерно ответил на вопрос.

А тут мне начали предлагать инструменты, а не процессы.

Что в общем не удивительно для Росси по немецки постановка задачи звучит так:

Für Service muss Ablaufpläne erstellt werden. Es müssen alle Prozesse abgedeckt werden.

Я думал что здесь

В общем-то, я так и подумал, слишком толсто выглядит. Ну ладно.

Но, кроме шуток, разве есть что-то кошернее и очевиднее UML?

вот и выросло поколение... жобэ прав

Причём здесь УМЛ?

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

А теперь читаем умные книги про то, что УМЛ - не нужно. Серьёзно.

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

Т.е. мне даже не расскажут, почему? Нет, спасибо, у меня пока есть своя голова.

Ссылки на умные книжки в студию! Вангую, правда, авторов уровня Фленова, но вдруг...

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

Одной считалке (после двухгодичного "забивания" я опять к ней вернулся, т.к. надо дописать) я вообще алгоритм разрисовал на целую 48-листовую тетрадь! И где-то лажанул, в результате считает хрень какую-то.

авторов уровня Фленова

Погуглил, кто это. Нашел "Linux глазами хакера". Да, я это говно когда-то даже покупал. Пролистал несколько страниц, порвал и выкинул в мусорку! Это полная жесть!

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

Ты на похожие темы внизу странички посмотри - первые две данный товарищ создал - судя по всему таки да, веб, но скорее всего backend, а не frontend. Эх, что-то стыдно мне за коллегу стало.

Погуглил, что такое REST. Ну и нафиг людей пугать? Писал бы "клиент-серверный"...

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

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

Я это на информатике проходил еще когда в школе учился. Сложного ничего нет, если тебя в гугле не забанили.

А давайте erzent позовем?

Ну, в веб-деве может оно и не надо. Вряд ли там кому-то приходилось вручную сортировать — для этого БД есть.

зачем мне нужно знать, как работает неэффективный алгоритм, если есть почти у каждого объекта Array метод sort?

вот и выросло поколение, которое не знает, что такое REST.

А когда то ведь был WCF, да

Мартин. Мартин. Принципы, паттерны и методики гибкой разработки на языке C#. От создателя «Чистого кода». Издательство Питер. 2012 год. Страница 224. Ну и еще где-то в тексте.

Продавалась на books.ru за 1 рубь. Но тебе и таких денег ради самообразования жалко, правда?

Я уже кучу всяких веб-морд наклепал: раньше сишные CGI в бэкенде были, теперь на модные вебсокеты перешел. Но никогда не думал, что это REST называется...

а теперь прочитай еще раз (внимательно) текст поста.

У меня уже есть написанный, протестированный и документированный (т.е все endpoints описаны) продукт.

Зачем мне нужны UML, диаграммы классов и последовательностей? Что это даст ПОЛьЗОВАТЕЛЮ Rest сервиса?

я пробовал создавать UML схемы. Потом перестал. Мартин 100 раз прав. Отсутствие нормальных инструментов для рисования UML-лек как бэ намекает.

Специалист не должен знать как, он должен знать где.

я тут специально для верующих в алгоримты написал постец

plantuml - куда уж нормальнее инструмент

и внимание вопрос! ни один «профессиональный программист» ни разу за пост не смог выразить идею о том, что Message Sequence Chart/Sequence diagram лучше подходит для сабжа.

Давайте обсудим это, господа высокооплачиваемые специалисты?

Вот ты пришел сюда, признался в своем непрофессионализме. Молодец. Дальше что?

Это буллшит деточка, специалист может нарисовать _документацию_ из коробков спичек, а хипсер будет всем доказывать что «это не тот тип диаграмм и не та методология и вот у меня удостоверение д'Артаньян блаженный есть!»

ты знал! ты знал! ты знал!

Там по твоей же ссылке в первом же комменте написано, почему оно не подходит для описания workflow.

Алсо, диаграмма процесса != блок-схема алгоритма.

Диаграмма общего воркфлоу системы люто помогает это потом внедрять, а периодически и понимать, как оно внутри должно работать.

Вот у нас есть, например, сервис общей авторизации для сайтов в виде апишечки, плюющейся json и некоего подобия OAuth. Без диаграммы процесса авторизации/регистрации/etc. меня бы пых-кодеры попросту задолбали вопросами «а чо нам делать» и код бы им не помог вообще никак.

oauth тоже можно на call seq диаграмме изобразить (да это может быть длинее), все зависит от поставленной задачи

Краткое содержание собеседования:

- C# знаешь? (Гордо) Знаю!

- Node.js знаешь? Нифига.

- Готов изучать? Ну типа да.

- Oracle знаешь? Нифига.

- Готов изучать? Ну типа да?

- MySQL знаешь? Ну типа да, но давно не применял.

- Паттерны какие знаешь? Ну типа синглтон.

- А еще? A.. ну.. это.. а вспомнил - MVC!

- ОК, но большинство проектов у тебя будет на ноде. Готов?

- Ну да.

- Тогда мы делаем с вами трудовой договор. Запрашиваемая вами зарплата - с этим все в порядке.

Может лучше обсудим то, как ты очередной раз не умеешь в примитивную терминологию и путаешь сервис с интерфейсом?

я это (пытался использовать just for test) для документирования одного Endpoint-а.

что ты понимаешь под словом интерфейс? У него куча значений.

Длиннее и менее удобно. Впрочем, никто не мешает совместить.
У нас диаграмма еще всяческие интерфейсные вещи содержит, не смотря на это она весьма маленькая и понятная. А по самим методам апи отдельная дока есть, где уже каждый подробно расписан.

Для документирования эндпоинтов это ок. Но в топике у тебя немного другое написано.

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

я это знаю

Не обязательно знать алгоритмы сортировки массива, но уметь написать свой - обязательно. Конечно если ты хочешь уметь что-то, кроме как брать данные с БД и выводить их на страничку, а потом брать данные у пользователя и ложить их в БД.

это же 99% работы любого ынтырпрайс офисного хомячка.

Зы. А ну да, нужно бухгалтерию предметную область знать.

уметь написать свой - обязательно

это из серии «придумайте свое док-во теоремы Пифагора»?

согласен

а если ты хочешь спроектировать архитектуру сложнее трехзвенки с макаронами?