Как стать автором
Обновить
-11
0.2

Пользователь

Отправить сообщение

sql портянки с вложенными запросами и тоннами джоинов?

Возможно, это признак плохо спроектированной БД

А если нельзя перепроектировать БД, то можно добавить вьюшки в БД

А, тут и без меня уже всё написали.

И да, пока всё просто не усложняйте

Keep it simple, stupid

Single Responsibility Principle

Каждый класс должен отвечать только за одну зону ответственности (действий), чтобы его было проще дополнять и менять. 

Еще чтобы было проще прочитать и понять. Переключение контекста проблемы в мозгу очень затратная операция. А еще задачи можно разделит между разными программистами.

Open Closed Principle 

Опять же смотри полиморфизм

Принцип подстановки Барбары Лисков

почти что = определение подтипов

Полиморфизм подтипов для этого и вводят. Как тут подсказывают, LSP = полиморфизм типов + правило что подтип не должен "усиливать предусловия"

Но есть и другие виды полиморфизма, не менн полезные:

Interface Segregation Principle

это практически определение интерфейса: чтобы уменьшить зависимость между классами выдели зависимость в интерфейс. YAGNI в чистом виде

Dependency Inversion Principle

Тут все сложно. И то что определение не поместилось в одном предложении намекает на это. Для борьбы с зависимостями можно использовать абстракции. Но есть еще следующие методы:

  • DI (зависимости внедрены внешним кодом и класс их помнит всю свою жизнь при инжекции в конструктор или только в контексте вызова при инжекции в метод)

  • IoC (зависимости знает внешний код, а класс их вообще не знает)

  • Factory method (для управления зависимостями создается специальный класс, который больше ничего не умеет)

  • Контекстная зависимость (Contextual Dependency): Модуль может определить зависимость, которая будет разрешена в контексте выполнения. Например, модуль может определить интерфейс зависимости, а внешний код может предоставить конкретную реализацию этой зависимости в контексте выполнения. Модуль будет использовать эту зависимость в своей работе, но не будет знать о конкретной реализации.

Но и это еще не все про DIP

Пресловутую проблему "You wanted a banana but what you got was a gorilla holding the banana and the entire jungle" можно обойти тем что банану не нужно знать кто его владелец. Т.е. если код следует предметной области, то DIP не нужен.

Вотъ(С)

Предположим, у нас есть класс FileManager, который отвечает за чтение и запись данных в файл. Однако, в соответствии с SRP, этот класс должен быть ответственен только за одну обязанность. Разделим его функционал на два класса: FileReader и FileWriter

Нет, предметная область одинаковая, не должен. Но может. Чисто ООП-шные mind games и метания юного Вертера. Вот обработку файлов и бизнес-логики уже не стоит смешивать. Разработчики этого часто разные люди, придется одному вмешиваться в работу другого. А если один человек, то придется переключать контекст проблемы в голове, что в сущности то же что и как 2 человека работают.

Предположим, у нас есть класс FileManager, который отвечает за чтение и запись данных в файл. Однако, в соответствии с SRP, этот класс должен быть ответственен только за одну обязанность. Разделим его функционал на два класса: FileReader и FileWriter

Что такое критерий сортировки? Алгоритм? Ну что ж, можно алгоритм указывать в виде параметра, а можно создать несколько функций сортировки. В данном случае необходимости в полиморфизме не вижу.

Принцип подстановки Лисков

Очень узкий взгляд, из всех вариантов полиморфизма указан только полиморфизм наследования, плохой вариант.

public class Shape { public virtual void Draw() { // Default implementation } }

public class Circle : Shape { public override void Draw() { // Specific implementation for drawing a circle } }

public class Rectangle : Shape { public override void Draw() { // Specific implementation for drawing a rectangle } }

Вот другие типы полиморфизма, реализующие LSP

  1. Ad-hoc Polymorphism:

    • public class Calculator 
      {
      public int Add(int a, int b) 
      { 
          return a + b; 
      }
                               
      public double Add(double a, double b)
      {
          return a + b;
      }
      

      }

    • This example showcases method overloading in C#, allowing different implementations of the Add method to be selected based on the types of the arguments, aligning with LSP by enabling the substitution of objects of subclasses for objects of the superclass without impacting the correctness of the program.

  2. Parametric Polymorphism:

    • Example:

      public class List <T>
      {
      // Implementation of a generic list
      }

    • C# supports parametric polymorphism through generic classes like List, enabling the reuse of code with different types without affecting the correctness of the program, in line with LSP.

  3. Inclusion Polymorphism:

    • ...

Виды полиморфизма

Ad hoc полиморфизм (специализированный полиморфизм)

-Перегрузка функций (методов)

-Перегрузка операторов

Полиморфизм подтипов

-Полиморфизм включения

Параметрический полиморфизм

-Параметрические методы

-Параметрические типы

ну чего-то устал уже душнить...

может и нет дерева метрик?

есть набор показателей

у показателя есть точность измерения

у пар показателей есть корреляция

объединим показатели в пары там где корреляция выше порога

потом попробуем показатели отсортировать по неким уровням стратегичности

получим некое дерево (мы же хотим дерево, да?)

но вот чем выше уровень стратегичности, абстрактности тем хуже оно измеряется

бабац

и либо получаем подтасовку либо оно все просто не работает

Говорят, ИИ хорошо находят корреляции
Ну так, сделайте миллиард гипотез и проверьте через ИИ
может и получите некое дерево

И еще. Дерево предполагает транзитивность отношений. А реально это не так из-за того что это не полная корреляция

А что по поводу корреляций показателей говорят ваши дата-сатанисты?

.net проект имеет некоторые проблемы сборки под докер

  • с локальными (не с сайта) nuget packages - не помню как решать

  • с typescript - нужно включать node и npm в докер

Сборка под докер это тоже публикация исходников и сборка в среде Linux, в самом докере. Почему не собирать npm в Винде не знаю.

Зато разработка и тестирование в windows + visual studio одно удовольствие. Linux как страшный сон

1000 собеседований

Это же сколько времени кандидатов ты бездарно потратил

TL;DR

В этой статье речь о том что балансировщик нагрузки должен знать сколько ресурсов у сервера и так запускать микросервисы чтобы они меньше общались по сети

То есть ничего нового

И не марайте термин cell-based architecture

Устоявшегося применения термина нет, но есть варианты и получше

Например, умное шардирование БД с зеркалированием

https://habr.com/ru/companies/vk/articles/807685/

Видимо, клиент может отправить PDF по почте, соцсетям и другим каналам

Приковать рабов к галерам!

Денег нет, но вы держитесь!

Всё по заветам наших президентов

Забыл описать бизнес логику на клиентской части мобильного приложения. Ай ай.

А ведь там находится голосовой подсказчик и логика прохождения контрольных точек.

Ну ладно, в следующий раз.

Когда брали на работу говорили что про контейнеры

Думал, в докере развернем

А вышло вон как )))

пристрелите м10, пожалуйста!

и mumps заодно

Нет никакого architecture decision

Есть ADR architecture decision records

И сразу акцент с архитектуры как законченного документа уходит на выбор, записи.

Если хотите перевод, то это

Документально зафиксированный выбор варианта архитектуры

нда...

такая анатомия это не привлекательные наружные половые органы

это кишки и кости, разбросанные по операционному столу

Дело не в названии

Эта функция не возвращает причину почему логин не валидный

Если хотите название то лучше разделить на несколько простых валидаторов без выброса исключений

bool IsAllLettersInLowerCase

bool что-то ещё

Или сделать общий валидатор, возвращающий строку или enum ошибки

string IsValidLogin

все так хорошо шло

а потом мысль автора скатилась: в узкую область - облака, потом в вендор лок, а потом в прямую рекламу

Используйте Option<T> или Result<T>

или хотя бы nullable int

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

пускали в глаза инвесторам

https://youtu.be/hAwtrJlBVJY?t=563

@xkb45bkc4

Что делать со срочной фичей, которая кажется заказчику очень важной и должна быть сделана еще вчера?

Вчера и приходите.

Есть фичи с коротким дедлайном, когда завтра уже не нужно. Есть фичи с высокой ценой откладывания на каждый день позже.

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

С высокой ценой откладывания можно отнести ну... запуск ракеты. Перенесли запуск - потеряли миллион. Поторопились и не перенесли - потеряли миллиард.

Информация

В рейтинге
2 507-й
Зарегистрирован
Активность