• 30 октября 2017, понедельник
  • Санкт-Петербург, Свердловская набережная 44Д БЦ Лето, офис компании Wrike

Java и велосипеды: когда стоит вкладываться в написание собственных инструментов на бэкенде?

Регистрация на событие закрыта

Извините, регистрация закрыта. Возможно, на событие уже зарегистрировалось слишком много человек, либо истек срок регистрации. Подробности Вы можете узнать у организаторов события.

Другие события организатора

2342 дня назад
30 октября 2017 c 19:00 до 22:30
Санкт-Петербург
Свердловская набережная 44Д БЦ Лето, офис компании Wrike

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

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

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

Встреча может быть интересна людям, принимающим архитектурные решения на проекте —опытным Java-разработчикам, архитекторам, техническим лидерам, да что уж, всем бекенд-девелоперам с высоким уровнем осознанности☺

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

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

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

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

Как вы думаете, в современной автомобильной промышленности при каких обстоятельствах автоконцерн вкладывается в разработку своего собственного стеклоподъемника, а не возьмет готовый, хороший и стандартный агрегат? Или когда автоконцерн занимается разработкой нового аккумулятора, а не довольствуется стандартным? Может, даже приведете пример такой компании? 
Или вот вы, как часто лично вы собираете себе пылесос собственными руками из подручных средств или, скажем, шьете костюм на заказ в ателье? Или, может, все-таки «нормальный» юзкейз — это поход в магазин и выбор домашнего помощника или обновки из числа уже готовой продукции, возможно, с некоторыми компромиссами относительно своих первоначальных представлений об идеальном кандидате, например, в виде отсутствующих перламутровых кнопок или присутствующих крылышек?
А вот в нашей области разработки ПО почему-то написание собственных велосипедов возведено чуть ли не в романтическую степень. Более того, разработчики гордятся своими велосипедами, активно ими делятся и выкладывают на github, демонстрируя, как минимум, наличие тонны свободного времени! Честно говоря, мне кажется, большинство таких «велосипедов» оказывается либо проектами уровня «Hello World» с целью научиться чему-нибудь, либо, как в том анекдоте: «Мы не помним для чего мы изобрели бильярдный шар, из которого растут волосы, но это было адски сложно».
В своем выступлении я как прагматичный разработчик порассуждаю над вопросами, которые должен задать себе «велосипедист» или тимлид «велосипедиста», прежде чем отправляться в Тур Де Франс. Я приведу примеры библиотек и фреймворков, появление которых было, на мой взгляд, обосновано и продиктовано прагматичным подходом, а также приведу примеры творений, появление которых я не могу объяснить, исходя из прагматичных соображений.​

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

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

 

Как добраться до Wrike

--

Регистрация

Рекомендуемые события

Организуете события? Обратите внимание на TimePad!

Профессиональная билетная система, статистика продаж 24/7, выгрузка списков участников, встроенные инструменты продвижения, личный кабинет для самостоятельного управления и еще много чего интересного.

Узнать больше