Comments 17
Очень плохая практика — жестко привязывать код к конкретной реализации
Очень спорное утверждение. Наоборот, народ уже наелся слоями абстракции и сразу пишут под конкретный Postgresql или под конкретного облачного провайдера.
Уходят от тяжёлых ORM и переходят на легковесные мэпперы, а IDEA поддерживает sql в коде.
Оригинальный пост 2012 года, ну вы чего. Ладно дубликат, но какая актуальность может быть 8 лет спустя?
Компании нанимают Full Stack — потому что не хотят голову включать и думать, как пасти группу независимых котов-экспертов. А гипотетический Full Stack всегда не уверен в глубине своих знаний, всегда готов вписаться в любую задачу, желая положительного отзыва для ежегодного повышения и бонусов, идеальный сотрудник для галеры, в которой не производящий персонал ищет любые способы доказать друг другу свою незаменимость и нужность. Вчера Full Stack включает стек технологий от фронтенда до деплоя. Сегодня он умеет общаться с клиентом, и понимает задачи бизнеса, завтра — бухгалтерию и юридические бумаги тоже он ведёт. А менеджмент молодец, он проекты управляет, продукты релизит, повышения отмечает.
Хороший специалист знает свой уровень абстракции на экспертном уровне, и хорошо понимает уровни по соседству. Что там дальше — забота других профессионалов, делающих свою работу, а не человека-оркестра.
Да fullstack разработчик может сносно выполнять работу группы независимых котов-экспертов. При том что по глубине знаний в отдельной области проигрывает эксперту. Но приложения работают, релизы релизяться.
А менеджмент молодец, он проекты управляет, продукты релизит, повышения отмечает.
Вот только fullstack разработчики требуют оклад который сопоставим с группой специалистов. Так как прекрасно понимают что они выполняют работу нескольких специалистов.
В некоторых случаях они работают быстрее группы специалистов так как не тратят время на согласование и конфликты, но однозначно проигрывают крепко спаянной группе где каждый делает свою работу на отлично.
Вот только такой подход работает только на простых и средних проектов. Крупные и сложные системы требуют производительности и объема работы которую не способен дать один человек или способен — но за время которое не актуально для компании.
Сам fullstack и самый ложный проект который делал — содержал TDD, DDD, SQL, NoSql, RabbitMq, BPMN, JsonRPC, WSDL (SOAP), REST, OAuth2.0, React, MobX, GraphQl, Sass, Laravel и еще 8+ интеграций с внешними сервисами.
Потом к этому проекту еще добавилось Vue2, NuxtJs (NodeJs), ExpressJs, SSR.
И все это в одной системе которую пилил пол года. В то время как группа из 5-6 крепких разработчиков сделала бы все за 2-3 месяца а может бы и уложилась в 1 месяца.
Однако компания решила что лучше платить одному человек 3 оклада и обождать, чем искать на рыночный оклад еще 5 человек, потом вводить их в курс дела, управлять отделом, решать конфликты между ними и оформлять документы на 5 человек.
самый сложный проект который делал
RDD (resume driven development) он не содержал?
UPD, а вижу Ваш комментарий в другом топике:
Да было программирование ради программирования как на фронте (React + MobxStateTree + Graphql) так и на бэке (TDD, DDD, Layers, Queues, Chanels and Filters).
Внезапно содержал.
Вообще все технологии которые человек осваивает, все проекты который человек реализует это плюс в первую очередь к его опыту и уже во вторую соответственно к резюме, причем не важно в какой сфере.
Были ли технологи среди этого списка которые я не использовал в production — да это был GraphQl до этого использовал его в одном pet проекте. И да он сократил мне пару недель работы.
Использовал ли я все технологии из списка в одном проекте до этого — тоже нет.
Плохо ли для компании то, что в работе человек пытается использовать технологии которые не использовали раньше в этой компании?
Зависит от результатов — а результаты в том же сообщении из которого цитата.
SQL — нужно ли для проекта если он хранит данные?
NoSql — нужно ли если в sql можно реализовать хранение одной сущности но она во второй нормальной форме будет размазана на 5 таблиц а в 3-й на 8 таблиц и таких их 5 штук и по ним будут выгружаться отчеты?
RabbitMq — нужен ли если результаты обработки данных и важные события необходимо предоставлять параллельно и другим системам и после уже из этих систем собирать данные и события и все это асинхронно?
Нужен ли React/Vue + (Mobx/Vuex) если есть страницы которые сильно зависят от пользовательского ввода и меняются на лету в зависимости от того какие данные вводит клиент и разбить ввод и валидацию данных на шаги?
Хотя… — можно просто разом вывалить на него все 15 обязательных и 35 необязательных полей которые зависят от 15. А если вариантов таких станиц более 10?
Нужен ли JsonRPC/WSDL(SOAP)/REST/OAuth2.0 если у нескольких партнеров зоопарк систем и каждый принимает данные только по своему специфичному протоколу?
Нужен ли DDD если приложение состоит их 2-3 предметных областей, 5 агрегатов у каждого из которых 3-5 типов атрибутов? Нужен ли BPMN если над этими агрегатами есть 4 стратегии в каждой из которых от 3 до 15 бизнес процессов которые еще и меняются регулярно?
Готов ли человек отвечать за такого объема систему и оперативно вносить в нее изменения?
Нужен ли TDD и спокойный сон или подход "#$&^! #$&^! и в production" а после "и так сойдет?" а после 48 часов без сна в погоне за плавающим багом?
React/Vue — ну вот к этому я и хотел придраться (как и к JsonRPC/WSDL(SOAP), но причина уважительная), два инструмента для одной задачи.
BPMN — хм, и как оно себя показало? Просто реквайрментов не хватало?
«Нужен ли TDD и спокойный сон или подход „#$&^! #$&^! и в production“ а после „и так сойдет?“ а после 48 часов без сна в погоне за плавающим багом?»
От плавающего бага TDD не спасет. Ну это вообще тема для холивара по типу: «TDD не нужно, интеграционных навалили и норм»
«Готов ли человек отвечать за такого объема систему и оперативно вносить в нее изменения?»
Непонятно какого, это все можно и в хелов ворлд напихать. Я так понимаю разговр о том полугодовом проекте. Ну в общем — а почему бы и нет? Но желательно хотя бы втроем — хороший менеджер-аналитик и 2 дева «шоб не скучать и конкурировать».
Производительность была критична, так что то что хорошо ложиться на реляционную базу — лежит в ней, что не ложиться — то в nosql.
BPMN хорошо себя показало — была полная диаграмма процессов всего проекта, правда размер диаграммы титанический, если распечатывать — то только на ватман в пол-стены. За то все заинтересованные в проекте могли в любое время узнать что и как и зачем работает. Плюс к каждой задаче была своя диаграмма которая указывала какие шаги какого процесса меняем. Без этого никто вообще бы не понял что меняем и где.
TDD не спасло только от одного бага — как раз с graphQl. Схема генерировалась на все объекты что называется на лету, для каждого запроса интроспекцией по всем трем базам данных. Естественно при нагрузке генератор схемы начал лагать что привело в тормозам в 1-2 секунде на фронте при каждом запросе но только когда выгружали отчеты — в итоге сделали кэш схемы который сбрасывали только при миграции.
Что касается людей — то когда проект начал приносить доход то через 3 месяца уже наняли полноценную команду — (2 backend, 1 frontend).
Как раз frontend и предложил заменить react на vue. Так как react не прост в отличии от vue — по скольку ему сапортить проект — то почему бы и нет? Тем более что заняло это 2 недели и руководство было не против посмотреть на нового человека в деле — и да вышло не плохо.
После мне старые друзья предложили вкусный оффер, я сообщил компании что собираюсь уходить — на мое место взяли спеца, до обучил команду (благо документация по проекту есть) BPMN + спецификация на каждый домен и сабдомен. После того как команда начала тянуть проект я со спокойной совестью ушел.
После узнал что проект жив и активно развивается — его домены распилили на микросервисы и горизонтально масштабируют. Все в принципе довольны и счастливы.
«развивается — его домены распилили на микросервисы и горизонтально масштабируют»
Ну хорошо, что хоть не сразу макросервисы, «monolith first» как грица.
Для чего и кому? Как я понял это «UML на минималках» (и это хорошо). Подходит ли он для описания архитектуры приложения? Немного погуглил, и большинство кейсов не связаны с архитектурой.
Как я себе это вижу в идеале (который вряд ли осуществим) — на верхнем уровне бизнесс процессы с «sub process» -ами для менеджеров и т.д., но каждый «sub process» можно развернуть и уже попасть на уровень, допустим доменов, а еще ниже уже внутридоменные детали. Что бы посоветовали?
Инструменты выжны, редакторы там и тд, чеи пользовались?
Сам BPMN хорош для того чтобы конкретный кейс менеджер смог представить у себя в голове и посмотреть в любое время.
Cамый простой аналог — схема на салфетке. Только тут она в цифровом виде и по правилам. Сразу отсекает задачи с нечетким ТЗ или конфликтом логики.
Текстом-то можно что угодно написать — хоть "7 красных перпендикулярных линий". Но визуально сразу видно где и что конфликтует.
Для Lead удобно в плане понимания того что хотят от него и в каком виде, да и декомпозицию проводить проще, плюс можно для себя пометить какие участки процесса кто из команды делает.
Для исполнителя тоже все понятно — вот схема и вот эти три квадрата мои, первый средний до среды, второй простой до пятницы а с последним нужно недельку провозиться, либо разбить его на более мелкие этапы. Квадраты с права и слева от меня Васи и Пети — нужно обсудить с ними интерфейсы и форматы данных.
Сами используем Camunda Modeller — сам по себе он прост, вложенность там можно реализовать но только самую примитивную. Не так давно они даже движок сделали который может эти схемы запускать (каждый процесс вызывается через api), но на production такое однозначно не пойдет.
Говорят еще существует некий RationalRose — но его не пробовал даже.
В идеале есть идея создать свой вариант, где все процессы сперва рисуются в виде схемы но под капотом — обычных JSON объекты, после чего схема скармливается генератору который автоматом создает цепочку команд на том или ином языке — остается только набить их кодом, в идеале еще добавить с документацией в общий каталог — чтоб в следующий раз не писать велосипед а взять уже готовое решение.
Перевод: Кто такой Full Stack разработчик?