База в свою очередь может быть распределенной — и проблема «шины» тут всего лишь делегирована на движок БД, однако никуда не девается. И Вы в такой ситуации просто надеетесь теперь не на шину микросервисов, а на шину базы данных — что с ней всё в порядке будет и транзакции на всех узлах БД целостны и согласованы.
Вообще же — thecoder тут в нескольких постах пояснил, что работа с транзакциями — это последнее, что надо реализовывать как микросервисы, только в случае, когда уж другого выхода нет. Признак потенциального микросервиса — это насколько все плохо будет для системы в целом, если сервис откажет. Если система переживет временную потерю сервиса приемлемо — его можно вынести, а если это чревато большими проблемами — сто раз подумайте, прежде чем этот модуль отторгать.
И мне сдается, что весь негатив к микросервисной архитектуре как раз оттого, что люди не думают что творят, когда начинают выносить в микросервисы тесно связанные модули — но здесь злой Буратино не микросервисная архитектура, а сам архитектор.
Опять: проблема синхронизации данных — это не проблема микросервисов как таковых, а проблема любых распределенных систем, каковыми могут быть и монолиты — как несколько инстансов на разных узлах.
Я имел ввиду следующую мысль: если речь идет о микросервисе, работающем в составе некоторой системы сервисов, то желательно, чтобы этот микросервис не запрашивался множеством других сервисов, а запрашивался в цепочке — родитель сверху, потомок — ниже. Тогда, если что-то меняется в работе микросервиса — это (возможно) приводит к необходимости изменений лишь в двух ближайших его «родственников», а если что-то пойдет не так — то и это «не так» не расползется по связям бог знает куда, а будет влиять только на цепочку, что значительно упростит поиск и исправление бага.
Разумеется, это не про те «микросервисы», которые на самом деле уже и не «микро», а полноценные приложения, к которым обращается масса других приложений за какими-то данными.
Вообще же, надо просто понять — откуда есть пошли эти микросервисы. Они ведь появились не только лишь потому, что кому-то вздумалось «поиграть в микросервисы». Микросервисы — это логичный ответ на конкретные задачи. Я выше тут писал про свой пример — у меня есть в проекте задача обслуживания клиента, и есть задача периодического мониторинга неких данных, которые я предоставляю клиенту. Можно обе задачи решать в рамках одного монолитного приложения, но так же хорошо эти две задачи могут работать и по отдельности. У меня нет сильной связанности между двумя этими задачами: то есть сбор (обновление) данных конечно нужен, но если он не увенчался успехом в очередной итерации — клиенту допустимо предоставить на его запрос предыдущие данные. Другая особенность состоит в том, что сбор данных может меняться довольно часто из-за того, что сам источник этих данных изменяется и под него надо подстраиваться — в условиях монолита это будет означать необходимость править весь проект, прерывать обслуживание клиентов при апдейте проекта. А в условиях микросервиса — я могу править сервис более удобнее. Я могу вынести микросервис сбора данных куда угодно — это, кстати, тоже одна из задач проекта, так как наш доблестный РКН любит поиграть в модераторов. Я могу наплодить кучу одинаковых микросервисов, тем самым зарезервировав их, я могу относительно легко добавлять микросервисы с другим типом собираемых данных — конечно же тут придется и принимающую часть изменять для того, чтобы она умела эти данные принять, но вся инфраструктура уже построена — нужны лишь кастомны методы приема и обработки конкретного типа данных.
Я не являюсь ни теоретически подкованным в микросервисах, ни обладателем обширного практического опыта их применения, ни даже их почитателем — я использую то, что разумно в поставленной задаче.
Да, конечно, речь идет о понимании концепции, а часто у специалиста есть опыт работы с какой-то технологией — и он переносит его целиком на другую, из чего получается натягивание совы на глобус, а по итогу этот специалист говорит: да фигня эта «сова» ваша. Что же касается адаптации задачи к технологии… я сталкивался не раз с тем, что одна и та же задача вполне себе решается несколькими способами, вполне хорошо решается. У каждого решения — свои плюсы и минусы, и тут требуется решить — какой набор плюсов/минусов удобнее. Ну и, конечно, возможно это только если способен эти разные решения создать, чего никогда не будет, если есть предубеждения против чего-то — а по факту это неумение работать с той или иной технологией.
Это была шутка юмора. Хотя в ней и не только юмор — вы спрашиваете про проблемы в шине — но это равнозначно, что спросить: А если сервер откажет? И что ты будешь делать со своим монолитом, Илон Маск? Это же ерунда — эти отказы не следствие выбора архитектурного решения. Из-за чего шина может отказать? Из-за проблем кода самой шины? — Ну так это плохая шина, и в монолите будет проблема, если его «внутренняя шина» кривая. Или проблема связана со связью? — Ну так и монолит без сети скорее всего бесполезен как вещь в себе в современных-то реалиях, да и микросервисы городить для не сетевого приложения смысл какой?
Поэтому я бы не скидывал и ядерный взрыв как фактор в таком уж случае.
Ну, запутать можно и внутреннюю структуру вызовов внутри монолита, так что черт ногу сломит — откуда что берется, поэтому хорошо сделанный монолит — это уже по факту тесно связанная куча «микросервисов», только их интерфейсы взаимодействия не сетевые.
Отторгнуть такие квазимикросервисы из монолита вовне не составит проблемы, но есть ли в этом смысл — это зависит от контекста задачи. При отторжении мы естественно получаем необходимость выстраивания взаимодействия с «потребителями», ранее решаемое платформой, на которой крутится монолит, а как бонус — получаем возможность вынести сервис на другие серверные мощности, возможность использования сервиса другими приложениями и определенную свободу по изменению внутренних механизмов сервиса, не оказывающих влияния на интерфейс взаимодействия, а так же возможности более легкого масштабирования и резервирования сервиса.
О серебристости GraphQL речи не идет, но есть два фактора, которые позволяют его эффективно применить в ряде задач. Во-первых — это его явные преимущества, которые я перечислил выше, а если говорить коротко — то это его высокая гибкость по сравнению с тем же REST.
Второе же заключается в том, что используя graphql необходимо и мыслить в концепции graphql, попытки же сделать «как в REST, только GraphQL» к хорошему явно не приведут, что, в общем-то, справедливо для любой технологии.
Верно — graphql. Избавляет от боли модификации api, кача избыточных данных, разрастания набора эндпоинтов. Запихнул его в свой проект с микросервисами — теперь у меня свой проект с graphql и микросервисами: )))
А кроме шуток, и говоря о заметке уровнем выше про опыт с микросервисами — я полагаю, что надо еще и осторожнее быть со связями между сервисами, то есть в идеале один сервис связан не более чем с двумя другими сервисами, обеспечивая иерархическое дерево, иначе геморрой при изменениях начинает расти экспоненциально как функция от количества связей на сервис. С одной стороны такое ограничение вроде как и противоречит концепции широкого переиспользования, с другой — это продиктовано соображениями локализации и сдерживания сложности. Если в такой ограниченной микросервисной архитектуре возникает необходимость изменений какого-либо сервиса, то это хотя бы не порождает слишком много изменений, а те, что неизбежны — по-крайней мере распространяются в известном направлении — вдоль своей ветви. Но это так — интуитивные соображения безопасности, реального опыта эксплуатации пока мало.
Микросервисы иногда напрашиваются на старте — когда есть куски работы, слабо связанные по времени исполнения (имеется ввиду процессорное время) и результаты работы этих кусков допускают возможность краша. Сейчас работаю над проектом, в котором есть основной сервис со своей базой данных, и есть добытчик данных, которые основной сервис периодически запрашивает у добытчика. Оба сервиса, конечно, синхронизированы по времени обновления данных, но если у добытчика отказ, то основной процесс от этого не страдает — он работает на уже собранных данных — тут изначально напрашивалось разделение на сервисы, что и было реализовано в архитектуре. И здесь проявляются преимущества микросервисов — добытчики данных могут менять алгоритмы сбора данных как угодно без необходимости править весь проект — требуется лишь поддерживать стандарт интерфейса передачи данных между сервисами, можно балансировку и резервирование легко сделать для добычи данных — надо лишь на основном сервисе добавить адреса добытчиков. Сервисы в данном случае занимаются каждый своей работой.
Накладными расходами тут являются поддержание интерфейсов между сервисами — как в архитектурном плане (согласованность форматов), так и в физическом (доступность сети), и, конечно, мониторинг. Изначально я хотел вообще сделать основной сервис с функциями контроля над добытчиками, но лимит времени на разработку не позволил чрезмерно углубляться, будет развитие проекта — вот тогда и можно будет дальше эту тему развить.
Статья же — однобокая, но она так и задумана, наверное. Ведь действительно лучше сделать работающее приложение, которое еще сто раз поменяется, чем стараться изначально все эти сто предстоящих изменений предусмотреть — и, конечно, все равно ошибиться, ибо всего не учтешь. Но то, что изначально хорошо можно вынести в отдельный сервис — почему бы и не вынести, если есть время и ясное понимание и обоснование преимуществ такого решения.
Тут даже вопрос не про выставление статуса, а про адекватность и ответственность разработчика. Верно то, что адекватному и ответственному просто не нужен этот контроль от слова совсем — он только мешает, а вот неадекватного и безответственного человека — хоть законтролируйся — все равно в лучшем что-то ну очень посредственное получишь. В итоге вся идея контроля — не от большого ума и высокой компетенции менеджмента компании, сама цель непонятно — что хотят контролировать и чего добиться? Самоудовлетворения своей значимости (ай эм биг босс!) или поддерживать иллюзию контроля? В самом деле, вот просто житейски — какой из этого прок и кому?
И еще справедливости ради надо таки сказать, что как без повара нет ресторана, так нет его и без хорошего администратора, официантов, дяди Васи, отвечающего за закуп продуктов, даже без — прости господи — без маркетолога, который этот ресторан пропиарит хорошо и поэтому будет спрос на него… Так что это всё же общий труд и в нём нет главных. Правда высокие менеджеры порой стараются убедить всех своих сотрудников в обратном — так ими легче управлять.
Очень возможно — я не претендую на исчерпывающую полноту своего личного опыта, однако он имеет место быть, и, насколько мне известно — он у меня не уникален и довольно распространен. Соответственно здесь, в рамках обсуждения ваших методов контроля мы и делимся своими соображениями и опытом, что потенциально могло бы и вам пригодиться, если смотреть на излагаемое как на источник информации, а не попытку подорвать ваш авторитет или чего-то в этом роде.
Впрочем, я не настаиваю на обсуждении. Если же вы не против — с интересом познакомлюсь с вашим взглядом на командную работу. Я всегда рад ознакомиться с иной точкой зрения.
А на чем эти построения о «командной работе» основаны? Я, например, как человек приземленный, предпочитаю свои соображения соотносить с практикой. И мой опыт говорит, например, о том, что есть очень большие интервалы, когда никакой командной работы — не требуется, и даже сидя в офисе — ты сам в себе, в своей работе. Есть, разумеется, и напротив — интервалы, когда требуется командная работа — это особенно важно на этапе выработки концепции, на этапе тестирования большого блока, на этапе запуска и первых дней жизни проекта — тут разговора нет и никакому вменяемому разработчику не придет в голову уклоняться от этого. Но жесткая структура митапов — ежедневно, например, вне зависимости от контекста — это не более чем синдром контроля головного мозга, а не необходимость в виду реальных предпосылок. Это тот же микроменеджмент, задекорированный под благие намерения.
Если вы такая продвинутая компания, то я бы порекомендовал вам к действительности и обратиться — да вот хотя бы провести ненавязчивый опрос среди своих же сотрудников — что дают им эти ваши контролирующие рамки? Тот же Гугл с его квазианархией — по крайней мере как это преподносится — про возможность работы над своими проектами «в рабочее время», про возможность работать как удобнее и прочие плюшки — вы думаете они там просто зажрались? А я полагаю, что там умные люди просто воспользовались старым добрым тезисом: «Если не можешь прекратить безобразие — возглавь его.» И поимели профит с этого вместо затрат на контроль.
А ваша позиция уже становится чисто защитной — типа возражающий вам просто неправильный (согласно вашим правильным правилам). Ясен пень, что навязываться вам никто не навязывается и не переубеждает — мы лишь говорим о ДЕЙСТВИТЕЛЬНОСТИ, как оно на самом деле происходит, и что можно эту действительность обратить себе на пользу, а не пытаться с невеликим успехом подогнать под свои представления о правильном.
Значит вы пока не работали над проектами, где один человек уже не в силах справляться со всеми этими функциями.
Работал в команде и очень хорошо себя чувствовал — там да, мог погружаться и на более продолжительное время. Сейчас — нарабатываю опыт, и пока вся свистопляска с ролями при всех неудобствах, в целом — хороший и ценный опыт. Поднаторею — начну искать более специализированных рамок деятельности.
Уже есть мечтания, как я такой клёвый в клёвой команде, где каждый своим занят, где тесты покрывают всё, ревью кода проводят, устраивается внутренний обмен знаний на постоянной основе между сотрудниками, сеньоры доброжелательны и мегакомпетентны и т.д.: )))
Мои 3-4 часа — это наиболее плодотворные часы, когда создается что-то новое в проекте, естественно, бывает и больше, но в среднем — примерно столько в день. Больше 4 часов такой активной работы по моим наблюдениям — это уже приглаживание кода, пробы, отладка и т.д., но никак не наращивание функционала проекта. Поэтому я свой день и делю на две половины — в первую у меня обычно творческий подъем, я с прошлого вечера наметил и обдумал что и как сделать — а с утра начинаю воплощать. Заряда и придумок хватает как раз где-то на 3-4 часа.
Кстати сказать, еще одна программистская особенность — это необходимость периодической ревизии сделанного. Конечно в моем случае накладывается пока еще не слишком большой опыт в работе с той платформой, что я работаю, хотя и не только это влияет — те же неизбежные, постоянные и достаточно высокого темпа обновления самих платформ, приводят к тому, что постоянно смотришь на код и видишь новые возможности реализации, новые подходы. Это не говоря уже о том, что сам заказчик подкидывает новые соображения, в свете которых архитектура решения требует изменений.
Ну и конечно особенность моей работы — в почти полном цикле: я проясняю ТЗ, придумываю архитектуру, сам же пишу функционал, тестирую и сам его выкатываю в продакшн — фактически объединяя в себе несколько ролей: аналитика, менеджера, программиста, тестировщика и DevOps. И это не хваставство — это в некотором роде недостаток в моей работе, ибо я не могу себе позволить концентрироваться полностью на чем-то одном. А вот заказчик зачастую воспринимает меня — как исключительно программиста, совершенно упуская из виду очень большую часть проделываемой мной работы, и попытки разъяснить это часто натыкаются на непонимание:
— Аналитика? Какая нафиг аналитика?! Мы же тебя ясно сказали — хотим сайт. С кнопочками! Что тут анализировать? А про архитектуру… так зачем тебе архитектура — садись да пиши! Всё ж ясно!
— Менеджмент? Да ладно, просто сделай к такому-то числу.
— Тесты? Какие тесты?! Пиши сразу правильно и хорошо — и тестировать не надо будет. Или ты часом может не профессионал?
— DevOps… слов понавыдумывают! Наш Вася легко тебе предоставит сервер с облака?! Настраивать там что-то? Да что там настраивать — это ж сервер, и Вася тебе его даст!
При наличие более узкой области работы — возможно и получалось бы больше погружаться, хотя и тогда от постоянного изучения никуда не денешься, а вот со стороны заказчика это выглядит как конструктор собрать из уже готовых деталей — и на что там еще можно время потратить как не на отлынивание от работы!
Плюсанул бы, но нет правов: ) Я в последние полтора года работаю на фрилансе. Точнее — на подряде, проектно и со свободным графиком — есть план с дедлайнами по этапам, а внутри этого периода я могу работать где и сколько угодно — моя задача принести в клювике к обозначенному сроку результат.
За полтора года я сделал «от и до» 3 средних проекта, 1 маленький, 1 сняли с разработки заказчики (полпроекта так сказать среднего) и еще 2 средних проекта сейчас в разработке в разной стадии готовности. Ну то есть вполне результативно время прошло, если иметь ввиду, что проекты я тяну от составления ТЗ до выкатки в продакшн со всеми этими DevOps делами включительно.
И вот я читаю иногда — не в этой статье — про офисные квадратно-гнездовые методы программирования — и уже, знаете, ужасаюсь. Страшно, как в дурдоме. Непонятно кому и зачем надо это вот такое вот. Создается впечатление, что настаивающие на контроле люди просто неадекватны — никакой эффективности от сидения в офисе не прибавляется, подконтрольные никакого удовольствия от работы не испытывают и, как следствие, тихо саботируют, вместо того, чтобы в творческом полете поражать и себя и заказчика плодами своего труда, метрики к изначально творческому процессу применяются нерелевантные и контрпродуктивные, заставляющие исполнителя симулировать деятельность, а не действительно делом заниматься. В общем — реально страшная картина помешательства.
Ну, раз вы за эти два с половиной года еще не устали, значит либо не всегда такой подход был, либо действительно за архитектурой приглядывают. Потому что говнокод — здесь я под говнокодом подразумеваю не забагованный и/или криво писаный код, а код, который пишется не в какую-то хорошо продуманную структуру, а произвольно лепится — неизбежно приводит к тому, что в продукте начинаются суровые проблемы согласованности работы компонентов. Это как строить здание без плана, прифигачивая, что в голову пришло. Я поэтому не люблю «хакеров», которые могут — да — сделать финт в каком-то фрагменте, но этот финт на самом деле часто представляет собой сокрытие проблемы архитектуры, в виду чего и приходится изворачиваться; да и даже будучи к месту — зачастую наращивается сложность проекта без крайней на то необходимости — а это, как говорят знающие люди, самое «дорогое» в разработке — сложность.
Что же до плохо написанного кода (истинный говнокод так сказать: ), кода, написанного второпях (костыли) и прочий «ад» — то это не страшно, если эти фрагменты существенно изолированы, тут как раз ситуация лечится локальным рефакторингом. Но изолировано что-то может быть только в соответствующей продуманной структуре — отсюда снова и опять про бдение архитектуры.
А сколько времени проект существует с таким подходом к разработке?
Грань тут очень тонкая, и проект при таком подходе рискует превратиться в большой ком допущений. Сделанные допуски — никуда не исчезнут сами собой, и сумма их — отнюдь не арифметическая, а вызывает тут же синергию, только со знаком «плохо». Единственное спасение — это продуманная архитектура, которая позволяет облагородить приложение со временем рефакторингом функциональных блоков, но из сказанного автором статьи, не видно, что контроль над архитектурной чистотой приложения свято блюдется, да и слабо верится, что такое возможно в условиях постоянного фичегенрирования — концепт неизбежно начинает развиваться хаотически.
В общем, что-то мне подсказывает, что этому проекту не более года или около того, и вкушение всех последствий — впереди.
Вообще же — thecoder тут в нескольких постах пояснил, что работа с транзакциями — это последнее, что надо реализовывать как микросервисы, только в случае, когда уж другого выхода нет. Признак потенциального микросервиса — это насколько все плохо будет для системы в целом, если сервис откажет. Если система переживет временную потерю сервиса приемлемо — его можно вынести, а если это чревато большими проблемами — сто раз подумайте, прежде чем этот модуль отторгать.
И мне сдается, что весь негатив к микросервисной архитектуре как раз оттого, что люди не думают что творят, когда начинают выносить в микросервисы тесно связанные модули — но здесь злой Буратино не микросервисная архитектура, а сам архитектор.
Разумеется, это не про те «микросервисы», которые на самом деле уже и не «микро», а полноценные приложения, к которым обращается масса других приложений за какими-то данными.
Вообще же, надо просто понять — откуда есть пошли эти микросервисы. Они ведь появились не только лишь потому, что кому-то вздумалось «поиграть в микросервисы». Микросервисы — это логичный ответ на конкретные задачи. Я выше тут писал про свой пример — у меня есть в проекте задача обслуживания клиента, и есть задача периодического мониторинга неких данных, которые я предоставляю клиенту. Можно обе задачи решать в рамках одного монолитного приложения, но так же хорошо эти две задачи могут работать и по отдельности. У меня нет сильной связанности между двумя этими задачами: то есть сбор (обновление) данных конечно нужен, но если он не увенчался успехом в очередной итерации — клиенту допустимо предоставить на его запрос предыдущие данные. Другая особенность состоит в том, что сбор данных может меняться довольно часто из-за того, что сам источник этих данных изменяется и под него надо подстраиваться — в условиях монолита это будет означать необходимость править весь проект, прерывать обслуживание клиентов при апдейте проекта. А в условиях микросервиса — я могу править сервис более удобнее. Я могу вынести микросервис сбора данных куда угодно — это, кстати, тоже одна из задач проекта, так как наш доблестный РКН любит поиграть в модераторов. Я могу наплодить кучу одинаковых микросервисов, тем самым зарезервировав их, я могу относительно легко добавлять микросервисы с другим типом собираемых данных — конечно же тут придется и принимающую часть изменять для того, чтобы она умела эти данные принять, но вся инфраструктура уже построена — нужны лишь кастомны методы приема и обработки конкретного типа данных.
Я не являюсь ни теоретически подкованным в микросервисах, ни обладателем обширного практического опыта их применения, ни даже их почитателем — я использую то, что разумно в поставленной задаче.
Поэтому я бы не скидывал и ядерный взрыв как фактор в таком уж случае.
Отторгнуть такие квазимикросервисы из монолита вовне не составит проблемы, но есть ли в этом смысл — это зависит от контекста задачи. При отторжении мы естественно получаем необходимость выстраивания взаимодействия с «потребителями», ранее решаемое платформой, на которой крутится монолит, а как бонус — получаем возможность вынести сервис на другие серверные мощности, возможность использования сервиса другими приложениями и определенную свободу по изменению внутренних механизмов сервиса, не оказывающих влияния на интерфейс взаимодействия, а так же возможности более легкого масштабирования и резервирования сервиса.
Второе же заключается в том, что используя graphql необходимо и мыслить в концепции graphql, попытки же сделать «как в REST, только GraphQL» к хорошему явно не приведут, что, в общем-то, справедливо для любой технологии.
А кроме шуток, и говоря о заметке уровнем выше про опыт с микросервисами — я полагаю, что надо еще и осторожнее быть со связями между сервисами, то есть в идеале один сервис связан не более чем с двумя другими сервисами, обеспечивая иерархическое дерево, иначе геморрой при изменениях начинает расти экспоненциально как функция от количества связей на сервис. С одной стороны такое ограничение вроде как и противоречит концепции широкого переиспользования, с другой — это продиктовано соображениями локализации и сдерживания сложности. Если в такой ограниченной микросервисной архитектуре возникает необходимость изменений какого-либо сервиса, то это хотя бы не порождает слишком много изменений, а те, что неизбежны — по-крайней мере распространяются в известном направлении — вдоль своей ветви. Но это так — интуитивные соображения безопасности, реального опыта эксплуатации пока мало.
Накладными расходами тут являются поддержание интерфейсов между сервисами — как в архитектурном плане (согласованность форматов), так и в физическом (доступность сети), и, конечно, мониторинг. Изначально я хотел вообще сделать основной сервис с функциями контроля над добытчиками, но лимит времени на разработку не позволил чрезмерно углубляться, будет развитие проекта — вот тогда и можно будет дальше эту тему развить.
Статья же — однобокая, но она так и задумана, наверное. Ведь действительно лучше сделать работающее приложение, которое еще сто раз поменяется, чем стараться изначально все эти сто предстоящих изменений предусмотреть — и, конечно, все равно ошибиться, ибо всего не учтешь. Но то, что изначально хорошо можно вынести в отдельный сервис — почему бы и не вынести, если есть время и ясное понимание и обоснование преимуществ такого решения.
И, вообще — есть в этом всём что-то такое… Novell Netware, OS/2… деревья раньше были не только большими, но и разными: ) И это было прекрасно.
И еще справедливости ради надо таки сказать, что как без повара нет ресторана, так нет его и без хорошего администратора, официантов, дяди Васи, отвечающего за закуп продуктов, даже без — прости господи — без маркетолога, который этот ресторан пропиарит хорошо и поэтому будет спрос на него… Так что это всё же общий труд и в нём нет главных. Правда высокие менеджеры порой стараются убедить всех своих сотрудников в обратном — так ими легче управлять.
Впрочем, я не настаиваю на обсуждении. Если же вы не против — с интересом познакомлюсь с вашим взглядом на командную работу. Я всегда рад ознакомиться с иной точкой зрения.
Если вы такая продвинутая компания, то я бы порекомендовал вам к действительности и обратиться — да вот хотя бы провести ненавязчивый опрос среди своих же сотрудников — что дают им эти ваши контролирующие рамки? Тот же Гугл с его квазианархией — по крайней мере как это преподносится — про возможность работы над своими проектами «в рабочее время», про возможность работать как удобнее и прочие плюшки — вы думаете они там просто зажрались? А я полагаю, что там умные люди просто воспользовались старым добрым тезисом: «Если не можешь прекратить безобразие — возглавь его.» И поимели профит с этого вместо затрат на контроль.
А ваша позиция уже становится чисто защитной — типа возражающий вам просто неправильный (согласно вашим правильным правилам). Ясен пень, что навязываться вам никто не навязывается и не переубеждает — мы лишь говорим о ДЕЙСТВИТЕЛЬНОСТИ, как оно на самом деле происходит, и что можно эту действительность обратить себе на пользу, а не пытаться с невеликим успехом подогнать под свои представления о правильном.
Работал в команде и очень хорошо себя чувствовал — там да, мог погружаться и на более продолжительное время. Сейчас — нарабатываю опыт, и пока вся свистопляска с ролями при всех неудобствах, в целом — хороший и ценный опыт. Поднаторею — начну искать более специализированных рамок деятельности.
Уже есть мечтания, как я такой клёвый в клёвой команде, где каждый своим занят, где тесты покрывают всё, ревью кода проводят, устраивается внутренний обмен знаний на постоянной основе между сотрудниками, сеньоры доброжелательны и мегакомпетентны и т.д.: )))
Кстати сказать, еще одна программистская особенность — это необходимость периодической ревизии сделанного. Конечно в моем случае накладывается пока еще не слишком большой опыт в работе с той платформой, что я работаю, хотя и не только это влияет — те же неизбежные, постоянные и достаточно высокого темпа обновления самих платформ, приводят к тому, что постоянно смотришь на код и видишь новые возможности реализации, новые подходы. Это не говоря уже о том, что сам заказчик подкидывает новые соображения, в свете которых архитектура решения требует изменений.
Ну и конечно особенность моей работы — в почти полном цикле: я проясняю ТЗ, придумываю архитектуру, сам же пишу функционал, тестирую и сам его выкатываю в продакшн — фактически объединяя в себе несколько ролей: аналитика, менеджера, программиста, тестировщика и DevOps. И это не хваставство — это в некотором роде недостаток в моей работе, ибо я не могу себе позволить концентрироваться полностью на чем-то одном. А вот заказчик зачастую воспринимает меня — как исключительно программиста, совершенно упуская из виду очень большую часть проделываемой мной работы, и попытки разъяснить это часто натыкаются на непонимание:
— Аналитика? Какая нафиг аналитика?! Мы же тебя ясно сказали — хотим сайт. С кнопочками! Что тут анализировать? А про архитектуру… так зачем тебе архитектура — садись да пиши! Всё ж ясно!
— Менеджмент? Да ладно, просто сделай к такому-то числу.
— Тесты? Какие тесты?! Пиши сразу правильно и хорошо — и тестировать не надо будет. Или ты часом может не профессионал?
— DevOps… слов понавыдумывают! Наш Вася легко тебе предоставит сервер с облака?! Настраивать там что-то? Да что там настраивать — это ж сервер, и Вася тебе его даст!
При наличие более узкой области работы — возможно и получалось бы больше погружаться, хотя и тогда от постоянного изучения никуда не денешься, а вот со стороны заказчика это выглядит как конструктор собрать из уже готовых деталей — и на что там еще можно время потратить как не на отлынивание от работы!
За полтора года я сделал «от и до» 3 средних проекта, 1 маленький, 1 сняли с разработки заказчики (полпроекта так сказать среднего) и еще 2 средних проекта сейчас в разработке в разной стадии готовности. Ну то есть вполне результативно время прошло, если иметь ввиду, что проекты я тяну от составления ТЗ до выкатки в продакшн со всеми этими DevOps делами включительно.
И вот я читаю иногда — не в этой статье — про офисные квадратно-гнездовые методы программирования — и уже, знаете, ужасаюсь. Страшно, как в дурдоме. Непонятно кому и зачем надо это вот такое вот. Создается впечатление, что настаивающие на контроле люди просто неадекватны — никакой эффективности от сидения в офисе не прибавляется, подконтрольные никакого удовольствия от работы не испытывают и, как следствие, тихо саботируют, вместо того, чтобы в творческом полете поражать и себя и заказчика плодами своего труда, метрики к изначально творческому процессу применяются нерелевантные и контрпродуктивные, заставляющие исполнителя симулировать деятельность, а не действительно делом заниматься. В общем — реально страшная картина помешательства.
Что же до плохо написанного кода (истинный говнокод так сказать: ), кода, написанного второпях (костыли) и прочий «ад» — то это не страшно, если эти фрагменты существенно изолированы, тут как раз ситуация лечится локальным рефакторингом. Но изолировано что-то может быть только в соответствующей продуманной структуре — отсюда снова и опять про бдение архитектуры.
Грань тут очень тонкая, и проект при таком подходе рискует превратиться в большой ком допущений. Сделанные допуски — никуда не исчезнут сами собой, и сумма их — отнюдь не арифметическая, а вызывает тут же синергию, только со знаком «плохо». Единственное спасение — это продуманная архитектура, которая позволяет облагородить приложение со временем рефакторингом функциональных блоков, но из сказанного автором статьи, не видно, что контроль над архитектурной чистотой приложения свято блюдется, да и слабо верится, что такое возможно в условиях постоянного фичегенрирования — концепт неизбежно начинает развиваться хаотически.
В общем, что-то мне подсказывает, что этому проекту не более года или около того, и вкушение всех последствий — впереди.