Сейчас мы имеем огромное количество все возможных фреймворков, и кажется что за нас уже всё написано, и осталось только взять и сложить всё по частям. Но на самом деле всё не так просто. Большое количество фреймворков является одной из проблем, о которых я хочу поговорить.
Вот лишь несколько областей, где могут возникнуть проблемы с фреймворками:
Я думаю, что это можно считать самой большой и самой фундаментальной проблемой с которой сталкиваются разработчики. Перед выбором конкретного фреймворка, необходимо четкое понимание того, почему вы выбираете его, и действительно ли он соответствует вашим потребностям. Я очень часто сталкиваюсь с проектами, где изначально был выбран не правильный фреймворк, и это влечёт за собой множество проблем.
Возьмём к примеру Hibernate, очень полезный фреймворк, который тем не менее не всегда является правильным инструментом для работы. Очень часто Hibernate применяют для проектов, где требуется всего 5-10 различных SQL запросов. Вместо того чтобы написать хороший код, который использует JDBC, используют Hibernate, и проект становиться раздутым, с дополнительной зависимостью от Hibernate и большим количеством не нужного кода.
Также я встречал проблемы с Hibernate в тех случаях, когда проект строился с использованием уже существующей базы данных, которая в свою очередь имеет очень сложную и не гибкую схему. И хотя в целом Hibernate сильно упрощает ORM, в этих случаях он только добавляет проблем и очень сложно соединить Hibernate и сущестующую схему сохранив все достоинства обоих.
Аналогичная ситуация возникает при применении Application Server’ов. Хотя они не являются фреймворками, они тем не менее продоставляют прекрасную возможность сделать неправльный выбор. Очень часто Application Server применяют для простого web приложения, когда на самом деле хватило бы простого Servlet Container’а. Аналогичная ситуация что и с ORM, когда нужно всего несколько SQL запросов.
Фреймворки (и сервера приложений) должны соответствовать требованиям проекта. В противном случае, от их применения вы скорее получите недостатки чем достоинства.
Непонимание внутренней работы фреймворка может привести к непредсказуемым результатам. Зачастую это приводит к страшной производительности. Возьмём к примеру опять же Hibernate. Если вы не понимаете, как это работает, то легко написать код, который создает огромное количество SQL запросов. Вы в конечном итоге будете долго не понимать в чём проблема, и почему ваше приложение настолько медленно работает.
Помимо понимания внутреннего устройства, нужно просто прочитать документацию, и хотя бы поверхностно знать некоторые возможности фреймворка, средства настройки и т.п. Очень часто у разработчиков возникают какие либо проблемы просто потому что они не читали документацию. Можно неделю биться над проблемами с ActiveMQ, читать логи, смотреть исходники и дебажиться с ними, а можно изначально знать что это настраивается через определённое свойство в URL и потратить на это 2 минуты.
Если вы решили использовать фреймворк, то вам нужно иметь хотя бы общее представление о том, как он работает.
Слишком большое разнообразие на выбор
По иронии судьбы, так как в настоящее время настолько много различных фреймворков, то может быть очень трудно выбрать какой именно использовать. Может быть несколько подходящих вариантов которые могут решить ваши проблемы. Например, сколько Dependency Injection фреймворков существуют в настоящее время? Что вы выберете String, Guice, или что-то еще? Не так просто узнать, какой из них будет работать лучше в ваших условиях, и вы можете ломать голову в течение длительного времени пытаясь решить. Большое количество вариантов, действительно становится проблемой (хотя это, безусловно, лучше, чем отсутствие таковых).
Будьте осторожны, когда вы читаете список фозможностей фреймворка. Может показаться, что это решение вашей проблемы, но вы можете быть разочарованы после того, как закатали рукава и начали работать с ним. Авторы или поклонники некоторых фреймворков аннонсируют, что их фреймворки могут делать почти все, в реальности же часто их возможности оказываются ограниченными.
Также иногда начинающие разработчики, которые даже не хотят понять, как решить конкретную проблему, просто хотят найти фреймворк и надеяться, что он сделает всё за них. Результаты, конечно, оказываются плачевными.
Прежде чем выбирать фреймворк, не жалейте времени, чтобы изучить его. Постарайтесь понять, как он работает и является ли он подходящим для ваших задач. Не правильно выбранный фреймворк может осложнить вашу задачу и поставить весь проект под угрозу. Для некоторых конкретных задач, вам, возможно, вообще не нужен какой либо фреймворк. Просто напишите код сами.
Имейте в виду, что, как только вы начинаете использовать какой-либо фреймворк, в дальнейшем может быть очень трудно отказаться от него, так как вы внесли уже слишком много зависимостей в ваш код.
P.S. Я не хотел сказать ничего плохого о Hibernate. Я считаю Hibernate хорошим фреймворком и упоминал его лишь в качестве примера.
//Спасибо за внимание
Вот лишь несколько областей, где могут возникнуть проблемы с фреймворками:
- Выбор правильного инструмента для работы
- Понимание внутреннего устройства
- Слишком большое разнообразие
Выбрать правильный инструмент для работы
Я думаю, что это можно считать самой большой и самой фундаментальной проблемой с которой сталкиваются разработчики. Перед выбором конкретного фреймворка, необходимо четкое понимание того, почему вы выбираете его, и действительно ли он соответствует вашим потребностям. Я очень часто сталкиваюсь с проектами, где изначально был выбран не правильный фреймворк, и это влечёт за собой множество проблем.
Возьмём к примеру Hibernate, очень полезный фреймворк, который тем не менее не всегда является правильным инструментом для работы. Очень часто Hibernate применяют для проектов, где требуется всего 5-10 различных SQL запросов. Вместо того чтобы написать хороший код, который использует JDBC, используют Hibernate, и проект становиться раздутым, с дополнительной зависимостью от Hibernate и большим количеством не нужного кода.
Также я встречал проблемы с Hibernate в тех случаях, когда проект строился с использованием уже существующей базы данных, которая в свою очередь имеет очень сложную и не гибкую схему. И хотя в целом Hibernate сильно упрощает ORM, в этих случаях он только добавляет проблем и очень сложно соединить Hibernate и сущестующую схему сохранив все достоинства обоих.
Аналогичная ситуация возникает при применении Application Server’ов. Хотя они не являются фреймворками, они тем не менее продоставляют прекрасную возможность сделать неправльный выбор. Очень часто Application Server применяют для простого web приложения, когда на самом деле хватило бы простого Servlet Container’а. Аналогичная ситуация что и с ORM, когда нужно всего несколько SQL запросов.
Фреймворки (и сервера приложений) должны соответствовать требованиям проекта. В противном случае, от их применения вы скорее получите недостатки чем достоинства.
Понимание внутреннего устройства
Непонимание внутренней работы фреймворка может привести к непредсказуемым результатам. Зачастую это приводит к страшной производительности. Возьмём к примеру опять же Hibernate. Если вы не понимаете, как это работает, то легко написать код, который создает огромное количество SQL запросов. Вы в конечном итоге будете долго не понимать в чём проблема, и почему ваше приложение настолько медленно работает.
Помимо понимания внутреннего устройства, нужно просто прочитать документацию, и хотя бы поверхностно знать некоторые возможности фреймворка, средства настройки и т.п. Очень часто у разработчиков возникают какие либо проблемы просто потому что они не читали документацию. Можно неделю биться над проблемами с ActiveMQ, читать логи, смотреть исходники и дебажиться с ними, а можно изначально знать что это настраивается через определённое свойство в URL и потратить на это 2 минуты.
Если вы решили использовать фреймворк, то вам нужно иметь хотя бы общее представление о том, как он работает.
Слишком большое разнообразие на выбор
По иронии судьбы, так как в настоящее время настолько много различных фреймворков, то может быть очень трудно выбрать какой именно использовать. Может быть несколько подходящих вариантов которые могут решить ваши проблемы. Например, сколько Dependency Injection фреймворков существуют в настоящее время? Что вы выберете String, Guice, или что-то еще? Не так просто узнать, какой из них будет работать лучше в ваших условиях, и вы можете ломать голову в течение длительного времени пытаясь решить. Большое количество вариантов, действительно становится проблемой (хотя это, безусловно, лучше, чем отсутствие таковых).
Будьте осторожны, когда вы читаете список фозможностей фреймворка. Может показаться, что это решение вашей проблемы, но вы можете быть разочарованы после того, как закатали рукава и начали работать с ним. Авторы или поклонники некоторых фреймворков аннонсируют, что их фреймворки могут делать почти все, в реальности же часто их возможности оказываются ограниченными.
Также иногда начинающие разработчики, которые даже не хотят понять, как решить конкретную проблему, просто хотят найти фреймворк и надеяться, что он сделает всё за них. Результаты, конечно, оказываются плачевными.
Заключение
Прежде чем выбирать фреймворк, не жалейте времени, чтобы изучить его. Постарайтесь понять, как он работает и является ли он подходящим для ваших задач. Не правильно выбранный фреймворк может осложнить вашу задачу и поставить весь проект под угрозу. Для некоторых конкретных задач, вам, возможно, вообще не нужен какой либо фреймворк. Просто напишите код сами.
Имейте в виду, что, как только вы начинаете использовать какой-либо фреймворк, в дальнейшем может быть очень трудно отказаться от него, так как вы внесли уже слишком много зависимостей в ваш код.
P.S. Я не хотел сказать ничего плохого о Hibernate. Я считаю Hibernate хорошим фреймворком и упоминал его лишь в качестве примера.
//Спасибо за внимание