Если вы хотите построить дом, начинаете ли вы строить экскаватор?
Представьте, что вы хотите построить дом. Вы определенно не создадите для этого необходимых инструментов. Вы лучше возьмете некоторые существующие инструменты и запачкаете руки. Это кажется очевидным, не правда ли?
Когда люди начинают создавать новый веб-продукт, они часто делают наоборот. Они начинают создавать свой собственный фреймворк или библиотеки.
Это мудрое решение? Вот моя точка зрения.
Может быть несколько причин для создания собственного фреймворка / библиотеки. Если ваш продукт на самом деле является фреймворком, прекратите читать и продолжайте писать код. ;-)
Люди думают, что они должны все писать сами
Некоторые разработчики считают, что им нужно создавать все с нуля и собственными руками. В противном случае они плохие разработчики и не заслуживают ни копейки. Ну давай же! Это фигня. Думаю, все наоборот. Разработчик может показать хорошие навыки, выбрав подходящий фреймворк. Он / она должен оценить различные фреймворки или технологии и привести веские аргументы, почему определенная структура лучше подходит для данных требований.
И это еще не все. Разработчик должен понимать философию и концепции фреймворка.
Некоторым людям только любопытно, и они хотят экспериментировать
Если экспериментирование и любопытство мотивируют писать все с нуля, подумайте дважды. Хотите провести эксперимент в производственной среде с платными клиентами? И помните, что вы также должны поддерживать этот фрагмент кода.
Позвольте задать вам вопрос: вы бы попробовали экспериментальное лекарство?
Узкие сроки
Некоторые могут возразить, что сроки слишком жесткие и что оценка и изучение новой структуры требует слишком много времени. С моей точки зрения, это тоже неверный аргумент. Вот причины: если вы разрабатываете продукт без фреймворка, вам нужно кодировать много вещей, что делалось миллионы раз. Возможно, вам придется кодировать ORM, аутентификацию и авторизацию, проверку и многое другое. Это займет у вас много времени, которое вы бы предпочли потратить на поиск и изучение своего фреймворка.
Фактически, фреймворки сэкономят вам много времени. Вам не нужно создавать общие функции. Они были реализованы и протестированы сообществом, которое фактически отвечает за структуру.
Во всем мире нет адекватной структуры или технологии для вашего передового продукта.
Если это действительно так, что ж, вам нужно построить все с самого начала. Но существует так много существующих фреймворков и библиотек, написанных на стольких разных языках и основанных на стольких различных технологиях. Действительно ли ваш продукт настолько особенный, что вы не можете использовать существующие решения?
Не изобретайте велосипед
Запомните свою первоначальную цель. Вы хотите создать новый продукт, а не фреймворк или библиотеку. Это самое главное. Убедите своего босса, что стоит найти подходящие фреймворки, прежде чем начинать писать код. Вот еще несколько аргументов:
- Фреймворки разрабатываются, тестируются и поддерживаются сообществом очень опытных разработчиков.
- Раньше в продакшене использовались фреймворки. Они стабильны.
- В частности, создание безопасной аутентификации и авторизации является трудным и требует много времени.
- Фреймворки задокументированы. Коллегам легче начать писать код, если есть нехватка ресурсов.
- Разработчики могут сосредоточиться на реализации продукта. Следовательно, скорость разработки увеличится.
- Юридические проблемы. Если вы хотите интегрировать оплату, ваше приложение должно соответствовать определенным критериям.
Некоторые из аргументов применимы и к другим инструментам. Это, например:
- Инструменты сборки вроде gulp или grunt.
- Инструменты зависимости, такие как maven, composer и npm.
- Генерация шаблонов с йоменом.
Все они сокращают процесс разработки и помогают поддерживать продукт в будущем.
Фреймворки и библиотеки для всех
Фреймворки и библиотеки не ограничиваются серверными приложениями. Они существуют также для клиентских целей и тестирования. Назову несколько из них:
Вывод
Если вы создаете продукт, используйте одну из замечательных фреймворков или библиотек на рынке. Существуют фреймворки практически для всех целей. Они помогают сократить время вывода на рынок, и вы производите продукт более высокого качества.
Если вы действительно хотите создать фреймворк / библиотеку, делайте это в свободное время или в качестве побочного проекта. И есть также возможность внести свой вклад в существующие фреймворки с открытым исходным кодом.
В одном из моих текущих проектов мы решили использовать Laravel PHP Framework для создания API. В одном из следующих постов блога я объясню, почему.
Аргументов, безусловно, намного больше. Некоторые читатели также могут не согласиться с моей точкой зрения. Не стесняйтесь оставлять комментарии и высказать свое мнение.
