Ну и как мысль - если эта визуальная инструкция будет на столько подробной, что её можно будет однозначно перенести в код, то зачем вообще рабочий сервис руками писать?
Затем, что все свои ошибки ты допустишь на ней и не придётся потом рефакторить возможное говно, которое можно заметить на uml.
Это первое.
Второе - uml не привязывается к языку - соответственно если что-то не устроит в проде на текущем стеке, его можно супер быстро переписать на что угодно.
В третьих - никакого кода, для понимания работы сервиса. Быстрое введение новичков в курс дела. Изучить синтаксис uml можно за пару вечеров, а вот стек проекта - нет.
Генераторы статики - это говно, ты прав.
Это доказали ещё в 2010 или когда там ucoz, wix и прочие платформы для мамкиных пиратов нарисовались.
Я не говорю о том, что тебе нужно чуть-ли не работу функции описать.
Здесь скорее i/o интерфейсы, а уже как ты там это кодировать будешь и на чём - роли не играет.
Условно функция А принимает аргумент Б и возвращает данные типа В.
Так тоже много букав. Классовая диаграмма не только классы содержит, интерфейсы у меня конкретно в этой. Одни интерфейсы: interface A { participantsReaders: string[] }
Хочется отдельный тип максимально короткого формата, то есть вынести string[] + указание что это json допустим в кастомный тип jsonArray и получить вот такое:
Потому-что это противоречит масштабированию команды, это ведь всё возможно будет поддерживаться уже не мной.
Да и это хорошая практика, целиться в понимание твоей работы, человеком как минимум соответствующего твоей квалификации.
В портфель кинуть не стыдно.
Я ещё убрал борщ где разжовывал всё до примеров запросов на определённом языке.
Потом посчитал бредом, т.к. это формат документации, а не uml и почистил всё.
Если я буду делать как мне удобнее сейчас, что будет если это удобнее изменится через неделю? - переписывать, а мне лень :)
Я скрупулёзно всё делаю, иногда трудно удержатся от излишних деталей.
Мне человек сказал что ещё немного и я в 3d этот uml буду делать)
Затем, что все свои ошибки ты допустишь на ней и не придётся потом рефакторить возможное говно, которое можно заметить на uml.
Это первое.
Второе - uml не привязывается к языку - соответственно если что-то не устроит в проде на текущем стеке, его можно супер быстро переписать на что угодно.
В третьих - никакого кода, для понимания работы сервиса. Быстрое введение новичков в курс дела. Изучить синтаксис uml можно за пару вечеров, а вот стек проекта - нет.
Генераторы статики - это говно, ты прав.
Это доказали ещё в 2010 или когда там ucoz, wix и прочие платформы для мамкиных пиратов нарисовались.
Я не говорю о том, что тебе нужно чуть-ли не работу функции описать.
Здесь скорее i/o интерфейсы, а уже как ты там это кодировать будешь и на чём - роли не играет.
Условно функция А принимает аргумент Б и возвращает данные типа В.