Вы — не Google

https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb
  • Перевод
Мы, программисты, иногда почему-то сходим с ума. Причём по каким-то совершенно нелепым причинам. Нам нравится думать о себе, как о супер-рациональных людях, но когда дело доходит до выбора ключевой технологии нового продукта, мы погружаемся в какое-то безумие. Вдруг оказывается, что кто-то слышал что-то об одной классной вещи, а его коллега читал комментарий о другой на Хабре, а третий человек видел пост в блоге о ещё чём-то похожем… и вот мы уже пребываем в полнейшем ступоре, беспомощно барахтаясь в попытках выбора между совершенно противоположными по своей сути системами, уже и забыв, что мы вообще пытаемся выбрать и почему.

Рациональные люди не принимают решения таким образом. Но именно так программисты часто решают использовать что-то вроде MapReduce.

Вот как комментировал этот выбор Joe Hellerstein своим студентам (на 54-той минуте):

Дело в том, что в мире сейчас есть где-то 5 компаний, обрабатывающие данные подобных объёмов. Все остальные гоняют все эти данные туда-сюда, добиваясь отказоустойчивости, которая им на самом деле не нужна. Люди страдают гигантоманией и гугломанией где-то с середины 2000-ых годов: «мы сделаем всё так, как делает Google, ведь мы же строим один из крупнейших (в будущем) сервисов по обработке данных в мире!»

image

Сколько этажей в вашем датацентре? Google сейчас строит четырёхэтажные, как вот этот в Оклахоме.

Получить больше отказоустойчивости, чем вам на самом деле нужно, может показаться хорошей идеей. Но это только в том случае, если бы это получилось автоматически и бесплатно. Но это не так, у всего есть своя цена: вы не только будете пересылать значительно больше данных между узлами (и платить за это), но и ступите с твёрдой земли классических систем хранения данных (со всеми их транзакциями, индексами, оптимизаторами запросов и т.д.) на зыбкую почву слабой инфраструктуры новомодных систем. Это важный шаг (и часто — шаг назад). Сколько пользователей Hadoop сделали его сознательно? Сколько из них со временем могут сказать, что это был выверенный и мудрый шаг?

MapReduce и Hadoop в этом плане являются лёгкими мишенями для критики, ведь даже последователи карго-культа со временем признали, что их обряды как-то не очень работают для привлечения самолётов. Но это наблюдение можно и обобщить: если вы решаете использовать какую-то технологию, созданную большой корпорацией, вполне может быть, что вы не пришли к этому решению сознательно; вполне возможно, что к этому привела какая-то мистическая вера в то, что можно имитировать поведение гигантов и таким образом достичь тех же высот.

image

Да, это ещё одна «анти карго-культ» статья. Но подождите! У меня ниже есть полезный чек-лист, который поможет вам принимать более взвешенные решения.

Клёвая технология? Ну, давайте заценим.


В следующий раз, когда вы вдруг обнаружите совершенно обалденную технологию, на которой стоит вот прямо сегодня переписать всю вашу архитектуру, я попрошу вас сделать паузу:

  1. Задумайтесь о том, какую проблему вам нужно решить в вашем продукте. Поймите её до конца. Вашей задачей должно быть решить эту проблему с помощью каких-то инструментов, а не решить «какую-то» проблему, которую может решить понравившийся вам инструмент.

  2. Выберите несколько потенциальных инструментов. Не выбирайте себе одного «любимчика», пока не будете иметь списка из нескольких альтернатив!

  3. Для каждого кандидата найдите его "Главный Документ" и прочтите его. Не комментарии или переводы, а «тот самый» документ.

  4. Определите исторический контекст, который привёл к созданию данного инструмента таким, каким он был создан.

  5. Идеалов не бывает. Взвесьте преимущества и недостатки каждого инструмента. Поймите, на какие компромиссы пришлось пойти его создателям, чтобы достичь главных заявленных ими целей.

  6. Думайте! Трезво и честно ответьте себе на вопрос, совпадают ли ваши цели и приоритеты с целями и приоритетами создателей тех инструментов, которые вы планируете использовать. Какой новый факт об этом инструменте мог бы заставить вас отказаться от его использования? Например, насколько должен отличаться масштаб ваших задач от тех, на которые рассчитан инструмент, чтобы заставить вас задуматься о нерациональности его применения?

А ещё вы — не Амазон


Вышеуказанную методику достаточно легко применять на практике. Совсем недавно я обсуждал с одной компанией их планы использовать Cassandra для нового (достаточно нагруженного операциями чтения) проекта. Я прочёл оригинальный документ, в котором описывались принципы работы Dynamo и, зная, что Cassandra достаточно близка к Dynamo, понял, что эти системы строились на принципе приоритизации операций записи (Амазон хотел, чтобы операция «добавить в корзину» абсолютно всегда проходила успешно). И они даже добились этого, пожертвовав, однако, гарантированной консистентностью и функциональностью традиционных реляционных баз данных. Но компания, с которой я обсуждал применения этого решения, не ставила запись данных в приоритеты (все данные приходили одним блоком раз в сутки), а вот консистентность и производительное чтение были как-раз очень нужны.

image

Амазон продаёт много разных товаров. Если операция «добавить в корзину» вдруг начнёт работать нестабильно — они потеряют много денег. У вас та же ситуация?

Компания, которая хотела внедрить у себя Cassandra, делала это потому, что один из запросов в их PostgreSQL выполнялся несколько минут и они считали, что упёрлись в аппаратные возможности платформы. После буквально пары уточняющих вопросов, оказалось, что перенос их базы на SSD ускорял этот запрос на 2 порядка (до нескольких секунд). Это всё ещё было медленно, конечно, но просто оцените, как переход на SSD (секундное дело), смог ускорить узкое место где-то в 100 раз. Без всяких фундаментальных переделок архитектуры. Стало совершенно ясно, что переход на Cassandra — не верный путь. Здесь требовался некоторый тюнинг существующего решения, возможно — перемоделирования схемы базы данных, но определённо не попытки решить проблему ЧТЕНИЯ инструментом, созданным для решения проблем ЗАПИСИ.

К тому же, вы — не LinkedIn


Я был очень удивлён, когда узнал, как одна моя знакомая компания решила построить свою архитектуру вокруг Kafka. Это показалось мне странным, поскольку их основной задачей был процессинг нескольких десятков (в хороший день — нескольких сотен) достаточно важных транзакций. Для такой входной нагрузки подошло бы даже решение "бабушка, вручную записывающая операции в бумажный блокнот". Kafka, чтобы вы понимали, был создан для сбора всей аналитической информации LinkedIn (все вот эти сообщения, запросы, группы, чаты, новости, оценки и т.д.). Огромное количество данных. Не могу оценить их объёмы сейчас, но несколько лет назад LinkedIn называл цифру порядка 1 триллиона событий в день, с отдельными пиками до 10 миллионов в секунду. Да, я понимаю, что и 10 транзакций в день тоже с его помощью можно успешно обработать. Но зачем это делать? Разница теоретической нагрузки и практической необходимости составляет 10 ПОРЯДКОВ!

image

Наше Солнце, например, всего на 6 порядков больше Земли.

Да, вполне возможно, что инженеры этой компании рационально оценили все преимущества Kafka и выбрали этот инструмент по каким-то неизвестным мне причинам, не связанным с нагрузками. Но более вероятно, что они просто подпали под влияние какого-то восторженного отзыва, статьи, мнения сообщества или что-то ещё, кричавшее им «бери Kafka»… Нет, ну вы подумайте, 10 порядков!

Я уже говорил, что вы — не Амазон?


Ещё более популярной вещью, чем распределённые базы данных Амазона, является их архитектурный подход для масштабирования: сервис-ориентированная архитектура (SOA). В 2001 году Амазон осознал, что не может эффективно масштабировать нагрузки на свой front end, и, работая над решением этой проблемы, пришел к SOA. Эта история успеха передавалась устно и письменно от одного инженера к другому и вот уже мы приходим к ситуации, когда каждый первый стартап из трёх программистов и нуля пользователей начинает свой жизненный путь с того, что разбивает свою домашнюю страницу на наносервисы. К тому времени, когда Амазон осознал необходимость перехода на SOA, у них было 7800 сотрудников и они продавали товаров на 3 миллиарда долларов в год.

image

Вот этот зал вмещает 7000 людей. А у Амазона было 7800, когда понадобился переход на SOA.

Я не говорю, что вам нужно ждать момента найма 7800-го сотрудника для внедрения SOA. Просто задайте себе вопрос — это вот именно та проблема, которую нужно решать сейчас? Других уже нет? Если вы мне скажете, что это действительно так и ваша компания из 50 человек вот прямо сейчас упирается именно в отсутствие SOA, то как вы объясните тот факт, что есть в десятки раз большие компании, которые от этого нисколько не страдают?

И даже Google — не Google


Использование хорошо масштабирующихся инструментов, вроде Hadoop или Spark может быть очень интересным. Однако, на практике классические инструменты лучше подходят для обычных и даже больших нагрузок. Иногда кажущиеся «большими» объёмы могут даже полностью поместиться в ОЗУ одного компьютера. Вы знали, что уже сегодня можете получить терабайт ОЗУ за примерно 10000 долларов? Даже если у вас есть целый миллиард пользователей (а у вас его нет), то за эту цену вы получите целый килобайт данных в ОЗУ на каждого из них. Очень быстро доступный килобайт. Возможно, этого недостаточно для ваших задач и придётся что-то читать\писать с диска. Но сколько это будет дисков — вот прямо тысячи? Вряд ли. Вам не понадобятся решения вроде GFS и MapReduce, которые создавались, на минуточку, для хранения поискового индекса ВСЕГО ИНТЕРНЕТА.

image

Место на жестких дисках сегодня стоит значительно дешевле, чем в 2003 году, когда было опубликовано описание GFS.

Возможно, вы читали документацию по GFS и MapReduce. Тогда вы можете помнить, что основной проблемой, которую пытался решить Google, была не вместимость, а пропускная способность. Они построили распределённую систему, чтобы получить доступ к нужным данным быстрее. Но сегодня на дворе 2017 год и пропускная способность устройств выросла. Учтите, что вам не понадобится обрабатывать столько же данных, сколько обрабатывает Google. Так, может быть, достаточно будет купить жестких дисков получше (возможно, SSD) и этого хватит?

Возможно, вы рассчитываете со временем вырасти. Но считали ли вы, на сколько именно? Будете ли вы аккумулировать данные быстрее, чем будет падать стоимость SSD? Насколько вашему бизнесу нужно будет вырасти до того момента, когда все ваши данные перестанут помещаться на одной физической машине? В 2016 году система Stack Exchange, обслуживающая 200 миллионов запросов в сутки, использовала всего 4 SQL сервера: один для Stack Overflow, один для всего остального и две реплики.

Вы можете пройти по указанному мной выше чек-листу и всё равно остановиться на Hadoop или Spark. И это даже может быть верным решением. Важно, однако, понимать, что верное здесь и сейчас решение не обязательно останется таким надолго. Google знает это хорошо: как только они решили, что MapReduce недостаточно хорошо работает для построения поискового индекса, они перестали его использовать.

Прежде всего поймите вашу проблему


Эта мысль не моя и она далеко не нова. Но, возможно, в интерпретации этой статьи, вместе с чек-листом выше она достучится до вашего сердца. Если нет, вы можете просмотреть такие материалы, как Hammock Driven Development, How to Solve It или The Art of Doing Science and Engineering — во всех них проскакивает один и тот же призыв думать, пытаться понять проблему перед тем, как героически бросаться её решать. В книге G. Polya есть такая фраза:
Глупо пытаться найти ответ на вопрос, которого ты не знаешь. Грустно работать над тем, что не решает твою проблему.
Инфопульс Украина 223,83
Creating Value, Delivering Excellence
Поделиться публикацией
Комментарии 197
  • +39
    Статья напомнила одну компанию, в которой мне удалось (крайне недолго) поработать.

    «Медовая» неделя, знакомлюсь с состоянием дел.

    — А вот тут у нас основная база данных, мы сделали горизонтальный шард на 6 (шесть!) инстансов, запись в БД у нас делается специальной процедурой, вот тут в ней идет вычисление ключа шарда…
    — Ну ОК, сделано довольно грамотно, молодцы. А сколько записей сейчас в самой большой таблице?
    — 50 000…

    facepalm.jpg

    Я это называю «удовлетворять своё любопытство за счёт работодателя».
    • +33
      Удовлетворять любытство за счет работодателя не такая уж и дурная идея. Ведь это ж лучше, чем за свой счет, не так ли?
      • +11
        Это отвратительная идея с точки зрения бизнеса.

        Бизнесу, как ни странно, нужно решение его задач. Бизнес нанимает людей, наивно полагая, что они знают, как решать задачи бизнеса максимально эффективно.

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

        А теперь представьте себе. Скажем, три человека (тим-лид и два его подчиненных) в той или иной мере 2-3 месяца работали над реализацией этой идеи (я про ненужный шардинг, если вы не забыли). Грубый подсчет дает около полутора миллионов рублей, потраченных за это время только на их зарплату с начислениями. И это я еще не считаю стоимость аренды и оборудования рабочих мест и прочие косвенные расходы.

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

        Я думаю, что если бы им предложили возместить расходы, они бы сильно задумались в следующий раз, стоит ли проводить такие эксперименты.
        • +11
          Да, бизнес от этого может пострадать, но только в случае, описанном вами. Представьте себе другую ситуцию, в которой разработчики пытаются рости в профессиональном плане и их инициатива не стоит компании сильно бОльших денег, чем какой либо иной подход. Не смотря на то, что казалось бы бизнесу надо быстрее и дешевле, эксперименты(удачные, пусть и требующие чуть большего времени) могут оказаться полезнымии самому бизнесу в среднесрочной или долгосрочной перспективе. Потому что на выходе мы имеем:
          1. Запас по прочности и масштабируемости(для приведенной выше ситуации)
          2. Прокаченных и довольных разработчиков, которые могут решать теперь и более сложные задачи.
          • +3
            Да, бизнес от этого может пострадать, но только в случае, описанном вами. Представьте себе другую ситуцию, в которой разработчики пытаются рости в профессиональном плане и их инициатива не стоит компании сильно бОльших денег, чем какой либо иной подход

            В подавляющем большинстве случаев работодателю нужно оптимальное решение задачи подходящим инструментом в оптимальные сроки. Что подразумевает отсутствие экспериментов с незнакомыми платформами. Ну просто потому, что даже если платформа и решает поставленную задачу (по слухам, которые донеслись из Stack Overflow и прочих интернетов), то в 99% случаев незнакомый с ней разработчик потратит непозволительное количество времени на набивание шишек и обход подводных камней. И если и вправду она такая хорошая, то при осознанном выборе зовут сторонних консультантов, имеющих опыт работы с ней, и внедряют под их руководством, одновременно обучая своих специалистов. В этом случае как раз на выходе будет и запас по прочности, и прокачанные свои разработчики.
            А когда собственный разработчик убеждает работодателя: «А давайте возьмем эту новую клёвую штуку и попробуем сделать проект на её основе», при том, что инструмент ему незнакомый, но ему интересно просто с ним поработать, то это, как правило, чистой воды халтура и обман своего работодателя.
            • –1
              Что подразумевает отсутствие экспериментов с незнакомыми платформами

              А если задача ставится так, что оптимально использовать незнакомые платформы, по сравнению с знакомыми? Например, вы всегда работали с postgresql, а тут вам нужен полнотекстовый поиск с кучей других параметров.


              И опять же таки, в подавляющем большинстве случаев vision проекта (а его может и не быть) может кардинально менятся, и выбрать один инструмент, а не другой в итоге может получится выгоднее, хотя и не очень видно вначале.

              • +2
                А если задача ставится так, что оптимально использовать незнакомые платформы, по сравнению с знакомыми? Например, вы всегда работали с postgresql, а тут вам нужен полнотекстовый поиск с кучей других параметров.


                Найдите специалиста по незнакомой платформе и оплатите консультацию. Это будет на порядки дешевле, чем по вляпаться в зря потерянное время по причине своей некомпетентности и нежелания эту некомпетентность признавать.

                И опять же таки, в подавляющем большинстве случаев vision проекта (а его может и не быть) может кардинально менятся

                Меняются требования — перепроектируем. Это нормальный процесс.
                • –1
                  Найдите специалиста по незнакомой платформе и оплатите консультацию. Это будет на порядки дешевле, чем по вляпаться в зря потерянное время по причине своей некомпетентности и нежелания эту некомпетентность признавать.

                  Или взять некомпетентного специалиста на коснультацию. Ведь шанс напоротся на некомпетентного специалиста особенно на рынке СНГ довольно велик, ведь вы не знаете технологию нормально.

                  • +3
                    > Найдите специалиста по незнакомой платформе и оплатите консультацию

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

                    Так бывает достаточно часто — над проектами работают сложившеяся команды. Да, конечно же удобно когда те технологии, которые полностью знакомы команде совпадают с текущими задачами, но что делать если нет? Сразу вот так вот менять команду? Добавлять/менять специалистов? Время и ресурсы потраченные на это часто превысят расходы на до-обучение текущих.

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

                    Ну и главное — почти все решения не окончательны. Всегда можно что то попробовать, fail fast, и вернуться на правильный путь. Путём небольших экспериментов продвигаться к цели.
                    • +1
                      Найдите специалиста по незнакомой платформе и оплатите консультацию.

                      Разработчик, пускай даже глава разработчиков оплатить может разве что из своего кармана, как правило.


                      Это будет на порядки дешевле, чем по вляпаться в зря потерянное время

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

                      • 0
                        В плане затрат, как правило, не на порядки. Разовые коммерческие консультации стоят порядка месячной зарплаты штатного разработчика минимум при сроках порядка недели.

                        Это как-то сильно близко к себестоимости, если мы ищем спеца высокого уровня для консультации мидлов.

                        • 0

                          Я про консультации спецов высокого уровня спецом высокого уровня по неизвестной первым технологии. Грубо — 300% накрутки к зарплате спеца по популярным темам.

                • +2
                  Да не вопрос. Пожалуйста. Но при соблюдении двух условий:

                  1. Затраты на эксперименты и «прокачку» разработчиков посчитаны, хотя бы в условных человеко-часах, что позволяет оценить себестоимость, и доведены до бизнеса.
                  2. Бизнес согласен на такие затраты. Причем согласие тоже зафиксировано каким-то образом, а не на уровне «Ну мне Петя сказал, что можно этим заниматься».
                  • +1
                    1. Затраты на эксперименты и «прокачку» разработчиков посчитаны, хотя бы в условных человеко-часах, что позволяет оценить себестоимость, и доведены до бизнеса.

                    Посчитаны кем? Разработчиками? С чего вдруг? А если бизнес не счел нужным посчитать — почему разработчик этим должен заниматься? Причем в рабочее время, ага, которое тоже, между прочим, денег стоит.
                    2. Бизнес согласен на такие затраты. Причем согласие тоже зафиксировано каким-то образом, а не на уровне «Ну мне Петя сказал, что можно этим заниматься».

                    Если речь идет о ФОТ — то он будет, при условии что бизнес доволен конечным результатом. Причем этот результат — с т.з. бизнеса, а не наши с вами рассуждения об избыточности примененной технологии. Выплаченная ЗП — это и есть подтверждение согласия, увольнение — неподтверждение.
                    • 0
                      Посчитаны кем? Разработчиками? С чего вдруг?

                      С того, что в любой методике разработки первичная оценка дается исполнителем. Это совершенно нормальная часть любого процесса.

                      — Тут надо применить Монгу
                      — ОК, сколько тебе примерно надо времени, чтобы попробовать и решить точно?
                      — Ну дня три…
                      — Хорошо, пишем 40 часов на research

                      Выплаченная ЗП — это и есть подтверждение согласия, увольнение — неподтверждение.

                      Как-то у вас всё категорично :)
                      • 0
                        Посчитаны кем? Разработчиками? С чего вдруг? А если бизнес не счел нужным посчитать — почему разработчик этим должен заниматься? Причем в рабочее время, ага, которое тоже, между прочим, денег стоит.

                        Не Вам конкретно, но вообще:

                        В нормальных бизнесах исследования новых решений должны идти особняком, а не при выполнении текущего заказа от клиента (исключая случаи, когда это нужно именно здесь и сейчас и сам факт эксперимента согласован с заказчиком и он согласен это оплачивать). Заказы выполнять надо только с помощью проверенных разработчиком решений.
                        Но такая схема работает только в случае, когда цену на свои услуги разработчик нормально формирует, закладывая в расчеты себестоимости и затраты на эти исследования и повышение квалификации персонала, а не тупо «ЗП + 100% наценки + любой наш каприз за ваши деньги». Работающие по последней схеме долго не выживают — их первые методично сожрут рано или поздно.
                        • +1
                          Что значит «проверено разработчиком»?
                          Разработчик написал игрушечное demo-приложение?
                          Так все нюансы проявляются только в реальном проекте, и иногда не в первый месяц разработки.
                          • –1
                            Именно это и значит: разработчик перед предложением мне использовать какую-то технологию должен, как минимум, прочесть ее описание и сделать в ней хотя бы с десяток-другой тестовых «Hello world». И если бы так и происходило всегда и везде, то в этой статье не было бы примера с использованием Амазоновской Кассандры.
                            • +1
                              И в чём разница между MySQL и Кассандрой для Hello-world приложения?
                              Стандартный деплой СУБД контейнером, стандартные компоненты доступа, малый объём тестовых данных, никакой разницы не заметишь.
                              • 0
                                малый объём тестовых данных, никакой разницы не заметишь

                                Генерация тестовых данных, нагрузочные тесты, не? Тогда почитайте о бенчмарках баз данных — многие «решения» отпадут даже после их прочтения. А потом можно провести по этим методикам и свои исследования.

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

                                  Вы про коммерческую разработку для внешних заказчиков? Как быть с чисто внутренними проектами?

                                  • 0
                                    В смысле? Свой собственный саппорт какого-либо ИТ-решения, используемого в рабочем процессе компании? И как быть с чем? С нагрузочными тестами? Почему у Вас не получается?
                                    • 0

                                      Собственный отдел разработки не ИТ-компании, например.


                                      Как быть с "предлагать клиентам апробированные хотя бы на тестах решения"? На каком уровне должен решаться вопрос "давайте попробуем новую технологию", если бизнес (внутренний заказчик) не отличит ReactJS от ReactOS?

                                      • 0
                                        Как быть с «предлагать клиентам апробированные хотя бы на тестах решения»?

                                        Очень просто: если руководство поставит мне задачу «должен появиться вот такой-то воркфлоу» и я начну его реализовывать применением нового хромированного молотка за 100500 баксов по антикварному хрусталю, то пойду искать другую работу.
                                        На каком уровне должен решаться вопрос «давайте попробуем новую технологию», если бизнес (внутренний заказчик) не отличит ReactJS от ReactOS?

                                        Внутри службы. Но руководитель службы несет ответственность за этот выбор. И, в случае фиаско зачастую идет искать другую работу.

                                        :) :)

                                        Или Вы про клинические случаи, когда руководители не просто отдают заявку «нам надо то-то и то-то» в работу ИТ-службе, а еще и указывают чем и где это реализовывать? Тогда все равно рано или поздно лучше начать искать другую работу :)
                                        • 0
                                          и я начну его реализовывать применением нового хромированного молотка за 100500 баксов по антикварному хрусталю, то пойду искать другую работу
                                          А иначе можно всю жизнь на Фортране просидеть. Как руководство поймёт, что это хромированный молоток, а не самый подходящий инструмент для задачи?
                                          • 0
                                            Как руководство поймёт, что это хромированный молоток, а не самый подходящий инструмент для задачи?

                                            А Ваше руководство счета подписывает не глядя? Куда слать резюме?
                                            • 0
                                              Счета на закупку лицензий или какие?
                                              Хромированным молотком может быть и бесплатный ClickHouse.
                                              • –1
                                                Хромированным молотком может быть и бесплатный ClickHouse.

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


                                                PS
                                                Не вижу смысла обсуждать сферических коней в вакууме, которых Вы вырисовываете на основании моих предыдущих ответов. Можете считать, что Вы победили.

                                          • +2
                                            если руководство поставит мне задачу «должен появиться вот такой-то воркфлоу» и я начну его реализовывать применением нового хромированного молотка за 100500 баксов по антикварному хрусталю, то пойду искать другую работу.

                                            А если вы его начнёте реализовывать с изобретения палки-копалки?


                                            Внутри службы. Но руководитель службы несет ответственность за этот выбор. И, в случае фиаско зачастую идет искать другую работу.

                                            О чём и речь. Выбирают техсредства техспециалисты, а не бизнес. Бизнес может доверять выбор полностью (если он условно бесплатный), может требовать ТЭО различного уровня детализации и достоверности, может применять меры дисциплинарной ответственности за выходы из бюджетов/сроков и т. п. — это его решения.

                      • 0
                        Наверное, в таком случае надо спросить работодателя, не против ли он таких экспериментов за его деньги. И в подавляющем большинстве случаев работодатель скажет, что ему нужно решение задачи (он сам определит — тактической или стратегической) минимальными средствами. В этом смысл бизнеса и конкурентоспособности. Никому не приходит в голову строить склад на 100.000 метров, когда продукции на 10.000 метров).
                        Теперь понятно, почему в разных компаниях стоимость одних и тех же решений задач отличается в десятки раз. Бизнес в незавидном положении.
                        • +1

                          На ассемблере решать задачи того же складского учёта?


                          Суть сколь-нибудь оригинальной разработки в экспериментах на всех уровнях. Нет "золотых пуль".

                          • –1
                            Ресурсы должны подбираться адекватные задачам. А если берется что-то суперское по принципу «там точно все есть, надо или не надо» — это, наверное, не вполне эффективно.
                            • 0

                              Адекватность — понятие субъективное. Какой выбор по вашему более адекватный — берём фреймворк, закрывающий 90% функциональности, пускай и содержащий ещё 400% кода, который использовать в обозримом будущем не планируется, или берём набор библиотек, закрывающий процентов 50 функциональности, а остальное пишем сами?

                              • 0
                                В этом случае скорее всего правильный первый вариант. Лишь бы не было так, что «берём фреймворк, закрывающий 30% функциональности и 500% ненужного кода, а остальное пишем, пилим, и лепим воркэраунды для неподдерживаемых, но нужных фич. Просто потому, что он сейчас модный». К сожалению, этот вариант не редкость.
                                • +1
                                  и содержащий ещё 400% кода, который использовать в обозримом будущем не планируется


                                  А вы что конкретно экономите-то? Место в пять мегабайт на диске под «неиспользуемый» код?

                                  И нужно ли его экономить?
                                  • +2
                                    А вы что конкретно экономите-то? Место в пять мегабайт на диске под «неиспользуемый» код?

                                    Обсуждать некий абстрактный теоретический фреймворк — дело неблагодарное, но в общем случае «400% ненужного кода» совсем не означает, что он просто лежит на диске и никому не мешает. Он может быть задействован, негативно влиять на производительность приложения, наконец, содержать баги и нежелательные фичи, которые как-то влияют на остальные 100% нужного и полезного кода. Поэтому тут каждый конкретный случай надо рассматривать отдельно.
                                    • 0
                                      «Ненужный» может быть задействован. ОК.
                                      • 0
                                        «Ненужный» может быть задействован. ОК.

                                        Вы зря так это скептически восприняли. Это не какая-то неожиданность, а повсеместная практика. Вот, например, простое веб-приложение на ASP.NET MVC. Я там использую один классический маршрут «сущность\идентификатор», под него контроллер и пару представлений. Фрейморк мне пошарится в поисках кастомных обработчиков, поищет файлы на диске, поищет фильтры и т.д.
                                        Весь этот код для решения моей задачи совершенно ненужный. Но фреймворк так устроен, этот код там есть для других целей и других задач, и я никуда от него не денусь, он будет и в моём приложении и будет вызываться при обработке каждого запроса.
                                    • –1
                                      Покупаю принтер, проприетарный драйвер 80 мб.
                                      Файл настройки под сервер печати Линукс — 20 кб (при этом файлы, к примеру, от Самсунга подходят для Ксерокса).
                                      Мне кажется, что-то здесь не так. Мало того, что место на диске, он еще и висит в процессах.
                                    • 0

                                      Надо еще учитывать, что некоторые фреймворки, закрывая какую-то функциональность, увеличивают стоимость оставшейся функциональности.

                                      • 0
                                        Адекватно было бы не придумывать синтетический пример, который явно показывает преимущество одного из вариантов.
                                        А почему я не могу взять набор библиотек закрывающий процентов 95% функциональности, а остальное написать сам?
                              • 0
                                Это отвратительная идея с точки зрения бизнеса.

                                А где в этот момент был бизнес, почему он не контролировал?

                                • +1
                                  Хороший вопрос, но, думаю, не для обсуждения здесь.
                                  Вкратце: поверили вместо «проверили». Более подробно вряд ли смогу здесь рассказать.
                                  • 0
                                    Почему же, вполне для обсуждения здесь.

                                    Некомпетентность сверху привела к некомпетентности снизу (я считаю тезис о том, что только такая причинно-следственная связь возможна, доказывать не требуется).
                                    • +3
                                      Некомпетентность сверху привела к некомпетентности снизу

                                      Почему некомпетентность? Обычное делегирование полномочий. Топ-менеджмент доверяет руководителю ИТ-департамента в этом плане, а тот также выбором фреймворков не занимается, а делегировал это своим девелоперским подразделениям.
                                      Такое точно делегирование и в финансовом учете, и в маркетинге, и в производстве. Просто специфика разработки софта такова, что у программистов обычно возникает и желание, и возможность поковыряться в чём-то новом сугубо для утоления любопытства. Такого нет ни в маркетинге, ни в бухгалтерии.
                                      • +2
                                        руководителю ИТ-департамента в этом плане, а тот также выбором фреймворков не занимается

                                        А тогда что у вас делает CTO? Делегирует дальше и зарплату получает, а ответственность на ком?

                                        • +3
                                          CTO, к сожалению, может преследовать свои цели, перпендикулярные целям бизнеса. Например «имитировать бурную деятельность и занятость, чтобы не сокращался поток бабла».

                                          Поверьте, так тоже бывает.
                                          • 0

                                            Все всегда преследуют свои интересы. Тот же архитектор может преследовать сделать самую совершенную систему с масштабированием и отказоустойчивостью.

                                            • +1
                                              Зачем?

                                              Вменяемый архитектор сначала уточнит бизнес-требования, а затем превратит их в технические.

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

                                              Если он это не понимает — он не архитектор пока еще.
                                              • 0

                                                Архитектор же должность. Разве нет?


                                                Все люди подвержены своим интересам, и архетектор в том числе. Превращение бизнес-требований в технические не очень однозначный процесс, так что тут остается простор для своих решений в духе "у меня был полезненный опыт касательно X, так что тут я заложу масштабирование, даже если заказчик не хочет, то он точно захочет это в дальнейшем и так далее",

                                                • 0
                                                  Архитектор — это роль.
                                                  Если ресурсы позволяют вам иметь выделенного «освобожденного» архитектора — я вас поздравляю, такое случается нечастно.

                                                  я заложу масштабирование, даже если заказчик не хочет

                                                  Об этом и был мой самый первый коммент. Удовлетворение своего любопытства за чужой счет. Имхо, один из самых страшных грехов «разработчиков», которые никак не хотят понять, что «творцы тут не нужны» (с)
                                                  • –1

                                                    Это не удовлетворение любопытства. Архитектор уже делал много таких систем и у него это скажем, больное место. Он в каждую систему добавляет масштабирование не из интереса, а потому что так правильно и так или иначе будет нужно в дальнейшем, по его мнению.

                                          • 0
                                            А тогда что у вас делает CTO?

                                            СТО должен заниматься стратегическими вопросами — в каком направлении развивать ИТ инфраструктуру. Финансовыми вопросами по своей части — определять и защищать бюджеты на поддержание и развитие ИТ, и обеспечивать контроль их выполнения. Планированием работ по своей зоне ответственности должен заниматься. Должен контролировать приоритетные ИТ-задачи для бизнеса. Ну а фреймворки — это уже ответственность системного архитектора (иногда в одном лице с тимлидом), а никак не СТО.
                                            Ну т.е. когда проблема всплывёт, как раз СТО будет раздавать люлей своим подчинённым, и будет отчитываться перед руководством компании, что-то сочинять про «обстоятельства, которые невозможно было предусмотреть на этапе проектирования». Но вот на уровне СТО заранее избежать подобной проблемы, как правило, действительно не получается.
                                            • 0

                                              А кто требования к системе формирует? Архитектор лишь создает архитектуру исходя из требований и ограничений(в том числе и финансовых)

                                              • +1
                                                А кто требования к системе формирует?

                                                Требования к системе формирует бизнес. Или продакт-менеджер, если разрабатываемый софт не для внутреннего потребления, а для внешних клиентов. И в требованиях могут быть условия «нужно реализовать интеграцию с Х» или «нужно уметь выполняться в среде Y», но практически никогда не бывает условий «нужно писать на фреймворке Z». Этот Z уже определяется архитектором, исходя из его видения, насколько Z подходит для решения задачи.
                                              • 0
                                                Распространённое заблуждение: делегирование задач не означает делегирование ответственности. Ответственность перед бизнесом остаётся у делегирующего, а у того, кому делегируют появляется ответственность перед делегирующим. «Вассал моего вассала — не мой вассал»
                                                • 0
                                                  Я, честно говоря, не понял — вы таким образом решили подтвердить мой пост, или наоборот, возразили мне, не прочитав его до конца?
                                            • 0
                                              Вы совершенно правы, но мы с вами разговариваем про разные вещи, а именно про конкретную реализацию и общую механику соответственно.

                                              В контексте существовала определенная ситуация.
                                              • +1

                                                Сугубо для утоления любопытства, это, пожалуй, редкость. Чаще сочетание двух основных факторов в той или иной пропорции:


                                                • повышение (или хотя бы не понижение) своей востребованности на рынке труда
                                                • решение текущих проблем разработки и эксплуатации

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

                                          • +1
                                            Это очень сложный вопрос, на самом деле. Насколько компетентен бизнес в том, чтобы контролировать новые технологии. Другая опасность, которая может ждать бизнес в таком случае: «зачем делать что-то новое, если у нас сайт работает на Joomla 1.5 и есть не просит уже 10 лет?»
                                          • 0
                                            С другой стороны, если посмотреть диалектически, завтра тому же бизнесу вдруг срочно потребуются люди, знающие о крупных распределённых системах. И возьмёт их бизнес на рынке, потому что существует достаточно специалистов, уже освоивших эти технологии за чужие деньги.
                                            • 0
                                              Вы опять путаете причину со следствием. Бизнесу обычно не нужны никакие «крупные распределенные системы». Им нужны продажи, расширение рынков, поле для маркетинговых экспериментов, новые каналы продаж, обратная связь с клиентами и так далее.

                                              То, что эти потребности бизнеса будут удовлетворяться «распределенной системой» — это уже техническое решение. И не факт, что верное.
                                              • 0
                                                Это всё понятно. Но я призываю смотреть на процесс шире, диалектически. Завтра бизнесу могут понадобиться специалисты другой квалификации. Здесь и сейчас понадобятся (долго обучать за свои деньги у нас никто не стремиться). И он их выхватит с рынка, потому что на рынке уже есть специалисты, ранее изучившие новые технологии.
                                                Конечно, кажется, что дела идут вразрез с идей оптимизации затрат каждого конкретного бизнеса, но зато существует экосистема как таковая. Некая избыточность для системы — благо, именно избыточность даёт ресурс для быстрого развития.
                                                • 0
                                                  А я призываю смотреть на процесс честнее и объяснять тому, чьи деньги вы собрались тратить — на что именно они будут потрачены.

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

                                                  Смысл всех моих комментов можно свести к фразе «Обманывать — нехорошо».
                                                  • +1
                                                    Бизнесу именно что нужна избыточность. Я в третий раз призываю смотреть диалектически :)
                                                    Не зря же говорят, допустим, что IT-бизнес лучше всего делать в Силиконовой долине. Почему? — Потому что концентрация людей, которые умеют и знают, там наибольшая.
                                                    Никто конкретно не оплачивает эту самую избыточность из своего кармана, но всем объективно хорошо, когда она есть, потому что дела растут быстрее у всех. Но я, конечно, понимаю, что с точки зрения микроэкономики, атомизированного субъекта отношений «купи-продай» это всё ересь. Однако — работает в реальной жизни!

                                                    ps. Понятие «обман» вообще очень размытое в нашей отрасли. «Вася, сколько тебе нужно на этот таск? — Два ч/д… Вася, прошло два ч/д, где коммит? — Обнаружились новые обстоятельства...» :)
                                                    • 0

                                                      Прошу обратить внимание, что вашим собеседником слово "избыточность" используется совершенно не в том смысле, в каком его используете вы.

                                                      • +2
                                                        Вася, сколько тебе нужно на этот таск? — Два ч/д… Вася, прошло два ч/д, где коммит?


                                                        Какая прекрасная в своей нелепости ошибка.

                                                        Вася сказал честно — два человеко-дня, примерно 15 часов работы.
                                                        Тот, кто спрашивал, не сумел превратить оценку трудозатрат в календарный срок, составив план-график, и теперь сваливает вину за свою некомпетентность, как PM-а, на бедного Василия.

                                                        А ведь Вася срок не говорил!
                                              • 0

                                                Кстати.
                                                Все эти миллионы были распылены только в том случае, если разработчики в течение всего этого задвигали важные задачи подальше и весь рабочий день до последней минуты тратили на шардинг. Но я сильно сомневаюсь, что руководство будет терпеть то, что выдаваемые им задачи (зачастую срочные, весьма вероятно) начнут решаться через 2-3 месяца.
                                                Куда вероятнее, что они тратили на него свое свободное время (а между задачами руководства почти всегда можно найти час-другой в день, либо задержаться на работе), и все задачи руководства решали в срок, либо с небольшой (да, в 3,14 раза)) задержкой срока, которая совершенно не влияла на бизнес.
                                                Не было бы шардинга, у них всего лишь было бы свободное непродуктивно потраченное на баш и хабр время. Зарплата выплачивалась бы все равно в том же объеме.
                                                И в чем тут "распыление"? В изношенной клавиатуре? Протертых байтами проводах? Километрах пробега мыши?

                                          • 0
                                            MapReduce, которые создавались, на минуточку, для хранения поискового индекса ВСЕГО ИНТЕРНЕТА.

                                            И если вы это используете для чего-то меньшего, то вы не правы?) Я вот для обработки 100кб данных использовал что-то похожее на MapReduce, правда самописное.


                                            Идея использовать инструменты по предназначению довольно неплохо, но проблема в том, что на уровне мелких компаний откровенно все равно, что использовать.


                                            А на уровне больших все равно нужно будет передылывать.

                                            • –1
                                              И сколько сотен серверов было в вашем чём-то похожем на MapReduce для 100кб данных?
                                              • +9

                                                Целых 0, потому что MapReduce — это парадигма, и к ней не обязательно поднимать гиганские кластеры.


                                                Я к тому, что не совсем не понимаю спича по поводу "Не используйте MapReduce", ведь это парадигма работы с данными, которая масштабируется от одной маленькой базы до ВСЕГО ИНТЕРНЕТА.

                                                • +6
                                                  MapReduce — модель распределённых вычислений, представленная компанией Google, используемая для параллельных вычислений над очень большими, несколько петабайт, наборами данных в компьютерных кластерах.


                                                  Но парадигма Group-By обработки данных конечно появилась задолго до этого.
                                                  Это тот случай когда копировальный аппарат начали называть ксероксом, хотя это всего лишь производитель
                                                  • +2

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

                                            • +2
                                              У нас во фронтенде похожая ситуация происходит. Все решили, что если google и facebook делают у себя SPA (single page application), то любой сайт должен строиться именно таким образом. В результате теперь какой-нибудь интернет-магазин на три с половиной товара имеет серверный рендеринг, выносящую мозг архитектуру со встроенными в нее старыми решениями и костылями, а чтобы что-то во всем этом изменить, необходимо скачать себе зависимостей на пол гигабайта…
                                              • +12

                                                Но ведь на текущем витке фронтендовых технологий SPA и правда удобнее и проще делать. Каноничный клиент-сервер кажется проще ровно до тех пор, пока внезапно не оказывается, что фильтры в интернет-магазине должны работать без перезагрузки страницы, справа внизу должен быть уютный чятик, а блок сравнения товаров желательно сделать так, чтобы он тоже не требовал перезагрузки страницы.
                                                Современный веб уже очень сильно не про "отдать отрендеренную сервером страничку".

                                                • +1
                                                  Разницы между «отдать страничку с данными» и «отдать эти же данные в JSON» для вменяемого backend-разработчика почти нет. Разве что заголовок про content-type правильный не забыть.

                                                  Весь адъ начинает твориться уже на фронте. Это какой-то отдельный мир :)
                                                  • +4

                                                    Это далеко не всегда так.
                                                    Отдать страничку с данными и правда не сильно сложно, гораздо сложнее отдать часть приложения с данными. Потому что вдруг выясняется, что у фронтенда есть:


                                                    • внутреннее состояние (любимый цвет кнопок, текст не до конца набранного комментария, настройки какого-нибудь фильтра и еще уйма интересных штук, которые разумеется более чем реализуемы в парадигме "отдать страничку, а при переходе по ссылке отдать следующую страничку", но по какой-то причине очень часто приводят к "я тут накидал на jquery, пожалуйста не трогай это никогда")
                                                    • архитектура. Потому что на чистом HTML, CSS и JS можно реализовать всё что угодно, но на Angular (фанатам фейсбука читать как "React") оно почему-то выходит более поддерживаемым и работоспособным.
                                                    • как ни странно, команда, которая обычно этим самым фронтендом занимаются фуллтайм, и обычно, при SPA подходе decoupling (как это по-русски правильно?) получается значительно выше.
                                                    • 0
                                                      Разницы между «отдать страничку с данными» и «отдать эти же данные в JSON» для вменяемого backend-разработчика почти нет.
                                                      Вообще-то разница на порядок. Перегнать данные в JSON — одна команда. Отдать страничку с данными — надо сверстать шаблон и сделать бэкендовую часть логики вывода с учётом ряда параметров. Фактически вы переносите стейт, который в SPA, на бэкенд и дублируете её.
                                                      • –4
                                                        Сверстать шаблон? Причем тут разработчик backend-а?

                                                        Шаблоны в отдельный репозиторий, описываем в документации объекты, передающиеся в шаблоны, отдаем верстку на аутсорс в менее развитый регион, при сборке объединяем с основным репозиторием.
                                                    • 0

                                                      Не забываем про PJAX и аналоги. Те же ВК, ютуб, гитхаб (правда, хз зачем это ему) работают без перезагрузки и имеют «уютные чятики» и прочие аудиоплееры, однако сервер им по старинке отдаёт отрендеренную страничку (точнее, часть), которая через innerHTML запихивается куда надо. По своему опыту могу сказать, что делать такое нетрудно.

                                                      • +10

                                                        (с печалью) и в итоге мы имеем бесконечную прокрутку в стиле xkcd#1309 ("Почему ты переворачиваешь страницы так странно? — Если я притронусь не в том месте, то потеряю открытую страницу, и придётся листать с самого начала")


                                                        SPA требует много работы, и об этом забывают — в итоге 95% SPA хуже, чем тупая пачка страниц со ссылками. Примерно все, которые сделаны не самыми крупными разработчиками.

                                                        • 0
                                                          Крупные разработчики тоже постоянно лажают и пользование их сайтами при определенных сценариях превращается в муку.
                                                          • +2

                                                            Бывает. Но у них значительно больше ресурсов на тестирование и багфикс — так что если даже они со всем этим лажают, то простому разработчику уж точно не стОит использовать в вебе сложные вещи.

                                                          • –1

                                                            Проблема исключительно в one-way binding'е данных на UI. Когда при прокрутке странички (допустим, у нас статья с кучей подзаголовков) хэштег страницы автоматически подменяется на текущий позаголовок (и при обновлении страницы мы попадем на него) такого не происходит никогда.

                                                            • 0

                                                              Понятно, что конкретная проблема решаема (в конце концов, работают же SPA у Гугла, Мейлру и прочих). Но при этом на куче сайтов (к примеру, мобильный сайт fontanka.ru — не самое мелкое СМИ) всё криво (случайно тапнул по статье, нажал back — листай с начала).


                                                              Т.е. масса народу лажает в SPA и т.п. — при том, что SPA им не особо и нужны, люди просто погнались за модой.

                                                              • 0

                                                                Начал писать длинный ответ, но потом понял, что он ни к чему.


                                                                SPA сложнее, и сломать его легче — это понятно. Но разработка любого современного портала, окромя возможно сайта-визитки ученика школы 1218 требует этой сложности.


                                                                Понятно, что конкретная проблема решаема (в конце концов, работают же SPA у Гугла, Мейлру и прочих). Но при этом на куче сайтов (к примеру, мобильный сайт fontanka.ru — не самое мелкое СМИ) всё криво (случайно тапнул по статье, нажал back — листай с начала).

                                                                Тайпнул по статье, нажал back, прокрутка вернулась назад — всё нормально работате. Правда, я смотрел в responsive-вкладке дебага хрома, не на телефоне, мб особенности железа. Но на первый взгляд я не вижу там никаких проблем.


                                                                Мода — понятие растяжимое. Мода мыть руки — тоже мода. Носить одежду после каменного века — тоже. Нужно только разделять полезную вроде этих, и бесполезный хайп. SPA я считаю скорее полезной тенденцией, в среднем.


                                                                А использовать инструмент без его понимания вредно в любом случае, что для SPA, что для Pure-HTML only, что для чего угодно. Не вина инструмента в этом.

                                                                • 0

                                                                  Только что проверил: m.fontanka.ru, листаете до полного списка статей (или просто жмёте "все новости"), несколько раз нажимаете "ещё новости", чтобы подгрузить список дальше (при этом url не изменяется). Дальше тап по статье, бэк — всё, позиция потеряна.


                                                                  В общем, хочется посоветовать разработчику: "не льсти себе, встань ближе" ;-)

                                                                • –2
                                                                  при том, что SPA им не особо и нужны, люди просто погнались за модой.

                                                                  Мне, как разработчику, SPA нужны. Их легче разрабатывать и поддерживать чем традиционные "серверные HTML-генераторы". Естественно при наличии соответствующего инструментария.

                                                                  • +1

                                                                    При наличии соответствующего инстрементария может оказаться легче использовать "серверные HTML-генераторы", разве нет?

                                                                    • –1

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

                                                                      • 0

                                                                        Разработка сразу двух слоев не может быть проще чем разработка одного слоя при наличии сопоставимого инструментария.

                                                                        • 0

                                                                          Разработка монолита дешевле, но поддержка дороже.

                                                                          • 0

                                                                            Смотря в чем поддержка заключается.

                                                                          • 0

                                                                            Может. Уменьшение связанности, увеличение связности, уменьшения количества ответственностей и прочие подобные принципы созданы для упрощения разработки, а не усложнения.


                                                                            Но до недавнего времени с инструментарием на фронтенде было гораздо хуже, чем с инструментарием на бэкенде.

                                                                            • 0

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

                                                                              • 0

                                                                                Ну я исключительно о сознательном внедрении.

                                                              • 0
                                                                Если у кого-то проблемы с тем, чтобы сделать всё это на жикверях (или голом js), то ему явно рано лезть в более сложное по своей сути SPA.
                                                                • +2
                                                                  Возьму на себя смелость сказать: 90% сайтов делать быстрее и проще на vanilla JS+jQuery, даже с интерактивом, чем внедряя очередной 100500-й фреймворк. Просто кривая обучения не выйдет на отрезок «окупаемость»: идеи, заложенные в тот же React, никак не помогут обычному малому бизнесу продать его полтора мешка картошки. А костылей нахватать и столкнуться потом с проблемой поддержки всего этого хозяйства — как будьте-нате.
                                                                  У нас во фронт-енде действительно с этим полный адЪ :)
                                                                  • 0
                                                                    Возьму на себя смелость утверждать, что 90% сайтов клепается ради самих сайтов. Типа создадим красивый сайт и посещаемость или продажи втридорога сами по себе потекут рекой. Главное, чтобы все было красиво. Точно так же, как снять самый дорогой магазин на центральной улице города и на прилавках с вензелями выложить эту картошку с 146% наценкой и пипл выстроится в очередь к кассе. Главное — идея! И при разработке нового бизнеса в Сети создатель должен думать об идее, а не навороченности инструментов для ее претворения в жизнь. Получится из этого стартап с кучей венчурных инвесторов и другими вкусностями — прекрасно. Получится просто еще один бизнес — тоже неплохо :)
                                                                    • +1

                                                                      Если каждый сайт начинать с нового стэка, модного на этой неделе, то да, проще и быстрее написать на коленке.


                                                                      Если же писать приложение, с расчётным сроком эксплуатации лет в 5 хотя бы...

                                                                    • +1
                                                                      А почему нельзя сделать все тоже самое, но на виджетах, внедренных в стандартный html?
                                                                      Пусть страницы останутся нативно-индексируемыми, а все что требует сложной интерактивности будет внутри неких компонентов. Я возлагал надежды на web-components в этом плане, но как то у них медленно все продвигается.
                                                                      • 0

                                                                        Вы забываете задать себе вопрос: а нужно это бизнесу? То есть, возможно этот магазин и не будет сколько ни будь популярным, может оно ему это все пока и не нужно. Ну и всегда есть возможность масштабированя другими инструментами, не только так сказать SPA-first.

                                                                    • +4
                                                                      В целом очень нужная, правильная статья.
                                                                      Только хотел бы отметить один момент:
                                                                      Я прочёл оригинальный документ, в котором описывались принципы работы Dynamo и, зная, что Cassandra достаточно близка к Dynamo, понял, что эти системы строились на принципе приоритизации операций записи.
                                                                      И они даже добились этого, пожертвовав, однако, гарантированной консистентностью и функциональностью традиционных реляционных баз данных. Но компания, с которой я обсуждал применения этого решения, не ставила запись данных в приоритеты (все данные приходили одним блоком раз в сутки), а вот консистентность и производительное чтение были как-раз очень нужны.

                                                                      Чтобы прийти к таким выводам, нужно достаточно глубоко изучить инструмент, что, на самом деле, не так просто и требует времени. Усугубляет ситуацию обилие выбора, особенно в NoSQL решениях.
                                                                      Разработчик зачастую не хочет копать достаточно глубоко, проще и приятнее — «чик-чик и в продакшен».
                                                                      • –3
                                                                        Для этого в компании нужен системный архитектор. Задача разработчика — код писать, а не выбирать решения.

                                                                        Даже если компания экстремально маленькая, всегда можно найти на почасовку грамотного человека, который подготовит вам архитектурное решение.

                                                                        Иначе так и будут плодиться «CRM на mongoDB», которые потом приходится переписывать, тратя человеко-годы, или просто выкидывать (причем бывает, что вместе с командой, которая такое накодила)
                                                                        • –11
                                                                          Системный администратор, который выбирает фреймворки под задачу?
                                                                          И много программистов согласится на такое?
                                                                          • +11
                                                                            Архитектор, а не администратор, вы невнимательно прочли.

                                                                            Системный архитектор — это роль, отвечающая как раз за обоснованный выбор технологий и архитектурных решений.

                                                                            Отсутствие в команде такой роли приводит обычно к Битриксу :)
                                                                            • +2
                                                                              Да, да, невнимательно прочитал. А коммент «изменен» по какому поводу, если не секрет?
                                                                              Но то что не обновился перед отправкой — это да, ошибся.
                                                                              • 0
                                                                                «Комментарий бы изменен» — добавил строчку про Битрикс.
                                                                              • 0
                                                                                Это больше Software Architect, но не принципиально. Системный архитектор ближе к аналитикам: API между компонентами и т.п.
                                                                                • 0
                                                                                  Вы правы, конечно, но разница на практике не настолько принципиальна.
                                                                            • +1
                                                                              О, выходные закончились, прибежали отдохнувшие «архитекторы», начали ставить минусы. Не понравилось про «CRM на mongoDb»? Так это суровая правда жизни. Мне и CRM с монгой, как с основной базой приводилось видеть, и интернет-магазины и много еще чего. С реализацией left join и constraints в коде приложения :)

                                                                              И всегда эти истории заканчивались печально. «Архитекторы» увольнялись, кому-то приходилось, употребляя весьма непечатные выражения, наводить порядок в их хозяйстве и объяснять бизнесу, что решение фактически придется написать заново…
                                                                              • +4

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


                                                                                По моему опыту — именно специальные системные архитекторы и имеют привычку выбирать странные решения вроде монги, шарепоинта или SSIS. Просто потому что читали об их плюсах — но не читали о минусах.

                                                                                • 0
                                                                                  Вступайте в дискуссию, обсудим. Если я неправ, я способен это признать.

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

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

                                                                                    Если им сверху спустить sharepoint, они будут плеваться и брыкаться, делать пусть не на от^&%сь, но строго в рамках ТЗ (чуть шире им не интересно).

                                                                                    Если они сами выбирают технологию, они смогут с ней поиграться, как им нравится, и сделать намного больше и красивее, чем в ТЗ.
                                                                                    • 0
                                                                                      Вы с другой стороны, уважаемый коллега.

                                                                                      Со стороны бизнеса «поиграться» равносильно «выкинуть деньги в никуда». Когда бизнес нанимает разработчика, он полагает, что нанял профессионала, который знает решение его (бизнеса) проблем, и что разработчику не нужно «играться», но он может сесть и сделать.

                                                                                      Вы же предлагаете немного по-детски наивный подход: «дайте нам бабла, мы поиграемся и сделаем, как нам нравится, и пофигу на ТЗ».

                                                                                      В реальной жизни не нужно делать лучше, чем в ТЗ. Нужно сделать то, что написано и как можно быстрее.

                                                                                      Мотивация? Ну да, отчасти здесь я с вами соглашусь. Однако существует множество методик управления, которые создадут у разработчиков иллюзию их причастности к принимаемым решениям. Так что не вижу большой проблемы.
                                                                                      • +1
                                                                                        Возможность «поиграться» также является фактором выбора места работы, и можно нанять более высококвалифицированного специалиста, платя ему меньше, позволяя при этом эксперименты.
                                                                                        • 0
                                                                                          Вы с другой стороны, уважаемый коллега.
                                                                                          Возможно, и нет. Для вашего решения требуется больше затрат. Нужны отдельные люди на много новых ролей: дизайнеры, UI-специалисты, архитекторы решений, и т.п.

                                                                                          Если разработчик не будет прилагать усилий, а тупо кодить, кто-то другой должен приложить эти усилия и описать, что нужно. Причём в случае заинтересованного разработчика он уже в «теме» проекта. А вводить 100500 лишних людей в проект, чтобы они вникли во все детали — это время, значит, и деньги.

                                                                                          Однако существует множество методик управления, которые создадут у разработчиков иллюзию их причастности к принимаемым решениям
                                                                                          Если какой-то разработчик зевает от упоминания sharepoint, можно его убедить, что он сам его и выбрал?
                                                                                          • 0
                                                                                            Нужны отдельные люди на много новых ролей

                                                                                            Я нигде не утверждал, что роль == должность или что каждая роль — это отдельный человек. Напротив, если вы внимательно почитаете мои комментарии, то найдете прямо противоположные утверждения.

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

                                                                                            Если какой-то разработчик зевает от упоминания sharepoint, можно его убедить, что он сам его и выбрал?

                                                                                            Плохой пример, потому что никто в здравом уме не будет выбирать sharepoint :)) Но в целом да, решение можно подать, как якобы принятое коллективно.
                                                                                            • +1
                                                                                              Один человек вполне может сочетать несколько ролей, не вижу никаких проблем. Важно только, чтобы роли были выделены, формализован список обязанностей и зафиксирована ответственность по каждой роли
                                                                                              Как это в реальности выглядит?

                                                                                              Мол, ты, Вася — сегодня архитектор. Пишешь дизайн-документ для себя — завтрашнего кодера. Обоснуешь принятое решение.

                                                                                              И что от этого изменится? Если Вася хочет Кассандру, он напишет в документе, какая она крутая и как используется в решениях всякими знаменитостями типа Cisco и т.п.
                                                                                              • 0
                                                                                                Как это в реальности выглядит?


                                                                                                Это выглядит как документ. На бумаге. Который фиксирует должностные обязанности, скажем, некоего «Ведущего разработчика». В котором написано «Исполняет роль DBA, включая следующие обязанности: ...».

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

                                                                                                И что от этого изменится?

                                                                                                Появляется понятие «ответственность». Если аудит покажет, что решение было неверным, но принятым Васей в рамках его обязанностей (которые он на себя принял), то Вася может пострадать материально (возмещение убытков) или морально (увольнение).
                                                                                                • +1
                                                                                                  Были случаи, когда консультант или архитектор лично возмещал убытки за неверное решение?

                                                                                                  Кто и по каким канонам решает, что верно, а что — неверно? Нет никаких формальных документов, значит — произвол «эксперта».

                                                                                                  Если какая-то контора это практикует, вокруг них должна сложиться репутация, что там, мягко говоря, странные руководители. Адекватный человек туда не пойдёт.
                                                                                                  • 0
                                                                                                    Я случаев возмещения убытков в рамках формальных процедур лично не знаю. Но это не значит, что их нет.

                                                                                                    Случаи увольнения за профнепригодность (дада, с той самой комиссией и аттестацией) по итогам внешнего аудита мне известны.
                                                                                    • +1
                                                                                      Шарепоинт или какой-нибудь WebSphere/WebLogic Portal скорее будет продвигать CIO, которому сейлы промыли мозг «чудесами интеграции», поддержкой из одного корыта и большой скидкой.
                                                                                  • 0
                                                                                    Задача разработчика — код писать, а не выбирать решения.

                                                                                    Извините, конечно, но «код писать» — это задача кодера, а не разработчика.
                                                                                    На мой взгляд, тем и отличается хороший разработчик от плохого, что плохой просто сидит и пишет код, а хороший разработчик создаёт законченное, надёжной и качественное решение безнес-задачи.
                                                                                    • 0
                                                                                      Извините, конечно, но «код писать» — это задача кодера, а не разработчика.

                                                                                      Можно рассматривать кодера как одну из ролей разработчика. Т. е. разработчик может выполнять роли архитектора, проектировщика, ПМа, кодера, тех писателя и т. п, если он, например, на фрилансе.

                                                                                • +11

                                                                                  Очень хорошая и правильная статья. Но до своей ЦА вряд ли дойдёт. А этих ребят, как ни странно, безумное количество. Раз в неделю вижу примеры, например, переписывания с PHP на Go неких проектов, которые годами исправно тащили все свои полтора rps. Причём уже несколько раз видел, когда это закономерно проваливается, и люди делают вывод, что нужно было подражать другому популярному тренду. И начинают новый виток бессмысленной разработки.

                                                                                  • –7
                                                                                    А всё потому, что программист должен писать код.
                                                                                    Очень жаль, что эту простую истину приходится каждый раз объяснять заново.

                                                                                    — Не выбирать фреймворк и не подбирать библиотеки: это роль архитектора
                                                                                    — Не закупать железо или облачные ресурсы: это сисадмин
                                                                                    — Не проектировать базу данных: это DBA
                                                                                    — Не заниматься выкладкой кода в бой и обновлением: это dev-ops
                                                                                    — Не тестировать и не писать тестовые сценарии: это QA
                                                                                    — и даже не настраивать себе софт на рабочем месте

                                                                                    А просто писать код. И всё.

                                                                                    К сожалению, в 95% случаев всё заканчивается на уровне «тыжпрограммист? вот иди и сделай!» и ни о каком разделении ролей внутри команды говорить не приходится. А нет разделения ролей — нет и ответственности, получается, что ответственность «коллективная», за ошибочные решения как бы никто не отвечает, виноватых нет.
                                                                                    • +2
                                                                                      Зависит от штата. Для команд в 2-3 человека будет динамическое совмещение ролей. Мне чаще всего встречались команды, где один выполняет все операции, а другой ответственен за внешнее оформление, контент и тестирование. Это в лучшем случае.
                                                                                      Либо разбиение внутри команды идет бюрократическими методами и не учитывает специфики работы, т.к. за назначение ролей ответственен менеджер, которому надо иной раз подсказывать как пользоваться Word (и такие случаи бывали. Встречалось на предприятиях с низкой з/п)
                                                                                      • –1
                                                                                        Поэтому я и пишу «роль», а не «должность». Даже на трех человек всегда можно выделить и формализовать роли.

                                                                                        Есть такой классный документ, называется «должностные обязанности». Так вот, там можно писать примерно так: «Выполняет роль инженера QA, включая следующие обязанности:… „
                                                                                        Только не говорите, что это “бюрократия», просто банальный порядок.
                                                                                        • 0
                                                                                          Этот неловкий момент, когда я даже не знал должностных обязанностей, т.к. роль у меня вообще другая. Получилось такое из-за жесткого задания должностей и их несоответствия современным потребностям, когда на целый отдел с десятком ПК ни одного ITшника, который может настроить этот парк.
                                                                                          • +3
                                                                                            Вы не можете не знать должностных обязанностей, потому что обязаны с ними ознакомиться под роспись.
                                                                                            Если не знакомились — считайте, что никаких обязанностей у вас нет :)
                                                                                      • +5
                                                                                        Я помню, как мы делали как-то софт для автоматизированной вёрстки газеты объявлений. Архитектор выбирал фреймворки и библиотеки, сисадмин подбирал железо и настраивал софт, DBA проектировал базу, тестер тестировал, программист программировал, дизайнер рисовал всякие графические штуки. Мой друг работал дизайнером, я работал архитектором, сисадмином, DBA, тестировщиком и программистом. Ещё попутно работал нашим бухгалтером и директором. Так многие мелкие команды работают.
                                                                                        P.S. Проект, кстати, тогда взлетел и проработал, пока не померла газета :)
                                                                                        • +6

                                                                                          К сожалению слепое следование подобному подходу порождает до ужаса однобоких специалистов.


                                                                                          Я бы сказал что так должно быть в идеале в крупных проектах с большими командами (и обычно так и есть),
                                                                                          однако, если программист "только пишет код" и никогда даже не пытался "во все остальное", это чаще всего крайне посредственный программист.


                                                                                          Специалист должен знать смежные области, чтобы быть специалистом в своей.


                                                                                          Не выбирать фреймворк и не подбирать библиотеки: это роль архитектора

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


                                                                                          Не закупать железо или облачные ресурсы: это сисадмин

                                                                                          Закупать железо не должен, но как минимум должен иметь представление на каких мощностях и платформах его код может/должен работать.


                                                                                          Не проектировать базу данных: это DBA

                                                                                          Очень спорно что программист не должен принимать в этом участия, выделенные DBA — это больше удел "у нас половина бизнес логики в БД", а обычно же бизнес-логика БД сильно переплетена с приложением (во всяком случае приложения рассчитывают на те гарантии что дают им БД), и знать реляционную теорию и принципы работы с массивами данных — прямая обязанность программиста, также как и принимать участие в проектировании процессов работы с данными.


                                                                                          Не заниматься выкладкой кода в бой и обновлением: это dev-ops

                                                                                          Да, хорошо когда этим занимаются отдельные люди, но понимание должно быть и приложения должны быть написаны таким образом, чтобы упрощать этот процесс, а это уже обязанность программиста а не dev-ops.


                                                                                          Не тестировать и не писать тестовые сценарии: это QA

                                                                                          Смотря что подразумевать под тестированием: автотесты (юнит, апи, интеграционные), само понимание того как сделать софт "тестируемым", проверка функциональности того что программист непосредственно пишет, да и вообще всяческий самоконтроль — это только в плюс, очень тяжело работать с людьми которые даже базово не пытаются проверять что пишут.
                                                                                          Я сталкивался с подобным, когда на ревью / к тестерам / в сборку отправляли вообще никак не работающий и не проверенный код, и это в больших компаниях, а в малых то и тестер не всегда есть.


                                                                                          и даже не настраивать себе софт на рабочем месте

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


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


                                                                                          Программист должен знать те инструменты с которыми он работает.


                                                                                          Статья как раз о том — что нужно понимать почему мы выбираем тот или иной инструмент, нужно понимать как он работает изнутри, чем он нам поможет, а чем может навредить. А что бы хоть на каком то уровне это понимать нужно хоть немного (а чем больше тем лучше) "мочь в смежные области" — это и для себя хорошо и для работодателя. Без понимания этих вещей, которыми программист вроде бы не должен заниматься, невозможно грамотно этот самый инструмент выбрать и избежать тем самом казусов описанных автором.


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

                                                                                          • +1
                                                                                            Полностью подписываюсь под всем, но хотел бы еще добавить, что, например, архитектором невозможно стать, не принимая мелких решений по библиотекам/фреймворкам/утилитам, которые будут в тулчейне использоваться.
                                                                                            В сообщении, на которое вы ответили, вообще не предполагается, что человек из одной области может в другую перейти — какие-то дискретные непересекающиеся области получаются. А в реальности стать, к примеру, devops нельзя, никогда не программировав, имея только опыт развертывания чего-то в вакууме или какие-то системные понятия. Очень сомнительные советы.