Отдел прикладного, отдел веб, отдел бд…
У вас матричная структура производства? Почему на ней остановились, а не на проектной?
В 95% случаях один и тот же разработчик может писать и прикладное, и веб, и для бд. И получаться будет значительно эффективнее в плане уменьшения количества коммуникаций (между максимум 3 девов и менеджера, который обязан выжечь в камне апи между слоями).
В остальных 5% случаев достаточно пригласить на «пару часиков» гуру дизайна, оракла и т.п., чтобы решить исключительные задачи.
Департамент развития считаю антипаттерном.
Архитектуру очень опасно вырывать из производства, потому что даже она может меняться со временем. Особенно актуально при решении неопределенных задач а-ля стартап или когда заказчик вообще не знает, что ему надо и/или когда процессы быстро меняются.
Или например, под невстречающуюся ранее задачу выбрали некий инструмент, который оказался багованный/неудобный в использовании. Если держать руку на пульсе, можно успеть его сменить более удобным.
Или такой вариант — вливается новая кровь в команду. Этот человек может рассказать о своем опыте, новых более удобных инструментах разработки и т.п.
Но если такие вопросы решает некий отдел, их решение может затянуться и в итоге народ просто не будет проявлять инициативу по улучшениям, стек технологий будет устаревать. Значит, текущий код может стать тяжело поддерживаемым, можете потерять возможность быть на волне как более производительных инструментов, так и нанимать лучших и отличных спецов, потому что ваши устаревшие технологии никого не привлекают.
Передать такое на поддержку куда бы то ни было принципиально невозможно.
Почему? Неужели так плохо написано?
P.S. Вообще можете не париться, сейчас даже с ужасными процессами и устаревшими технологиями, толпой студентов на позициях лидов компании работают, развиваются и зарабатывают деньги.
Проект не будет стартовать сразу с 12 разработчиками. Для них всех не будет работы. Вначале будет сформирован костяк из сеньоров для проработки требований и формирования архитектуры, а потом потихонечку будут подключаться рабочие руки.
Я думаю, что в Индии можно словить всех 120 ребят быстро, но подготовка нужна серьезнее.
За 5 лет опыта ни разу не встречался с такими хитрыми, даже не слышал. Ок, может не повезло.
Не думаю, что с отпусками и перетеканием сотрудников в другие конторы ситуация принципиально отличается.
Перепланирование можно делать гораздо безболезненее, особенно в рамках митингов. Предположу, что чистый менеджмент может быть (в зависимости от масштаба проекта), но его в любом случае будет меньше, чем там.
По зп — сетки я бы устроил прозрачные, пересмотр зп по результатам, особенно в начале, чтобы исключить подобное недовольство.
По поводу работы команды в тихаря, вопросов по тех деталям, отношений — тимлид и сеньоры должны быть опытными и сильными, это да… Agile… А в общем то эти проблемы встречаются всюду и успешно решаются.
Мне кажется, Вы сильно сгустили краски :)
И даже с такими рисками мне было бы страшнее начинать проект с той толпой индусов. :)
Давайте проведем мыслительный эксперимент. Пусть средняя ставка в час у тех 120 разработчиков 3 бакса. Вместо них можно собрать 12 человек со средней ставкой 30 баксов в час. Такую команду можно легко собрать на территории России и ближнего зарубежья. Я предположу, что это будет очень сильная команда, и за 6 месяцев они могут сделать не меньше той толпы индусов. При этом будет сразу экономия на сопровождающий ресурс — менеджмент и аналитиков (которые обязаны разжевывать требования до диаграмм выполнения кода). Я уже не говорю про другие факторы типа тех долга, стоимости внесения изменений, количестве issues на 1000 строк кода.
Что скажете? Похоже на правду?
Я совсем не согласен с фразой «только позориться перед будущим боссом». Работодатель может не уследить ситуацию на рынке, не учесть, что к нему пришла супер звезда и просит свою рыночную зп. Факторов много, поэтому надо все обсуждать, иначе может случиться так, что предложили весьма среднюю зп (но хорошую по рынку), соискатель согласился с ожиданиями, что будет лучше, а на деле ничего улучшаться не собирается.
Отношения с работодателя — это не отношения с девушками. Платят — ты делаешь для компании, не платят — не делаешь. Если прям надо себя целиком отдавать — давайте долю. Все. Поэтому и речи не может быть о том, чтобы сравнивать людей по тому что эти уже что-то поработали, а этот понтуется, ничего еще не сделал, поэтому он нам не подходит. Это ни разу не адекватность.
Если бы это написал действительно Ваш руководитель, имхо, валить от него надо было бы сразу и без разговоров.
Нормальный сам бы подошел, завязал разговор и плавно и ненавязчиво перешел бы к проблемным вопросам. А тут как конченный мудак — вызывает на ковер.
Мне не понравился подход, который используется для описания сущностей — изменяемые структуры, какой-то лишний trait на сущность.
Я считаю более удачный подход, который используется в slick — case classes, описание структуры таблицы отдельно от сущности. Это проще для восприятия и лишено side effects, так как возможно использование модели где угодно.
Еще Ваше решение ну очень слабо тестируемо, так как package object models не замокаешь.
Я считаю первый способ близким к идеальному.
Всегда можно сделать пометку в комментариях, что на самом деле метод «приватный».
Важно то, что не придется писать и поддерживать лишнюю кучу кода.
А как с производительностью этого запроса, используя PostGis?
На каком числе записей тестировался указанный в статье запрос, который занял полсекунды?
Вы рассматривали/сравнивали с той же функциональностью в ElasticSearch?
Я не назову это решение ни красивым, ни интересным. Оно переусложненное в рамках поставленных целей.
Программная сортировка займет меньше кода и тупо проще.
Это все здорово. Но я опять не увидел целесообразности этих решений.
Зачем писать Всеобъемлющий Супер Фреймворк, если можно решить каждый вопрос в отдельности, даже если писать все 'вручную' (те же отдельные вызовы апи)?
Ваш клиентский код будет генерить сотни-сотни вызовов апи в секунду? зачем заморачиваться об ограничениях браузера?
Почему бы не добавить этот самый запрос вытаскивания друзей друзей? Это очень просто и очень явно. Здесь я вижу немного кода на серверной стороне, обрабатывающей запрос. И не вижу супер-мега сложного кода фреймворка.
И даже при этом фреймворке ваши разработчики будут писать количество кода сравнимое с первым вариантом, но во втором варианте у Вас будет в системе присутствовать очень сложная система этого фреймворка.
Я не могу понять, а что плохого в том, что придется во время валидации интерпретировать данные согласно схеме? Давайте назовем этот процесс конвертацией из json в js-объект модели. И тут сразу все встает на свои места и может быть легко автоматизировано путем простой декларацией схемы. Сюрприза по Вашему примеру меня ждать не будет, потому что если данные не парсятся, то вылетит ошибка на этапе конвертации.
Вы извините, конечно. Но я вижу астронавта от архитектуры.
Такой велосипед на первый взгляд требует уйму времени на поддержку (баго фикс, въезжание новых разработчиков в особенности фреймворка).
Поэтому очень хочется понять, зачем он был сделан.
В начале поста брошены ну уж очень абстрактые фразы, из которых нельзя понять юз кейсы конечных пользователей. Из функциональности фреймворка тоже это понять нельзя, потому что, возможно, сделано не то и не так. Встречался с таким.
Ну например, такие вопросы:
— Зачем нужны batch-запросы? В самом элементарном случае мы можем сделать RESTful api для каждого из запросов, параллельность выполнения чанков можем гарантировать на стороне клиента. Почему Вы выбрали вариант сложнее?
— Что за юз кейс для выполнения на клиенте произвольного кода? Почему бы не использовать некий eval валидного js-кода на стороне сервера хотя бы?
— Я правильно понимаю, что схемы нет в проекте? Ну то есть если мы отправляем объект типа Person в одном запросе на сервер может прийти поле с именем dateOfBirth, а во втором birthDate? Если есть, то почему мы железно должны указывать тип данных например Date, а не определять его по схеме?
В некоторых алгоритмах это важно — иначе никакого стека не хватит, чтобы уместить данные по всей цепочке вызовов.
Даже придумали такой финт ушами как хвостовую рекурсию, когда пишешь алгоритм рекурсивно, а он компилятором разворачивается в итеративный вариант.
А в кровавом ынтырпрайзе и сайтиках, сваяных за пару дней, где царствуют жава и пыха соответственно, такие вопросы крайне-крайне-крайне редко возникают.
Поэтому тут на первое место выходит поддержка и скорость написания.
Почему рекурсия это плохо?
Сравните поддержку кода написанного рекурсивно и без использования рекурсии.
Если все правильно подсчитали, то должно получиться, что поддержка рекурсивного кода сильно проще и дешевле. Я, правда, не встречался с простыми реализациями итеративных алгоритмов :)
Естественно, не рассматриваем ситуацию, когда в условиях задачи стоит условно-бесконечная вложенность.
Откуда вы взяли 99.9%? А запрос в базу данных (да-да-да, все та же терминология) к бэкенду не относится?
А Вы попытались выяснить, что имел в виду тот единственный человек, который ответил про БД на вопрос про запросы?
Капец, слов нет.
Если подчиненных 25, значит должна быть выстроена иерархия из опытных сотрудников, которые уже менторят и следят за менее опытными коллегами и совсем джуниорами на листьях иерархии.
Микроменеджмент очень хорош в случае небольшого количества сотрудников и на этапе сработки. Например, если чел собаку съел на определенном виде задач (сделал 100500 вьюшек для данных), то зачем мне его контролировать? Я уверен, что он все сделает правильно. А вот если челу поручается R&D задача, причем я точно знаю, что в этой области он не работал, естественно, я буду с ним очень плотно взаимодействовать.
upd. большой пардон, отвечал на комментарий выше :)
У вас матричная структура производства? Почему на ней остановились, а не на проектной?
В 95% случаях один и тот же разработчик может писать и прикладное, и веб, и для бд. И получаться будет значительно эффективнее в плане уменьшения количества коммуникаций (между максимум 3 девов и менеджера, который обязан выжечь в камне апи между слоями).
В остальных 5% случаев достаточно пригласить на «пару часиков» гуру дизайна, оракла и т.п., чтобы решить исключительные задачи.
Департамент развития считаю антипаттерном.
Архитектуру очень опасно вырывать из производства, потому что даже она может меняться со временем. Особенно актуально при решении неопределенных задач а-ля стартап или когда заказчик вообще не знает, что ему надо и/или когда процессы быстро меняются.
Или например, под невстречающуюся ранее задачу выбрали некий инструмент, который оказался багованный/неудобный в использовании. Если держать руку на пульсе, можно успеть его сменить более удобным.
Или такой вариант — вливается новая кровь в команду. Этот человек может рассказать о своем опыте, новых более удобных инструментах разработки и т.п.
Но если такие вопросы решает некий отдел, их решение может затянуться и в итоге народ просто не будет проявлять инициативу по улучшениям, стек технологий будет устаревать. Значит, текущий код может стать тяжело поддерживаемым, можете потерять возможность быть на волне как более производительных инструментов, так и нанимать лучших и отличных спецов, потому что ваши устаревшие технологии никого не привлекают.
Почему? Неужели так плохо написано?
P.S. Вообще можете не париться, сейчас даже с ужасными процессами и устаревшими технологиями, толпой студентов на позициях лидов компании работают, развиваются и зарабатывают деньги.
Я думаю, что в Индии можно словить всех 120 ребят быстро, но подготовка нужна серьезнее.
За 5 лет опыта ни разу не встречался с такими хитрыми, даже не слышал. Ок, может не повезло.
Не думаю, что с отпусками и перетеканием сотрудников в другие конторы ситуация принципиально отличается.
Перепланирование можно делать гораздо безболезненее, особенно в рамках митингов. Предположу, что чистый менеджмент может быть (в зависимости от масштаба проекта), но его в любом случае будет меньше, чем там.
По зп — сетки я бы устроил прозрачные, пересмотр зп по результатам, особенно в начале, чтобы исключить подобное недовольство.
По поводу работы команды в тихаря, вопросов по тех деталям, отношений — тимлид и сеньоры должны быть опытными и сильными, это да… Agile… А в общем то эти проблемы встречаются всюду и успешно решаются.
Мне кажется, Вы сильно сгустили краски :)
И даже с такими рисками мне было бы страшнее начинать проект с той толпой индусов. :)
Давайте проведем мыслительный эксперимент. Пусть средняя ставка в час у тех 120 разработчиков 3 бакса. Вместо них можно собрать 12 человек со средней ставкой 30 баксов в час. Такую команду можно легко собрать на территории России и ближнего зарубежья. Я предположу, что это будет очень сильная команда, и за 6 месяцев они могут сделать не меньше той толпы индусов. При этом будет сразу экономия на сопровождающий ресурс — менеджмент и аналитиков (которые обязаны разжевывать требования до диаграмм выполнения кода). Я уже не говорю про другие факторы типа тех долга, стоимости внесения изменений, количестве issues на 1000 строк кода.
Что скажете? Похоже на правду?
Отношения с работодателя — это не отношения с девушками. Платят — ты делаешь для компании, не платят — не делаешь. Если прям надо себя целиком отдавать — давайте долю. Все. Поэтому и речи не может быть о том, чтобы сравнивать людей по тому что эти уже что-то поработали, а этот понтуется, ничего еще не сделал, поэтому он нам не подходит. Это ни разу не адекватность.
Нормальный сам бы подошел, завязал разговор и плавно и ненавязчиво перешел бы к проблемным вопросам. А тут как конченный мудак — вызывает на ковер.
Я считаю более удачный подход, который используется в slick — case classes, описание структуры таблицы отдельно от сущности. Это проще для восприятия и лишено side effects, так как возможно использование модели где угодно.
Еще Ваше решение ну очень слабо тестируемо, так как package object models не замокаешь.
Куда смотрели сеньоры и лиды, когда такой код уходил в продакшн?
Всегда можно сделать пометку в комментариях, что на самом деле метод «приватный».
Важно то, что не придется писать и поддерживать лишнюю кучу кода.
@async @transactional" гугл мне выдал эту ссылку: forum.spring.io/forum/spring-projects/container/76021-async-transactionalЯ сам такое не городил, поэтому вопрос: Вы это пробовали? Работает? Знали об этом способе?
На каком числе записей тестировался указанный в статье запрос, который занял полсекунды?
Вы рассматривали/сравнивали с той же функциональностью в ElasticSearch?
:)
А если нужна пагинация, то данное решение не поможет его осуществить на первый взгляд.
Программная сортировка займет меньше кода и тупо проще.
Зачем писать Всеобъемлющий Супер Фреймворк, если можно решить каждый вопрос в отдельности, даже если писать все 'вручную' (те же отдельные вызовы апи)?
Ваш клиентский код будет генерить сотни-сотни вызовов апи в секунду? зачем заморачиваться об ограничениях браузера?
Почему бы не добавить этот самый запрос вытаскивания друзей друзей? Это очень просто и очень явно. Здесь я вижу немного кода на серверной стороне, обрабатывающей запрос. И не вижу супер-мега сложного кода фреймворка.
И даже при этом фреймворке ваши разработчики будут писать количество кода сравнимое с первым вариантом, но во втором варианте у Вас будет в системе присутствовать очень сложная система этого фреймворка.
Я не могу понять, а что плохого в том, что придется во время валидации интерпретировать данные согласно схеме? Давайте назовем этот процесс конвертацией из json в js-объект модели. И тут сразу все встает на свои места и может быть легко автоматизировано путем простой декларацией схемы. Сюрприза по Вашему примеру меня ждать не будет, потому что если данные не парсятся, то вылетит ошибка на этапе конвертации.
Вы извините, конечно. Но я вижу астронавта от архитектуры.
Поэтому очень хочется понять, зачем он был сделан.
В начале поста брошены ну уж очень абстрактые фразы, из которых нельзя понять юз кейсы конечных пользователей. Из функциональности фреймворка тоже это понять нельзя, потому что, возможно, сделано не то и не так. Встречался с таким.
Ну например, такие вопросы:
— Зачем нужны batch-запросы? В самом элементарном случае мы можем сделать RESTful api для каждого из запросов, параллельность выполнения чанков можем гарантировать на стороне клиента. Почему Вы выбрали вариант сложнее?
— Что за юз кейс для выполнения на клиенте произвольного кода? Почему бы не использовать некий eval валидного js-кода на стороне сервера хотя бы?
— Я правильно понимаю, что схемы нет в проекте? Ну то есть если мы отправляем объект типа Person в одном запросе на сервер может прийти поле с именем dateOfBirth, а во втором birthDate? Если есть, то почему мы железно должны указывать тип данных например Date, а не определять его по схеме?
Насчет хорошо/плохо. Я говорю, что это хорошо для определенного круга задач и плохо для другого. В большинстве случаев, рекурсия хорошо. Вот и все.
И не слушайте других, они че попало могут нести. Всегда задавайте вопрос зачем? почему?
Даже придумали такой финт ушами как хвостовую рекурсию, когда пишешь алгоритм рекурсивно, а он компилятором разворачивается в итеративный вариант.
А в кровавом ынтырпрайзе и сайтиках, сваяных за пару дней, где царствуют жава и пыха соответственно, такие вопросы крайне-крайне-крайне редко возникают.
Поэтому тут на первое место выходит поддержка и скорость написания.
Сравните поддержку кода написанного рекурсивно и без использования рекурсии.
Если все правильно подсчитали, то должно получиться, что поддержка рекурсивного кода сильно проще и дешевле. Я, правда, не встречался с простыми реализациями итеративных алгоритмов :)
Естественно, не рассматриваем ситуацию, когда в условиях задачи стоит условно-бесконечная вложенность.
А Вы попытались выяснить, что имел в виду тот единственный человек, который ответил про БД на вопрос про запросы?
Капец, слов нет.
Микроменеджмент очень хорош в случае небольшого количества сотрудников и на этапе сработки. Например, если чел собаку съел на определенном виде задач (сделал 100500 вьюшек для данных), то зачем мне его контролировать? Я уверен, что он все сделает правильно. А вот если челу поручается R&D задача, причем я точно знаю, что в этой области он не работал, естественно, я буду с ним очень плотно взаимодействовать.
upd. большой пардон, отвечал на комментарий выше :)