лучший способ «представить» OOP / OOD команде опытных инженеров C ++

Я ищу эффективный способ, который также не кажется оскорбительным, чтобы представить концепции ООП существующим членам команды? Мои товарищи по команде не новички в ОО языках. Мы давно занимаемся C ++ / C #, поэтому сама технология знакома.

Тем не менее, я смотрю по сторонам и без особых усилий (в основном в форме обзоров кода), кажется, что мы производим код C, который оказывается внутри классов. Практически не используется принцип единой ответственности, абстракции или попытки свести к минимуму связь, это лишь некоторые из них. Я видел классы, у которых нет конструктора, но они устанавливают memset в 0 каждый раз, когда они создаются.

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

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

Я играю с идеей сделать презентацию (или серию) и пытаюсь снова вызвать ООП вместе с некоторыми примерами существующего кода, который мог бы быть написан лучше и мог бы быть реорганизован. Я мог бы использовать несколько действительно старых проектов, которые больше никому не принадлежат, поэтому, по крайней мере, эта часть не должна быть деликатной проблемой. Однако будет ли это работать? Как я уже сказал, большинство людей давно занимались С ++, поэтому я думаю, что а) они будут сидеть и думать, почему я рассказываю им то, что они уже знают, или б) они могут воспринимать это как оскорбление, потому что я говоря им, что они не знают, как выполнять работу, которую они делали годами, если не десятилетиями.

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

Я не новичок в колледже, у которого утопические идеалы идеально разработанного кода, и я ни от кого этого не ожидаю. Причина, по которой я пишу это, заключается в том, что я только что сделал обзор человека, который действительно имел приличный дизайн высокого уровня на бумаге. Однако, если вы представляете классы: A -> B -> C -> D, в коде B, C и D все реализуют почти один и тот же общедоступный интерфейс, а B / C имеют одну линейную функцию, так что самый верхний класс A выполняет абсолютно вся работа (вплоть до управления памятью, разбора строк, согласования настроек ...) в основном с помощью 4-х монго-методов и, для всех целей и задач, вызывает почти непосредственно в D.

Обновление: я технический руководитель (на этой должности 6 месяцев) и имею полную поддержку менеджера группы. Мы работаем над очень зрелым продуктом, и затраты на техническое обслуживание, безусловно, дают о себе знать.

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

Когда я давал свое обучение, я потратил некоторое время на поиск патологических «плохих» примеров в существующем коде (различных проектов) и рефакторинг их в презентации, шаг за шагом, используя принципы. Это продемонстрировало, что

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

Проверки кода были очень полезны, но проблема с проверками кода заключается в том, что они происходят только после факта.

По одному проекту мы делали дизайн обзоры.

15 минут. На белой доске. Обсудите дизайн до кодирования.

Самая важная часть - планирование обзора проекта до начала любой работы по внедрению.

У нас также были «Критические Обзоры Дизайна», которые были большой, потной сделкой. Они включали много документов и длинную презентацию. Их было сложно запланировать, и почти всегда их выталкивали до начала кодирования, что сводило их ценность к нулю.

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

Я предполагаю, что вы моложе, чем некоторые разработчики, но выше в пищевой цепи.

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

Старый код, как правило, был оптимизирован для быстрой работы на оборудовании того времени; среди прочего это означает сокращение уровней наследования и избегание вызовов функций / методов для тривиальных операций.

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

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

Стремление к юнит-тестам со 100% -ным охватом ветвей каждого нового / измененного метода не приведет к минимизации связи между методами

Возможно, вы захотите забрать книгу «Шаблоны проектирования» из «Банды четырех». Это не специфично для C ++, поэтому вы не будете открыто критиковать знания ваших коллег по C ++, когда вы обращаетесь к ним. Но в то же время он затрагивает темы, которые вы считаете актуальными. Кроме того, книга широко признана актуальной, поэтому они не могут легко отклонить ее как теоретическую или непрактичную.

С другой стороны, учтите, что C ++ не является чисто ОО-языком ни в дизайне, ни на практике. Вся история конструктора / memset звучит так, что вы должны представить RAII, который вообще не является техникой ОО, но специфичен для C ++ (к сожалению - IDispose .Net показывает, что происходит, когда RAII является запоздалой мыслью). Соответствующими книгами здесь являются (Подробнее) Effective C ++ и (Подробнее) Exceptional C ++.