# БИБЛИОТЕКА Курсы Системная инженерия Теория ограничений Управление Linux Сознание, интеллект Политэкономия Сумма технологии Экстраполяция в будущее АНАЛИТИКА Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации АРХИТЕКТУРА Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Микросервисы ESB Solution Design DDD РАЗРАБОТКА Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Continuous Integration git Frontend HTTP/REST Apache Регулярка JS Perl ТЕСТИРОВАНИЕ Ресурсы QA и QC Цикл тестирования 1 Тест-анализ 2 Тест план 3 Тест-дизайн и покрытие Уровни тестирования Виды тестирования Баг-репорт Шаблоны XPATH Безопасность Нагрузочное Android Автоматизация Selenium Генератор ИНН ДАННЫЕ Об информации SQL MongoDB
Эта страница:
Почерпнуть мудрость ЖЦ разработки ПО (SDLC) Оценка "величины" задачи Модель Waterfall Методология RUP Методология Agile Методология Kanban Непрерывная интеграция (CI) OOP - базис WCF Распространённые ошибки Уровень квалификации разработчика Пару слов о ВМ и контейнеры
Ещё в этом разделе:
РАЗРАБОТКА Фронтенд HTTP/REST основы Apache web-server Регулярные выражения git Javascript Perl Python Ruby Rust Полезности в Windows
Другие разделы:
# АНАЛИТИКА АРХИТЕКТУРА ДАННЫЕ РАЗРАБОТКА БИБЛИОТЕКА ТЕСТИРОВАНИЕ
Разработка
Все балаганы с картинками и фасилитаторами заканчиваются в тот момент, когда насладившийся картинками и фасилитированным общением начальник уходит, и оставшимся инженерам надо, наконец, заняться настоящим мышлением, то есть выдать на-гора реально сложный работающий продукт.
Красивый и захватывающий процесс легко подменяет результат.
Конечно, инженеры, которых учили думать, работают не так, как об этом рассказывают опирающиеся на картинки люди из движения design-thinking.
Почерпнуть мудрость

Разное

Интерфейсы

JAVA

ЖЦ разработки ПО (SDLC)

Для IT-продуктов мы можем построить расширенную V-модель:

Если мы работаем по Agile, то все эти этапы выполняются внутри каждой пользовательской истории (user story). Если у нас более длинные итерации, то по этим фазам проходит сразу целая очередь или подсистема.
На V-модели видно сколько проектирования должно быть выполнено до старта нашего проекта. С другой стороны, видно, какие действия будут совершены для окончательной валидации нашего предмета поставки.
Соответственно, результаты предшествующего проектирования должны поступить нам на вход (причем, не всегда "самотёком"), а действия по валидации будут вызывать запросы на изменения, поддержку или дефекты, выявленные после поставки.

ЖЦ производства информационной системы в общем виде являет собой следующую развёртку во времени:

(скачать схему в XML)

Реализация программного продукта (Процесс 10 из схемы выше) в общем виде выглядит так:

Оценка "величины" задачи
Набросокъ:
"Размер" задачи Затрагиваемые Бизнес-процессы Потребность в степени вовлечения Заказчика и сторонних стейкхолдеров Объект доработки - тип компонента ПО
L (список наиболее суровых развестистых бизнес-процессов) высокая
(почти ничего не известно, размытые бизнес-требования, требуется информация от контрагентов)
  • Интерфейсы (интеграция с новыми Системами)
M (список бизнес-процессов "средней руки") средняя
(уже есть вопросы, чуются подводные камни в бизнес-требованиях, нет чётких кейсов воспроизведения ошибки)
  • данные (в БД, файлах)
  • формы GUI
  • интерфейсы (интеграция с другими Системами)
  • периодические задания (SSIS-пакеты, job'ы, cron'ы)
  • вспомогательные (плагины, хранимые процедуры SQL)
S (список коротких прямолинейных бизнес-процессов) минимальная
(уже всё понятно, и нам сообщено, есть чёткий кейс воспроизведения ошибки)
  • сообытийные процедуры для форм GUI
  • те или иные отчёты
  • подсистема управления правами

Размер задачи оценивать в максимальный из получившихся оценённых параметров, например:
У нас есть

  • предполагаются изменения в БП = Регистрация Клиента (S)
  • но потребность в вовлечении заказчика = средняя (M)
  • и объект доработки = форма GUI, событийные процедуры для форм GUI, данные (M)
, значит оцениваем задачу как М.

Потенциал для совершенствования: если суммируются несколько признаков одного уровня (например, объекты доработки), то оценка по этому признаку уходит на уровень выше.

Модель Waterfall
software development lifecycle

Водопад ("Waterfall") представляет собой прогнозируемый подход к разработке, когда сначала создаётся технический проект, план работ, а потом по этим эскизам выполняется работа. В случае срыва сроков, виноватым является разработчик. Waterfall часто используют государственные заказчики.

Выбирают Waterfall, если заказчик(у):

  • идёт в относительно стандартный проект, который до этого уже делался;
  • неплохо понимает, что хочет уже сейчас;
  • не готов отдать существенную часть своего времени контролю и плотному общению с технарями;
  • важно знать, сколько будет стоить разработка уже сейчас, и важно, чтобы эта была головная боль разработчика, как всунуть качество в ограниченный бюджет;
  • важно знать, когда будет завершена разработка, и важно, чтобы подрядчик финансово отвечал за срыв сроков.

Сравнение Waterfall и Agile
Методология RUP

RUP (Rational Unified Process) = методология разработки программного обеспечения, созданная компанией Rational Software.
Была целенаправленно разработана для разработки больших программных систем.

RUP использует итеративную инкрементальную модель разработки.
В конце каждой итерации (в идеале продолжающейся от 2 до 6 недель) проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного продукта.
Итеративная разработка позволяет быстро реагировать на меняющиеся требования, обнаруживать и устранять риски на ранних стадиях проекта, а также эффективно контролировать качество создаваемого продукта.
Полный жизненный цикл разработки Продукта состоит из четырёх этапов, каждый из которых включает в себя одну или несколько итераций:

Этап "Начальная стадия" (Inception). Итерация 1
Посвящена сбору требований будущих пользователей к системе. Пользователи рассказывают каждый свой кусочек работы (сценарий использования системы пользователем), а Аналитик из отдельных операций и процедур пытается собрать целый рабочий процесс.
Цель этой итерации выйти на бизнес-сценарий использования системы / будущий бизнес-процесс на основе ИС. Их может быть больше чем один, поэтому не стоит замыкаться на том чтобы был обязательно один.
Компания-Заказчик — это Банк. Он решает, что хочет начать предоставлять своим клиентам услугу по удаленной выдаче наличных при помощи банкоматов, установленных в офисах клиентов и на станциях метро.

Для оказания данной услуги, нужно разработать и доработать имеющееся у банка программное обеспечение. В ходе сбора требований и их анализа было выделено три крупных процедуры в бизнес-сценарии услуги:
  1. Загрузка наличных в банкомат Сотрудниками банка.
  2. Выдача наличных Клиенту по его запросу со счёта в банке.
  3. Учет количества загруженных и выданных купюр.
В этой итерации ещё нет работ связанных с проектированием архитектуры будущей системы, разработки программы, тестирования и доставки. RUP не ставит условий, что они обязательно нужны, но по своему усмотрению вы можете их выполнить.
Этап "Начальная стадия" (Inception). Итерация 2
После того как бизнес сценарии определены, собранные требования раскладываются по шагам бизнес-сценария и системным сценариям. На этом этапе также выявляются те шаги бизнес-сценариев, что были не выявлены в первой итерации.
В ходе второй итерации были выявлены две дополнительные процедуры к основному бизнес-сценарию:
  1. Мониторинг и нотификация, направляемая банкоматом в банк, об окончании в нём наличных.
  2. Мониторинг и нотификация о работоспособности банкомата или наличия на нем проблем/ошибок в работе.
Для обеспечения доступности услуги выдачи наличных в режиме 24/7.
Результатом этой итерации становятся:
  1. На 90% законченные бизнес-сценарии.
  2. Намеченные, но не детализированные системные сценарии использования по каждому бизнес-сценарию.
  3. Собранные требования структурированы по бизнес и системным сценариям.
Этап "Уточнение" (Elaboration). Итерация 3

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

Законченный результат передается Системным Аналитикам и Архитектору для моделирования того, что будет происходит внутри системы. Выделяются классы, кооперации между ними, последовательности взаимодействия. Формируется базовое представление об архитектуре будущей системы, выделяются подсистемы, компоненты системы и их распределение по узлам ИТ-решения.

Уже в этой итерации могут быть начаты работы по разработке и результатом итерации станет готовый прототип, поддерживающий выполнение первичных шагов-этапов ключевого бизнес-сценария. Его уже можно показывать пользователям для сбора обратной связи и уточнения требований.

Этот прототип не передается в опытную или промышленную эксплуатацию, так как заложенная в основу архитектура является первым пробным шаром и в последующих итерациях будет скорректирована.

Этап "Уточнение" (Elaboration). Итерация 4

Стартует параллельно третьей итерации, когда в ней закончены работы по анализу и начаты работы по проектированию.

На этой итерации происходит проработка первичных шагов-этапов остальных бизнес-сценариев. Причина по которой прорабатываются они, а не последующие шаги для ключевых бизнес-сценариев, это определение будущей архитектуры всей программы.

Каждый бизнес-сценарий может потребовать для своей реализации каких-то специфических компонент будущей системы и по этой причине архитектурные решения для каждого бизнес-сценария должны быть согласованы между собой.

Результатом этой итерации станут:

  1. Архитектурные решения для каждого бизнес-сценария.
  2. Согласованный проект общей архитектуры системы 1.0
  3. Вторая версия прототипа с готовыми первыми шагами вторичных бизнес-сценариев в дополнение к первым шагам ключевого бизнес-сценария.

Этап "Конструирование" (Construction). Итерация 5

Стартует параллельно четвертой итерации, когда в ней закончены работы по анализу и начаты работы по проектированию. Предполагается, что к моменту старта итерации уже получена обратная связь по результатам тестирования пользователями прототипа, изготовленного во время третьей итерации. Здесь происходит проработка остальных шагов-этапов ключевого бизнес-сценария и связанных с ними системных сценариев использования.

Предполагается, что к моменту начала этапа работ "Проектирование", уже будет выполнена реализация (разработка) четвертой итерации и начато тестирование второй версии прототипа.
Происходит уточнение согласованного проекта общей архитектуры системы после которого внесение каких-то концептуальных изменений в него практически сводится к нулю, но всё ещё возможно, так как остаются не реализованными полностью вторичные бизнес-сценарии.

Результатом итерации становятся:

  1. Полностью реализованный ключевой бизнес сценарий.
  2. Согласованный проект общей архитектуры системы 2.0
  3. Третья версия системы, реализующая ключевой бизнес-сценарий и первые шаги для вторичных бизнес-сценариев.

Здесь уже возможна передача системы для опытной эксплуатации бизнес-пользователям так как система уже перестаёт быть прототипом и в большей степени похожа на ту, что будет передана бизнес-пользователям как её финальный вариант.

Этап "Конструирование" (Construction). Итерация 6

Стартует параллельно пятой итерации, когда в ней закончены работы по анализу и начаты работы по проектированию.

Прописываются остальные шаги-этапы вторичных бизнес-сценариев и связанных с ними системных сценариев использования. Предполагается что к началу данной итерации выполнено тестирование второй версии прототипа, изготовленной вовремя четвертой итерации и получена обратная связь от пользователей по работе с первичными шагами-этапами вторичных бизнес-сценариев.

Результатом итерации становятся:

  1. Полностью реализованные вторичные бизнес сценарии.
  2. Финальный проект общей архитектуры системы 3.0
  3. Четвертая версия системы, реализующая все бизнес-сценарии.

Начинается полноценная опытная эксплуатация системы бизнес-пользователями и примерка её под промышленное использование.

Этап "Внедрение" (Transition). Итерация 7

Здесь происходит внесение каких-то критических изменений в реализацию бизнес-сценариев, выявленных в ходе опытной эксплуатации и не позволяющих полноценно использовать систему в промышленной эксплуатации.

Этап "Внедрение" (Transition). Итерация 8

На этой итерации проводятся работы по повышению удобства использования системы пользователями и оптимизации изготовленных решений. Пользователей в первую очередь интересует скорость и пропускная способность их участков. Происходит передача системы на поддержку. Проводятся формальные процедуры по завершению и закрытию проекта.

Методология RUP не ставит условий по количеству итераций и их распределению по фазам. Концепт фаз и итераций введен для снижения рисков, потребности в ресурсах, задания ритма реализации проекта и предоставления возможности внести требуемые изменения при разработке большой информационной системы.

Основная идея RUP -- выдать уже в первых итерациях прототип будущей системы с порцией готовых к использованию / применению бизнес-сценариев.
Так как доставка части Результата проекта (инкремента) осуществляется в конце каждой итерации, это позволяет начать получать выгоду от использования промежуточных версий Результата и возвращать вложения в проект ещё в ходе его реализации.

Новации RUP

  1. Бизнес-моделирование и связанные с ним Сценарии Использования (Use Case).
    Сперва разрабатывается бизнес-сценарий использования, где будущая система представляет собою "чёрный ящик", который удовлетворяет все потребности Пользователя/Бизнеса. На его основе разрабатываются системные сценарии использования, описывающие функции системы, которые будут поддерживать выполнение бизнес-сценария.
  2. На основе выделенных системных сценариев использования системы принимаются архитектурные решения и выделяются компоненты, которые будут поддерживать бизнес-сценарии и решается будут ли они использоваться совместно для поддержки нескольких бизнес-сценариев или останутся заточенными под конкретный сценарий. (Объектно-ориентированное проектирование и программирование)
  3. Наличие выделенных сценариев использования системы позволяет разделить их на первичные и вторичные. Вторичные основываются на результатах выполнения первичных сценариев, которые по большому счёту самодостаточны. Отсюда появляется возможность выделить итерации и разложить реализацию всех сценариев по ним.
Упрощённый концепт RUP:

Каждый бизнес-сценарий разворачивается в системные сценарии использования.
Каждый системный сценарий -- в требования к интерфейсам, алгоритмам, данным и не функциональные (производительность, время доступности, скорость ответа...).
На основе выделенных требований определяется будущая архитектура системы и её функциональные модули (сервисные подсистемы).
Подсистемы разбиваются на компоненты.
Компоненты содержат исполняемый код.

Методология Agile

Гибкая методология разработки (англ. Agile software development, agile-методы) = серия подходов к разработке ПО, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля.

Гибкий итеративный подход Agile не включает практик, он определяет ценности и принципы, базируясь на т.н. "agile-манифесте":

  • Люди и взаимодействие важнее процессов и инструментов
  • Работающий продукт важнее исчерпывающей документации
  • Сотрудничество с заказчиком важнее согласования условий контракта
  • Готовность к изменениям важнее следования первоначальному плану
Подход нацелен на минимизацию рисков путём сведения разработки к серии коротких циклов (итераций), которые обычно длятся 2-3 недели.
Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование.
Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации.
Подразумевается возможность заказчика вдруг и неожиданно в конце каждой итерации выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим "авралам" с массовым рефакторингом и переделками практически на каждой очередной итерации. В итеративном подходе предполагается очень плотное участие заказчика в процессе, он буквально должен жить с командой разработки, а в случае срыва сроков делить с ней риски.

Вот схематическое изображение ЖЦ одного из самых распространённых методов гибкой работы, SCRUM:
scrum

Выбирают Agile, если:

  • заказчик готов отдать 80%-100% своего времени проекту с полным погружением;
  • заказчик обладает достаточной компетенцией и готов погружаться в разработку вместе с технарями;
  • заказчик готов разделить риски за срыв сроков или за невысокое качество работы подрядчика;
  • заказчик, как и разработчик, отлично понимают, что на данный момент нормально требования не собрать, потому что они еще не продуманы до конца, а работать начинать надо, потому что рынок, бизнес, и всё такое.
  • разработчиками являются высококлассные специалисты, за плечами у которых десятки больших реализованных проектов, которые способны в голове за 20 минут набросать диаграмму классов небольшого модуля, тут же прикинуть процессы меняющие их состояния, предположить критические зависимости и т.д. В этом случае можно попытаться обходиться без чётких требований и стадии анализа как таковой

Типичные ошибки при адаптации Scrum

  • Проектного менеджера хоть и окрестили Владельцем Продукта, однако он не получил необходимых полномочий и поэтому не вправе формировать видение продукта или менять приоритеты реализации.
    Как и раньше, он вынужден согласовывать каждый свой шаг с руководством, зажат в рамки требований по срокам и объёму работ.
    А значит, скорость принятия решений осталась прежней. Никакого ускорения или адаптации под меняющиеся условия.
  • Проектную команду хоть и назвали Scrum-командой, но люди, включённые в неё, по-прежнему могут числиться каждый в своём отделе и подчиняются непосредственно своим линейным руководителям.
    Соответственно, каждый из участников команды прежде всего делает то, что ему поручит его линейный руководитель, а не Владелец Продукта. Как следствие, задачи по продукту будут всегда ниже по приоритету, а значит, скорость реализации продукта, под который "собрали" Scrum-команду, никак не повысится.
  • Скорее всего, как и прежде, участники команды будут заняты и в других проектах.
    В то время как Scrum прямо оговаривает: участники команды должны быть выделены в Scrum-команду на 100 % своего рабочего времени, и заниматься только тем продуктом, которые ведет их Владелец Продукта.
    Если люди "поделены на проценты" между проектами/продуктами, то они будут переключаться между ними, что резко снизит как вовлечённость, так и эффективность работы над каждым конкретным Проектом/Продуктом.

Сравнение Waterfall и Agile

Методология Kanban

Канбан = метод для определения, управления и совершенствования сервисов, поставляющих результаты умственного труда, такие как экспертные и креативные услуги, а также разработку физических или программных продуктов.

Основы современного Канбан:

  1. Визуализировать поток поставки
  2. Ограничивать WIP-лимиты
  3. Измерять время выполнения задачи (Lead Time). Минимизировать его.
  4. Сделать правила работы явными и известными для всех участников процесса
  5. Помогать друг другу
  6. Собирать статистику по времени выполнения (Lead Time) разного типа задач для прогнозирования последующих поставок

WIP-лимиты (Work In Progress, WIP) = лимит на количество единовременно находящихся в производстве рабочих элементов. Ограничение незавершённой работы.

Критерии готовности (Definition of Done, DoD) = чёткие и понятные всем критерии, по которым рабочий элемент может считаться готовым после отработки.

Время производства (Lead Time, LT) = время выполнения задачи с момента принятия обязательств до момента поставки.

Обязательство (Commitment) = чётко сформулированное негласное соглашение между заказчиком и сервисом о следующем:

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

Канбан-Доска (Board)

Каденции (встречи, митинги)

  • Собрание по пополнению (1 раз в неделю).
    Проводится в целях перемещения элементов за точку принятия обязательств (помещения рабочих элементов в систему) и контроля подготовки вариантов рабочих элементов к дальнейшему выбору
  • Ежедневная "летучка" (1 раз в день).
    Всё что нужно вместе со всеми посмотреть на доску и определить, что мешает каждой задаче справа налево перейти правее, и чему может помешать она.
  • Собрание планирования поставки (с частотой поставки)
    Проводится в целях контроля и планирования поставок заказчикам - выбрать те задачи, которые являются более приоритетными на ближайшую поставку. Происходит также тогда, когда есть какие-то проблемы с поставкой или неопределенность

Роли в Канбане

Менеджер Запросов для Сервиса (Service Request Manager, SRM) несёт ответственность за изучение потребностей и ожидания заказчиков, содействие выбору и приоритизации рабочих элементов на Собраниях по Пополнению.
Другие названия для данной роли: Менеджер Продукта, Владелец Продукта, Менеджер Сервиса.

Менеджер Поставки для Сервиса (Service Delivery Manager, SDM) несёт ответственность за поток работы, в ходе которого выбранных рабочие элементы поставляются заказчикам, за обеспечение проведения Канбан-Митингов и Собрание Планирования Поставки.
Другие названия роли: Менеджер Потока, Менеджер Поставок и даже Мастер Потока.

Стоимость задержки (Cost of Delay)

  1. Expedite --> несём потери уже сейчас.
    Делать поставку надо срочно.
  2. Fixed date --> начнём нести потери с определённой даты.
    Начинать разработку надо достаточно рано, чтобы обеспечить своевременную поставку.
  3. Regular / Standard --> стоимость задержки возрастает постепенно.
    Необходимо обеспечить разумные сроки ожидания поставки.
  4. Intangible --> стоимость задержки может оказаться значительной, но в отдалённой перспективе.
    Важно, но не срочно. Планировать поставку когда удобно.

Накопительная диаграмма потока (CFD)

Непрерывная интеграция (CI)

Непрерывная интеграция (CI - Continuous Integration) = практика разработки программного обеспечения, которая заключается в слиянии рабочих копий в общую основную ветвь разработки несколько раз в день и выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. В обычном проекте, где над разными частями системы разработчики трудятся независимо, стадия интеграции является заключительной. Она может непредсказуемо задержать окончание работ. Переход к непрерывной интеграции позволяет снизить трудоёмкость интеграции и сделать её более предсказуемой за счет наиболее раннего обнаружения и устранения ошибок и противоречий.
Непрерывная интеграция является одним из основных приёмов экстремального программирования.

Типовая экосистема разработчика ПО при непрерывной интеграции: Типовая экосистема разработчика ПО при непрерывной интеграции На рисунке мы видим следующие сущности:

  • IDE
    Разработчик. Пишет код и в какой-то момент коммитит его в репозиторий исходных кодов.
  • Репозиторий
    Хранилище исходного кода и различных метаданных о нем. Отсюда система непрерывной интеграции загружает код в процессе сборки.
  • Система непрерывной интеграции
    Позволяет автоматизировать процессы сборки исходных кодов, публикации собранных приложений, либо информации о выявленных проблемах. Наша основная цель.
  • Стенд (на рисунке выглядит как сервер)
    В данном случае сервер, на который загружается приложение после успешной сборки.
  • Трекер ошибок
    Система контроля и отслеживания ошибок в работе или сборке приложения. Именно сюда система непрерывной интеграции может записать отчет в случае невозможности успешно завершить сборку приложения.

Примерная последовательность действий, выполняемая в процессе сборки приложения: Примерная последовательность действий, выполняемая в процессе сборки приложения Рассмотрим рисунок на примере типичного спринта: разработчик пишет код и загружает(1) его в репозиторий. Далее, по какому-либо событию, в дело вступает система непрерывной интеграции. Она загружает из репозитория необходимые исходные коды(2-3) и запускает процесс их сборки(4). В случае успеха, собранное приложение может быть загружено(5-1) на стенд. В случае неудачи, система может создать(5-2) задачу в багтрекере.

OOP - базис

Объектно-ориентиированное программирование (ООП) = методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования/

Инкапсуляция = свойство системы, позволяющее объединить данные и методы, работающие с ними, в классе. Некоторые языки (например, С++) отождествляют инкапсуляцию с Сокрытием, но большинство (Smalltalk, Eiffel, OCaml) различают эти понятия.
Инкапсуляция обеспечивается следующими средствами:

  • Контроль доступа. Поскольку методы класса могут быть как чисто внутренними, обеспечивающими логику функционирования объекта, так и внешними, с помощью которых взаимодействуют объекты, необходимо обеспечить скрытость первых при доступности извне вторых. Для этого в языки вводятся специальные синтаксические конструкции, явно задающие область видимости каждого члена класса. Традиционно это модификаторы public, protected и private, обозначающие, соответственно, открытые члены класса, члены класса, доступные внутри класса и из классов-потомков, и скрытые, доступные только внутри класса. Конкретная номенклатура модификаторов и их точный смысл различаются в разных языках.
  • Методы доступа. Поля класса в общем случае не должны быть доступны извне, поскольку такой доступ позволил бы произвольным образом менять внутреннее состояние объектов. Поэтому поля обычно объявляются скрытыми (либо язык в принципе не позволяет обращаться к полям класса извне), а для доступа к находящимся в полях данным используются специальные методы, называемые методами доступа. Такие методы либо возвращают значение того или иного поля, либо производят запись в это поле нового значения. При записи метод доступа может проконтролировать допустимость записываемого значения и, при необходимости, произвести другие манипуляции с данными объекта, чтобы они остались корректными (внутренне согласованными). Методы доступа называют ещё аксессорами (от англ. access - доступ), а по отдельности - геттерами (англ. get - чтение) и сеттерами (англ. set - запись)

Наследование = свойство системы, позволяющее описать новый класс на основе уже существующего с частично или полностью заимствующейся функциональностью. Класс, от которого производится наследование, называется базовым, родительским или суперклассом. Новый класс - потомком, наследником, дочерним или производным классом.

Полиморфизм подтипов (иногда просто - "полиморфизм") = свойство системы, позволяющее использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта.

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

  • "полей" - переменных более элементарных типов;
  • "методов" - процедуров и функций, связанных с классом, для работы с его полями. Они определяют действия, которые можно выполнять над объектом такого типа, и которые сам объект может выполнять. То есть он является моделью информационной сущности с внутренним и внешним интерфейсами для оперирования своим содержимым (значениями полей).

Объект - cущность в адресном пространстве вычислительной системы, появляющаяся при создании экземпляра класса. Взаимодействие объектов в абсолютном большинстве случаев обеспечивается вызовом ими методов друг друга.

WCF

Создастся проект с 2 тестовыми методами и комментами к ним
Если без оптимизаций пока, то принцип такой: ты пишешь набор классов, которые будут сериализоваться-десерилизоваться. Это называется контракт данных
Потом описываешь в интерфейсе (IService) и классе-реализации (Service) методы, которые умеют получать-отдавать твои контракты

How do I create a WCF Service Library project in Visual Studio 2017?
individual components - windows communication foundation

Распространённые ошибки
  1. неосмысленные имена переменных;
  2. проверка наиболее возможной ситуации находится в конце списка проверок;
  3. отсутствие проверки "если ничего из указанного";
  4. отсутствие валидации параметров метода в самом начале метода;
  5. отсутствие валидации данных до выполнения операции с данными в БД типа update/insert (не отлавливаются пустые значения,..);
  6. обращение в БД с запросами вида "select * from A" (возвращает очень много данных);
  7. неоправданное и неаргументированное время жизни при использовании кэшей;
  8. ошибки с правами доступа (пароли лежат где-то в открытом виде,..);
  9. глобальные константы в коде классов;
  10. куча одинаковых(очень похожих) кусков кода не вынесены в функции;
  11. использование функции, когда не полностью известно(понятно) её предназначение и принцип работы (например, использование функции округления, не интересуясь в какую сторону она округлит);
  12. отсутствие комментариев на сложных участках;
  13. подключать/использовать библиотеки/функции дублирующие функционал друг друга, когда можно было бы обойтись чем-то одним из арсенала;
  14. оставлять в коммите код, использовавшийся для дебага (может тормозить систему, заполняет логи лишней информацией);
  15. размещение сложных условий в одну строку (нечитабельно, например t = y && p &&!q&&(!!l)?k?m:n :0);
    Никогда не пишите длинных if-ов
  16. при переборе массивов, особенно двумерных, каждый раз использовать обращение к элементу массива, а не присвоить его значение какой-нибудь переменной и работать с ней в пределах, даёт существенный прирост скорости в часто выполняемых операциях в том числе с клиентской стороны при обхода DOM-дерева, иначе каждый раз у элемента верхнего будет искаться наследник и так далее.
Уровень квалификации разработчика

Junior -- тот, кого нельзя оставить без присмотра. Задачу надо разжевать, код придирчиво отревьюить, время от времени узнавать, как дела и поправлять на ходу. Выхлопа от работы джуна ожидать не стоит (т.е. времени он не сэкономит, скорее потратит), но на него можно сгрузить рутину и через некоторое время он подтянется и выхлоп будет.

Middle -- работает работу сам. В задачах тоже разбирается сам, где не может, сам задаёт релевантные вопросы. Кроме ревью кода пригляда за ним не требуется, но и помощи в определении курса тоже не ожидается.

Senior -- автономная боевая единица. Если в него кинуть размытой формулировкой проекта, то он её сам уточнит, ещё и укажет на слабые места и покритикует, подберёт рабочий стек технологий (без оглядки на хайп) и сам в одиночку всё запрограммирует (и за джунами присмотрит). Ещё и заказчика пнёт (возможно, через прокладку-менеджера, если таковая зачем-то есть), что тот ему ещё вчера обещал уточнения к ТЗ прислать.

Пару слов о

О мотивации

Я множество раз в процессе своей работы непосредственно разработчиком наблюдал, как технические требования, сроки, разумные доводы и здравый смысл, приносились в жертву одной простой вещи - прибыли. Так почему же, спрошу я вас, дорогой автор, мотивация рядового разработчика должна отличаться от мотивации директора компании или заказчика, который ну очень-очень хочет поскорее начать зарабатывать деньги при помощи такой крутой штуки, как собственный программный продукт?

В современном капиталистическом обществе такие вещи, как совесть, сочувствие и добрая воля совершенно не поощряются, более того, нет ни единого социального механизма для их культивации и или хотя бы поддержания на определенном уровне. Так почему, что-то кроме денежного эквивалента моего труда должно меня волновать?

О KPI

Все рассказы о введении KPI для программистов неизменно заканчивались тем, что программисты переставали работать и вместо этого прокачивали KPI.
Зарплата зависит от числа закоммиченных строк кода? --пишем к каждой функции комментарий длиннее тела функции.
Зависит от числа закрытых тикетов? --заводим по десять тикетов на все аспекты каждой проблемы, а потом все закрываем одним патчем. Ну и так далее.

ВМ и контейнеры
(скачать схему в draw.io-формате)