Самопис, или готовое решение?

Холиварная и вечная тема по поводу того, писать ли свой велосипед, или использовать готовые решения. Сразу скажу, что на вопрос такого рода нет ответа. Это просто два решения, у каждого из которых есть свои сильные и слабые стороны, исходя из которых нужно делать выбор. Об этих сторонах я и хотел поговорить. Дабы ихбежать холивара, в своих доводах я постарался быть как можно более объективным и не носить заинтересованного оттенка.

Самопис или готовое решение

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

Скорость разработки предусмотреных возможностей

Готовое решение, если оно есть - подходит гораздо лучше, чем самопис, тем более оно уже обкатано и там уже наступили на все встретившиеся грабли. Если область достаточно не популярная - вам может попасться специфическое готовое решение, подходящее вам не полностью. В этом случае принимать решение уже вам. Тем более, что время на поиски решения придется потратить и прогнозировать результат будет сложно. Побеждает коробка

Скорость разработки не всех предусмотренных возможностей

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

Прихотливость приложения

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

Скорость работы приложения (время отклика приложения)

Однозначно - грамотно написаный самопис с учетом всей специфики проекта и знания узких мест будет работать быстрее, иногда в сотни раз. По сути 90% приложений быстродействие глаживается простым вводом кеширования, все на самом деле сильно зависит от специфики работы. Самопис гибче, а по этому позволяет отказаться от сложных конструкций, которые могут создавать лишнюю нагрузку. Для простеньких проектов без особых требований к нагрузке - подойдет любое из решений. Ничья для небольших проектов. Самопис для высоконагруженных проектов

Скорость разработки приложения

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

Обновляемость

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

Ничья. Просто нужно учесть специфику

Ответственность

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

Отвечает разработчик)

Безопасность

Плохой самопис может быть дырявым (не безопасным) и следует это учесть, тут помочь могут только прямые руки разработчика. Тут разобрались.
Как бы не казалось, что коробочное решение сильно обкатано - оно остается уязвимым. Уязвимым его делает доступность и массовость. Каждый понетциальных взломщик может сделать себе копию замка и начать подбирать ключи, пока не получится. А также проанализировать приложение на предмет узких мест для совершения атаки в слабые перегородки защищенной крепости. Тут открытый (скачиваемый) код делает приложение опасным. А массовость делает эту уязвимость еще и ценной. Ведь найти дыру в массовом коробочном решении так вкусно. В качестве награды можно подчинить себе сразу почти все сервисы, что используют это коробочное решение.
Чаще всего уязвимости содержаться в не популярных плагинах к попцулярным коробочным решениям, по этому следует внимально их провреять, если это возможно.
В этом вопросе побеждает грамотный самопис, который также удалось проверить на предмет доступности к взлому.

Побеждает хороший самопис (главное отличить хороший самопис от плохого).

Лицензии

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

Побеждает самопис

Цена

Коробочные решения, особенно редких продуктов могут стоить и стоить не дешево. За них могут браться деньги только за лиценции. И не факт, что все это вам обеспечит именно то, что вы хотите. В этом плане разработчики просят деньги лишь за сам факт разработки - за лиценции нужно будет платить все время. Разработчики просят ещемесячные деньги за поддержку, но поддерживать можно как самопис, так и коробочные решения, которые как закрытый ящик вдруг могут сломаться по совершенно непонятным причинам.
Популярные коробочные решения в основном бесплатны, их разработчики зарабатывают деньги, продавая примочки к ним, или за счет рекламы и популярности, быть может на спонсорах, которые хотят сделать мир чуть лучше.
Цена самописа в этом плане может быть и дорога, все зависит от квалификации разработчика и от бюджета.
Дешевый самопис вам обойдется дешево, но тут есть вероятность заплатить потом дважды. Эта потребность секономить у заказчика может вылиться в большие деньги впоследствии, по этому лучше коробочное решение, чем не опытный самопис.
Не всегда квалифицированные разработчики берут много денег за свои разработки. Тут многое зависит от политики и стратегии. Возможно, решение, которое создает разработчик планируется потом еще где-то использовать, по этому сделать его хоть за какие деньги и сделать его за бесплатно влияет на вопрос стоимости. Возможно, разработчик планирует в дальшейшем зарабатывать на поддержке, или продвижении, чем на самое разработке. Также вопрос может решиться, обеспечив долю от прибыли, или акций, если на начальном этапе денег не много и бюджеты очень ограничены.

Тут все индивидуально. Ничья

Контроль и прогнозирование

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

Риски

Риск, что посредственный разработчик кинет выше, чем популярное коробочное решение исчезнет. Шанс, что разработчик вынужден будет оставить разработку по непредвиденным обстоятельствам тоже существует, по этому крайне важно писать поддерживаемый код и обращаться в команды разработчиков, где между ними сразу будет заменяемость. Это также позволит увеличить скорость разработки. Но следует учитывать, что коробочное решение тоже может перестать поддерживаться, или сменит лицензию, или завысит цену за лицензию в 3 раза, и оно будет накладно - тоже есть. Просчитайте риски заранее.
Грамотный разработчик, дороживший своей репутацией и пишущий код не для галочки, а чтобы его впоследствии поддерживать самому - при соблюдении всех договоренностей (выплат) с обеих сторон - не замотивирован кидать. Просто в этом нет смысла. Тем более, если вы с ним частично знакомы и знаете, где он обитает))

Ничья

Итог

Как и говорилось в начале - все очень индивидуально. Старайтесь использовать преимущества каждого из методов. При грамотной разработке - у разработчика должно и так накопиться своих микрорешений, которые можно объединить в любой блок для быстрой разработки других решений. Ведь по большей части все стандартные популяпные решения сводятся либо к табличным приложениям вида CRUD (блог, faq, форум, контент, агрегатор, магазин), либо к последовательным цепочкам действиям вида BPM (игры rpg, опросы).

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

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

  • Автор: kosmom
  • Рейтинг: 0
  • Просмотров: 496
  • Комментариев: 0
  • Создан: 26.10.2015 16:19

Комментарии (0)