Меня зовут Эдгар (ZergsLaw), я работаю в компании, которая занимается  финтех-разработкой для b2b и b2c. Когда только устроился в компанию, то попал в команду большого финтех-проекта и получил «в нагрузку» небольшой микросервис. Мне поручили его изучить и подготовить план рефакторинга, чтобы в дальнейшем выделить отдельную команду поддержки для сервиса.



«Мой» сервис — это proxy между определенными модулями большого проекта. На первый взгляд изучить его можно за один вечер и браться за дела поважнее. Но приступив к работе я понял, что ошибся. Сервис был написан полгода назад за пару недель с задачей протестировать MVP. Всё это время он отказывался работать: терял события и данные, или переписывал их. Проект перекидывали из команды в команду, потому что никто не хотел им заниматься, даже его создатели. Теперь стало ясно почему под него искали отдельного программиста.

«Мой» сервис — это пример плохой архитектуры и изначально неправильного проектирования. Все мы понимаем, что так делать нельзя. Но почему нельзя, к каким последствиям это приводит и как попытаться все исправить, я и расскажу.

— Чайники, весы, игрушки, лампочки, кофемашины… В эти и другие устройства встраивают bluetooth-модули.
— Зачем?
— Чтобы дать пользователю управлять своими устройствами через приложение. К примеру, управлять освещением в комнате.
— Ой, а можно ли собрать какое-то своё простое устройство и управлять им прямо через браузер?
— Да! И эта статья как раз об этом.

Поделюсь несколькими практиками, которые использую при создании React-компонентов. Заинтересованных прошу под кат.

Рассмотрим создание эффекта ухода текста в прозрачность как альтернативу обрезания текста многоточием.