«Слишком объектно-ориентированный»

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

TDD также не очень практикуется здесь, но я хочу иметь тестируемый код. Закрывать бизнес-логику в статических приватных методах в больших «классах Бога» (что кажется нормой для этой команды) не очень поддается проверке.

Я изо всех сил стараюсь донести свою мотивацию до моих коллег. Есть ли у кого-нибудь совет о том, как я могу убедить своих коллег, что использование OO и TDD приводит к более легкому обслуживанию кода?

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

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

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

Все гениальны. Но если вы судите рыбу по ее способности лазить по дереву, она будет жить всю жизнь, полагая, что она глупая. - Альберт Эйнштейн

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

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

Читая ваш вопрос, я вспомнил один совет из книги Pragmatic Programmer.

Один из его советов Be a Catalyst for Change:

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

Пришло время готовить каменный суп. Выясните, что вы можете разумно просить. Развивайте это хорошо. Как только у вас это получится, покажите людям и позвольте им удивляться. Затем скажите: «Конечно, было бы лучше, если бы мы добавили…». Притворись, что это не важно. Расслабьтесь и подождите, пока они начнут просить вас добавить функциональность, которую вы изначально хотели. Людям легче присоединиться к постоянному успеху. Покажите им проблеск будущего, и вы заставите их сплотиться.

Итак, я думаю, что если вы начнете делать хорошую работу со своими знаниями в области OO и TDD, вскоре они начнут искать и спрашивать о вашей работе.

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

Сделать фабрики, где фабрики производят более одного типа объектов. Используйте внедрение зависимостей, где оно сразу показывает преимущества. Создайте интерфейсы, которые будут реализованы несколькими классами.

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

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

Войны выигрываются по одной битве за раз.

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

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