#организация_кода — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #организация_кода, aggregated by home.social.
-
Мы сократили деплой кнопок с двух дней до одного часа, или как Nx облегчил жизнь фронтендеров Рунити
Привет, Хабр! На связи Никита Ли, frontend-разработчик в Рунити. За последние годы мы в Рунити пришли к довольно привычной для крупных frontend-команд ситуации: проектов становилось больше, кодовая база разрасталась, а количество переиспользуемых пакетов и микрофронтендов росло слишком быстро. Поддерживать зоопарк репозиториев становилось всё сложнее — и по времени, и по нервам. В этой статье расскажу, с какими проблемами мы столкнулись, зачем вернулись к одному репозиторию и что Nx реально изменил в нашей работе.
-
Мы сократили деплой кнопок с двух дней до одного часа, или как Nx облегчил жизнь фронтендеров Рунити
Привет, Хабр! На связи Никита Ли, frontend-разработчик в Рунити. За последние годы мы в Рунити пришли к довольно привычной для крупных frontend-команд ситуации: проектов становилось больше, кодовая база разрасталась, а количество переиспользуемых пакетов и микрофронтендов росло слишком быстро. Поддерживать зоопарк репозиториев становилось всё сложнее — и по времени, и по нервам. В этой статье расскажу, с какими проблемами мы столкнулись, зачем вернулись к одному репозиторию и что Nx реально изменил в нашей работе.
-
Мы сократили деплой кнопок с двух дней до одного часа, или как Nx облегчил жизнь фронтендеров Рунити
Привет, Хабр! На связи Никита Ли, frontend-разработчик в Рунити. За последние годы мы в Рунити пришли к довольно привычной для крупных frontend-команд ситуации: проектов становилось больше, кодовая база разрасталась, а количество переиспользуемых пакетов и микрофронтендов росло слишком быстро. Поддерживать зоопарк репозиториев становилось всё сложнее — и по времени, и по нервам. В этой статье расскажу, с какими проблемами мы столкнулись, зачем вернулись к одному репозиторию и что Nx реально изменил в нашей работе.
-
Мы сократили деплой кнопок с двух дней до одного часа, или как Nx облегчил жизнь фронтендеров Рунити
Привет, Хабр! На связи Никита Ли, frontend-разработчик в Рунити. За последние годы мы в Рунити пришли к довольно привычной для крупных frontend-команд ситуации: проектов становилось больше, кодовая база разрасталась, а количество переиспользуемых пакетов и микрофронтендов росло слишком быстро. Поддерживать зоопарк репозиториев становилось всё сложнее — и по времени, и по нервам. В этой статье расскажу, с какими проблемами мы столкнулись, зачем вернулись к одному репозиторию и что Nx реально изменил в нашей работе.
-
Как мы с третьего раза сделали надёжную и быструю аутентификацию в микросервисном приложении (гибридный подход к JWT)
Мы хотели сделать надёжную и быструю аутентификацию в микросервисном приложении. Перепробовали три популярных подхода, которые показались нам нерациональными. Сразу оговорюсь: нерациональными в нашем конкретном случае. Всё-таки нашли оптимальный вариант, совместив JWT-токены с обменом запросами между сервисами. Если совсем просто, то мы разделили сервисы на «обычные» и «элитные», и вместо того, чтобы каждый раз ходить напрямую в сервис аутентификации, используем JWT-токены для обмена данными. В итоге получилась весьма надёжная, хорошо масштабируемая и быстрая система. Теперь расскажу о том, как она работает в теории и на практике. А ещё поделюсь ссылкой на работающую сборку на GitHub, которую можно потестировать.
-
Почему 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
-
[Перевод] 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
-
[Перевод] 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
-
[Перевод] 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 #техникум #кодовая_база
-
Архитектура Xорошего Кода Прошивки (Массив-Наше Всё)
В этом тексте я написал о некоторых подходах к организации кода для микроконтроллеров. Основная идея - массив наша основная скрепа . Главные достоинства представленной архитектуры - это простота поддержки, сопровождения и масштабирования кодовой базы.
https://habr.com/ru/articles/816589/
#архитектура #архитектура_прошивки #firmware #структура_программ #организация_программ #организация_кода #массив #array #техникум #кодовая_база
-
Архитектура 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 #проектирование #организация_кода #архитектура_приложений