Необычный митап про Java в Питере 30 октября

    Для тех, кто устал от технических митапов про библиотеки, инструменты, фреймворки, мы приготовили кое-что совсем иное — встречу-дискуссию “Java и велосипеды: когда стоит вкладываться в написание собственных инструментов на бэкенде?”



    У нас всегда есть выбор. Разрабатывать фреймворки самим, или взять готовый у поставщика. Java, Spring, Hibernate, etc. Если мы берем что-то “из коробки”, вполне можем сделать хороший продукт. Если мы хотим создать нечто особенное, существенно выделяющее нас по сравнению с конкурентами, разработка собственных инструментов может быть оправдана — мы будем точно понимать, как он устроен, и сможем выжать из него максимум. Так в каком же случае имеет смысл вкладываться в разработку internal-инструментов, а в каком можно довольствоваться готовыми решениями?

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

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

    Программа и спикеры:

    1. Дмитрий Мамонов, Wrike «От велосипедов к мотоциклам: почему разработка собственных решений может быть лучше использования готовых фреймворков».

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

    2. Владимир Красильщик, Яндекс «Добро пожаловать, или велосипедистам вход воспрещен»

    Как вы думаете, в современной автомобильной промышленности при каких обстоятельствах автоконцерн вкладывается в разработку своего собственного стеклоподъемника, а не возьмет готовый, хороший и стандартный агрегат? Или когда автоконцерн занимается разработкой нового аккумулятора, а не довольствуется стандартным? Может, даже приведете пример такой компании?

    Или вот вы, как часто лично вы собираете себе пылесос собственными руками из подручных средств или, скажем, шьете костюм на заказ в ателье? Или, может, все-таки «нормальный» юзкейз — это поход в магазин и выбор домашнего помощника или обновки из числа уже готовой продукции, возможно, с некоторыми компромиссами относительно своих первоначальных представлений об идеальном кандидате, например, в виде отсутствующих перламутровых кнопок или присутствующих крылышек?

    А вот в нашей области разработки ПО почему-то написание собственных велосипедов возведено чуть ли не в романтическую степень. Более того, разработчики гордятся своими велосипедами, активно ими делятся и выкладывают на github, демонстрируя, как минимум, наличие тонны свободного времени! Честно говоря, мне кажется большинство таких «велосипедов» оказывается либо проектами уровня «Hello World», с целью научиться чему-нибудь, либо, как в том анекдоте: «Мы не помним для чего мы изобрели бильярдный шар, из которого растут волосы, но это было адски сложно».

    В своем выступлении я как прагматичный разработчик порассуждаю над вопросами, которые должен задать себе «велосипедист» или тимлид «велосипедиста», прежде чем отправляться в Тур Де Франс. Я приведу примеры библиотек и фреймворков, появление которых было, на мой взгляд, обосновано и продиктовано прагматичным подходом, а также приведу примеры творений, появление которых я не могу объяснить, исходя из прагматичных соображений.​

    3. Вячеслав Лапин, EPAM — «Взлом „кривой входа“»

    Изобретение «велосипедов» — прекрасный приём для обучения! Начинающие художники в основном копируют картины мастеров, так почему в IT NIH-синдром считается злом? Ведь чтобы понять, как работает библиотека или фреймворк, лучше всего самостоятельно попытаться решить ту проблему, которую они решают, написав, как правило, что-то подобное.

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

    Однако часто это не является кратчайшим, дешевейшим и безопаснейшим путём решения задач бизнеса заказчика, так что редкий заказчик на такое согласится. Куда в такой ситуации деваться «бедному разработчику» — об этом и пойдёт речь в моём докладе.

    Регистрация
    Онлайн-трансляция
    • +15
    • 2,5k
    • 6
    Wrike 90,90
    Wrike делает совместную работу над проектами проще
    Поделиться публикацией
    Комментарии 6
    • +1
      > Как вы думаете, в современной автомобильной промышленности при каких обстоятельствах автоконцерн вкладывается в разработку своего собственного стеклоподъемника, а не возьмет готовый, хороший и стандартный агрегат? Или когда автоконцерн занимается разработкой нового аккумулятора, а не довольствуется стандартным? Может, даже приведете пример такой компании?
      > А вот в нашей области разработки ПО почему-то написание собственных велосипедов возведено чуть ли не в романтическую степень.

      А еще в нашей области разработки ПО очень любят дурацкие метафоры. Стеклоподъемник делает очень ограниченную задачу. И интеграция простейшая — +12В, масса, подключение к CAN-шине (на худой конец к сигнальному опять же 12В проводу) — все!
      А теперь вспомните фреймворки — шаг в сторону от задуманного автором фреймворка — и начались проблемы…
      • +1
        Об этом тоже будем говорить, приходите.
      • +3
        Да потому что 99% костюмов в магазине — такой дерибас, что лучше уж заказать у мастера (и будет дешевле чем тот 1% нормальных костюмов).
        • 0
          Бронированное стекло, стекло большого размера, стекло необычной формы, стекло с необычной траекторией движения — и стандартный не подойдёт
          • +1
            Как вы думаете, в современной автомобильной промышленности при каких обстоятельствах автоконцерн вкладывается в разработку своего собственного стеклоподъемника, а не возьмет готовый, хороший и стандартный агрегат?

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


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

            • 0
              ой, да я вас умоляю — в мире программирования столько уже готовых, отточенных решений, что достаточно просто не быть мудаком, чтобы их не применить. НО! если ты мудак, а вокруг тебя не технические люди и велики шансы убедить их в том, что то, что ты им предлагаешь — это именно то, что им нужно. И не важно, что есть уже 100500 готовых решений, без заусенец и являющиеся де-факто стандартами — они об этом не то, что не знают, но и через 5 лет не узнают.

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

            Самое читаемое