Есть много разных подходов, которые вы можете выбрать перед тем, как начать программировать, когда в вашей голове всплывает абстрактная идея о каком-то приложении или решении проблемы. если у вашей идеи есть веб-интерфейс — выбор еще больше.
Существует несколько языков программирования, с помощью которых вы можете кодировать для веб-сайтов, настольных компьютеров и мобильных платформ — C#, Java, Python, C++ и так далее. Если вы знаете разные языки программирования, то выбранный язык должен наиболее подходить для решаемой вами задачи. Некоторые языки содержат много абстракций и хороши для логики высокого уровня и прочего, другие обращаются к оборудованию и напрямую переключают биты с максимальной эффективностью и скоростью. Другое разделение, которое начинает исчезать, — это разделение между объектно-ориентированными языками и функциональными. С каждой новой версией каждый язык становится похожим на любой другой — с объектно-ориентированными API, с функциональными функциями, такими как лямбда-функции, необязательные переменные и параметры, расширения и так далее.
Второй фильтр при выборе языка программирования должен быть тот, который вы знаете лучше всего и с которым вы наиболее продуктивны. Это хорошая идея — знать разные языки и иметь в арсенале разные подходы, но в конце дня вас ждет ваша бизнес-логика, и вы должны быть быстрыми в ее реализации. Несколько человек, которых я знаю, являются языковыми гуру и энтузиастами и немного закрыты для использования других языков, чем другие. С наличием фреймворков и API-интерфейсов для каждого случая и платформы это, вероятно, не имеет большого значения или не мешает показу, и вы, вероятно, могли бы жить с одним языком.
(KISS) Keep It Simple & Stupid — этот подход, вероятно, хорош для относительно небольших по размеру проектов и приложений. Зачем использовать jQuery, какой-то сложный фреймворк с разделением бизнес-логики, пользовательского интерфейса, доступа к базе данных, толстого фреймворка Javascript — CSS, зачем использовать back-end фреймворк с несколькими уровнями абстракции и разделением архитектурных компонентов, если приложение до конца его жизнь будет мала? Если появятся новые вещи, в любом случае потребуется полная переработка. Почему бы не сделать его маленьким и простым — как код, как количество зависимостей и так далее?
Контроллер представления модели — MVC — это один из фундаментальных шаблонов проектирования в программировании для отделения представления от модели, от контроллера (бизнес-логики), особенно при разработке веб-сайтов, приложений и платформ. Это стало настолько распространенным шаблоном, что он даже встроен в изначально считавшуюся клиентской технологией, такой как JavaScript.
Компонентно-ориентированные фреймворки. Компонентно-ориентированные фреймворки можно найти везде — на сервере, на клиенте, на настольном компьютере и на мобильных платформах. Мое первое личное знакомство с ним и опыт моих коллег были двадцать лет назад — с Borland Software. Затем он был интегрирован в Microsoft Visual Studio. Так что какой-то проект с открытым исходным кодом захватил его, потому что это концепция, а не частная технология.
Сегодня, особенно в качестве Java-разработчика, у вас есть большой выбор компонентно-ориентированных фреймворков. Самые известные из них и те, которые я затронул: JSF, Apache Wicket, Google Web Toolkit и Vaadin. Последние два уже интегрированы в мой Инструмент для создания баз данных.
Еще одна характеристика, которую вы можете выбрать, когда думаете о среде программирования для Интернета, — это выбор ориентированного на клиента против ориентированного на сервер или где-то посередине.
Десять лет назад читал статью в твиттере, которая показала в бенчмарке, что серверный рендеринг html был самым быстрым, потому что при использовании клиентского фреймворка, где браузер сначала загружает скрипт, потом информацию и на третьем шаге — визуализирует контент, вместо первого шага — показать контент — с какой-то серверно-ориентированной структурой.
Еще одним преимуществом является то, что html, сгенерированный сервером, лучше индексируется поисковыми системами. Этот плюс, вероятно, исчезает, потому что сегодня пауки умны и действуют очень похоже на браузер. Акцент сместился с кода на скорость (с точки зрения отзывчивости сайта и взаимодействия с пользователем).
Минусы сгенерированного сервером html — если он сгенерирован вручную, а не каким-то фреймворком — он не так поддается тестированию. Кроме того, если приложение закодировано в режиме, ориентированном на клиента, а не на сервере, может быть применено некоторое кэширование кода и данных и другие оптимизации.
