Сторонние компоненты — деньги на ветер или экономия средств?

    Многие их тех, кто использует .NET, Delphi и другие средства разработки, рано или поздно сталкивались с выбором: разработать что-то недостающее самому, или приобрести готовое? И со спокойной душой отправлялись писать свои собственные компоненты, неприятно поразившись стоимостью существующих. А так ли велика их цена на самом деле? Вот небольшая история, которая заставила меня взглянуть на стоимость компонентов другими глазами.

    Однажды один мой товарищ, занимающийся разработкой программ для небольшого предприятия, задал мне такой вопрос: «Как думаешь, сколько времени потребуется, чтобы написать грид с сортировкой, группировкой и возможностью редактирования записей?»

    На тот момент я уже несколько лет работал в DevExpress и объём работ более-менее представлял, да и нетрудно было оторваться от кресла и дойти до авторов XtraGrid, чтобы у них выяснить временнУю оценку.

    Сошлись на том, что если писать с нуля, то что-то начнёт работать только месяца через 3 — да и то, получившийся контрол ещё долго придётся дотачивать напильником и править в нём баги. Эту информацию я и сообщил своему товарищу. Затем спросил, а есть ли у него желание в очередной раз изобретать велосипед и не проще ли купить готовый грид, наш XtraGrid, например, или любой другой, устраивающий по функциональности. Его ответ меня несколько удивил: «Купить это конечно хорошо, но как я объясню начальству, что следует купить готовый продукт, а не написать свой самостоятельно?»

    «А действительно, почему?» — подумал я. Полминуты размышлений привели меня к ответу, что это просто-напросто выгоднее. Уточнив размер зарплаты товарища, я выложил свою аргументацию. А она была очень проста.
    Пусть размер оплаты труда программиста составляет $1000 в месяц. При этом он затратит 2-3 человеко-месяца на самостоятельную разработку контрола. Итого $2000-$3000 затрат только на зарплату. Плюс дальнейшее развитие контрола и исправление в нём ошибок тоже займут какое-то время. Кроме того, заказчик получит результат не раньше, чем через указанные 2-3 месяца.

    А можно использовать $1000 чтобы приобрести уже готовые компоненты и затратить пару недель на их изучение и внедрение в программу. Итого получается $1500 и результат за 2 недели. Выгодно? На мой взгляд более чем.

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

    В использовании сторонних компонентов есть и некоторый риск, например, что задачу не удастся решить с их помощью, или найдутся баги в компонентах, которые производитель не спешит исправлять. Поэтому прежде чем покупать, всегда имеет смысл опробовать компоненты, благо все их производители предоставляют достаточный пробный период использования и/или «money back». Скачиваете компоненты и делаете за пару дней на них пробное решение. Если всё хорошо, то вполне вероятно, что ваш выбор удачен.

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

    Взгляните на документацию, которая идёт с компонентами. Мы все не любим читать документацию, но тем не менее в ней чаще всего можно найти ответы на большое количество вопросов. Хорошая документация содержит не только краткое описание свойств и методов компонентов, но и обзорные документы, описывающие архитектуру компонентов, рекомендуемые подходы к их использованию (best practices). Большое количество примеров кода в документации, как простейших, так и более сложных — тоже несомненный плюс.

    Также имеет смысл обратить внимание на качество службы поддержки производителя компонентов. Хорошая служба поддержки и отреагирует на ваш вопрос оперативно, и решение даст правильное. В случаях, где нет простого и прямого решения, предложат вам приложение-пример, где реализована ваша задача или похожая на неё. А уж если и это не помогло — всячески постараются найти обходной путь, чтобы решить вашу задачу.

    Так что оценивайте трудозатраты, скачивайте разные компоненты, сравнивайте и решайте.

    Удачного вам выбора!
    Developer Soft
    75.17
    Company
    Share post

    Comments 46

      +4
      Арифметика действительно простая, но на первый взгляд (и далеко не для всех) очевидная. Только когда сам через это проходишь — убеждаешься, что купить вышло бы дешевле и надёжнее как для разработчика, так и для клиента.
        +8
        На примере проекта существующего более 8 лет, в котором изначально никто не задумывался о составе используемых компонентов:
        — проект становиться тяжело портируемым под новые версии сред разработки;
        — трудно добавлять новый функционал в купленные с исходниками компоненты (каждый пишет как ему удобно);
        — сторонние компоненты с исходниками после правки под себя, перестают развиваться и у Вас есть своя правленная версия, а разработчики идут своим путем.
        При написании своих компонентов Вы сами решаете в какую сторону их развивать, может оказаться так, что при обновлении сторонних компонентов в новой версии не окажется необходимой функции.
          0
          Под каждым пунктом подпишусь самолично. Чего только стоит накатывание своих фиксов\апдейтов на новый релиз того же DevEx'a.
            0
            используйте такие компоненты которые позволяют внедряться и менять свое поведение с помощью плагинов и пр.
            для javaee вариант грида — jmesa на гуглокоде
            +1
            ИМХО, всё перечисленное — это проблемы архитектуры конкретного продукта, а не использования сторонних компонент (о чём, собственно, и повествует первый абзац). Если делать из продукта свалку решений (чужих и собственных) то при любом раскладе ничего хорошего из этого не получится.
            +4
            а еще проще поискать на просторах opensource, ведь существует немалое количество достойных бесплатных компонентов, grid для delphi — EhLib
            бесспорно devexpress тоже достойные компоненты, но смысл покупки оправдан только если будет окупаемость и желательно после 1-го проекта)))
              0
              Еще есть SourceGrid для C# — его конечно нужно допиливать напильником, зато с исходниками и бесплатен.
              +1
              Как-то всё утрировано.

              По времени: если разработчик не один, то разработка будет идти быстрее (по календарному времени), а вот разбирательство и осваивание вряд ли. А если вспомнить про ротацию кадров, то покупка закрытого решения может оказаться ещё дороже (каждому новому сотруднику придётся разбираться, были бы исходники — разбираться было бы быстрее)

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

              Ну и самое главное, не рассмотрена ещё одна альтернатива — разрабатывать не с нуля, а на основе свободных решений, имеющих часть необходимой функциональности (правда тут тоже может быть проблема с начальником, которому надо объяснить, что в некоторых случаях нужно открывать свои доработки, но это проще, чем уговорить его платить деньги :) )
                +2
                Есть среди заказчиков такие потрясающие личности, которые хотят продавать все, что для них сделано. Вплоть до тог доходит, что им на сайт нужно гостевую книгу поставить, но при этом разработав ее с нуля чтобы можно было ее продавать для других проектов…
                  0
                  Встречаются, но и оплату с них надо брать соответствующую и пускай продают. А вообще надо различать ситуации, когда заказчик заказывает именно разработку софта (тогда, обычно, все права ему принадлежать), а когда ему нужна функциональность, и не важно откуда она возьмётся — напишите снуля, используете свои другие наработки или вообще возьмёте open-source.
                  +1
                  У DevExpress исходники тоже доступны (за дополнительные, но отнюдь не запредельные деньги).
                  Конечно, это не Open Source, но только в том смысле, что вы не имеете права эти исходники распространять. А изучать, отлаживать и дорабатывать для себя — пожалуйста.

                  А рассчитывать на то, что написанный для своих нужд компонент удастся продать… Всякое может быть, но конкурировать с фирмами, занимающимися этим профессионально, будет очень сложно.
                  +5
                  А у кого-нибудь из присутствующих был опыт продажи компонентов, разработанных в ходе реализации другого проекта? Поделитесь историей.
                    +2
                    Скачиваете компоненты и делаете за пару дней на них пробное решение. Если всё хорошо, то вполне вероятно, что ваш выбор удачен

                    Я бы поспорил. Только после полутора месяцев использования Silverlight грида от Infragistics всплыла достаточно серьезная проблема, которую пришлось решать ректальным путем. Они просто не предполагали, что это понадобится. Результат — нервы начальства и работа разработчика на грани увольнения. Ну и, помимо этого, постоянное допиливание до нужного функционала, по мелочам.
                      –2
                      Скорее всего требования при выборе компонентов были поставлены не правильно, либо вообще не поставлены. У каждой задачи есть конкретные требования, выявляемые путем анализа. Если Вы этого не сделали, то результат не удивляет. Другое дело, когда компонент не удовлетворяет требованиям новой задачи, но здесь уж как певезет.
                        +1
                        Ну вот нам и не повезло :) Это была как раз новая задача. Так что, фразу «как повезет» можно применить и к теме топика.
                        +4
                        С самописным кодом от этого тоже никто не застрахован
                          +1
                          Более того, при самостоятельной разработке компонента разработчик проходит по всем тем же граблям, по которым проходят разработчики стороннего компонента. Только они уже прошли, и нашли решения.
                            0
                            Либо не прошли/не нашли — тут все от конкретной задачи зависит.
                          +2
                          Что у вас за начальство такое, что за чужие ошибки — сразу работа на грани увольнения.
                            0
                            Это не ошибка была, просто для выполнения новой задачи стал нужен дополнительный функционал, который не был реализован в гриде.
                            А работа на грани увольнения — это, конечно, достаточно образно :) Но неприятностей было бы немало. Жесткий график, серьезный клиент и неожиданное препятствие. Нервная работа у нас, однако… *удерживая дергающуюся бровь руками* Хе-хе…
                            0
                            У меня всплыла ректальная проблема с Silverlight DataGrid ;)

                            А какой грид для сервелата теперь посоветуете?
                              0
                              Зная то, что я знаю сейчас о своем продукте, я бы на самом деле долго колебался бы между Ingragistics и Telerik.
                                0
                                *Infragistics
                                Мучо пардоно
                            +7
                            Неожиданно увидеть DX на Хабре. Текущий проект на работе целиком и полностью построен на компонентах DevExpress'а с небольшими вкраплениями наших контролов, наследованных, опять же, от DX. Изначально он брался из-за нескольких контролов (отчетник очень уж лют :)), но потом стали использовать все.
                            Использование сторонних компонентов в общем-то палках о двух концах: с одной стороны, освобождаешь себя от написания, с другой стороны, меньше контролируешь и ответственность переносится на вендора. DevExpress'ом в общем-то довольны. Какие-то баги с их стороны за 2 года моей работы в проекте появлялись пару раз и саппорт всегда присылал решение. Документация действительно на высшем уровне.
                              +6
                              DevExpress — это самый крупный и серьезный проект сторонних компонентов, который я видел за свою рабочую историю. И насколько я сталкивался с некоторыми компонентам — сделано все очень грамотно и работает хорошо. Конечно возникали и нестыковки и находились ошибки, но без этого не обойтись.

                              И хотелось бы, чтоб кто-то, так же серьезно занялся разработкой компонентов для Qt.

                              А по теме — очень согласен, более того в мире Delphi использование сторонних компонент — это была один из основных подходов. Поэтому компонентов наплодили очень много.
                                0
                                А как же Telerik? Очень плотно покрывают всё для C#/.net
                                  0
                                  ну DevExpress намного древней. А главное — я ничего не знаю о Telerik так как ушел из мира Windows, когда появилась технолгия .NET (не из-за нее :-), а просто так получилось).
                                  Именно поэтому и написал, что «за свою рабочую историю».
                                    +1
                                    Все пытаюсь себя заставить попробовать Телерик в деле, но убивают скины их контролов — после DevExpress, выглядят просто ужасно
                                      0
                                      Хм, раньше были кривые сейчас всё гораздо лучше стало. Веб-контролы от DevExpress очень тяжелые по сравнению с Telerik.
                                      А вот на Win-платформе DX рулят однозначно.
                                  +1
                                  DevExpress — всегда радовали своей документацией. Вы делаете отличный продукт. прикрутите шаблоны к экспорту в хтмл, пожалуйста… :)
                                    0
                                    А вот и наши подтянулись. Welcome! )
                                      +2
                                      Со стоимостью не все так просто: обычно компоненты продаются с лицензиями на каждый компьютер (или очень дорогая enterprise версия) и если программистов много, то стоимость всех лицензий может превысить стоимость собственной разработки.

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

                                      Мы одно время использовали купленные компоненты (правда, купили только одну лицензию), но со временем стали постепенно мигрировать на самописные.

                                      Кстати, грид раньше действительно был камнем преткновения в средствах разработки от Microsoft, т.к. в стандартной поставке не было ничего достаточно функционального. Но с выходом .NET 2.0 появился отличный грид. Он не такой навороченный, как DevExpress, но основную функциональность он покрывает.
                                        +2
                                        С лицензиями кстати у всех по-разному. У нас, например, лицензия на разработчика, а не на компьютер. Т.е. если проект удаётся толково разделить на модули, то вполне реально экономить и при этом не нарушать лицензию. Впрочем, подход с одной лицензией на 100 человек тоже никто не отменял.
                                          0
                                          Обычно у каждого разработчика свой компьютер, так что разницы особой нет, разве что лицензию проще нарушить, т.к. привязаться к разработчику вместо компьютера сложнее.
                                          У нас было разделение на разные модули, в том числе и на UI, бизнес логику и т.д., но разработчики делились по функциональному принципу (финансовый модуль, склад и т.п.). Т.е. каждый разработчик занимался и UI и бизнес логикой, т.е. нуждался в лицензии.
                                          Делить разработчиков на UI и бизнес нереально в сложных проектах, т.к. в этом случае все разработчики должны быть в курсе _всех_ бизнес процессов.
                                        +4
                                        В нашем проекте начали использования компонента dhtmlxGrid (благо была урезанная бесплатная версия). В итоге, через два года использования в проекте — решено в обязательном порядке от него отказаться, как и от любых других сторонних.

                                        Причины банальны и просты: 1) иногда функционала не достаточно, 2) иногда функционал излишен, 3) массивность библиотек, 4) специфика использования, 5) сложность описания «простых» задач…

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

                                        Всё сугубо субъективно. Решайте ДО использования. Думайте о будущем проекта — оно покажет необходимость использования сторонних компонент, а не текущие задачи или «нравится внешне».
                                          0
                                          Ооо, любимые графики от ДевЭкпресса. Мы их выбрали за то, что они умеют сериализоваться :-)
                                            0
                                            Было вот какое дело, давно правда. Использовал ваши компоненты, но когда вышла более новая версия, то вся структура очень сильно поменялась, вплоть до названия мемберов и типов данных. Пришлось много переписывать :-)

                                            А компоненты красивые, заказывать однозначно.
                                              0
                                              а вариант взять готовое опенсорсное не рассматривал ваш коллега? почему вопрос ставится именно так: купить или написать самому?
                                                +1
                                                Вопрос ставился «сколько времени займёт написать»?
                                                Open source тоже вполне себе вариант, особенно если бюджет ограничен.
                                                Как и у любого другого варианта тут есть свои плюсы и минусы.
                                                Из серьёзных минусов я бы отметил следующее. Можно найти open source грид. Можно найти бары. Т.е. многое можно подобрать под свои нужды, но по отдельности. Могут возникнуть сложности при попытке заставить это всё нормально работать в связке. Надо обязательно проверять. Документация и саппорт также не всегда на высоте.
                                                  +2
                                                  Тут коммерческие компоненты хорошего качества с трудом найдешь, а вы про опен-сорс…
                                                  +1
                                                  Ооо! Я вас люблю! Прикуел, если честно, когда узнал что вы из России! Компоненты у вас препрекрасные! cxGrid просто великолепен! Использую, к сожалению пиратские билды, прямо признаюсь… Но от продукта в восторге полном!!! У меня даже кот монитор нюхает когда видит Ваш dxBarManager! Может быть слишом много восторга, но Ваши продукты и впрям облегчили жизнь мне, как разработчику! Спасибо Вам! P.S. ну поделиииитесь лицензией пожалуйста, ну поделиииитесь! =)
                                                    +1
                                                    В случае с DevExpress, как раз переживать нечего. Заплатив деньги (хотя и не малые) можно быть спокойным, что обновления будут вовремя сделаны, баги исправлены, и т.д.
                                                    Если же речь идет о менее именитых наборах компонентов, то тут как раз не все так очевидно. Хотя и цены там значительно либеральнее. Например, вполне можно отдать $50 и за GridEh, даже если автор «устанет» сопровождать библиотеку, полтинник — не те деньги, что бы писать подобный продукт самому.

                                                    PS
                                                    Рад увидеть DevExpress на Хабре!
                                                      +1
                                                      Вопрос к DevExpress — почему компоненты для Silverlight Grid, Menu etc… заточены под нечеловечески большие шрифты?
                                                      Почему под WinForms шрифты нормального размера.
                                                        +1
                                                        Вроде шрифты как шрифты, 8-12. А вообще какие дизайнер в теме задал, такие и используются. Никакой специальной «заточки» нет.
                                                        0
                                                        Эта логика легко масштабируется на «а зачем вообще заказывать разработку если можно купить готовый продукт и настроить?»

                                                        Мой скромный опыт подсказывает, что контролов в VS достаточно для всех разумных желаний заказчика в области интерфейса. Если заказчик хочет странного то проще потратить пол дня и убедить его отказаться от странного, а не тратить пол-года на реализацию его ночного сновидения.

                                                        Ну а если речь об опенсоурс то вопросов меньше — все библиотеки и контролы доступны.
                                                        • UFO just landed and posted this here

                                                          Only users with full accounts can post comments. Log in, please.