Вам надоело, что бизнес приходит с абстрактными проблемами, или того хуже с готовым решением? В итоге ограничивая работу отдела разработки в принятии решений? Как сделать сложные требования понятными и структурированными, чтобы они работали быстрее и эффективнее для решения задач бизнеса?  

Бизнес-требования — это основа для разработки IT-решений. Но часто их описывают слишком сложно или неоднозначно. В результате разработчики тратят время на уточнения деталей, а заказчики остаются недовольны.

Формат Use Case помогает избежать этих проблем. Он описывает сценарии взаимодействия пользователей и систем в четкой, последовательной форме. Это не просто техническая документация, а «инструкция» для всех участников проекта: аналитиков, разработчиков, тестировщиков и бизнес-пользователей.

Автор: Борис Абрамов, lead system analyst

Дорогой читатель! Если ты оказался тут, то скорее всего ты столкнулся с той же проблемой, что и я: 

ты занимаешься Android разработкой и все вокруг говорят о какой-то «чистой архитектуре» (она же - Clean Architecture), указывают её в требованиях к вакансиям, указывают на практиках в вузе и т.д.

Однако информацию о данном подходе приходится собирать по кусочкам. Так что в данной статье я Даниил Закляков, разработчик WMT Group попробую на своем опыте подробно, доступным языком объяснить с чего начинать и как эту архитектуру строить.

Зачем всё это?

В процессе изучения чистой архитектуры может показаться, что это - чепуха, выгода от которой не оправдывает время, которое затрачивается на её создание. Но давайте просто посмотрим на два проекта: один без архитектуры, другой с архитектурой.

Когда я переходил из военной сферы в IT, то начинал свой путь в управлении проектами. Мне казалось достаточно освоить инструменты и методологии, чтобы стать успешным PM. Курсы давали базовые знания, но реальность оказалась сложнее. Этот год стал для меня испытанием, но и подарил ценные уроки, о которых редко говорят в учебниках. Делюсь тем, что помогло мне выжить и стать лучше в профессии.

Привет, Хабр! Я уже рассказал, что умею разнообразно писать счётчики . Пришло время сделать шаг вперёд! Сегодня поговорим о том инструменте, который я и миллионы разработчиков используют ежедневно. Речь пойдёт о великом и ужасном ReactJS.

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

И важное: несмотря на указанные ниже проблемы, я до сих пор считаю React прекрасным и удобным инструментом для создания фронтенда, в частности SPA.  Громких слов типа «ReactJS не пригоден для разработки» тут не будет - пригоден, да ещё как! Но... и на Солнце бывают пятна. Приступим.

Современная фронтенд-разработка технологически весьма сложная: множество зависимостей,  микросервисы, размеры самих проектов, плагины для настройки окружения и многое другое.  

Это касается и одного из самых ключевых этапов в разработке - сборка проекта. Множество проектов, на которых я работал, собирались (и собираются) с помощью Webpack. Это классический и проверенный временем инструмент: со своими преимуществами и недостатками.  

В какой-то момент недостатки стали перешивать:  

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

Вместо этого мы напишем функцию-счётчика на JavaScript. Несколько раз, причём всякий раз по-разному с пользой.

Казалось бы, задача простейшая, даже старый-добрый to-do list куда сложнее и заковыристее. Предложение написать функцию-счётчика на собеседованиях уже классика, которая делается на автомате. Уверен, что большинство опытных воинов фронтенда либо помнят традиционное решение, либо по памяти накатают его в течение 30 секунд. Традиционно эту задачу решают замыканием. Однако, почему именно им? А если попробовать сделать это как-то иначе? Я попробовал и реализовал счётчик несколькими разными (подчас неочевидными) способами, попутно спросив совета у нейросетей, а также подключив тяжёлую артиллерию в лице Babel, TypeScript и даже WebAssembly. Давайте посмотрим, что получилось!