Я ищу эффективный способ, который также не кажется оскорбительным, чтобы представить концепции ООП существующим членам команды? Мои товарищи по команде не новички в ОО языках. Мы давно занимаемся C ++ / C #, поэтому сама технология знакома.
Тем не менее, я смотрю по сторонам и без особых усилий (в основном в форме обзоров кода), кажется, что мы производим код C, который оказывается внутри классов. Практически не используется принцип единой ответственности, абстракции или попытки свести к минимуму связь, это лишь некоторые из них. Я видел классы, у которых нет конструктора, но они устанавливают memset в 0 каждый раз, когда они создаются.
Но каждый раз, когда я поднимаю ООП, все всегда кивают и создают впечатление, что они точно знают, о чем я говорю. Знание концепций - это хорошо, но нам (некоторым больше, чем другим), кажется, очень трудно применять их, когда дело доходит до выполнения реальной работы.
Проверки кода были очень полезны, но проблема с проверками кода заключается в том, что они происходят только после факта, поэтому некоторым кажется, что в конечном итоге мы переписываем (это в основном рефакторинг, но все еще занимает много времени) код, который был только что написан. Также обзоры кода дают обратную связь только отдельному инженеру, а не всей команде.
Я играю с идеей сделать презентацию (или серию) и пытаюсь снова вызвать ООП вместе с некоторыми примерами существующего кода, который мог бы быть написан лучше и мог бы быть реорганизован. Я мог бы использовать несколько действительно старых проектов, которые больше никому не принадлежат, поэтому, по крайней мере, эта часть не должна быть деликатной проблемой. Однако будет ли это работать? Как я уже сказал, большинство людей давно занимались С ++, поэтому я думаю, что а) они будут сидеть и думать, почему я рассказываю им то, что они уже знают, или б) они могут воспринимать это как оскорбление, потому что я говоря им, что они не знают, как выполнять работу, которую они делали годами, если не десятилетиями.
Есть ли другой подход, который бы охватил более широкую аудиторию, чем обзор кода, но в то же время не показался бы лекцией о наказании?
Я не новичок в колледже, у которого утопические идеалы идеально разработанного кода, и я ни от кого этого не ожидаю. Причина, по которой я пишу это, заключается в том, что я только что сделал обзор человека, который действительно имел приличный дизайн высокого уровня на бумаге. Однако, если вы представляете классы: A -> B -> C -> D, в коде B, C и D все реализуют почти один и тот же общедоступный интерфейс, а B / C имеют одну линейную функцию, так что самый верхний класс A выполняет абсолютно вся работа (вплоть до управления памятью, разбора строк, согласования настроек ...) в основном с помощью 4-х монго-методов и, для всех целей и задач, вызывает почти непосредственно в D.
Обновление: я технический руководитель (на этой должности 6 месяцев) и имею полную поддержку менеджера группы. Мы работаем над очень зрелым продуктом, и затраты на техническое обслуживание, безусловно, дают о себе знать.