Спасибо за такой развёрнутый комментарий! Это отличное дополнение к разделу о негативных сторонах стандартизации.
К сожалению, Вы правы, стандартизация может закончиться плачевно. Но дело, как мне кажется, не в стандартизации, а в руководстве. Без стандартизации дела, скорее всего, шли бы ещё хуже. Если разработкой стандартов и контролем занимается целый департамент, что мешает ему постоянно следить за развитием и обновлением стандартов? Только менеджмент. Руководство либо не понимает, как с этим работать, либо его такая ситуация устраивает.
Да! Кода стало примерно на треть меньше, он стал существенно проще. Стали тратить меньше времени на доработки, в часах не измеряли, но это отметили многие разработчики.
Ещё один эффект обнаружили, когда нужно было сделать большую сложную форму с валидацией. Форма на библиотеке до хуков заметно лагала в IE, после обновления на новую версию библиотеки всё заработало нормально.
Давайте на примерах: приведение дат к строкам в разных форматах, создание строки поиска с автодополнением, валидация ввода пользователя, шифрование данных, запросы к серверу и обработка ошибок — типичные задачи для фронтенда, в котором я работал. Вряд ли всё это вы будете писать с нуля, скорее всего вы будете использовать наработки вашей компании или найдёте решение в интернете, так быстрее. Если вы работаете в компании, в которой несколько команд уже не первый год делают проекты, новые задачи, которые до вас никто не решал, будут встречаться довольно редко. Отдельная история — это бизнес-логика, но и здесь значительный объём будет покрыт готовыми решениями.
Вот на самом деле не важно, на чём этот Вася пишет, пока он пишет один, когда их становится 10, это уже другая история. И тут один стек даст и общие библиотеки, и общие темы для разговоров, и переходы разработчиков из проекта в проект, и другое, о чём было в статье. Всё остальное тоже важно, безусловно, я не предлагаю упираться в один стек, но он действительно даёт многое.
К сожалению, не для всех эти вещи очевидны, иначе стандартизации уделялось бы больше внимания. Часто в разработке идут по модели Diversity, сваливают в кучу разные технологии и подходы, я постоянно это вижу. Давайте попробуем Ramda, а вот ещё есть Immutable. Это же крутые штуки. Давайте в этом приложении будем использовать стандартную архитектуру с Redux, а в этом не будем, тут можно обойтись контекстом.
Если такова политика компании, руководство намеренно выбрало такой путь, понимая, что хочет получить от такого разнообразия — тогда это ок. Но часто руководство не лезет в разработку и не понимает последствий таких решений.
Единый стек может быть, взять, например, Сбербанк или Альфу. Есть основной стек, есть стандартизированная разработка, веб пишется на одном, мобильные приложения на другом. Внутри веба тоже есть и Angular, и React, но в рамках одного направления всё довольно стандартно, большое количество команд пишет примерно одинаково.
Сейчас сложно сказать, переход занял около двух месяцев, переводом занимался один разработчик, ему иногда помогал второй, оба параллельно решали ещё и задачи других проектов. Чтобы перевести проекты с Flow на TS, не так много кода нужно изменить, а вот с хуками пришлось повозиться.
Банальный кодинг во фронтенде — явление довольно редкое, особенно если речь идёт о больших проектах, а их у нас не мало, и только готовыми решениями не обойтись. Тут как с фреймворками: в них уже решена куча инженерных задач для того, чтобы разработчики решали другие инженерные задачи.
Начинающие программисты решают задачи на своём уровне, пользуясь готовыми шаблонами и библиотеками, а те, для кого это уже просто, могут заняться например развитием инфраструктуры криптографических операций (работа с электронно-цифровыми подписями), а это очень не банальная история.
Поэтому хочу сказать, что квалификация персонала у нас разная, и для каждого уровня есть свои задачи.
Мы обычно используем термины «программист» или «разработчик», когда говорим о наших коллегах, но Вашу мысль я понял, и она выдаёт в Вас человека с опытом.
Да, потрудиться пришлось, как результат мы действительно получили хорошую взаимозаменяемость, и возможность нанимать разработчиков с квалификацией от уровня Junior для разработки промышленных проектов.
Те же, кто знает, как лучше, обычно делают как лучше, потому что чаще всего они действительно знают, как лучше, поскольку большая часть из них выросла в компании до того уровня, когда уже можно принимать решения. А для тех, кто считает, что знает, как лучше, но это не точно, мы внедряем систему мотивации, которая позволяет направлять творческую энергию энтузиастов на решение актуальных проблем компании, поощряя активность и новаторство в нужном направлении, и недопоощряя активность там, где не надо. Здесь правила игры удобно привязать к деньгам, тогда всем жить становится легче.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
К сожалению, Вы правы, стандартизация может закончиться плачевно. Но дело, как мне кажется, не в стандартизации, а в руководстве. Без стандартизации дела, скорее всего, шли бы ещё хуже. Если разработкой стандартов и контролем занимается целый департамент, что мешает ему постоянно следить за развитием и обновлением стандартов? Только менеджмент. Руководство либо не понимает, как с этим работать, либо его такая ситуация устраивает.
Ещё один эффект обнаружили, когда нужно было сделать большую сложную форму с валидацией. Форма на библиотеке до хуков заметно лагала в IE, после обновления на новую версию библиотеки всё заработало нормально.
Если такова политика компании, руководство намеренно выбрало такой путь, понимая, что хочет получить от такого разнообразия — тогда это ок. Но часто руководство не лезет в разработку и не понимает последствий таких решений.
Единый стек может быть, взять, например, Сбербанк или Альфу. Есть основной стек, есть стандартизированная разработка, веб пишется на одном, мобильные приложения на другом. Внутри веба тоже есть и Angular, и React, но в рамках одного направления всё довольно стандартно, большое количество команд пишет примерно одинаково.
Начинающие программисты решают задачи на своём уровне, пользуясь готовыми шаблонами и библиотеками, а те, для кого это уже просто, могут заняться например развитием инфраструктуры криптографических операций (работа с электронно-цифровыми подписями), а это очень не банальная история.
Поэтому хочу сказать, что квалификация персонала у нас разная, и для каждого уровня есть свои задачи.
Да, потрудиться пришлось, как результат мы действительно получили хорошую взаимозаменяемость, и возможность нанимать разработчиков с квалификацией от уровня Junior для разработки промышленных проектов.
Те же, кто знает, как лучше, обычно делают как лучше, потому что чаще всего они действительно знают, как лучше, поскольку большая часть из них выросла в компании до того уровня, когда уже можно принимать решения. А для тех, кто считает, что знает, как лучше, но это не точно, мы внедряем систему мотивации, которая позволяет направлять творческую энергию энтузиастов на решение актуальных проблем компании, поощряя активность и новаторство в нужном направлении, и недопоощряя активность там, где не надо. Здесь правила игры удобно привязать к деньгам, тогда всем жить становится легче.