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

Разное

Интерфейсы

JAVA

Жизненный цикл разработки ПО (SDLC)

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

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

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

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

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

Модель 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 базируется на т.н. "agile-манифесте":

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

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

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

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

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

Типичные ошибки при адаптации 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) задачу в багтрекере.

Модные процессы разработки

Domain Driven Design

Domain Driven Design -- Разработчик сначала слушает не требования Клиента, но те слова, которые он употребляет. Тем самым определяя онтологию (предметную область) того что хочет Клиент. И её начинает реализовывать на самом нижнем уровне, добавляя те сущности, названия которых употреблял Клиент. А затем, уже когда Клиент более-менее сам начинает понимать что он хочет - просто перекомпоновывает и дорабатывает.

Test Driven Design

Test Driven Design -- сначала тест, потом разработка. У исповедующих этот способ разработки есть большие экзистенциальные трудности. Например, большая проблема для составления тестов идущих от логического НЕ. Трудно, скажем, написать тест на "система не должна взрываться", потому что непонятно как это проверить. Разработчик идёт от верификации, а валидация, которой в конечном счёте заинтересуется Клиент при приёмке - отсутствует.

OOP - базис

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

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

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

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

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

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

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

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

Пару слов о мотивации
Источник: комментарий к какой-то из статей на habrahabr.ru

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

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

Уровень квалификации разработчика

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

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

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

Распространённые ошибки
  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-дерева, иначе каждый раз у элемента верхнего будет искаться наследник и так далее.