 |
У нас всегда есть выбор. Разрабатывать фреймворки самим, или взять готовый у поставщика. Java, Spring, Hibernate, etc. Если мы берем что-то “из коробки”, вполне можем сделать хороший продукт. Если мы хотим создать нечто особенное, существенно выделяющее нас по сравнению с конкурентами, разработка собственных инструментов может быть оправдана — мы будем точно понимать, как он устроен, и сможем выжать из него максимум. Так в каком же случае имеет смысл вкладываться в разработку internal-инструментов, а в каком можно довольствоваться готовыми решениями?
Появляются новые версии больших фреймворков для основных языков, развивается опенсорс и так или иначе поднимаются вопросы, в каком случае архитектор проекта имеет право на эксперименты с новыми технологиями? Когда эти инструменты можно разворачивать на уровне всей компании? Насколько гибкость в выборе технологий зависит от размера, возраста проекта, внутренних или внешних заказчиков.
Между разработкой собственного продукта и разработкой на заказ есть множество различий — собственная разработка живет по другим правилам, и именно поэтому одно и тоже решение может быть плохим для outsourcing, но красивым и элегантным в разработке своего продукта.
Встреча может быть интересна людям, принимающим архитектурные решения на проекте —опытным Java-разработчикам, архитекторам, техническим лидерам, да что уж, всем бекенд-девелоперам с высоким уровнем осознанности☺
Программа и спикеры:
1. Дмитрий Мамонов, Wrike "От велосипедов к мотоциклам: почему разработка собственных решений может быть лучше использования готовых фреймворков".
Я расскажу, чем процесс разработки собственного продукта отличается от outsourcing проектов с технической точки зрения, когда имеет смысл вкладываться в разработку с нуля, а когда лучше взять готовое решение. Будет несколько примеров наших проектов, на которых я покажу, какие преимущества мы получили, взявшись делать собственные решения, и с какими трудностями столкнулись в процессе.
2. Владимир Красильщик, Яндекс «Добро пожаловать, или велосипедистам вход воспрещен»
Как вы думаете, в современной автомобильной промышленности при каких обстоятельствах автоконцерн вкладывается в разработку своего собственного стеклоподъемника, а не возьмет готовый, хороший и стандартный агрегат? Или когда автоконцерн занимается разработкой нового аккумулятора, а не довольствуется стандартным? Может даже приведете пример такой компании?
Или вот вы, как часто лично вы собираете себе пылесос собственными руками из подручных средств или, скажем, шьете костюм на заказ в ателье? Или может все-таки «нормальный» юзкейз — это поход в магазин и выбор домашнего помощника или обновки из числа уже готовой продукции, возможно с некоторыми компромиссами относительно своих первоначальных представлений об идеальном кандидате, например, в виде отсутствующих перламутровых кнопок или присутствующих крылышек?
А вот в нашей области разработки ПО почему-то написание собственных велосипедов возведено чуть ли не в романтическую степень. Более того, разработчики гордятся своими велосипедами, активно ими делятся и выкладывают на github, демонстрируя, как минимум, наличие тонны свободного времени! Честно говоря, мне кажется большинство таких «велосипедов» оказывается либо проектами уровня «Hello World», с целью научиться чему-нибудь, либо, как в том анекдоте: «Мы не помним для чего мы изобрели бильярдный шар, из которого растут волосы, но это было адски сложно».
В своем выступлении я как прагматичный разработчик порассуждаю над вопросами, которые должен задать себе «велосипедист» или тимлид «велосипедиста», прежде чем отправляться в Тур Де Франс. Я приведу примеры библиотек и фреймворков, появление которых было на мой взгляд обосновано и продиктовано прагматичным подходом, а также приведу примеры творений, появление которых я не могу объяснить, исходя из прагматичных соображений.
3. Вячеслав Лапин, EPAM — "Взлом "кривой входа"
Изобретение "велосипедов" — прекрасный приём для обучения! Начинающие художники в основном копируют картины мастеров, так почему в IT NIH-синдром считается злом? Ведь чтобы понять, как работает библиотека или фреймворк, лучше всего самостоятельно попытаться решить ту проблему, которую они решают, написав, как правило, что-то подобное.
С тех пор, когда наша отрасль отказалась от модели "получил образование — пошёл работать, используя накопленный багаж знаний до самой пенсии", и перешли к модели постоянного, перманентного обучения (фактически, обучение и работа стали одним, единым процессом), велосипедостроение прекрасно нас в этом поддерживает, фактически составляя суть практики при обучении — мы читаем туториалы, статьи, смотрим выступления на конференциях и пытаемся что-то из этого пробовать в своих боевых проектах, находя, таким образом, кратчайший путь по "кривой входа" в новую для себя технологию.
Однако часто это не является кратчайшим, дешевейшим и безопаснейшим путём решения задач бизнеса заказчика, так что редкий заказчик на такое согласится. Куда в такой ситуации деваться "бедному разработчику" — об этом и пойдёт речь в моём докладе.