Использование сторонних библиотек или собственная реализация

Что важнее при разработки программного обеспечения: скорость или качество? Как объяснить заказчику, что “быстрый” сыр бывает только в мышеловке? Какое решение выбрать? Какие бывают большие программы? Поговорим об этом в этой статье.

Вступление

Существуют разные задачи для разработчиков, которые всегда имеют ограничения. Не бывает так, что разработчику (или команде разработчиков) была поставлена задача "придумать программное решение" какой-либо задачи, а условиями были бы "неограниченность во времени" и "безмерные финансовые возможности".

Рис.1 "Время - деньги"

Ограничения чаще всего сводятся к установке лимитов по времени. Хотя мой многолетний опыт показывает, что чудеса случаются и задачи бывают (почти) без ограничений. В любом случае, команда разработчиков должна минимизировать временные потери и решить проблему в кратчайшие сроки, причем максимально "красиво". Но проекты бывают разные.

Большие и маленькие проекты

В данной статье рассматриваются проекты, которые ведутся компаниями разработчиками не один месяц или год, то есть долгосрочные проекты. Такие проекты пишутся "под заказ", максимально приближены к потребностям заказчика, постоянно совершенствуются и развиваются, имеют мощнейшую техническую поддержку. То есть, идут в ногу со временем. Еще сам Билл Гейтс говорил: "Программа, которая вышла релизной версии является устаревшей". Что же касается простых задач по разработки ПО, в данном контексте, таковыми являются программы, которые написаны "за один раз"" и не предполагают дельнейшего развития. Причем функциональность программ такого рода может быть не менее сложной чем у долгосрочных продуктов (а то и сложнее), просто решение само по себе не имеет дальнейшего развития. И прежде чем продолжить, хотелось бы оговорить некоторые понятия.

Сторонние компоненты и контролы

Под "сторонними компонентами" имеется в виду конкретные наборы контролов для разных платформ. Например, Telerik, XCEED, DevExpress, хотя, надо сказать, подобных библиотек десятки (если не сотни) в Интернете. Данные наборы имеют очень большой функционал, активно поддерживаются компаниями разработчиками и предназначены для разных платформ. Но все они "заточены" на то, чтобы "содрать" максимальное количество денег у пользователей этими контролами, потому что это коммерческие проекты, и этим всё сказано.

Попробую перечислить "плюсы" сторонних коммерческих продуктов при использовании их в собственных программах:

• Быстрая разработка. (Данное утверждение справедливо только для тривиальных задач)

Странно, но этом всё. Больше ничего в голову не приходит. Есть дополнения? А теперь перечислю "минусы" сторонних коммерческих наборов компонентов:

• Даже если вы являетесь счастливым обладателем версии компонентов с исходными текстами, вы не имеете возможность посмотреть историю разработки (source versions), а это, иногда, бывает очень сильно помогает в решении проблем.
• Все нововведения и исправления, которые выходят на платформе NET (JavaScript) сначала должны быть внедрены разрабочиками сторонных наборов компонентов. То есть, другими словами, вы всегда идет позади тех, кто разрабатывает ваши контролы, а точнее сказать, вы будете у них на "подпевках". Это значит, что они решают "как" и "в какую сторону" развивать свои компоненты, а значит и вашу программу и ее функционал в частности (речь идет о больших проектах).
• Стоимость (у некоторых компаний заоблачная). А некоторые компании требуют ежегодного продления лицензии, что напрямую сказывается на стоимости ваших программных продуктов для конечного пользователя.

Первые два пункта, можно свезти в один - "промежуточное звено или посредник". Посредник, который требует денег за обновления, у которого разработчики имеют разный уровень подготовки, у которого своя скорость написания "нового кода" и поддержка "старого кода". В общем, посредник - есть посредник.

Рис. 2 "Посредник просит денег"

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

Типизация программных задач

Остановимся на основных задачах, которые обычно встают перед разработчиком или группой разработчиков. Далее будем иметь в виду что у нас есть группа людей, то есть коллектив, состоящий из 5-10 разработчиков разной степени подготовленности, которые умеют писать программы на C# (VB), немного знакомы с JavaScript (jQuery), слышали про ООП и про "какие-то паттерны проектирования". Итак, начнем с того, что в процессе разработки так или иначе принимаются во внимание три основных параметра: скорость, качество, цена. Остановимся на каждом из них.

Скорость

Порой скорость играет наиважнейшую роль. Вплоть до того, что если вы не сделаете задачу быстро, то ее быстрее сделает другой коллектив, а значит денежный приз уйдет к соперникам. Но не зря же у русских есть пословица: "Поспешишь - людей насмешишь"? Скорость при разработке - палка о двух концах. И тут обрисовывается первый тип программных задач - "Сделать быстро и забыть". Если задача, поставленная коллективу разработчиков, требует максимально быстрого решения, примите к сведению, что в лучшем случае, на техническую поддержку (обновление, дополнения, сопровождение) вам придется приложить усилий во много раз больше чем на разработку, если вообще, не придется переписывать программный продукт заново. В проектах такого типа абсолютно правильным считается использование сторонних компонентов.

Качество

"Любая программа должна работать и работать правильно!" Это утверждение только одной стороны процесса разработки - заказчика, то есть пользователя. Но есть еще и другая неотъемлемая часть этого процесса - разработчик. Исходя из этого, лозунг должен звучать следующим образом: "Любая программа должна работать и работать правильно! А также должна легко расширяться и масштабироваться, код должен легко читаться, нововведения легко добавляться, служба поддержки должна легко и непринуждённо сопровождать программу!" Получилось немного громоздко, но зато самая суть. Из покон веков и во все времена за качество надо было платить, хотя в сфере разработки ПО получается, что ни за какие деньги не купишь время на разработку и отладку. А покупая отлаженный и работающий код (так заверяют разработчики компонентов, хотя это далеко не так), не гарантии, что код будет работать "правильно" относительно концепции вашего проекта.

Цена

Цена любой разработки зависит от множества параметров. Мне не хочется всех их обсуждать, пусть этим занимаются маркетологи. Я хочу просто акцентировать ваше внимание на том, что хороший и качественный программный продукт написать за пару месяцев невозможно. На моей практике были такие проекты, но через пару-тройку месяцев выходила только бета версия, а далее шла работа по наращиванию функционала и, конечно же, исправление неисправностей. Продукт, который пишется для "одного раза": запустили, работает, расплатились, попрощались, закрыли, забыли, удалили может быть разработан в сжатые сроки, хороший и качественный - нет. И я в очередной раз хочу повториться, что речь идет о больших проектах. Здесь стоит упомянуть о втором типе программных задач - "Программа, которая никогда не закончит писаться".

Подводя итоги

В конечном случае, выбор на способа и инструментов разработки зависит от типа программных задач. Если поставлена задача "максимально быстро написать ПО", которое в дальнейшем не будет развиваться (бывает такое), то тут однозначно использование сторонних коммерческих продуктов, которые максимально облегчать вам "дорогу" к успеху. Но если потребуется в дальнейшем доработка ПО, изменение или наращивание функционала стоит подумать про свои собственные наработки. Однозначных правил и законов нет, существуют и варианты. Например, нужно быстро создать продукт, но существует вероятность, что его придется дорабатывать. В таком случае, в стоимость продукта следует заложить цену на предстоящие расходы, а они, в свою очередь, будут многократно превосходить первоначальный уровень. Единственное что могу посоветовать при выборе подходов реализации проекта - это определить тип задачи. Как мы выяснили в статье их всего два:

1. "Сделать быстро и забыть"
2. "Программа, которая никогда не закончится"

Существуют и вариации на тему, но эти вариации уже "жонглируют" сроками выполнения задач.