Почему Feature-Sliced Design (FSD) не спасет ваш проект

Каждый разработчик рано или поздно сталкивается с вопросом: как организовать проект так, чтобы он не превратился в хаос? Или как исправить проект, в котором уже царит хаос? Начинается всё одинаково: мы делаем простое MVP или проект с ограниченным функционалом, не заморачиваемся по поводу архитектуры и организации кода, ведь проект небольшой и несложный, а сделать его нужно уже здесь и сейчас. Но время идёт, и у бизнеса появляются всё новые требования. Какие-то изначальные идеи полностью отменяются или меняются до неузнаваемости, разрастается команда, дизайн меняется несколько раз, появляется необходимость покрыть проект тестами, а иногда и необходимость вообще сменить стек технологий. И вот вы уже работаете над кодом, в котором становится всё сложнее вносить изменения в существующий функционал. Всё держится на костылях, становится трудно ориентироваться в куче файлов, и кажется, что всё устроено как-то не так, как должно быть. В этот момент мы начинаем задаваться вопросом: “а как нужно писать и организовывать код на самом деле?”. В поисках ответа мы читаем статьи, смотрим обучающие видео, доклады и неизбежно натыкаемся на Feature-Sliced Design (FSD).

https://habr.com/ru/articles/919316/

#fsd #архитектура #методология #организация_кода #фронтенд #фронтендразработка #паттерны #паттерны_проектирования

Инкапсуляция UI на примере чат-виджета

Привет, Хабр! Меня зовут Дмитрий Переверза, я Frontend Team Lead в компании Just AI. В рамках платформенного стрима мы занимаемся разработкой и развитием платформы для создания своих чат‑ботов. Cделать хорошего и полезного бота временами бывает сложно, поэтому для помощи разработчикам мы создаем инструменты, которые помогают ускорить разработку и упростить работу с ботами. В этой статье я расскажу, как реализовать изолированный UI, грамотно организовать код на примере виджета чата, и какие проблемы могут возникнуть в процессе разработки.

https://habr.com/ru/companies/just_ai/articles/911594/

#ui #инкапсуляция #чатбот #виджет #виджеты_сайтов #iframe #организация_кода

[Перевод] Dart / Flutter — применяя zero / empty объекты ко всему

Больше техническая заметка, чем статья, поэтому постараюсь изложить мысли как можно кратче. Приходя из JS/TS мира, когда я впервые написал на Dart, самой прекрасной вещью, помимо многих было использование функций isEmpty или isNotEmpty для String, List, Map, и так далее. Это было невероятно просто и прекрасно не писать каждый раз .length == 0 . Также, очень полезным паттерном были empty/zero значения как Duration.zero, Offset.zero , и другие. Спустя время, я нашел привычку использовать похожий принцип для работы с различными случаями, а также пришел к мысли - что если мы используем такие значения для большей части объектов, избавляясь от null (не для всех случаев, но тем не менее)? Немного поискав, нашел похожий паттерн в Go и других языках, и продолжил думать:

https://habr.com/ru/articles/896632/

#организация_кода #данные_приложения #теория #объектызначения #объекты #empty #zero

Клиентский код. Пространство имен

Привет, Хабр! У меня появилась необходимость отделить проект от фреймворка. Благо кода фреймворка в проекте было не так много, но избавиться от него тоже нужно. Поэтому было принятно решение переписать функционал который он покрывал. Одной из используемых функций фреймворка было - построение пространства имен. Пространство имен, проще говоря, создано что-бы задавать область видимости кода для другого кода. Используя пространство имен можно гарантировать что клиентский код не будет зависить от названия: переменных, функций, класса, и всего чего угодно в коде, в том числе при подключении нескольких библиотек тоже можно не переживать. Клиентский код будет зависить только от результата работы кода. Удачно получилось что тема пересекается с моей статьей . Может если это будет серия статьей с пометкой Клиентский код, то мне получится лучше донести что же всетаки это за код такой.

https://habr.com/ru/articles/895798/

#Пространство_имен #архитектура #организация_проекта_в_ОС #namespace #Организация_кода #Клиентский_код

Business Process Notation как подход к организации кода в проекте по разработке мобильного iOS приложения

Постановка проблемы На сегодняшний день наиболее известны такие архитектурные паттерны как MVC, MVVM, MVP, Viper, Clean Code. Все они в той или иной мере работают с тремя основными сущностями - Модель, Вью, Контроллер, добавляя время от времени некоторые дополнительные, например, Presenter. Вторая общая особенность данных архитектурных паттернов состоит в том, что названные выше сущности выделяются и классифицируются исходя из их технических характеристик. Например, Вью - это то, что отображает данные на экране, Модель - содержит в себе данные и их обработку, а Контроллер осуществляет взаимодействие между ними. Но эти характеристики не отражают сущности приложения в целом. Это как если бы мы разделили воду на водород и кислород и пытались бы из их особенностей понять сущность воды. Фрагментарность используемых сущностей и отсутствие целостного видения приложения приводит к общеизвестным проблемам, связанным с трудностями понимания кода и его управлением. Отсюда, ни один из этих паттернов не гарантирует, что на определённом этапе разработки приложения не возникнет ситуация, когда код станет тяжеловесным и очень сложным для управления. Именно в такие моменты приходится переосмысливать общую архитектуру проекта и отвечать на вопросы “Зачем нужен тот или иной код, какую задачу он решает?”, “Где расположен код, реализующий ту или иную функциональность и как он работает?”. И т.д. Продолжая пример с изучением воды следует сказать, что единицей её анализа является молекула воды. Это мельчайшая частица воды, которая тем не менее содержит в себе все её свойства. В программе такой мельчайшей и одновременно целостной единицей является задача, которую решает тот или иной блок кода. Отсюда, возникла идея использовать в качестве отправного пункта для организации кода именно те задачи, которые этот код решает. При этом, задача понимается как бизнес-процесс.

https://habr.com/ru/articles/866376/

#ios_development #business_process #architecture_pattern #организация_кода #навигация_проекта #MVC #MVVM #VIPER #модель_приложения #swift

Архитектура Xорошего Кода Прошивки (Массив-Наше Всё)

В этом тексте я написал о некоторых подходах к организации кода для микроконтроллеров. Основная идея - массив наша основная скрепа . Главные достоинства представленной архитектуры - это простота поддержки, сопровождения и масштабирования кодовой базы.

https://habr.com/ru/articles/816589/

#архитектура #архитектура_прошивки #firmware #структура_программ #организация_программ #организация_кода #массив #array #техникум #кодовая_база

Как написание своего плагина может поменять то как вы пишете код

Привет, я — Лёша, и я люблю веб. Иногда это даже взаимно. В жизни часто бывает, что едва ты начинаешь думать, что наконец стал разбираться в чём-то, что-нибудь происходит и оно говорит тебе: “Нет”. И это не всегда плохо. Например, я думал, что более-менее знаю, как нужно писать код, пока не написал свой плагин. И это очень сильно поменяло мой подход к программированию. И как?

https://habr.com/ru/articles/816461/

#программирование #javascript #плагины #подход_к_разработке #организация_кода #организация_работы #организация_разработки #мышление #продуктовая_разработка #продукт

Организация кода это важно и легко на основе Layer Architecture

Всем привет! Думаю многие читали кучу книжек по поводу Hexagonal, Onion, Clean, Layer Architecture и у вас могли остаться спорные вопросы как в сложности понимания материала, так и в реализации данных подходов в ваших проектах. Сегодня я хочу затронуть тему “Организации кода” и показать насколько это важно и легко одновременно на примере Layer Architecture (Слоистая архитектура).

https://habr.com/ru/articles/808391/

#Layer_Architecture #python #проектирование #организация_кода #архитектура_приложений