Заявка на услуги DST
Наш специалист свяжется с вами, обсудит оптимальную стратегию сотрудничества,
поможет сформировать бизнес требования и рассчитает стоимость услуг.
Как выбрать правильный стек технологий для веб-приложения
Перед запуском каждого проекта в сфере IT проходит множество процессов планирования и принятия решений. Эта фаза планирования имеет решающее значение и может оказать значительное влияние на будущее проекта.
Выбор правильного стека технологий может повлиять на время разработки, стоимость, качество приложения, а также на масштабируемость, поэтому так важно принять правильное решение, даже если вам нужно потратить больше времени, анализируя все плюсы и минусы доступных решений.
В этой статье разработчики Веб-студии DST Global (dstglobal.ru) объяснят вам, что на самом деле представляет собой стек технологий веб-приложения, и, кроме того, рассмотрим доступные технологии, их плюсы и минусы и попытаемся выбрать, какая технология подходит для конкретного случая. Кроме того, мы выбрали несколько важных факторов, которые следует учитывать перед принятием решения о стеке технологий.
Когда технологии выбраны, каждому внешнему проекту по-прежнему необходимо принять еще несколько решений, таких как структура вашего внешнего приложения, которые помогут вам поддерживать и масштабировать его.
Начнем с объяснения того, какой стек технологий находится во внешнем интерфейсе.
Что такое стек технологий?
Стек технологий - это комбинация языков программирования, фреймворков и программного обеспечения, используемых для создания приложения.
Каждое веб-приложение состоит из двух частей: клиентской и серверной. Клиентская сторона - это все, что пользователи могут видеть на экране. Важнейшими элементами технологического стека на стороне клиента являются:
- HTML, который отвечает за отображение содержимого в браузере,
- CSS стилизует контент,
- Javascript отвечает за интерактивную часть веб-приложения.
Эти технологии можно использовать с полезными фреймворками, такими как Bootstrap или React.js.
Серверная часть приложения не видна конечному пользователю, она обеспечивает данные для клиентской части. Что касается серверной части, мы должны принять во внимание выбор:
- язык бэкэнд-программирования, такой как Java или C #,
- такие фреймворки, как Spring или .NET,
- база данных, такая как PostgreSQL или MongoDB,
- сервер, такой как Apache или Nginx, или выберите бессерверную архитектуру.
Когда вы планируете следующий технологический стек приложения, вы должны учитывать серверную и клиентскую стороны. В этой статье мы углубимся в стек технологий внешнего интерфейса и рассмотрим различные возможности разработки внешнего интерфейса.
Обзор фреймворков Frontend
Современные фреймворки внешнего интерфейса могут управлять всеми тремя элементами пользовательского интерфейса; у них есть HTML-шаблоны, стили и интерактивные функции.
Прямо сейчас есть три наиболее распространенных фреймворка на выбор; это ReactJS, Angular и VueJS.
Чтобы иметь возможность выбрать любую из них, хорошо знать больше о каждой из технологий, поэтому мы пройдемся по каждой и опишем их с точки зрения стека внешних технологий и архитектуры внешнего интерфейса.
ReactJS
ReactJS - это не фреймворк; это UI-библиотека, созданная Facebook и поддерживаемая огромным сообществом. ReactJS подходит для менее сложных приложений и больше ориентирован на расширенный пользовательский интерфейс и повторно используемые компоненты на очень сложной логике внешнего интерфейса.
ReactJS имеет богатую экосистему, которая состоит из самого ReactJS и библиотеки React-DOM для управления объектами DOM. Далее React-Router, который отвечает за маршрутизацию. Кроме того, он поставляется с JSX, который является расширением синтаксиса для Javascript для создания шаблонов в ReactJS. Чтобы сделать разработку проще и быстрее, очень полезны инструменты разработчика React.
Кроме того, если вы планируете мобильное приложение для своего проекта, ReactJS имеет структуру для мобильной разработки под названием React Native, которая очень похожа на сам ReactJS.
С точки зрения компании, наиболее существенными преимуществами ReactJS являются относительно низкая стоимость разработки и короткие сроки разработки. Кроме того, найти разработчиков со знаниями ReactJS несложно, а технология присутствует на рынке уже давно, поддерживается большим создателем и огромным сообществом. Это означает, что ReactJS не исчезнет и не перестанет поддерживаться в ближайшее время.
Давайте быстро подведем итоги, когда выбор ReactJS для вашего следующего проекта будет хорошей идеей и почему.
- Если приложение, которое вы планируете, имеет расширенный пользовательский интерфейс со множеством повторно используемых компонентов и множеством манипуляций с DOM, хорошо использовать ReactJS.
- Если у вас сжатые сроки, ReactJS также будет хорошей идеей.
- Если у вас средний бюджет и хотя бы один senior-разработчик с опытом планирования и создания приложений ReactJS.
Это не лучший выбор, если приложение имеет расширенную логику или не может нанять опытного разработчика, который смог бы спланировать рабочий процесс приложения.
ReactJS легко изучить, но он не требует от разработчиков писать качественный код, поэтому вам всегда нужен опытный человек в команде, который позаботится об этом.
Angular
Большой конкурент ReactJS - Angular. В отличие от первой описанной технологии, Angular - это фреймворк, и он хорош для сложных проектов с более продвинутой логикой.
Angular имеет встроенную надежную экосистему разработки, такую как маршрутизация или управление состоянием. У него также очень чистая архитектура, и все разбито на три разных файла (логика, шаблон и стили).
Еще одним преимуществом сайта Angular является то, что его легко интегрировать с бэкэндом MVC.
Angular также заставляет разработчиков планировать и разрабатывать приложения до того, как они начнут работать над ним, что продлевает разработку и повышает качество проекта.
С точки зрения компании и руководства Angular обеспечивает очень высокое качество разрабатываемого проекта, но увеличивает стоимость приложения, а время разработки немного больше. Angular был создан Google и поддерживается одной из крупнейших IT-компаний, поэтому не нужно беспокоиться о том, что наш код быстро устареет. Недостатком выбора Angular в качестве основной технологии проекта является то, что нелегко найти разработчиков, знающих эту технологию, а обучение - непростое.
Подведем итог и по Angular.
- Если проект большой и сложный, со сложной логикой, но довольно простым пользовательским интерфейсом, Angular будет хорошим решением.
- Если вы заботитесь о качестве кода и хотите, чтобы ваш проект имел надежную масштабируемость, Angular - ваш выбор.
- Если у вас в команде есть Angular-разработчики, выбрать этот фреймворк - отличная идея.
Если приложение, которое вы планируете, больше ориентировано на пользовательский интерфейс и имеет много манипуляций с DOM, тогда было бы гораздо лучше выбрать что-то другое.
VueJS
Последней из самых популярных технологий, используемых в настоящее время во внешнем интерфейсе, является VueJS.
Vuex, который является менеджером состояний для VueJS, намного проще поддерживать, чем Redux.
VueJS, как и ReactJS, требует внешних свобод для создания полноценной экосистемы, но готовых решений гораздо меньше, что делает это немного рискованным.
Кроме того, у VueJS нет большой компании, и он не поддерживается огромным сообществом, поэтому неизвестно, как долго он будет поддерживаться.
С точки зрения руководства и компании VueJS - это малобюджетное решение, и разработчики могут легко изучить структуру, поэтому вам не нужен высококвалифицированный разработчик с многолетним опытом работы в этой технологии. Если вы хотите сократить время разработки, а проект небольшой, VueJS будет отличным решением.
Подведем итоги решения VueJS.
- Если приложение, которое вы разрабатываете, представляет собой небольшой побочный проект или небольшой MVP, то VueJS - отличное решение.
- Если у вас небольшой бюджет и только начинающие разработчики, также неплохо выбрать VueJS.
- Если у проекта нет большой логики и больших требований к пользовательскому интерфейсу, а дедлайн близок, VueJS - хорошее решение.
Javascript или Typescript?
Есть два решения при выборе основного языка программирования для внешнего интерфейса; это Javascript и Typescript, которые являются синтаксическим расширением Javascript.
В некоторых случаях требуется Typescript; например, когда вы решите создать свой проект с помощью Angular. Но VueJS и ReactJS не требуют использования Typescript, хотя могут иметь много преимуществ.
Во-первых, использование Typescript сокращает время разработки, поскольку сокращает количество ошибок, влияет на обслуживание приложения и упрощает его. Кроме того, эту технологию поддерживают все современные фреймворки. Кроме того, с помощью Typescript может быть проще разработать интерфейс, если бэкэнд еще не готов, но мы знаем, какой тип данных мы получим.
Единственным недостатком Typescript является то, что его не очень просто настроить с помощью ReactJS или VueJS.
Хорошая новость заключается в том, что Typescript создан Microsoft, поэтому очень мала вероятность, что он будет забыт, и вам придется переделывать приложение.
Подводя итог, можно сказать, что выбор Typescript может упростить и ускорить процесс разработки и помочь избежать частой отладки, что может быть очень важно, особенно до дедлайна.
CSS, Less или Sass?
Хотя современные фреймворки внешнего интерфейса могут предоставить вам все элементы, важные в стеке технологий вашего внешнего проекта, вы решаете, как вы хотели бы писать стили в приложении.
Написание стилей на чистом CSS не очень удобно в больших проектах. Наличие огромных файлов CSS может превратить разработку любого проекта в кошмар, затягивая процесс.
Чтобы упростить задачу, неплохо решить использовать какой-либо препроцессор, например Less или Sass. Их очень легко реализовать в проекте, использующем Webpack, и код становится намного чище.
И Less, и Sass позволяют нам использовать миксины, наследование или переменные, поэтому, если необходимо срочно изменить брендинг и цвета во всем приложении, это больше не проблема.
Единственная разница между Sass и Less заключается в том, что Sass написан на Ruby, поэтому он должен быть установлен на вашем компьютере, а Less написан на Javascript, поэтому для его запуска требуется установленный Node.js.
С точки зрения компании, самым большим преимуществом использования препроцессоров является экономия времени, и это позволяет нам избежать трудностей с поддержкой приложения, особенно когда оно будет расти.
Что следует учитывать при выборе технологического стека для проекта?
На этом этапе мы хотели бы остановиться на некоторых факторах, которые должны быть важны для каждого, кто принимает решение о техническом стеке интерфейсных приложений.
Размер приложения
Первый фактор, который следует учитывать при выборе технического стека, вероятно, довольно очевиден, потому что самым важным является размер приложения, потому что с размером проекта растет и сложность.
Время разработки
Еще один важный фактор при выборе технологического стека для проекта - это время вывода приложения на рынок.
Если времени мало, вам нужно выбрать технологию, которая не требует длительного планирования, разработка не сложна, и вы можете обратиться к разработчикам, которые знают эту технологию.
В случае длительного вывода на рынок вы можете рассмотреть несколько факторов, чтобы сделать правильный выбор.
Безопасность
Учитывая, что вы тратите много денег на приложение, вам нужно, чтобы оно было безопасным. Тем более, что количество кибератак продолжает расти, нужно серьезно отнестись к этому, чтобы позаботиться о безопасности своих данных.
Большинство популярных фреймворков внешнего интерфейса содержат некоторые рекомендации по безопасности. Вам нужно позаботиться о том, чтобы следовать всем этим рекомендациям в процессе разработки.
Стоимость
Для многих компаний это один из самых важных факторов. Большинство фреймворков и инструментов являются бесплатными и имеют открытый исходный код, но все же вам нужно нанять разработчиков, поэтому вам нужно рассчитать, сколько разработчиков вам понадобится, чтобы завершить приложение за определенный период времени с помощью выбранной технологии.
Помимо стоимости разработки, вам необходимо принять во внимание расходы на обслуживание и серверные расходы. Если вы хотите сократить расходы на обслуживание, возможно, стоит подумать о бессерверной архитектуре для вашего приложения.
Масштабируемость и поддержка
Также важно думать о будущем приложения. Если вы хотите, чтобы оно увеличивалось, оно должно быть легко масштабируемым и поддерживаемым. Добиться этого легко, просто нужно выбрать хорошую структуру проекта и позаботиться об использовании надежных технологий.
В зависимости от типа проекта вам может быть необходимо обратить внимание на еще несколько факторов, например производительность. Не забудьте переосмыслить каждый аспект приложения, чтобы вы могли спланировать его до его запуска, а внедрение любых изменений архитектуры становится действительно дорогостоящим.
Вывод
Выбор правильного технического стека важен для успеха приложения, которое вы планируете создать, и для плавного завершения процесса разработки до дедлайна.
Чтобы сделать правильный выбор, разработчики Веб-студии DST Global (dstglobal.ru) советуют среди всех доступных на рынке интерфейсных технологий, вы должны внимательно изучить наиболее важные функции приложения и посмотреть на факторы, которые могут так или иначе повлиять на решение.
Разным приложениям нужен другой подход, поэтому стоит помнить, что если предыдущий проект был выполнен с помощью Angular и был успешным, текущему может потребоваться другая технология.
Также стоит взглянуть на разницу между Javascript и Typescript и подумать, какой из них будет лучшим выбором для приложения.
Как выбрать правильный стек технологий для веб-приложения
Напишите нам прямо сейчас, наши специалисты расскажут об услугах и ответят на все ваши вопросы.
Комментарии и отзывы экспертов
Вам может быть интересно
Если вы разрабатываете веб-приложения на PHP, то вы, вероятно, сталкивались с необходимостью использовать какой-то фреймворк, то есть набор инструментов и библиотек, которые упрощают и ускоряют вашу р...
В быстро развивающемся мире веб-разработки выбор правильной платформы имеет реша...
Изучите с разработчиками компании DST Global, альт...
В этой статье разработчики компании DST Global рас...
С каждым днем популярность Javascript возрастает. ...
Фреймворки PHP произвели революцию в веб-разработк...
В этой статье специалистами DST Global исследуется...
Новые комментарии
DST Platform это система управления контентом (CMS) на базе искусственного интел...
Конечно нашей компании не нужен встроенный ИИ в систему управления, но в будущем...
Работаем в DST CRM уже несколько лет, отличная и очень удобная система
на счет Vue. На нем можно писать абсолютно любой сложности проекты Но еще больший плюс, что Vue можно подключить к любой html страницы, и вам не нужно устанавливать кучу пакетов, сборщиков, но вы можете пользоваться любимым инструментов везде и всегда. Ведь никто не будет разворачивать angular или react ради простенького сайта. А с Vue этого и не надо.
Разработанный с учетом постепенного внедрения, Vue может быть интегрирован в существующие проекты разработчиков поэтапно. Мне это нравится, потому что дает вам возможность посмотреть, насколько вам нравится Vue, прежде чем принимать серьезное решение использовать его для разработки.
Тем не менее, если вы предпочитаете, вы можете использовать его для создания сложных приложений с нуля!
Основная библиотека Vue ориентирована на уровень представления, что упрощает подбор и интеграцию с другими библиотеками или существующими проектами.
В сочетании с вспомогательными библиотеками он также хорошо подходит для сложных СПА-центров. Ознакомьтесь с Vue.js курсом, если это то, что вас заинтриговало.
Его привязка к данным и реагирующие компоненты предлагают эффективный и простой способ управления состоянием приложения и создания динамических пользовательских интерфейсов.
Vue также предлагает богатую экосистему, включая Vue Router для маршрутизации, Vuex для управления состоянием и Vue CLI для построения строительных лесов проекта.
Это делает его комплексным решением для разработчиков, ищущих баланс между производительностью, гибкостью и простотой использования.
Так как же писать такое приложение правильно? Разумеется, однозначного, а тем более единственно верного ответа на этот вопрос не существует. Различные организации, группы и индивидуальные программисты склоняются к своим, отвечающим их требованиям и предпочтениям методам и подходам. Кроме того, существуют устоявшиеся в силу тех или иных причин и широко применяемые решения, которые, так или иначе, справляются с поставленными задачами.
Не секрет, что при написании веб-приложения, помимо очевидной реализации требуемой функциональности, необходимо добиваться максимальной эффективности. Конечно, для скромных частных проектов это не особенно важно, но для крупных коммерческих проектов — жизненно необходимо. Давайте заглянем глубже.
Термин «эффективность» сам по себе достаточно широк, но мы в рамках нашего контекста определим его следующим образом: чем быстрее исполняются функции приложения и чем меньше аппаратных ресурсов они при этом потребляют, тем приложение эффективнее. Исходя из такой трактовки и нужно подходить к выбору средств и инструментов для создания нужного веб-приложения.
В каждом индивидуальном случае этот выбор должен делаться с учётом специфики конкретной задачи, но можно выделить и ряд общих рекомендаций, к которым мы пришли после достаточно обширного опыта работы по общепринятому образцу.
Итак, общеизвестно, что наиболее важным этапом создания любого ПО является проектирование его архитектуры. Здесь учитываются все требования и особенности и принимаются стратегические решения. Когда общая структура приложения определена, можно говорить о выборе подхода к её реализации, необходимости встраивания механизмов контроля, возможности расширения и масштабирования.
Говоря о контроле и тестируемости, уместно будет вспомнить известную истину, что возможность проверить работу приложения в различных условиях и с разнообразным набором данных — бесценна и не всегда достижима. Тем не менее, различные логи и механизмы оповещения, срабатывающие по определённым условиям, способны значительно облегчить тестирование и отладку.
Однако самой, наверное, неожиданной рекомендацией будет избегать любых сторонних библиотек и фреймворков всегда, когда это возможно. Это относится как к клиентской части приложения, так и к серверной. Приложение должно быть максимально компактным и потреблять минимальное количество ресурсов. Например, использование очень популярной библиотеки jQuery (или ей подобных) значительно замедляет работу клиентской части и требует немало ресурсов, что совершенно не обязательно. Абсолютно всё, что нужно, можно написать просто на JavaScript, а более быстрая загрузка и работа клиентской части будет высоко оценена заказчиком.
То же относится и к серверной части, а особенно к построению API для взаимодействия между ними. Для этой цели вполне достаточно использования устоявшихся протоколов CGI или WebSocket там, где это нужно. Различные фреймворки типа ORM несколько облегчают работу программиста ценой снижения эффективности приложения, да ещё и добавляют зависимость от этих библиотек и привносят в систему все их недоработки.
Гораздо эффективнее написать все необходимые сервисы самостоятельно на выбранном языке. Это радикально поднимет эффективность системы, ведь она не будет содержать лишнего кода, а тот код, который будет написан специально для реализации конкретной функциональности, будет исполняться намного эффективнее кода общего назначения.
Да, собственно написание приложения по таким принципам сложнее и чаще всего дольше, чем при использовании библиотек общего назначения, но ведь оно пишется один раз, а работает годами. Нам представляется разумным создание именно индивидуально ориентированных приложений (подобно индивидуальному пошиву костюма). Именно такой подход позволяет создавать быстрые надёжные эффективные приложения, которые, при должном уровне исполнения, значительно превзойдут системы общего назначения.
Чтобы написать хорошее приложение, его надо написать. Буквально — в блокноте, в формате основных идей о том, как оно должно работать и из каких логических частей состоять. Это не про «контроллер берёт данные из модели и отправляет на отрисовку». Это про то, какие логические части есть в приложении и как они друг с другом общаются.
Не советую бездумно гнаться за всем «модным и молодёжным»: не можете объяснить, зачем вам GraphQL и какие у него преимущества перед простым REST API из трёх запросов, — не используйте. Кажется, это очевидно, но я сам не раз попадал в эту ловушку. Подход «открыть awesome-лист и поставить всё» тоже не лучшее решение: наличие огромного количества сторонних зависимостей не делает проект круче.
Вопрос «какой фреймворк/ОРМ/админку использовать» решается просто: выбирайте тот инструмент, который лучше всего знаете. Ничего не знаете и не умеете — берите то, с чем быстрее и проще разобраться, где меньше всего «уличной магии». Например, из списка Yii/Laravel/Symfony я выберу Laravel. Из админок выберу AdminLTE, потому что она «ну вроде норм и работает». Ни один из авторов этих проектов до сих пор не заплатил мне за рекламу.
Я агностик и считаю, что нельзя создать идеальную архитектуру, которая не будет нуждаться в переделывании: никакие методологии не защищают вас от переписывания. Поэтому пишите так, чтобы ваше веб-приложение работало хорошо, пишите на том, что решает поставленную задачу. Не бойтесь написать лишнее и затем смело отрезайте ненужное: по-другому никак.
Бэкенд
Есть два подхода к реализации бизнес-логики со стороны бэкенда: сгруппировать её в одном сервисе (монолит) или реализовать каждый из компонентов логики в отдельном сервисе (микросервис). У обоих подходов есть как преимущества, так и недостатки, которые обсуждаются в профессиональном сообществе. На мой взгляд, при работе с небольшим проектом нужно использовать один сервис, а вот крупные проекты потребуют сложной архитектуры, как следствие, — наличия минимум нескольких микросервисов.
На каком языке реализовывать
Тут всё не так однозначно. Если не так важна производительность, то можно реализовывать на NodeJS (фреймворки ExpressJS, KoaJS, GatsbyJS), Python (фреймворки Django, Flask), Ruby (фреймворки Ruby on Rails, Grape). Если важна скорость — используйте Golang (фреймворки Gingonic, Beego, Revel). Думаю, самое верное решение — писать на том языке, который знаете. Мне, например, очень нравится Ruby и фреймворк Ruby on Rails.
Как реализовывать
Придерживайтесь паттерна MVC, и в какой-то момент вы заметите, что усложняется бизнес-логика. И дальше возникнет вопрос: где её реализовывать? В контроллерах или моделях? Один из наиболее простых и удобных способов — использовать интеракторы и презентеры.
Тестирование бэкенда
Всегда хочется понимать, корректно ли работает логика приложения. Чтобы каждый раз не проверять вручную работоспособность кода, нужно писать тесты. Как минимум у вас должны быть тесты на роуты, как максимум —на роуты, модели, вспомогательные классы. Подключите инструменты отслеживания текущего покрытия кода, чтобы быть уверенным в том, что ваше приложение работает без ошибок и сбоев.
Сваггер
Представьте, что вы начали разрабатывать фронтенд. Как понять, какие параметры и запросы отправлять на сервер? Смотреть в код бэкенда? Согласитесь, не лучшее решение. Лучше добавить поддержку сваггера — в идеале, если сваггер поддерживает генерацию через тесты, он поможет документировать API.
Фронтенд
Тут всё не так просто, так как фреймворков очень много. Сейчас в основном используют AngularJS, ReactJS, VueJS. У каждого есть свои достоинства и недостатки. Я бы выбрал ReactJS: он достаточно простой и гибкий.
Тестирование фронтенда
Для фронтенда есть два основных типа тестов — тесты на логику и тесты на отображение. Первые проверяют логическую реализацию функций и классов. Тесты на отображение отвечают за то, чтобы контент демонстрировался пользователю в задуманном виде. Можно использовать следующие фреймворки: Mocha, Chai, Jest, Ava, Enzyme, Jest.
Отслеживание качества контента
После создания сайта хочется понимать, насколько качественно он реализован. В этом может помочь Lighthouse — это автоматизированный инструмент с открытым исходным кодом для отслеживания качества вашего сайта. Система проводит аудит производительности и доступности веб-приложений, на основании этих данных можно в случае необходимости оптимизировать или доработать его.
Соответственно, разработчик (и руководитель проекта, и владелец продукта, и конечный потребитель) должен с самого начала осознать — что и зачем.
Без ответов на эти вопросы приступать к разработке глупо.
Быстрые прототипы и мгновенная обратная связь с заказчиком
Мы используем инструменты, которые позволяют в кратчайшие сроки проверить гипотезу и принять решение о запуске какой-то фичи в производство. Это может быть фреймворк с готовыми инструментами или методология ведения проекта или зарекомендовавшие себя паттерны проектирования.
Тут хорошо показывают себя Ruby on Rails/Laravel/Nest.js/Django. Подобные вещи помогают сохранять высокий темп разработки. Иначе бизнес может поменять концепцию, сократить бюджет или даже закрыть проект. А участники разработки без очевидных результатов рискуют просто перегореть.
Про окружение
К веб-сервисам могут обращаться совершенно разные пользователи с множества устройств, браузеров, с распределённой географией, скоростью подключения и так далее.
Сейчас верстка под разные экраны — самая незначительная забота. Мы живём в то время, когда уже нет той боли в эпоху IE6-7-8-9. Сегодня гораздо проще работать с интерфейсами, особенно с повсеместным переходом браузеров на WebKit.
Важнее думать о задержке в сетях, поскольку сервер и пользователь могут находиться на приличном расстоянии друг от друга. Если для одного подключения будет быстрый ответ, для другого — долгий, то это будет совершенно разный результат для пользователя.
Говоря о логике построения интерфейсов, стоит помнить, что несмотря на обилие различных фреймворков (Angular, React, Vue), предлагающих упростить разработку фронтенда, по неопытности строят монструозные системы, не думая, нужен ли этот код на странице. Страница оказывается перегружена, долго отрисовывается, плохо работает на мобильных устройствах. Как следствие, пользователи отказываются от приложения, бизнес теряет клиентов и деньги.
Помним про безопасность
Сегодня много спорят, как обмениваться данными — REST / SOAP / GraphQL — и при этом передают важную информацию в незашифрованном виде. Буквально недавно мы столкнулись с проектом, который получили на доработку, и обнаружили, что если в момент аутентификации отключить интернет, то приложение выдаёт ошибку «ERROR» и показывает пару логин/пароль.
Про декомпозицию
Если говорить об организации процессов, то всегда нужно иметь в виду, что должно быть продакшн-окружение и тестовое окружение, где можно все протестировать, проверить. И да, бэкапы нужны всего и всегда. Создание софта всегда следует декомпозировать на отдельные участки, на каждом выполняется своя работа — бэкенд, фронтенд, тестирование, не говоря про аналитиков, UX & UI designer, devops инженера.
Full-stack — это круто, но рискованно, использовать можно и нужно, но дозированно. Фронт и бэк всё-таки стоит разделять, иначе люди быстро сгорают или темп проекта замедляется, особенно когда идёт работа над большим приложением.
Про важное
Не так важно, MVC или MVP.
Важно как можно быстрее добиться единого контекста всем участникам проекта: разработчикам, аналитикам, заказчикам.
Важно говорить на одном внятном языке.
Важно декомпозировать всю разработку на небольшие элементы и использовать именно то, что нужно в конкретном моменте.
Важно знать свои инструменты.
Изолируйте, что можете. Поверьте, будет меньше боли.
Всё, о чём говорил выше, — дорого и долго, но в Enterprise-разработке без этого никак. Чем лучше будет уровень изоляции вещей, тем будет спокойнее жить приложению и разработчикам в будущем.
Помните про 12 факторов
Всё, что я рассказал, и даже больше содержатся в принципах 12-факторного приложения — открытой методике создания веб-сервисов, которая содержит общие декларации разработки софта, вне зависимости от платформы, языка разработки, назначения и т.п. Эти 12 факторов и есть 12 правил правильного написания приложений.
К сожалению, вот эти 12 факторов чаще всего открывают для себя на позиции middle/senior, когда уже обжигаются на ошибках, которых можно было бы избежать. Используйте это как направляющую в любых проектах!