Ага, на месяц, после чего нужные люди бы просто подали нужные жалобы на приложение в чем-то может быть даже справедливые.
Те кто размещает приложение (googlePlay, appstore) отправили письмо роботом с просьбой исправить баги а после бы залочили приложение так как править баги не кому.
Судя по всему искусственную сложность которую решало приложение устранило — переполошило спекулянтов (билетных агентов) которые поняли что если так и дальше пойдет — то они лишаться кормушки. Кормушку же организовала сама компания для "своих" людей которые и есть эти билетные агенты.
В итоге заплатили или подмазали кого нужно с ожидаемым результатом. Парню повезло что пришли вежливые офицеры которые вежливо проводили человека в суд где вежливо повесили на него ярмо и это в Индии.
Вы неправильно трактуете степень технической глубины, на котором следует общаться с бизнесом.
Бизнес разный бывает, просто я уже давно работаю в сфере где сам it проект — и есть продукт, что в основном руководство вполне понимает технические термины а если не понимает то есть CTO / ProjectManager / ProductOwner который может популярно перевести все это в понятный формат даже для 6-и летнего ребенка.
Для других сфер работает только момент с доверием — либо доверяют и выдают что нужно, когда нужно в необходимых объемах, при этом пока все это укладываются в бюджет на it и все что требуется работает сами не лезут.
Либо не доверяют и постоянно пытаются все "оптимизировать", провести аудит, вести новую %random methodology% управления и/или сертификации. Приглашают различных инфоциган которые в лучшем случае проведут никому не нужную лекцию о "выходе из зона комфорта" а в худшем уже расписали план внедрения, ликвидации текущей it команды и перевода it сектора компании на аутсорс с vendor lock и после продавливания к ногтю директора и высасывания всех активов компании.
Кстати именно в таких компаниях где it не основной продукт и отделу доверяют — работа вообще сказка, особенно если правильно настроить коммуникацию и процессы. Сроки по сравнению с продуктовыми кажутся смешными, переработки — только в случае ЧП и и своих собственных кривых рук. Ограничений на творчество кроме тех что коллективно приняты в отделе — нет. Единственные минусы это более низкий оклад, отсутствие бенефитов которые не особо и нужны, сложность в наращивании бюджета что важно если бизнес вырос а команда it нет, и опасность разлениться и не развиваться. Если же активно работать над собой и кодом — то можно очень сильно прокачиваться и в технологиях и soft skills.
С одной стороны вы определенно правы про техническию мотивацию — да правильно собрать все проблемы, перестроить архитектуру, вести стандарты оформления кода, тесты, спецификацию.
Вот только бизнесу это не нужно. Бизнесу нужна фича X желательно вчера.
На штатный рефакторинг времени бизнес не даст, а если и даст то не на постоянной основе а после опять кранчи с выпустить фичу вчера.
В итоге вы можете помимо и так авральной нагрузки еще и добровольно в не оплачиваемое время чисто из принципа рефакторить код после работы и спасибо вам за это не скажут, мало того еще и многие будут сопротивляться.
Либо запустить проект до уровня когда рефактиринг не поможет и останется только переписать проект с нуля.
В итоге остается либо попытаться объяснить бизнесу почему качество важно, какие проблемы у нас есть и как их решать и постоянного собирать метрики и еще каждый раз доказывать как и почему качество проекта приносит прибыль и лучше это сделать на ранних этапах проекта.
Либо понять что вам не по пути с этой компанией — если в мелочах вроде того как вам писать код вы не договорись то в случае кранча или любых других проблем все это вылезет в очень неприятные последствия как для компании так и для вас.
Если проект "малоприбыльный" — то нужно его либо превратить в прибыльный. Если проблема в качестве продукта — тогда рефакторинг и поможет. Если проблема в известности то поможет маркетинг а не +100500 новых фич. Если не достаточно фич — значит хромает реализация и стоит начать вторую версию. Либо возможно сама идея мертва не мучить труп и похоронить его.
Если проект "краткий по времени эксплуатации" то лучше сразу сделать его качественным по максимуму, так как нет ничего более постоянного, чем временное.
Если же проект MVP то не нужно после запуска продолжать его пилить как обычный проект а стоит сразу начать с нуля при первом получении прибыли а MVP сжечь как это и было изначально заложено в его природе.
Например мой учитель — занимался разработкой селе-предупреждающий системой еще при СССР и до сих пор ходит в горы и меняет для датчиков батареи этой системы.
Еще один знакомый занимается обслуживанием оборудования аэропорта.
Пара знакомых создают и продают iot устройства для рекламных стендов.
Еще один занимался по для управления поездами.
Еще пара знакомых занимаются BigData и аналитикой.
Да даже старший брат и тот пере-прошивает чипы для авто в своем СТО
Если вам внутри кода не удобно — это первый звоночек что нужно все переписать, не важно под каким предлогом вы продадите это бизнесу. Так как именно от этого удобства зависит напрямую мотивация.
Для менеджера — представьте что проект это офисное кресло, проект с костылями, магией это офисное кресло где оставили крестовину и газлифт и так как времени нет — пиастру и сиденье заменили на седушку от велосипеда.
Да оно выполняет свои функции, да на нем можно сидеть, но вот после постоянного его использования каждый день по 8 а иногда и по 14 часов в день в течении года у вас извиняюсь начнет "гореть" седалище.
В какой-то степени понимаю автора, сам заканчивал сперва колледж а потом и ВУЗ где была алгебралогики, теория множеств, теория конечных автоматов, матстат, функциональный анализ.
Были лабы на паскале с дихотомией, операциями над матрицами, построением фигур на основе функций и потом подсчета объема фигурой через интегралы, списками, графами и деревьями. Что-то из этого освоил на отлично, а что-то до сих пор не смог освоить.
Запомнился декану кафердры тем что каждую лабу сдавал на новом неожиданном языке и окончательно выбесил сдав программы на brainfuck и whitespace.
В тоже время сам проходил и иногда до сих пор прохожу курсы по технологии X, смотрел и смотрю видеоуроки по технологии Y, прочитал +100500 статей на хабре когда он был еще торт, а даже написал пару своих которые не вышли из песочницы. Контрибьютил в opensource проект по почте (когда еще не было github). Проходил коучинг на управление командой.
С одной стороны бизнесу достаточно вайтишников которые могут из готовых +100500 бибилиотек в node_modules в том числе и для создания n пробелов для отступов в консоли собрать нечто как-то работающее и даже приносящее деньги. А чтобы эти вайтишники дальше веслали активнее давать им лычки SuperMegaUltraFinalSeniorLead%TechName%Developer.
С другой стороны самое сложное что использовал в работе — конечные автоматы в хитром xml парсере, оценочная формула байеса в умном рейтинге и кое-что из статистики в вероятностном скоринге и фановая анимация на js + svg состоящая из кучи формул.
Остальная работа же на уровне — по нажатию кнопочки взять строку в базе и поменять ей статус при этом добавить еще 3 записи в другие таблицы и положить сообщение в rabbit. В общем сплошные CRUD, CRUD, CRUD и еще раз CRUD...
В итоге для rocket science мозгами не вышел, а текущая работа больше для того чтобы поддерживать комфортный уровень жизни — монотонная до серости, но хорошо оплачиваемая.
При всем этом как-то обидно смотреть на настоящих "инженеров — программистов" которым когда-то хотел стать но не хватило зубов, и понимать что они не нужны а если и нужны то 5-10 штук достаточно для моего города. А нужны люди которые быстро выполняют задачу из готового кода мешая все подряд и при этом не знают как написать fizzbuzz...
Сам BPMN хорош для того чтобы конкретный кейс менеджер смог представить у себя в голове и посмотреть в любое время.
Cамый простой аналог — схема на салфетке. Только тут она в цифровом виде и по правилам. Сразу отсекает задачи с нечетким ТЗ или конфликтом логики.
Текстом-то можно что угодно написать — хоть "7 красных перпендикулярных линий". Но визуально сразу видно где и что конфликтует.
Для Lead удобно в плане понимания того что хотят от него и в каком виде, да и декомпозицию проводить проще, плюс можно для себя пометить какие участки процесса кто из команды делает.
Для исполнителя тоже все понятно — вот схема и вот эти три квадрата мои, первый средний до среды, второй простой до пятницы а с последним нужно недельку провозиться, либо разбить его на более мелкие этапы. Квадраты с права и слева от меня Васи и Пети — нужно обсудить с ними интерфейсы и форматы данных.
Сами используем Camunda Modeller — сам по себе он прост, вложенность там можно реализовать но только самую примитивную. Не так давно они даже движок сделали который может эти схемы запускать (каждый процесс вызывается через api), но на production такое однозначно не пойдет.
Говорят еще существует некий RationalRose — но его не пробовал даже.
В идеале есть идея создать свой вариант, где все процессы сперва рисуются в виде схемы но под капотом — обычных JSON объекты, после чего схема скармливается генератору который автоматом создает цепочку команд на том или ином языке — остается только набить их кодом, в идеале еще добавить с документацией в общий каталог — чтоб в следующий раз не писать велосипед а взять уже готовое решение.
Все верно, единственно начинать рекомендую не с React а с Vue. И после него уже переходить на React.
Плюс уже на уровне изучение Vue + Vuex можно начать зарабатывать на хлеб с маслом и постепенно переходить на React и MobX. Как разобрались с MobX можно уже покуситься на Redux + Redux Thunk + Reselect. Если и их освоили — то можно уже начинать изучать GraphQl.
После того как Graphql сдастся — изучить Next/Nuxt + express + passport.js + sequilize + SQL + NoSql + Pm2 и стать уже full stack.
Либо как вариант уйти в firebase + ReactNative и пилить простенькие приложения на мобилу после чего уходить в Java/Kotlin либо в Swift/ObjectiveC
Если честно то все нужно обновить.
Думаю взять плату на z570 чипсете с AM4 сокетом
После если будет возможность взять 3900X проц если не хватит то на худой конец 2700X и памяти эдак гигов на 16 а после добить до 32.
Видеокарты 1080Ti пока за глаза хватает и несколько лет она еще поживет.
Зачем такие мощности? Думаю поднять на virtualbox 3 ноды ceph и 3 ноды k8s чтобы полноценно спроектировать кластер и написать terraform + ansible / chef скрипт для того чтобы уже развернуть его на своем сервере и посмотреть стоит ли оно того. ProxMox уже все почему-то считают старьем.
У самого i7 2600k — как работал так до сих пор работает, упор в основном в память — 8гб уже мало но в моем городу планка DDR3 на 4gb стоит в 3 раза дороже DDR4 на 8 gb. Так что думаю обноситься постепенно.
Производительность была критична, так что то что хорошо ложиться на реляционную базу — лежит в ней, что не ложиться — то в nosql.
BPMN хорошо себя показало — была полная диаграмма процессов всего проекта, правда размер диаграммы титанический, если распечатывать — то только на ватман в пол-стены. За то все заинтересованные в проекте могли в любое время узнать что и как и зачем работает. Плюс к каждой задаче была своя диаграмма которая указывала какие шаги какого процесса меняем. Без этого никто вообще бы не понял что меняем и где.
TDD не спасло только от одного бага — как раз с graphQl. Схема генерировалась на все объекты что называется на лету, для каждого запроса интроспекцией по всем трем базам данных. Естественно при нагрузке генератор схемы начал лагать что привело в тормозам в 1-2 секунде на фронте при каждом запросе но только когда выгружали отчеты — в итоге сделали кэш схемы который сбрасывали только при миграции.
Что касается людей — то когда проект начал приносить доход то через 3 месяца уже наняли полноценную команду — (2 backend, 1 frontend).
Как раз frontend и предложил заменить react на vue. Так как react не прост в отличии от vue — по скольку ему сапортить проект — то почему бы и нет? Тем более что заняло это 2 недели и руководство было не против посмотреть на нового человека в деле — и да вышло не плохо.
После мне старые друзья предложили вкусный оффер, я сообщил компании что собираюсь уходить — на мое место взяли спеца, до обучил команду (благо документация по проекту есть) BPMN + спецификация на каждый домен и сабдомен. После того как команда начала тянуть проект я со спокойной совестью ушел.
После узнал что проект жив и активно развивается — его домены распилили на микросервисы и горизонтально масштабируют. Все в принципе довольны и счастливы.
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 часов без сна в погоне за плавающим багом?
Вообще все технологии которые человек осваивает, все проекты который человек реализует это плюс в первую очередь к его опыту и уже во вторую соответственно к резюме, причем не важно в какой сфере.
Были ли технологи среди этого списка которые я не использовал в production — да это был GraphQl до этого использовал его в одном pet проекте. И да он сократил мне пару недель работы.
Использовал ли я все технологии из списка в одном проекте до этого — тоже нет.
Плохо ли для компании то, что в работе человек пытается использовать технологии которые не использовали раньше в этой компании?
Зависит от результатов — а результаты в том же сообщении из которого цитата.
Да 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 человек.
Весело однако, профакапились все а отвечать как всегда IT директору и страдать программистам (остались без кофе).
На прошлой работе тоже наняли пусть не этаж а комнату аналитиков. Только студентов было 3 из 5, остальные два — бывший сотрудник call центра и бывалый аналитик. Выдали им четкие задачи что нужно проанализировать. После чего люди долго ходили по кабинетам, задавали вопросы и запрашивали доступы к базам.
Через месяц — вывели диаграмму в powerBI на чем компания зарабатывает, статистику по разрезам клиентов плюс дали задание дизайнеру замутить инфографику для партнеров и клиентов.
На второй месяц вытащили все неудачные продукты и зарезали их. У многих разрабов бомбануло в том числе и у меня. Делаешь огромный проект на пол года работы, а потом приходят и говорят что в релиз это не пойдет и вообще проект зарезан — вот новые задачи.
На третий месяц вычислили 3 основных продукта на которых компания зарабатывает деньги и на них сфокусировали всю работу.
В итоге вышло результаты для компании вышли крутые.
Да и с моего отдела сняли обязанность делать пару отчетов.
Не был там с тех добрых времен когда у некра лиги саммон был скелет и кровавый шит резал 100% урона следующих 5 атак всего за 3 крови...
Ага, на месяц, после чего нужные люди бы просто подали нужные жалобы на приложение в чем-то может быть даже справедливые.
Те кто размещает приложение (googlePlay, appstore) отправили письмо роботом с просьбой исправить баги а после бы залочили приложение так как править баги не кому.
Судя по всему искусственную сложность которую решало приложение устранило — переполошило спекулянтов (билетных агентов) которые поняли что если так и дальше пойдет — то они лишаться кормушки. Кормушку же организовала сама компания для "своих" людей которые и есть эти билетные агенты.
В итоге заплатили или подмазали кого нужно с ожидаемым результатом. Парню повезло что пришли вежливые офицеры которые вежливо проводили человека в суд где вежливо повесили на него ярмо и это в Индии.
Бизнес разный бывает, просто я уже давно работаю в сфере где сам it проект — и есть продукт, что в основном руководство вполне понимает технические термины а если не понимает то есть CTO / ProjectManager / ProductOwner который может популярно перевести все это в понятный формат даже для 6-и летнего ребенка.
Для других сфер работает только момент с доверием — либо доверяют и выдают что нужно, когда нужно в необходимых объемах, при этом пока все это укладываются в бюджет на it и все что требуется работает сами не лезут.
Либо не доверяют и постоянно пытаются все "оптимизировать", провести аудит, вести новую %random methodology% управления и/или сертификации. Приглашают различных инфоциган которые в лучшем случае проведут никому не нужную лекцию о "выходе из зона комфорта" а в худшем уже расписали план внедрения, ликвидации текущей it команды и перевода it сектора компании на аутсорс с vendor lock и после продавливания к ногтю директора и высасывания всех активов компании.
Кстати именно в таких компаниях где it не основной продукт и отделу доверяют — работа вообще сказка, особенно если правильно настроить коммуникацию и процессы. Сроки по сравнению с продуктовыми кажутся смешными, переработки — только в случае ЧП и и своих собственных кривых рук. Ограничений на творчество кроме тех что коллективно приняты в отделе — нет. Единственные минусы это более низкий оклад, отсутствие бенефитов которые не особо и нужны, сложность в наращивании бюджета что важно если бизнес вырос а команда it нет, и опасность разлениться и не развиваться. Если же активно работать над собой и кодом — то можно очень сильно прокачиваться и в технологиях и soft skills.
С одной стороны вы определенно правы про техническию мотивацию — да правильно собрать все проблемы, перестроить архитектуру, вести стандарты оформления кода, тесты, спецификацию.
Вот только бизнесу это не нужно. Бизнесу нужна фича X желательно вчера.
На штатный рефакторинг времени бизнес не даст, а если и даст то не на постоянной основе а после опять кранчи с выпустить фичу вчера.
В итоге вы можете помимо и так авральной нагрузки еще и добровольно в не оплачиваемое время чисто из принципа рефакторить код после работы и спасибо вам за это не скажут, мало того еще и многие будут сопротивляться.
Либо запустить проект до уровня когда рефактиринг не поможет и останется только переписать проект с нуля.
В итоге остается либо попытаться объяснить бизнесу почему качество важно, какие проблемы у нас есть и как их решать и постоянного собирать метрики и еще каждый раз доказывать как и почему качество проекта приносит прибыль и лучше это сделать на ранних этапах проекта.
Либо понять что вам не по пути с этой компанией — если в мелочах вроде того как вам писать код вы не договорись то в случае кранча или любых других проблем все это вылезет в очень неприятные последствия как для компании так и для вас.
Если проект "малоприбыльный" — то нужно его либо превратить в прибыльный. Если проблема в качестве продукта — тогда рефакторинг и поможет. Если проблема в известности то поможет маркетинг а не +100500 новых фич. Если не достаточно фич — значит хромает реализация и стоит начать вторую версию. Либо возможно сама идея мертва не мучить труп и похоронить его.
Если проект "краткий по времени эксплуатации" то лучше сразу сделать его качественным по максимуму, так как нет ничего более постоянного, чем временное.
Если же проект MVP то не нужно после запуска продолжать его пилить как обычный проект а стоит сразу начать с нуля при первом получении прибыли а MVP сжечь как это и было изначально заложено в его природе.
Например мой учитель — занимался разработкой селе-предупреждающий системой еще при СССР и до сих пор ходит в горы и меняет для датчиков батареи этой системы.
Еще один знакомый занимается обслуживанием оборудования аэропорта.
Пара знакомых создают и продают iot устройства для рекламных стендов.
Еще один занимался по для управления поездами.
Еще пара знакомых занимаются BigData и аналитикой.
Да даже старший брат и тот пере-прошивает чипы для авто в своем СТО
Если вам внутри кода не удобно — это первый звоночек что нужно все переписать, не важно под каким предлогом вы продадите это бизнесу. Так как именно от этого удобства зависит напрямую мотивация.
Для менеджера — представьте что проект это офисное кресло, проект с костылями, магией это офисное кресло где оставили крестовину и газлифт и так как времени нет — пиастру и сиденье заменили на седушку от велосипеда.
Да оно выполняет свои функции, да на нем можно сидеть, но вот после постоянного его использования каждый день по 8 а иногда и по 14 часов в день в течении года у вас извиняюсь начнет "гореть" седалище.
В какой-то степени понимаю автора, сам заканчивал сперва колледж а потом и ВУЗ где была алгебралогики, теория множеств, теория конечных автоматов, матстат, функциональный анализ.
Были лабы на паскале с дихотомией, операциями над матрицами, построением фигур на основе функций и потом подсчета объема фигурой через интегралы, списками, графами и деревьями. Что-то из этого освоил на отлично, а что-то до сих пор не смог освоить.
Запомнился декану кафердры тем что каждую лабу сдавал на новом неожиданном языке и окончательно выбесил сдав программы на brainfuck и whitespace.
В тоже время сам проходил и иногда до сих пор прохожу курсы по технологии X, смотрел и смотрю видеоуроки по технологии Y, прочитал +100500 статей на хабре когда он был еще торт, а даже написал пару своих которые не вышли из песочницы. Контрибьютил в opensource проект по почте (когда еще не было github). Проходил коучинг на управление командой.
С одной стороны бизнесу достаточно вайтишников которые могут из готовых +100500 бибилиотек в node_modules в том числе и для создания n пробелов для отступов в консоли собрать нечто как-то работающее и даже приносящее деньги. А чтобы эти вайтишники дальше веслали активнее давать им лычки SuperMegaUltraFinalSeniorLead%TechName%Developer.
С другой стороны самое сложное что использовал в работе — конечные автоматы в хитром xml парсере, оценочная формула байеса в умном рейтинге и кое-что из статистики в вероятностном скоринге и фановая анимация на js + svg состоящая из кучи формул.
Остальная работа же на уровне — по нажатию кнопочки взять строку в базе и поменять ей статус при этом добавить еще 3 записи в другие таблицы и положить сообщение в rabbit. В общем сплошные CRUD, CRUD, CRUD и еще раз CRUD...
В итоге для rocket science мозгами не вышел, а текущая работа больше для того чтобы поддерживать комфортный уровень жизни — монотонная до серости, но хорошо оплачиваемая.
При всем этом как-то обидно смотреть на настоящих "инженеров — программистов" которым когда-то хотел стать но не хватило зубов, и понимать что они не нужны а если и нужны то 5-10 штук достаточно для моего города. А нужны люди которые быстро выполняют задачу из готового кода мешая все подряд и при этом не знают как написать fizzbuzz...
Если бы была только hr — на собеседовании еще сразу был тех. спец. и задавал некислые такие вопросы и задачки на тематику алгоритмов и паттернов.
Для меня это тоже был шок )))
Сам BPMN хорош для того чтобы конкретный кейс менеджер смог представить у себя в голове и посмотреть в любое время.
Cамый простой аналог — схема на салфетке. Только тут она в цифровом виде и по правилам. Сразу отсекает задачи с нечетким ТЗ или конфликтом логики.
Текстом-то можно что угодно написать — хоть "7 красных перпендикулярных линий". Но визуально сразу видно где и что конфликтует.
Для Lead удобно в плане понимания того что хотят от него и в каком виде, да и декомпозицию проводить проще, плюс можно для себя пометить какие участки процесса кто из команды делает.
Для исполнителя тоже все понятно — вот схема и вот эти три квадрата мои, первый средний до среды, второй простой до пятницы а с последним нужно недельку провозиться, либо разбить его на более мелкие этапы. Квадраты с права и слева от меня Васи и Пети — нужно обсудить с ними интерфейсы и форматы данных.
Сами используем Camunda Modeller — сам по себе он прост, вложенность там можно реализовать но только самую примитивную. Не так давно они даже движок сделали который может эти схемы запускать (каждый процесс вызывается через api), но на production такое однозначно не пойдет.
Говорят еще существует некий RationalRose — но его не пробовал даже.
В идеале есть идея создать свой вариант, где все процессы сперва рисуются в виде схемы но под капотом — обычных JSON объекты, после чего схема скармливается генератору который автоматом создает цепочку команд на том или ином языке — остается только набить их кодом, в идеале еще добавить с документацией в общий каталог — чтоб в следующий раз не писать велосипед а взять уже готовое решение.
Все верно, единственно начинать рекомендую не с React а с Vue. И после него уже переходить на React.
Плюс уже на уровне изучение Vue + Vuex можно начать зарабатывать на хлеб с маслом и постепенно переходить на React и MobX. Как разобрались с MobX можно уже покуситься на Redux + Redux Thunk + Reselect. Если и их освоили — то можно уже начинать изучать GraphQl.
После того как Graphql сдастся — изучить Next/Nuxt + express + passport.js + sequilize + SQL + NoSql + Pm2 и стать уже full stack.
Либо как вариант уйти в firebase + ReactNative и пилить простенькие приложения на мобилу после чего уходить в Java/Kotlin либо в Swift/ObjectiveC
Есть еще вариант упороться и уйти в Rust + wasm.
Если честно то все нужно обновить.
Думаю взять плату на z570 чипсете с AM4 сокетом
После если будет возможность взять 3900X проц если не хватит то на худой конец 2700X и памяти эдак гигов на 16 а после добить до 32.
Видеокарты 1080Ti пока за глаза хватает и несколько лет она еще поживет.
Зачем такие мощности? Думаю поднять на virtualbox 3 ноды ceph и 3 ноды k8s чтобы полноценно спроектировать кластер и написать terraform + ansible / chef скрипт для того чтобы уже развернуть его на своем сервере и посмотреть стоит ли оно того. ProxMox уже все почему-то считают старьем.
У самого i7 2600k — как работал так до сих пор работает, упор в основном в память — 8гб уже мало но в моем городу планка DDR3 на 4gb стоит в 3 раза дороже DDR4 на 8 gb. Так что думаю обноситься постепенно.
Производительность была критична, так что то что хорошо ложиться на реляционную базу — лежит в ней, что не ложиться — то в nosql.
BPMN хорошо себя показало — была полная диаграмма процессов всего проекта, правда размер диаграммы титанический, если распечатывать — то только на ватман в пол-стены. За то все заинтересованные в проекте могли в любое время узнать что и как и зачем работает. Плюс к каждой задаче была своя диаграмма которая указывала какие шаги какого процесса меняем. Без этого никто вообще бы не понял что меняем и где.
TDD не спасло только от одного бага — как раз с graphQl. Схема генерировалась на все объекты что называется на лету, для каждого запроса интроспекцией по всем трем базам данных. Естественно при нагрузке генератор схемы начал лагать что привело в тормозам в 1-2 секунде на фронте при каждом запросе но только когда выгружали отчеты — в итоге сделали кэш схемы который сбрасывали только при миграции.
Что касается людей — то когда проект начал приносить доход то через 3 месяца уже наняли полноценную команду — (2 backend, 1 frontend).
Как раз frontend и предложил заменить react на vue. Так как react не прост в отличии от vue — по скольку ему сапортить проект — то почему бы и нет? Тем более что заняло это 2 недели и руководство было не против посмотреть на нового человека в деле — и да вышло не плохо.
После мне старые друзья предложили вкусный оффер, я сообщил компании что собираюсь уходить — на мое место взяли спеца, до обучил команду (благо документация по проекту есть) BPMN + спецификация на каждый домен и сабдомен. После того как команда начала тянуть проект я со спокойной совестью ушел.
После узнал что проект жив и активно развивается — его домены распилили на микросервисы и горизонтально масштабируют. Все в принципе довольны и счастливы.
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 часов без сна в погоне за плавающим багом?
Внезапно содержал.
Вообще все технологии которые человек осваивает, все проекты который человек реализует это плюс в первую очередь к его опыту и уже во вторую соответственно к резюме, причем не важно в какой сфере.
Были ли технологи среди этого списка которые я не использовал в production — да это был GraphQl до этого использовал его в одном pet проекте. И да он сократил мне пару недель работы.
Использовал ли я все технологии из списка в одном проекте до этого — тоже нет.
Плохо ли для компании то, что в работе человек пытается использовать технологии которые не использовали раньше в этой компании?
Зависит от результатов — а результаты в том же сообщении из которого цитата.
Да 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 человек.
Весело однако, профакапились все а отвечать как всегда IT директору и страдать программистам (остались без кофе).
На прошлой работе тоже наняли пусть не этаж а комнату аналитиков. Только студентов было 3 из 5, остальные два — бывший сотрудник call центра и бывалый аналитик. Выдали им четкие задачи что нужно проанализировать. После чего люди долго ходили по кабинетам, задавали вопросы и запрашивали доступы к базам.
Через месяц — вывели диаграмму в powerBI на чем компания зарабатывает, статистику по разрезам клиентов плюс дали задание дизайнеру замутить инфографику для партнеров и клиентов.
На второй месяц вытащили все неудачные продукты и зарезали их. У многих разрабов бомбануло в том числе и у меня. Делаешь огромный проект на пол года работы, а потом приходят и говорят что в релиз это не пойдет и вообще проект зарезан — вот новые задачи.
На третий месяц вычислили 3 основных продукта на которых компания зарабатывает деньги и на них сфокусировали всю работу.
В итоге вышло результаты для компании вышли крутые.
Да и с моего отдела сняли обязанность делать пару отчетов.
За то наконец-то можно пользоваться skype на linux и он ничем не хуже и не лучше windows skype.
Да — были и до этого версии skype для linux — но все они вызывали боль...