Комментарии 37
Во всем важен баланс. Я думаю, вам сейчас еще десять раз накидают комментов на тему того, почему слабая связанность и interface segregation это хорошо (и будут правы).
Вопрос не в том, что пишут сразу сложно или лепят процессы, которые сразу сложны, а в том, действительно ли они решают больше проблем, чем создают. И на этот вопрос нет универсального ответа. И ваша статья на этот вопрос тоже не отвечает.
действительно ли они решают больше проблем, чем создают. И на этот вопрос нет универсального ответа. И ваша статья на этот вопрос тоже не отвечает.
Статья призывает задуматься, а надо ли тьма абстракций и наследования, где можно было бы обойтись функцией.
Опять же - дьявол в деталях. Кто определит границу этого "можно было бы"?
Как @Batalmv ниже написал, самое сложное - это определить вот этот баланс, где необходимо и достаточно. По одну сторону - говнокод и throw-away code, по другую - архитектурный астронавтизм.
Кто определит границу этого "можно было бы"?
Если есть сомнения, то делайте проще. Усложнить всегда успеете.
К сожалению есть еще один момент, который часто присутствует в "корпоративной" культуре. Эксперт либо прав сразу, либо - на него повесим всех собак, особено на fixed scope / fixed price
Да и на "итеративных" подходах надо заранее оформлять такие решения как тех. долг, но все равно осадочек останется. Почему сразу не настояли :)
Поэтому я лично предпочитаю описывать варианты, перенося все в термин денег, скоупа и сроков, и дальше предлагать "продукту/спонсору" выбрать. Ходите быстро доехать, и потом дольше допиливать, или выйти позднее, но с более интересным продуктом.
Главное дать опции именно в "бизнес"-терминах, чтобы люди в привычной им среде могли понять. а чего мы хотим.
----------------
Поэтому я бы чуток исправил на
Дайте две, а лучше три опции, как делать с двумя перспективами, на короткую и на длинную.
А там уже по приоритетам решить
Но она не призывает задуматься, а действительно-ли можно было обойтись функцией или нужно было обойтись меньшим числом абстракций и наследований, которые действительно необходимы.
Статья о крайностях, а работа инженера о поиске оптимального варианта.
Мне кажется, первопричина часто в product-manager. Часто бывает, что человек, ответственный за развитие продукта, вместо того, чтобы создать "нечто, созданное за бюджет, в срок и с целью заработать", начинает реализовывать все свои хотелки и мечты с детства.
Все таки, это первый человек, который отвечает, что продукт "закроет" бизнес цель. Именно он связывает бизнес задачу и разрабатываемый инструмент для ее решения. Если же разработчка превращается в "процесс наряжания новогодней елки детьми" - спасти уже сложно. А перечить ему тяжело, так как обычно он либо представитель заказчика - и тогда надо вообще аккуратно, либо все равно ближе к спонсору, чем остальные
------------------------------
Сложность архитектуры часто также идет оттуда. Я хочу все настравивать, я хочу все конфигурированное ... ну блин, а в итоге половина фич вообще никому не нужна. А вот эта гибкость часто требует усложнения. Ну а как иначе?
Тестами покрыты ключевые участки системы. Простейшая логика не проверяется
Ну такое. По опыту баги могут буть везде, и зашоренная команда не видит, хотя баг реально выглядит как 15ти килограмовый арбуз в центре стола.
За деплой отвечает сам разработчик
В enterprise нет от слова совсем. И не потому что там все переусложнено. Просто за стабильность систем в целом отвечает именно поддержка и она решает, как и что. Да, хочется побыстрее, но практика показывает, что "побыстрее" == мы завалили систему и сейчас быстро решаем, откатить все назад, либо еще чуть-чуть вручную потолкать все вперед.
Разработчик вообще часто живет в мире, где он сам себе нарезал доступа, код выполняется в единственном экземпляре, логи не нужны, так как он все может продебажить :) Последнее кстати самое ржачное, так как некоторые так реально думают и даже говорят
------------------------------
Из моего опыта, как архитектора, самое сложное в смысле принятия решения - это найти грань, между где лучше закодить и если то - поменять/дописать, а где - лучше заложить параметризацию заранее. И не могу сказать, что я всегда правильно решаю с первого раза :(
Ну, кстати вот да. Разработчики часто думают, что код который они запустили у себя, это вот тоже самое, что будет в эксплуатации. Но нет, это ведь не так.
Собственно как раз хорошо, когда продукт, как нечто конечно, формируется всеми, от идей до собственно деплоя, когда сразу все участники могут сказать о возможных проблемах и сразу пустить развитие в нужном направлении. И это не переусложнение, а норма.
Разработчики часто думают, что код который они запустили у себя, это вот тоже самое, что будет в эксплуатации. Но нет, это ведь не так.
Не очень вас понял. Вы умеете ввиду что на машине разработчика и на рабочей среде разные варианты системы? Ну это клиника тогда полная.
Нет, я имею ввиду, что разработчик проверяет функционал без нагрузок, без сетевого взаимодействия, без фаерволов, балансировщиков, WAF и чего угодно ещё. Плюс, скорее все, проверяет ещё и не задумываясь о протоколах, о шифровании траффика и много о чём. Он даже не знает о существовании этих вещей. Его не волнуют очень многие вещи.
Вообще не понимаю, в чём клиника, если есть разница между тем, что у разработчика и тем, что в проде? Это как раз не клиника, это как раз обыденная норма. Разные ОС, разные IDE - это в порядке вещей.
Переусложненный код
Рассуждать о сложности кода без контекста - не комильфо. И вообще попахивает дилетантством. У дилетантов все всегда объясняется очень просто. "Простейшая" операция check_user может быть аццки сложной, если мы говорим о банковском приложении со всякими комплаенсами и проверкой по "базам злодеев".
Когда я прихожу на новый проект и вижу дикие спагетти, то я беру таймаут минимум в полгода "на разобраться". Только потом начинаю судить, реально ли это говнокод или сделать проще скорее всего не так-то просто.
Сервис живет 2 года. Любой сервис живет 2, максимум 4 года.
Очень странное заявление.
Или это перевод и имелось ввиду то, что сервис "работает слаженно как организм"...
Очень интересная и занимательная статья) спасибо)
В стартапе можно\нужно быстро кодить и подзабивать на тесты. В банке никто не позволит творить отсебятину.
Но в целом, идея "сделать быстро" а потом улучшать вполне здравая (минуя банки, конечно). Сюда ещё можно добавить, что технологии быстро развиваются. Я за последние 20 лет сменил операционку, несколько языков, фреймворков, баз данных и подходов к разработке.
Есть не только стартапы и банки. Стартап, который пилит сервис, однажды может вырасти и таки стать тем, кто уже не может ломать свой продукт по 20 раз в день.
Идея сделать быстро и улучшить выглядит здравой, пока это пет-проект.
По факту же обычно это заканчивается на "сделать быстро", а потом ещё 20 задач "сделать быстро". И на улучшение никто не будет стремиться дать ни денег, ни времени, ни рук. итоге проект может так и остаться сделанным на коленке, когда следующим этапом будет "сделать с нуля, нормально". А это означает, что предыдущая работа, т.е. деньги и время, только в мусорку. И хорошо, когда есть новые деньги и время, но ведь часто бывает так, что люды на сделанном пытаются зарабатывать. А не получается.
Плюс если говорим про API, то там вообще не очень хорошо делать "лучше потом". Просто ломать совместимость потом будет болью.
Преждевременное абстрагирование даже хуже, чем преждевременная оптимизация, так как обычно затрагивает бОльшую часть проекта.
Даже если под новые требования придётся переписать часть ядра, то простой код переписывать проще. А угадать, в какую сторону потребуется расширение, в общем случае маловероятно.
Причины переусложения тривиальны - потому что нет естественных ограничителей.
Усложняют не потому что это реально нужно, а потому что никто и ничто не запрещает так делать. У настоящих инженеров и архитекторов (которые строят машины из металла и дома из железобетона) есть как минимум габаритные и весовые ограничения, и законы физики. Никто же не купит автомобиль размером с трехэтажный дом с энергопотреблением в пять мегатонн бензина на сотню км. Но в IT подобное вообще без проблем, ну купим новые серверы с терабайтом оперативки и 128 ядрами, делов то.
И у программистов это норма, они еще и посмеются над тобой, дескать если у тебя в автомобиле нет реактивного SPA салона с многоуровневыми микросервисами поддержки климата, задеплоенными в облако кубернетиса, да с отдельной командой DevOps на поддержке этого всего в гараже, то ты какой-то чепушила малоактуальный. А если ты не дай бог какие суммы по заказу посчитаешь просто в цикле, а не через распределенный MapReduce с асинхронной потоковой сериализацией через лямбда промисы с кастомными аннотациями с применением минимум сразу двух BoostSpringMobxNuxt$mol фреймворков - то все, сразу в джуны разжалуют и даже возле кофе машины перестанут здороваться.
Есть одна проблема - точность оценки. То, что неопытный или не особо компетентный специалист может считать переусложнением, человек более опытный может считать необходимой нормой, так как видит проблемы, которые возникнут, если не "переусложнять".
Мы все немного ограничены своими рамками и некоторые думают, что если ничего не происходит и идёт по плану, то это норма, а не потому, что кто-то предусмотрел проблемы и принял меры.
Притом это касается не только разработки, это касается очень много чего.
Вопрос в том, кто будет нести ответственность за решения и какие риски. Разработчику в вакууме, который не приносит денег и который, в случае неудачи, просто уволится и пойдёт на другое место работы, очень легко рассуждать о каком-то переусложнении. Вы никогда не увидите что такой человек скажет "я бы л неправ". И когда наступят последствия от его дурацких решений, в эпицентре будут другие люди. Разруливать будут другие и оплачивать будут другие. А разработчик будет и дальше плакаться и кричать о переусложнении и необходимости простых схем, но уже в другом месте. от и всего лишь.
И когда наступят последствия от его дурацких решений, в эпицентре будут другие люди. Разруливать будут другие и оплачивать будут другие.
Ой да ладно, разруливать. Там на "модном, правильном и сложном" уже в первый год после выкатки в прод обязательно случится эпическая замятня с банальным обновлением зависимостей и заморозка оных. А через три-четыре года это станет уже реальной проблемой, т.к. придет безопасник и будет уже прям совсем больно бить по рукам за непропатченные древние библиотеки, а пропатчить их не получится от слова совсем.
Т.к. найти людей с компетенцией и желанием ковыряться в каком уже напрочь устаревшем ануляро-джанго-ларавеле не получится за любые деньги, и придется брать вчерашних джунов с горящими глазами, которые все враз "быстро" с нуля перепишут на очередной модный нукст-солид-мобикс. На который на рынке через пять лет тоже не найдешь "специалистов".
Эти латте-смузи архитектурные приколы давно известны и видимо пока снисходительно прощаются бизнесами по лишь той причине, что бизнесу положено примерно раз в эти пять лет тотально с нуля переписывать-перерисовывать весь фронтэнд, чтоб чисто визуально не прослыть совсем замшелыми технолуддитами на фоне конкурентов. Ну и чтоб пользователи не скучали и чувствовали, что о них заботятся, и не разбегались к этим самым конкурентам от скрытой обиды и прочего ощущения обделенности вниманием. Вот так любители переусложненных новомодных архитектур и заказчики и нашли способ гармоничного сосуществования - вы нам позволяете играться от души за ваши немалые деньги, а мы создаем вам имидж технической продвинутости, трендовости и прогрессивности. До очередной пятилетней итерации "а не пора ли обновить нам наш сайт?".
ДА, разруливать.
С чего бы это? Нет, не случится.
Не знаю, какой безопасник придёт через 3-4 года. У меня таких нет. Я сам приду через 3-4 месяца и буду требовать подтягивать. Вот именно чтобы через 3-4 года это не стало реальной проблемой.
Найти получится даже запросто. Вообще-то \то хороших денег стоит.
Да, перепишут на нуктс, который просто фреймворк над вуе, который живёт, здравствует, активно развивается и на который есть и спецы и спрос.
Да, известны. Потому и говорю - есть опытные спецы, которые уже знают, как это нормально делать, а есть дедуганы, которым сложно и они умеют только трындеть.
Вы никогда не увидите что такой человек скажет "я бы л неправ".
А опытный сеньор или архитектор скажет? Ну конечно, ага. Все с точностью до наоборот.
Я скажу. И мои знакомые тоже говорят. Да, а вы как думали? Это называется нести ответственность. Вообще-то свою неправоту и неудачность идей опытные спецы озвучивают очень часто и это норма. Именно эти люди в глазах казуалв от мира ИТ что-то и переусложняют, так как уже имеют опыт и набитые шишки и понимают, к чему это приводит.
Почитал и не убедили.
По ряду причин. Во-первых у вас абстрактный конь в жидком вакууме на ложке, которой нет.
Проекты, они разные и это очевидно. Один начинают писать с нуля сегодня, не зная, что ждёт его в будущем. У другого проекта бекграунд в 20 лет.
Один проект это MVP стартапа, у которого есть только идея, а другой это огромная система по решению всего, что хочет заказчик.
В итоге в одних случаях будет переусложнение по одним пунктам, но в других этого не будет.
Как правило, переусложнение возникает не когда вы на ранних этапах пытаетесь лучше понять продукт, а когда вы "просто делаете". Да и вы оказываетеся в моменте, когда ваш проект это куча кода, сшитого из кучи кусков, притом недокументированного и никто не понимает, как он работает, работает оно так себе, а самое главное - дальше уже просто никак.
И вы с вашим подходом как раз и придёте ко всем описанным вами рискам, примтом гарантировано. В смысле я это буквально кучу раз видел.
То, что у вас описано во "вредителях" это прям то, за что надо бить. Во-первых, с какого перепугу вы обзываете кого-то вредителями?
Во-вторых, почему вы всё пытаетесь подогнать под шаблоны? Технари бывают разными, а если человек закладывает риски, это не значит, что он любит всё переусложнять. Человек может просто неверно рассчитывать риски, это да, но остальное чушь.
То, что вы назвали "грамотным подходом" это как раз и есть вредительство и полная хрень.
Дальше вообще забавно:
РПС может вырасти. Что значит вырасти? Он что, растет внезапно? На сколько он может вырасти. Вы делали проект на коленке дома как стартап, бахнули его в гугл-плей и он взял 200 млн юзеров за 2 недели? С какой вер-стью это случится? Надо ли на такие доли процентов создавать сложные системы, способные держать такие нагрузки? Большинство компаний и команд и 10к РПС видели лишь во снах.Ну, во-первых то и значит - вырасти. На сколько - да хз. Давайте начнём с вопроса, что у вас вообще за сервис. Абстракции обсуждать смысла нет. Если вам надо отдавать статику для фронта, это один вопрос. Если к вам прилетает POST запрос, который запускает динамику на сервисе, это совершенно другой вопрос и проблема тут не в РПС, к которому вы так привязались, а к утилизации мощностей.
Будут добавлять новые фичи. Я не представляю себе синьера или мидла, которому дадут писать сервисы и фичи и он напишет так, что туда невозможно будет добавить фичу. Какие фичи? Перекрасить кнопку? Поменять название? Или новая фича уровня, вчера это был гугл, а сегодня это стал сайт по приюту для собак?Вы не представляете, а я представляю. Я такие проекты видел. И то? О чём разговор? О реальности или о ваших фантазиях?
Перекрасить кнопку, серьёзно? Это главное, что знаете в разработке? Это у вас ровень синиора или что? Фичи бывают очень разные и работать они могут очень по разному. Я запросто представляю, как приходится костылить, чтобы реализовать новый функционал.
Если ошибемся придется все переписать. Еще раз, если вам пришлось все переписать, то даже 5 лет проектирования и описание каждой строчки аналитиком и тех. писателем - вас бы не спасло. Я не говорю сразу броситься кодить и собрать непонятно что, грумминг 1-2 часа - это ок, не надо только каждую строчку холиварить и каждый новый сервис гонять через 20 комитетов.Не очень понятна тяга к утрированию. А вы знаете, что для подумать не обязательно планировать каждую строчку и собирать какие-то комитеты? И да, вообще-то нормальные изначально подходы очень даже спасают от необходимости всё переписывать. Например нормальная архитектура, вместо Feature factory вполне спасают от такого. Я понимаю, что некоторые разработчики видят продукт как просто большой набор фич... Ну, результаты я тоже видел.
В общем, я не знаю, к чему там призывает автор в выводе, я просто вижу, что здесь неопытный специалист пытается делать вид, что он опытный и не понимает последствий тех или иных решений. А так же не понимает, сколько времени и сил (ну и нервов) будет выкинуто на помойку, просто потому, что на ранних этапах было лень что-то продумать и что-то показалось сложным.
Причины переусложения тривиальны - потому что нет естественных ограничителей.
Тому, кто только что в первый раз прочитал паттерны (условно - Фаулера), обязательно нужно всё это опробовать в первом же самостоятельном проекте. :)
Тому, кто только что в первый раз прочитал паттерны (условно - Фаулера), обязательно нужно всё это опробовать в первом же самостоятельном проекте. :)
Там не только паттерны. Есть масса реальных примеров в вполне боевых проектах. Суть задачи - есть на входе ArrayList, нужно его отфильтровать и сделать другой ArrayList. Куда уже проще. Смотришь код - а там чего только не навалено - и Java Streams, и Spring Batch, лямбды, инъекции, Generics, какие-то бины с кодогенерацией из YAML. Потом берешь commit blame и идешь к "автору" с вопросом: "А на кой хрен ты тогда вот это все наложил тут?" Ответ огонь - "Да просто хотел попробовать Java Streams, но не было другой подходящей задачи". ОООК. Идешь ревьюверу и аппруверу (все же ходы записаны): "Как так, почему ты это все пропустил в мерж?" Ответ почти аналогичен: "Да я тоже всегда хотел попробовать Spring Batch, не мог найти под них задачу, а тут было очень интересно почитать разобраться, потестить, опыт для резюме".
Парни, а что, сделать себе песочницу на гитхабе и там незаметно поиграть всяким друг с дружкой нет, так нельзя было? Этот вопрос впрочем остался без ответа.
Парни, а что, сделать себе песочницу на гитхабе и там незаметно поиграть всяким друг с дружкой нет, так нельзя было?
Можно было. Можно было и Теорию Относительности не изобретать. Ньютоновская физика и так норм была. Планеты крутятся, гравитация мутится.
Как в вашей логике разработчику составить мнение о том же Spring Batch, если он в бою ни разу не видел? В песочнице-то любой хэллоуворлд норм работает.
Сейчас не умеют делать просто.
Нужен сервис на 100 человек которые там ничего сложного не делают? А давайте все напишем на микросервисах штук 50 сделаем на каждый чих, все это в докер и потом в кубер и сверху ещё рэбит и обязательно надо не забыть каждому сервису по феньшую отдельно БД выделить. Зачем? Вдруг сервис будет масштабирован на 100000 человек и миллион запросов в минуту?
Люди раньше в блокноте писали сайты и шатлы в космос запускали на железе от современной микроволновки, сейчас же требуется мейнфрейм на 1000500 террафлопс чтобы запустить магазин по продаже резиновых писек.
Эм... Сейчас умеют делать просто.
Не очень понятно "ничего сложного" это что? Окей, допустим кубер не нужен (хотя в чём проблема этот сервис запустить как 1-3 воркера в уже существующем?) но в докере в чём проблема? Он просто пакует окружение. Что тут сложного? ОПять же - а почему не ребит, если он уже под рукой и не надо с нуля поднимать?
Люди и сейчас в блокноте пилут, если надо. Вы крайне сильно утрируете и пытаетесь выдавать ложную альтернативу, т.е. только крайностей. Вариантов многим больше.
но в докере в чём проблема? Он просто пакует окружение. Что тут сложного? ОПять же - а почему не ребит?
Проблема в том, что этих зверьков тоже нужно кому-то обслуживать, обновлять, патчить, мониторить. Если облако с "модной" инфрастуктурой есть уже купленное и работающее на смежных проектах, с приложенной тренированной DevOps командой, то ок, может быть и можно брать сразу на старте под новый проект, если всем так проще.
Но чаще всего проблема высосана из пальца, потому как весь этот докеркуберцирк легко заменяется простыми словами bash, ssh/scp, crontab, zip/unzip, chroot (если прям параноит секурность или зависимости по линковке сильно хитрые).
Да и build.sh, и даже deploy.sh - можно и из putty запускать, никакие teamcity для этого не обязательны. Ну разве что jenkins прикрутить, чтоб начальству веселые картинки показывать с кнопками, ему так менее тревожно, чем смотреть в черные экраны с непонятными буквами в стиле первой Матрицы.
Работают же эти простые слова везде и на старте из коробки, хитрой настройки, компетенций, экспертизы и прочей поддержки не требуют.
Нужно и? В чём проблема их обслуживать? Вам даже не нужно никакой тренированной команды, вам просто надо понять, как работает "модный" инструмент, который на деле уже лет 10 как обыденный. И как работает IaC. А идея там очень простая - мы не ручками делаем окружение, а описываем его в файлике для воспроизводимости. Вы же обновляете систему? Ну вот, там она обновляется так же, только не через команду в консоли, а через команду в файле.
Конечно заменяются. И через Н итераций на паре десятков проектов вы приходите к аду и к необходимости тратить кучу времени на поддержание, к отсутствию идемпотентности и ещё к очень большому количеству проблем.
И да, скрипты можно запускать из putty. Но скрипты из putty это если вы студент или дяденька 40+, который просто не осилил в обучение и устарел лет на 15.
Просто я вам говорю как опытный специалист - все эти штуки, они не просто так получились и чем больше выхотите зарабатывать бабок, тем больше вы задумаетесь об эффективности и надёжности. И поверьте, чем выше уровень, тем меньше баша и putty в ваших проектах. Я бы вообще сказал, что при нормальном развитии баша должно стать 0 какой-то момент. Как и scp, zip и всего прочего хлама, который любят за собой таскать устаревшие, неопытные специалисты.
Не очень понятно, о чем речь. Простые вещи надо делать просто, в этом посыл? Ну да.
А сложные вещи надо проектировать с учётом сложностей, и это может быть сложно. Сложность же невозможно убить. Если у вас проект на годы и с запланированными тысячами точек расширения, то вы не можете сделать просто, иначе вам всю жизнь придётся переписывать всё с нуля.
Есть такой тезис: Сложность должна быть адекватна проекту. Причем адекватна с разных сторон и на разном уровне. Методика, пригодная для создания онлайн-магазина, не подойдет для, скажем, банковской системы - и наоборот. Это, как мне кажется, понимают (практически) все. Проблема в том, что каждый, кто хоть сколько-то проработал в индустрии, наверняка сталкивался с проектами, которые переросли свою исходную базу. Оно по-всякому бывает - неожиданный успех продукта, прототип, засунутый в рабочую систему, накопившийся техдолг - сценариев много, а результат один, весьма болезненный. И всякий, кто с таким сталкивался, хочет этого в дальнейшем избежать. А, поскольку не знают, где именно упадут, то соломку стелят повсюду.
Хороший способ упростить ситуацию — дать кому-нибудь пинка. Потому что не надо страдать фигней.
Как перестать переусложнять и начать жить