The Question
август 2016.
238

В каких ситуациях лучше пользоваться готовыми решениями?

Ответить
Ответить
Комментировать
0
Подписаться
1
2 ответа
Поделиться

С одной стороны, мы одни из немногих, кто всегда выступал евангелистом использования готовых стандартных решений, но, вообще говоря, мир не настолько универсален и потребности заказчиков диктуют использование разных прикладных систем. Высокопроизводительная процессинговая система и система аналитики работают принципиально по-разному, они требуют особого подхода к производительности различных частей инфраструктуры. Что-то масштабируется вертикально, что-то – горизонтально. Единообразие здесь пока невозможно. Есть допущения, совершенно невозможные в большом бизнесе. В малом бизнесе ты можешь закрыть глаза на производительность каких-то вещей и сказать: «Хорошо, я буду использовать унифицированную инфраструктуру».

И с высокой степенью вероятности для 98% случаев тебе действительно этого хватит. Другое дело, если мы проектируем платежную систему Сбербанка, то, мягко говоря, это не то же самое, что построить платежную систему микрофинансовой организации. Это разные подходы, разные «головные боли». Большие корпорации всегда порождают более сложные требования, там другой уровень конкуренции. Почему нас радуют унификации там, где они возможны – потому что это, условно говоря, в 70% случаев избавляет нас от большой головной боли. В масштабах корпорации это очень много.

0
0
Прокомментировать

Это был вопрос риторический? Сам спросил, сам ответил? ;-) А я вот тут начну воду мутить!

Как VP R&D в высоко-технологичной международной компании, программист с 25-тилетним опытом работы (до сих пор hands-on, кстати), скажу так - я предпочитаю всё in-house! При динамически развивающемся продукте нет никакой возможности в длительных интеракциях с 3rd-party (сторонними?) разработчиками по поводу каждого мало-мальски незначительного измения в API. Я уж не говорю про backward compatibility (обратная совместимость?)! Это вообще головная боль... :-\ Стараюсь при разработке не использовать сторонние решения, если есть возможность внутренней реализации. Ну, кроме, конечно, явных примеров с "не своих" решений - решений, не являющихся основой продукта. Как у нас, например, платежные системы - естественно, интерграции.

Единственный приемлемый подход в использовании "готовых решений" - это инженерный подход ко всей системе в целом, изначальная нацеленность на интеграции и интерфейсное программирование. Архитектура, в которой много R и мало D, если так можно выразиться. Но для этого нужен именно такого типа архитектор, нужны, чаще всего, совешенно другие специалисты в команде... И главное - команда крутых специалистов, которые будут это "большое R" осуществлять. А уж "D" можно и оффшорно набрать.

Кроме того, в случае старт-апа преимущественно иметь минимум сторонних интеграций, потому как при продаже фирмы акцент сильно смещается в область проприетарных решений ;-) и происходит серьезный анализ продукта на возможные лицензионные упущения.

P.S. Все вышеизложеное - IMHO.

P.P.S. Прошу прощения за англизмы - не всегда знаю, как перевести слова, которые никогда не использовала в русском варианте.

0
0
Прокомментировать
Ответить
Читайте также на Яндекс.Кью
Читайте также на Яндекс.Кью