[Программирование, Управление разработкой, Управление продуктом, Микросервисы] Суровая правда о разработчиках и разработке

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
10-Фев-2021 17:33

Цитировать

Давным-давно, в одной далёкой галактике появились персональные компьютеры и люди всех возрастов и профессий, у кого был доступ к этому чуду инженерной мысли, стали придумывать и писать программы, как для работы, так и просто, забавы ради. Несмотря на то, что вычислительная техника уже существовала к тому моменту и университеты выпускали юнцов с профильной специализацией, профессия разработчика не была распространённой и касалась в основном научно-исследовательских лабораторий - ребят в белых халатах. Персональные компьютеры сдвинули эту ситуацию с мертвой точки: у небольших компаний появилась возможность упростить свою ежедневную деятельность, а дома ПК можно было использовать даже для игр!Огромных зарплат в те времена не было, компании по разработке ПО создавались романтиками в съемных комнатушках-офисах, в которых часто приходилось и ночевать. Кто-то не выдерживал и сдавался, кто-то создавал шедевры и богател, но в те времена никто не говорил, что люди получают зарплату просто так. Те времена подарили нам кучу программ, часть из которых остаются самыми популярными в своей сфере и по сей день (Например, MS Excel. Страшно думать, но до сих пор большинство инвестиционных банкиров используют для своих моделей именно MS Excel). Те времена подарили нам таких людей как Питер Нортон и Андерс Хейлсберг или Джон Кармак с Сидом Майером, если игры вам ближе.В конце 90х, с повсеместным развитием интернета, стали проявляться первые тревожные звоночки. Зарплаты разработчиков стали расти вместе с акциями доткомов, этот пузырь стал притягивать к себе любых людей, способных написать хоть какой-то код. Вместо людей, прекрасно знающих свою область стали появляться случайные люди, которые хоть как-то справлялись с поставленными задачами. Единственным плюсом, наверное, был тот факт, что пока еще эти ребята не диктовали бизнесу, как он должен работать.Доткомы благополучно умерли и лет на десять чума современной разработки исчезла, чтобы вернуться в начале десятых годов 21 века с новой силой. Укоренившийся в жизни интернет привел к тому, что любой конторке больше пяти человек стал требоваться сайт (а лучше портал) и потребность в разработчиках (а, следовательно, и зарплаты) стала расти. В России за пять лет зарплаты выросли с 200 долларов до тысячи и десятки тысяч молодых «специалистов» принялись штурмовать новые горизонты.Команды росли, сложность решений росла, люди, основавшие бизнес, постепенно стали отходить от дел и перестали контролировать какие-либо процессы разработки, в результате чего разработка фактически превратилась в вещь в себе. Отдельную отрицательную роль в этом процессе сыграли гиганты IT рынка типа Гугла, который возвел практику работы на корзину в ранг нормы, паразитируя на традиционном бизнесе и вливая кучу денег в решения, не имеющие какого-либо смысла. Люди, принимающие решения по ИТ, стали везде пихать опыт FAANG всюду и везде, давя авторитетом «Что вы будете спорить с компаниями, зарабатывающими сотни миллиардов?». Стоимость разработки продолжала расти, хотя никакого прорыва в технологиях с начала двухтысячных не произошло.Почему растет стоимость разработки? Ответ, на самом деле, тут прост и банален. Бизнес слабо понимает, что происходит в разработке, а разработка на самом деле работает сама на себя, делая то, что нравится, а не то, что надо, попутно внедряя в процесс кучу лишних людей. Разработчикам нравятся новые технологии, и они пытаются впихнуть их везде, где им дадут. Например, в моей текущей компании «на хайпе» стали внедрять BigData обосновывая это возможностью тонкой настройки бизнеса. Знаете, к чему это привело? Сотни миллионов денег были потрачены на то, чтобы сказать, что товары, которые покупают на точке в дорогом ТК в центре отличаются от товаров, покупаемых на окраине рядом с ЖД станцией. Серьезно? Вы потратили такой бюджет на то, чтобы найти факты, которые очевидны любому, кто занимался ритейлом? Другое «прорывное» решение касалось в определении людей, кто часто бывает рядом и предложении им семейных контрактов. О да, тут точно нужна BigData, без нее никак. Отдельная команда целый год пилила очень нужный в 2018 году блокчейн для голосовалок. Никто понятия не имеет, как его можно использовать в текущем бизнесе, но раз деньги выделяют, то почему бы и нет? Мы же не можем отставать по инновациям от Сбера? А Сбер не может отставать от Гугла?Отдельно упоминания, безусловно, стоят микросервисы и контейнеры, которые пихают везде и вся. Попробуйте в 2021 году пойти на собеседование и сказать, что вы не понимаете, зачем нужны микросервисы. Вас поднимут на смех! Скажут: «А как же хайлоад?», «А как же независимые команды?», «А как же отдельные стэки?».Ты пытаешься выяснить, что же за хайлоад. На проверку оказывается, что там 200 запросов в секунду в пике. Ребята, Asp.Net Core + MVC + EF + PG держит 185 тысяч запросов в секунду single-query. Какой у вас хайлоад? И да, все еще забывают, что количество запросов к нагрузке также имеют очень маленькое отношение. В случае того же Твитера нет никаких бизнес-критичных запросов, мы можем ставить сотни одинаковых инстансов и проксировать запросы как душе угодно, никто не пострадает. Это вам даже не Букинг какой-нибудь, где на последний номер может быть несколько желающих.Другой веселый юмор — это независимые команды. Сидят, значит двадцать человек. И они никак не могут поделить обязанности, чтобы не мешать друг-другу. Тут значит, они начинают пилить 4 микросервиса по 5 человек в команде и волшебным образом сразу проблемы все решаются. Да нет же, проблемы не решатся. Их станет в разы больше.Вот тут хорошо написано. Вам будет сложнее выделять домены, тестировать, деплоить. Вам даже просто понадобиться куча дополнительных людей высокой квалификации, начиная от архитектора, кончая тестировщиками с девопсами.Отдельная песня – это возможность команде самой определять стэк, на которой ей удобно работать. Ну вы знаете, тот знаменитый подход, который приводит к командам на Java, Go, C++, Rust и NodeJS на одном бизнес-проекте. Причем вместе с несколькими SQL и NoSQL одновременно. Так ведь удобно потом нанимать разработчиков на каждый из стэков и поддерживать кодовую базу в актуальном состоянии. Так удобно следить за безопасностью сотен пакетов на каждый из фреймвороков. Так приятно, когда один и тот же код для интеграций с системами аутентификации или мониторинга повторяется на каждом фреймворке заново. Так удобно иметь отдельные конвейеры CI/CD и команду поддержки под каждый стэк. Нет, если вы Гугл и у вас есть десятки тысяч инженеров хорошей квалификации, которым по факту нечего делать, то подход имеет право на существование. Но если вы не Гугл, то зачем повторять худшие практики?Ну и вишенка на торте – это лишние люди в конвейере производства программного обеспечения. Да, вот эти ребята, типа скрам мастера или эджайл коуча. Как-же без них удавалось спутники запускать и ММОРПГ создавать? Современные команды ведь настолько профессиональны и заточены на результат что никак не могут самостоятельно оценить и распределить таски, им обязательно нужны пара нянек.Я сам получаю деньги за то, что пишу код с 2006 года, в этом году будет 15 лет юбилея. И мне очень горько понимать, что моя любимая отрасль, которая подарила множество прекрасных продуктов, технологий или игр превратилась в огромного паразита, который воспроизводит сам себя и пытается высосать все соки. Сложно сказать, кто в этом виноват и когда свернули не туда. Факт состоит в том, что современное IT скорее тянет на дно бизнес, чем помогает ему развиваться. Все современные IT гиганты делали свое имя много лет назад при помощи других людей. Да, современный бизнес невозможен без IT. Но все забывают, что IT это прежде всего поддерживающее звено, а не основа мироздания. Какими бы не были прорывные технологии, условный Нетфликс все-таки будет оцениваться качеством контента.Что делать?Хотелось бы прояснить, почему вообще у меня пригорает на тему ситуации в IT. Как-то сложилось, что за свою жизнь я был активным пользователем IT продуктов. И уже не первый год, как я стал замечать, что качество продуктов, падает год к году. Яснее всего это видно, конечно же, в игрострое. Все идеи, которые успешно доят до сих пор появились лет 20-30 назад. MVP сего парада стал безусловно Warcraft 3: Reforged и Star Citizen. Однако нельзя сказать, что и в других отраслях таких проблем нет. Качество поиска Гугла стабильно падает. Фейсбук редизайнит так, что лучше бы вообще не трогал. И все это при том, что разработчиков в штате компаний все больше и больше. В качестве решения накопленных проблем мне лично видятся следующие меры:

Переход от экстенсивного развития к интенсивному: пересмотр бизнес-процессов в сторону упрощения, снижение количества регламентов;
Упрощение процесса разработки за счет более простых и эффективных бизнес процессов и прозрачной системы принятия решений;
Использование в рамках компании стандартных стеков технологий и пакетов;
Формирование центров компетенций разработки для поддержания актуальности стэков технологий, формирования стандартных шаблонов проектов компании и архитектур;
Подбор оптимальной архитектуры под бизнес требования;
Сокращение time-to-market за счет активного переиспользования кодовой базы, шаблонов и простой архитектуры;
Сокращение людей не увеличивающих ценность продуктов, таких как скрам мастер, эджайл коуч и прочих.

Если все это не сделать в ближайшее время и не повысить эффективность разработки, то есть высокая вероятность, что IT потянет на дно компании и нас будет ждать второй пузырь доткомов.А что Вы думаете о текущем этапе развития IT. Какие проблемы видите лично Вы, насколько они кажутся серьезными и как их лучше решать?
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_programmirovanie (Программирование), #_upravlenie_razrabotkoj (Управление разработкой), #_upravlenie_produktom (Управление продуктом), #_mikroservisy (Микросервисы), #_dotkomovskij_puzyr_2.0 (доткомовский пузырь 2.0), #_mnenie (мнение), #_problemy_razrabotki (проблемы разработки), #_monolit (монолит), #_mikroservisy (микросервисы), #_programmirovanie (
Программирование
), #_upravlenie_razrabotkoj (
Управление разработкой
), #_upravlenie_produktom (
Управление продуктом
), #_mikroservisy (
Микросервисы
)

Профиль ЛС

Ответить на тему

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

Текущее время: 22-Ноя 13:49
Часовой пояс: UTC + 5