Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5👍2🎉1
Термин «Ошибка на миллиард долларов» в отношении
NULL был введён известным учёным и программистом Тони Хоаром, который в 1965 году изобрёл NULL-ссылки. Спустя годы он назвал это решение "ошибкой на миллиард долларов", поскольку использование NULL привело ко множеству ошибок и уязвимостей, стоивших компаниям и разработчикам огромных затрат на устранение последствий.NULL часто приводит к ошибкам из-за его некорректной обработки. Если программа ожидает, что переменная содержит значение, а вместо этого встречается NULL, это приводит к сбоям, падениям и исключениям. Популярная ошибка — это NullPointerException, которая происходит, когда программа пытается использовать NULL как объект или ссылку. Такие ошибки трудно обнаружить, так как их проявление зависит от условий выполнения программы и использования данных, что делает их сложными для отладки и тестирования.Использование
NULL обязывает программистов проверять каждую переменную на предмет NULL, чтобы избежать сбоев. Это усложняет код, делает его менее читаемым и подверженным ошибкам, особенно когда проверки на NULL игнорируются или забываются. Чем больше кода, связанного с обработкой NULL, тем выше вероятность появления багов, особенно если пропущены проверки.NULL разрушает понятие инкапсуляции, так как от программиста требуется знать, может ли переменная быть NULL или нет. Часто интерфейсы неявно предполагают, что некоторые данные могут быть NULL, что может вводить разработчика в заблуждение. В дополнение, использование NULL неявно снижает выразительность кода, так как вместо определённого значения "ничего" (например, "не определено" или "неизвестно") часто используется просто NULL, что ухудшает понимание кода.Ошибки, связанные с
NULL, могут привести не только к сбоям, но и к уязвимостям, открывающим путь для атак. Например, злоумышленники могут использовать уязвимости, вызванные неправильной обработкой NULL, чтобы вызвать некорректное поведение системы или обойти ограничения доступа.В языках, таких как Java, Kotlin, C# и других, существуют типы
Optional (или Option в функциональных языках), которые обязывают явно указывать, что переменная может не содержать значения. Optional заставляет программиста явно обрабатывать случаи отсутствия значения, что уменьшает вероятность случайного использования NULL и упрощает работу с отсутствием данных.Некоторые языки, например Kotlin и Swift, поддерживают строгую систему типов, которая позволяет объявлять
nullable и non-nullable переменные. Если переменная объявлена как non-nullable, компилятор не позволит присвоить ей NULL или использовать её как NULL. Этот подход повышает безопасность кода на этапе компиляции, предотвращая распространённые ошибки с NULL-ссылками.Современные инструменты статического анализа (такие как SonarQube, ReSharper, FindBugs) могут автоматически обнаруживать места потенциального использования
NULL и предупреждать разработчиков. Эти инструменты помогают выявить случаи, когда переменная может оказаться NULL, и помогают предотвратить ошибки до выполнения программы.Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
Плохая организация кода проявляется в признаках, которые затрудняют его понимание, сопровождение и расширение. Такие проблемы могут быть следствием недостатков в архитектуре, неверного структурирования модулей, низкой читаемости и слабой гибкости.
Повторение одних и тех же блоков кода в нескольких местах. Дублированный код усложняет сопровождение, поскольку изменения нужно вносить в нескольких местах, что повышает вероятность ошибок. Выявлять общие фрагменты кода и выделять их в отдельные функции или методы. Следовать принципу DRY (Don't Repeat Yourself).
Модуль содержит функции, которые не связаны общей задачей, или класс имеет свойства и методы, не объединённые одной логикой. Пониженная связанность затрудняет понимание того, за что отвечает модуль или класс, увеличивает вероятность ошибок. Стремиться к высокой связанности, чтобы модули выполняли одну чёткую задачу. Следовать принципу Single Responsibility (единственная ответственность).
Модули или классы сильно зависят друг от друга и для работы требуют конкретной реализации других частей системы. Высокое сцепление снижает гибкость и увеличивает время на изменения. Модификация одной части кода требует модификации множества зависимых компонентов. Стремиться к слабому сцеплению, разрабатывая независимые модули с понятными интерфейсами. Использовать инверсию зависимостей и интерфейсы.
Сложные алгоритмы или структуры, которые можно упростить без потери функциональности. Усложнённый код труднее понимать, тестировать и отлаживать. Большая вероятность ошибок из-за запутанной логики. Применять KISS (Keep It Simple, Stupid) и YAGNI (You Aren't Gonna Need It) для минимизации сложности и реализации только необходимых функций.
Функции, занимающие несколько экранов кода, и методы, которые выполняют несколько задач одновременно. Длинный код труден для понимания, тестирования и повторного использования. Длинные функции часто имеют слишком много ответственности. Разделять функции на более короткие, каждая из которых выполняет только одну задачу. Стремиться к следованию принципу SRP (Single Responsibility Principle).
Непонятные или непоследовательные имена, которые не отражают назначение переменной, функции или класса. Повышает сложность чтения и понимания кода для других разработчиков, увеличивает вероятность ошибок. Использовать осмысленные, выразительные имена, которые чётко отражают их цель. Следовать принятым стандартам именования и писать самодокументируемый код.
Подключение библиотек или модулей, которые не используются или используются минимально. Увеличивает сложность кода, усложняет деплой и повышает риск конфликта версий. Регулярно проверять зависимости и удалять неиспользуемые, использовать только необходимые библиотеки и модули.
Модули и классы не соответствуют базовым принципам SOLID (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion). Проблемы с расширяемостью и поддержкой. Изменения могут привести к ошибкам в коде и сильному сцеплению. Проверять архитектуру на соответствие принципам SOLID и вносить улучшения, если структура нарушена.
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1🔥1
Полезен анализ планов выполнения (
EXPLAIN), системные логи запросов и внешние инструменты мониторинга вроде Percona или Datadog. В PostgreSQL используйте pg_stat_statements для анализа запросов по времени выполненияSELECT query, total_time FROM pg_stat_statements ORDER BY total_time DESC LIMIT 10;
В MySQL включите
slow_query_log для записи медленных запросовSET GLOBAL slow_query_log = 1; SET GLOBAL long_query_time = 1;
В SQL Server используйте
sys.dm_exec_query_statsSELECT TOP 10 total_elapsed_time / execution_count AS AvgTime, text FROM sys.dm_exec_query_stats CROSS APPLY sys.dm_exec_sql_text(sql_handle) ORDER BY AvgTime DESC;
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2🤯2
Разработчики могут не любить Java по нескольким причинам, связанным с особенностями языка, его экосистемы и исторической репутацией.
Java часто критикуют за необходимость писать много шаблонного (boilerplate) кода. Например, для выполнения простых операций, таких как создание POJO-классов (Plain Old Java Object), разработчики вынуждены прописывать геттеры, сеттеры, конструкторы, методы
equals и hashCode. Несмотря на наличие библиотек, таких как Lombok, для уменьшения шаблонности, это остается одной из претензий к языку.Исторически Java обновлялась медленно, что вызывало недовольство. До перехода на модель выпуска версий каждые шесть месяцев (с Java 9), промежутки между релизами были слишком большими. Это приводило к отставанию языка от более динамично развивающихся конкурентов, таких как Kotlin, Scala или Python.
Некоторые считают Java "устаревшим" языком из-за особенностей, таких как ручное управление многопоточностью (до появления улучшенных инструментов в Java 8 и последующих версиях) или отсутствие "современного" синтаксиса (например, до появления
var).Раньше Java часто ассоциировалась с медленной работой из-за интерпретируемой природы байт-кода и большого объема памяти, необходимого для запуска JVM. Хотя современные реализации JVM (HotSpot, GraalVM) сделали Java очень быстрой, этот стереотип все еще живет.
В крупных проектах на Java все еще можно столкнуться с использованием старых библиотек и инструментов, таких как XML-конфигурации для Spring. Такие проекты требуют больше усилий для модернизации и поддержки.
Java — строго типизированный язык. Это обеспечивает надежность и удобство поддержки, но снижает гибкость при разработке прототипов или экспериментировании. Это особенно заметно в сравнении с языками, такими как Python или JavaScript.
Kotlin, развиваемый JetBrains, стал официальным языком разработки для Android в 2017 году. Он предлагает более лаконичный синтаксис, мощные функции работы с null-значениями, и в целом воспринимается как более "современный" язык.
Java обладает огромной экосистемой, которая может быть одновременно преимуществом и недостатком. Иногда требуется глубокое понимание JVM, инструментов сборки (Maven, Gradle), и других особенностей.
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Это технология, позволяющая приложениям вызывать функции или процедуры, которые выполняются на удалённом сервере, как если бы они были локальными. Несмотря на удобство, такая модель имеет ряд подводных камней, которые необходимо учитывать при проектировании и разработке распределённых систем.
Удалённые вызовы маскируют тот факт, что операция выполняется через сеть. Это может создать ложное чувство локальности у разработчиков, которые не учитывают:
Сетевую задержку: вызовы занимают больше времени, чем локальные операции, особенно при медленных сетях. Сетевые сбои: соединение может быть потеряно, что приведёт к ошибкам выполнения или длительным тайм-аутам. Изменение задержки: время выполнения одного и того же вызова может существенно варьироваться в зависимости от сетевых условий.
Обработка ошибок в распределённых системах сложнее, чем при локальных вызовах:
Необходимо обрабатывать такие ошибки, как потеря соединения, тайм-ауты, отказ сервера. В некоторых случаях может возникнуть "проблема повторного вызова" (например, запрос был выполнен, но подтверждение потерялось), что приводит к возможной идемпотентности операций.
Для передачи данных через сеть они должны быть преобразованы в сериализованный формат. Это может:
Увеличивать задержки из-за времени, необходимого на преобразование. Создавать проблемы совместимости, если клиент и сервер используют разные версии протокола. Усложнять отладку и диагностику ошибок в данных.
Взаимодействие между распределёнными компонентами приводит к необходимости поддерживать согласованность данных: Проблема согласованности особенно актуальна при частичных отказах системы. Может потребоваться использование распределённых транзакций, что усложняет архитектуру.
Удалённые вызовы подвержены угрозам: Необходимо обеспечивать шифрование данных, чтобы избежать утечек. Аутентификация и авторизация играют ключевую роль в защите системы. Возможны атаки на уровень сети или использование слабостей в протоколах передачи данных.
При большом числе клиентов сервер может стать узким местом: Нагрузка на сервер может привести к деградации производительности. Требуется правильная стратегия масштабирования и балансировки нагрузки, например, использование нескольких серверов или очередей сообщений.
Различные протоколы (например, HTTP, gRPC, Thrift) обладают своими особенностями: Протокол может накладывать ограничения на производительность и возможности. Ошибки конфигурации или несоответствие версий могут вызвать проблемы.
Микросервисные архитектуры. Взаимодействие клиент-сервер (например, мобильное приложение и API). Системы с тяжёлой серверной логикой.
Чётко проектировать архитектуру, учитывая особенности сети. Использовать идемпотентные операции. Обеспечивать надёжные стратегии обработки ошибок. Применять мониторинг и трассировку (например, OpenTelemetry) для отслеживания поведения системы.
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
Принципы разделения ответственности (Separation of Concerns, SoC) предполагают разделение логики программы на отдельные части, каждая из которых выполняет строго определённую функцию. Это позволяет сделать код более структурированным, гибким и легче сопровождаемым. Популярные паттерны проектирования, основанные на разделении ответственности, включают MVC, MVP, MVVM и другие. Они применяются в разработке приложений для чёткого разграничения пользовательского интерфейса, бизнес-логики и работы с данными.
Хранит данные и логику их обработки. Отвечает за взаимодействие с базой данных или другими источниками данных. Уведомляет представление об изменениях данных.
Отображает данные пользователю. Реагирует на обновления данных от модели. Не содержит логики обработки данных.
Обрабатывает пользовательский ввод (например, нажатия кнопок, ввод текста). Вызывает соответствующие методы модели и обновляет представление.
Работает с данными и бизнес-логикой.
Интерфейс пользователя. Не содержит логики, только вызывает методы презентера.
Посредник между моделью и представлением. Получает данные из модели и передаёт их в представление. Не знает деталей реализации интерфейса (только абстракция).
Плюсы и минусы
Управляет данными и бизнес-логикой.
Отображает данные и предоставляет интерфейс для взаимодействия.
Посредник между моделью и представлением. Содержит логику преобразования данных для представления. Часто использует привязку данных (data binding), что позволяет автоматически обновлять UI при изменении данных.
Плюсы и минусы
Централизованное состояние приложения.
Компоненты, которые отображают состояние.
Описывают, какие изменения должны произойти в состоянии.
Функции, описывающие, как изменяется состояние на основе действий.
Плюсы и минусы
можно тестировать компоненты независимо друг от друга.
код проще понять и сопровождать.
компоненты можно использовать в других частях приложения.
команда может работать над разными частями параллельно.
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Это термин, которым называют старый код или программное обеспечение, созданное много лет назад, но до сих пор используемое. Важно понимать, что "легаси" не обязательно означает "плохой". Этот код может быть ценным и выполнять критически важные задачи, но у него есть свои особенности и проблемы, которые делают работу с ним сложной.
Программы, написанные 5, 10 или даже 20 лет назад, продолжают работать, хотя технологии уже изменились.
Разработчики, написавшие код, могли уйти из компании, не оставив подробных объяснений.
Код, который был написан для одних задач, со временем начинает использоваться для других, часто без переработки.
Код создавался на старых версиях языков программирования, библиотек или платформ, которые сегодня уже не поддерживаются.
Код может быть сложно понять, особенно если он написан без соблюдения современных стандартов или правил.
Старый код часто создавался без автоматизированных тестов, что усложняет внесение изменений.
Код может использовать библиотеки или платформы, которые больше не обновляются или не поддерживаются.
Даже небольшие правки могут вызвать неожиданные ошибки, поскольку никто не знает всех последствий изменений.
Если код выполняет свою задачу, компании часто решают оставить его как есть.
Легаси-код может управлять банковскими системами, производственными линиями или другими системами, от которых зависит бизнес.
Полная переработка кода может занять годы и потребовать огромных ресурсов.
Исправлять ошибки и улучшать работу системы по мере необходимости.
Переходить на современные технологии частями, чтобы минимизировать риски.
Создать новую систему, если старая больше не отвечает требованиям, но это требует времени и ресурсов.
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Это способность команды, процесса или организации быстро адаптироваться к изменениям, минимизируя затраты времени, ресурсов и усилий. Гибкость подразумевает не только оперативное реагирование на запросы, но и проактивное планирование с учетом возможных изменений. Она лежит в основе *ибких методологий разработки (Agile), которые ставят в приоритет взаимодействие, ценность для клиента и быструю адаптацию к новым условиям.
Гибкие системы и команды способны подстраиваться под новые бизнес-требования, изменения в технологиях или рыночных условиях без значительных потерь в эффективности. Это требует минимизации жестких зависимостей и использования подходов, таких как итеративная разработка.
Работа над проектом делится на небольшие этапы, каждый из которых добавляет определенную ценность. Итеративный подход позволяет на каждом этапе учитывать обратную связь и изменять стратегию.
Для достижения гибкости важно упрощение процессов, которые могут затруднять принятие решений или реализацию изменений. Это обеспечивает быстрое принятие решений на основе текущих данных.
Гибкость помогает лучше удовлетворять потребности клиента, благодаря постоянной обратной связи, приоритезации задач и возможности корректировки целей в процессе работы.
Гибкость подразумевает тесное взаимодействие между разработчиками, тестировщиками, аналитиками и бизнес-стейкхолдерами. Это ускоряет обмен информацией и сокращает задержки.
В быстро меняющихся условиях рынка запросы клиентов могут изменяться. Гибкость позволяет удовлетворять эти изменения, поставляя максимально актуальный продукт.
Итеративный подход позволяет быстрее выявлять и исправлять ошибки, чем при использовании традиционных методологий, таких как каскадная модель.
Гибкость позволяет быстрее выводить продукт на рынок, предоставляя минимально жизнеспособную версию (MVP) с возможностью дальнейшего развития.
Постоянная обратная связь и взаимодействие между участниками команды повышают прозрачность процессов и уменьшают риски недопонимания.
Основной документ, в котором заложены ценности и принципы гибкой разработки.
Конкретная реализация Agile с упором на спринты и роль Scrum-мастера.
Методология визуализации процессов, которая помогает выявлять узкие места и повышать эффективность.
Подход, направленный на повышение качества кода и оперативное удовлетворение изменяющихся требований.
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2🔥1
В контексте разработки программного обеспечения относится к способности команды, процесса или системы быстро адаптироваться к изменениям. Это ключевая характеристика Agile-методологий, которые нацелены на создание программного обеспечения через итеративный процесс, частую обратную связь и постоянную готовность к изменениям.
Способность вносить изменения в функциональность, требования или архитектуру продукта без значительных потерь времени и ресурсов. Это важно, так как бизнес-цели, приоритеты и технологии могут изменяться в течение жизненного цикла проекта.
В Agile-подходе используются короткие спринты (обычно 1–4 недели), в конце которых предоставляется работающий продукт или его часть. Это позволяет учитывать обратную связь и своевременно корректировать курс.
Гибкость также зависит от качества кода и архитектуры системы. Хорошо структурированный код облегчает внесение изменений и снижает риск появления ошибок.
В гибких командах разработчики, тестировщики, дизайнеры и бизнес-аналитики работают вместе, что ускоряет процесс и позволяет быстрее реагировать на изменения.
Использование CI/CD (Continuous Integration/Continuous Delivery) помогает оперативно вносить изменения в код и быстро их доставлять пользователям.
Быстрое тестирование гипотез и выпуск минимально жизнеспособного продукта (MVP), чтобы собрать обратную связь от пользователей.
Если меняются бизнес-требования, гибкая команда может переключиться на новые приоритеты, сохраняя при этом эффективность.
Адаптация к новым технологиям или платформам без больших затрат.
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1