Questions - LoiIver/documents GitHub Wiki

Проекты(роли, достижения) Какие новые технологии хочет?

Проектирование, шаблоны

  • • Полиформизм, инкапусуляция, наследование (см. задача)
  • • interface vs abstract class
  • • SOLID
  • • Примеры паттернов, которые вы используете, DI
  • • Примеры антипаттернов
  • • MVP ,MVC
  • • SOA
  • • CQRS, Event sourcing

CLR

  • • Выделение и высвобождение памяти, AppDomain
  • • valyue type, ref type, boxing, arrays List
  • • Куча, стэк
  • • Finalizer vs IDisposable
  • • IL код
  • • Expressions

Тестирование

  • • TDD BDD(A)
  • • mock vs stub
  • • детерменизм тестов

Многопоточность

  • • Примитивы синхронизации ( мьютекс vs семафор)
  • • Deadlock, Livelock
  • • Race conditions, volatile, interlocked, MemoryBarrier
  • • Timers
  • • Optimistic/Pessimisitc concurrency

WCF, MQ, ESB

  • • (RabbitMQ. MSMQ (A))
  • • Сериализация
  • • Falacies of distributed computing
  • • Другие методы связи между процессами?
  • • Известные форматы сериализации

ASP.Net

  • • WebForms vs MVC, other MVC
  • • Modules vc Handlers
  • • SQL Injection, XSS, XSRF ( как защититься от некорректного пользовательского ввода на стороне клиента, сервера, бд – энкодинг, дб параметры в процедурах)
  • • ModelBinding ( если в get запросе несколько переменных, а в action контроллера класс, сформированный из этих переменных)
  • • HTTP кэширование, CDN . HTTP заголовки ( expires, etag etc, кэширование на уровне nginx, браузера, что сделать, чтобы пользователь забрал новую версию js-а)
  • Database
  • • Реляционная теория, нормальные формы, уровни изоляции транзакций
  • • ORM
  • • Оптимизация, индексы, статистика
  • • NoSQL, виды

Какие сильные и слабые стороны у кандидата Если тормозит прод – что делать Подключиться студией Подключиться dotTrace, снять дамп, посмотреть , что конкретно тупит Diagnostic Tools in VS. Профайлер в SSMS dotPeek dotTrace

Блеснуть: хинты компилятору, CI/CD(TeamCity), Unit of Work StringBuilder

  Что не так с задачей:

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

    1. Точка с запятой в начале
    1. Тупое название класса
    1. Входные параметры завернуть в класс
    1. Name – это ФИО?
    1. Почему age, может, лучше DateOfBirth?
    1. Почему age это строка????
    1. Почему адрес это строка?? Может, его как-то разбить
    1. Почему пол это Sex ( он вообще-то gender и хорошо бы enum’ом), true – это женский или мужской?
    1. Не интуитивное название doNotHav

  Полиформизм, инкапусуляция, наследование (см. задача) interface vs abstract class SOLID single responsibility, open-closed, Liskov substitution, interface segregation и dependency inversion

Эти принципы, когда применяются вместе, предназначены для повышения вероятности того, что программист создаст систему, которую будет легко поддерживать и расширять в течение долгого времени[3]. Принципы SOLID — это руководства, которые могут применяться во время работы над программным обеспечением для удаления «кода с запашком» предписывая программисту выполнять рефакторинг исходного кода, пока тот не станет разборчиво написанным и расширяемым. Это часть общей стратегии гибкой и адаптивной разработки[en][3].

Инициал Представляет[1] Название[4], понятие

S SRP[5] Принцип единственной ответственности (The Single Responsibility Principle) Существует лишь одна причина, приводящая к изменению класса. O OCP[6] Принцип открытости/закрытости (The Open Closed Principle) «программные сущности … должны быть открыты для расширения, но закрыты для модификации.» L LSP[7] Принцип подстановки Барбары Лисков (The Liskov Substitution Principle) «объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы.» См. также контрактное программирование.

I ISP[8] Принцип разделения интерфейса (The Interface Segregation Principle) «много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс общего назначения.»[9]

D DIP[10] Принцип инверсии зависимостей (The Dependency Inversion Principle) «Зависимость на Абстракциях. Нет зависимости на что-то конкретное.»[9]

Принцип единственной обязанности

Принцип единственной обязанности (Single-Responsibility Principle, SRP) гласит, что на каждый класс должна быть возложена одна-единственная обязанность. У класса должна быть только одна причина для изменения.

Просто, потому что вы можете добавить все, что хотите в свой класс, не означает, что вы должны это делать. Обязанности помогут вам разработать приложение лучше. Спросите себя, должна ли логика, которую вы представляете, находиться в этом классе или нет. Использование уровней в приложении очень помогает. Разделите большие классы на меньшие и избегайте “божественных” классов. Последнее, но не менее важное, напишите простые комментарии. Если начинаете писать комментарии такие как in this case, but if, except when, or, то вы делаете это неправильно.

Принцип открытости/закрытости

Принцип открытости/закрытости (Open/Closed Principle, OCP): Сущности (классы, модули, функции и т.п.) должны быть открытыми для расширения, но закрытыми для модификации.

Вы должны сделать все переменные экземпляра private по умолчанию. Пишите методы get и set только, когда они действительно будут вам нужны. Я уже ответил на этот вопрос в предыдущей статье, поскольку девятое правило Объектной Гимнастики связано с этим принципом. Принцип подстановки Барбары Лисков

Принцип подстановки Барбары Лисков (Liskov substitution) в формулировке Роберта Мартина: «функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа не зная об этом».

Принцип подстановки Лисков (Liskov Substitution Principle, LSP ): Должна быть возможность вместо базового типа подставить любой его подтип. Давайте рассмотрим пример. Прямоугольник — плоская фигура с четырьмя прямыми углами. У него есть ширина (width) и высота (height).

Теперь, взгляните на следующий псевдо-код:

rect = new Rectangle();

rect.width = 10; rect.height = 20;

assert 10 == rect.width assert 20 == rect.height

Мы просто устанавливаем ширину width и высоту height на экземпляре Rectangle, и затем мы подтверждаем, что оба свойства правильны. Пока все идет хорошо.

Теперь мы можем улучшить наше определение, сообщив, что прямоугольник с четырьмя сторонами одинаковой длины называют квадратом. Квадрат — это прямоугольник, таким образом, мы можем создать класс Square, который расширяет класс Rectangle, и заменить первую строку, представленную выше, нижней:

rect = new Square();

Согласно определению квадрата, его ширина равна его высоте. Вы можете определить проблему? Первое утверждение перестанет работать, потому что мы должны были изменить поведение методов set в классе Square, чтобы соответствовать определению. Это нарушение Принципа подстановки Барбары Лисков. Принцип разделения интерфейса

Принцип разделения интерфейса (Interface Segregation Principle или ISP): много специализированных интерфейсов лучше, чем один универсальный. Другими словами, вам не придется реализовать методы, которые вы не используете. Осуществление ISP дает слабую связанность и сильную связность.

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

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

Обратите внимание на то, что это подобно Принципу единственной обязанности. Интерфейс — контракт, который удовлетворяет потребности. Нормально иметь класс, который реализует различные интерфейсы, но будьте осторожны, не нарушайте SRP.

Принцип инверсии зависимостей

Принцип инверсии зависимостей (Dependency Inversion Principle или DIP) имеет два основных положения:

• Абстракции не должны зависеть от деталей. • Детали должны зависеть от абстракций.

Этот принцип можно перефразировать, как использовать тот же уровень абстракции на заданном уровне. Интерфейсы должны зависеть от других интерфейсов. Не добавляйте конкретные классы к сигнатурам методов интерфейса. Однако используйте интерфейсы в своих методах класса.

Обратите внимание на то, что Принцип инверсии зависимостей не совпадает с Внедрением зависимостей. Внедрение зависимости это когда один объект знает о другом зависимом объекте. Иными словами, речь идет о том, как один объект получает зависимость. С другой стороны, Принцип внедрение зависимости заключается в уровне абстракции. Кроме того, контейнер внедрения зависимости — это способ для автоматического соединения классов. Это не означает, что вы делаете внедрение зависимости все же. Например, взгляните на Service Locator.

Также, вместо того, чтобы работать с классами, которые являются сильно связанными, используйте интерфейсы. Это называется программирование интерфейса. Он уменьшает зависимость от особенностей реализации и допускает повторное использование кода. Он также гарантирует, что Вы сможете заменить реализацию, не нарушая ожидания того интерфейса, согласно Принципу подстановки Барбары Лисков. Примеры паттернов, которые вы используете, DI Примеры антипаттернов MVP ,MVC SOA CQRS, Event sourcing

CQRS расшифровывается как Command Query Responsibility Segregation (разделение ответственности на команды и запросы). Это паттерн проектирования, о котором я впервые услышал от Грега Янга (Greg Young). В его основе лежит простое понятие, что вы можете использовать разные модели для обновления и чтения информации. Однако это простое понятие ведет к серьёзным последствиям в проектировании информационных систем. (с) Мартин Фаулер

Идея Event Sourcing в том чтобы записывать каждое событие, которое меняет состояние приложения в базу данных. Таким образом получается что мы храним не состояние наших сущностей, а все события которые к ним относятся. Однако мы привыкли к тому чтобы манипулировать именно состоянием, оно храниться у нас в базе и мы всегда можем его посмотреть. В случае с Event Sourcing мы тоже оперируем с состоянием сущности. Но в отличии от обычной модели мы это состоянием не храним, а воспроизводим каждый раз при обращении.

Многопоточность

Важно: для понимания доклада необходимо знать основы параллельного программирования, включая Monitors, Semaphores, read-write locks, атомарные операции (Interlocked) и т.д.

Удачи, красавица

⚠️ **GitHub.com Fallback** ⚠️