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

21

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

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

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

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

ThuneGrill
источник
17
Какова ваша роль? Хрюкать девелопер? Ты облажался - найди лучшую работу. Ведущий разработчик? Вы можете быть в состоянии изменить ситуацию ...
Мэтью Флинн
2
Не столько технический долг, сколько плохой дизайн и люди, которые не изменятся
ozz
1
Я знаю о технических и деловых аргументах, я спрашиваю, как лучше донести эти знания до моих коллег, которые, кажется, не замечают этого. Они видят много классов, я вижу тестируемую, расширяемую систему
ThuneGrill
5
Извините, вы должны уйти. Вы говорите над головами своих коллег. Это не изменится, пока проект не станет неуправляемым. Если вам не нравятся ручные тесты и марши смерти, вам лучше пойти куда-нибудь еще.
Кевин Клайн
4
Не видя рассматриваемого кода (да, сложно предоставить достаточно хороший пример, поэтому нам просто нужно доверять вашему суждению здесь), трудно сказать, действительно ли отсутствует ОО или вы настаиваете на чрезмерно сконструированном культе груза. ОО абстракции без уважительной причины. Я думаю , все видели примеры более спроектированного объектно - ориентированного программирование, где абстракции опираются на слое абстрактных заводов по производству абстрактных фабрик и т.д.
Kromster говорит Моника поддержка

Ответы:

32

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

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

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

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

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

Карл Билефельдт
источник
3
это процедурный и грязный. Но я говорю о новом коде, который я пишу, который называется "слишком объектно-ориентированным"
ThuneGrill
5
Грязный процедурный код, расширяемый с помощью ОО-кода, не может быть улучшением, просто добавляя путаницу.
wirrbel
7
@ThuneGrill, вы предполагаете, что они выбрали свой стиль кодирования из-за незнания объектно-ориентированного дизайна, что если бы вы могли просто обучить их, они увидели бы свет. Если кто-то с прибыльным программным бизнесом на строго объектно-ориентированном языке до сих пор не изучил преимущества OOD, «новый парень» не сможет его убедить. Поверь мне на слово и слово других комментаторов. Если вы не можете или не хотите изменить свой стиль, чтобы команде было легче читать, вы должны сократить свои потери.
Карл Билефельдт
3
@ThuneGrill: Карл прав. Придерживайтесь прагматических, а не религиозных причин. ООП, безусловно, хорошая идея, но я видел, что она доведена до смешных крайностей. Результат - сделать из мухи слона. Вещи, которые можно выполнить с 1000 строками кода, в итоге получат 10000 строк кода с изобилием классов. Тогда, ну и дела, это трудно поддерживать, и производительность отстой. (Независимо от того, какие классы коллекции используются.)
Майк Данлавей
1
Я не обязательно откажусь от идеи, что вы можете убедить людей в этом. Это сложно, но это может быть сделано - я сделал это. Поскольку этот вопрос кажется закрытым, см. Workplace.stackexchange.com/questions/9703/…
Эми Бланкеншип
7

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

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

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

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

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

Родриго
источник
Пытаюсь быть, но у убер-архитектора (который не кодирует) ничего этого не будет.
ThuneGrill
Как только он заметит преимущества TDD и улучшенную OO (надежность, производительность, ...), вы привлечете ваше внимание!
Родриго
3

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

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

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

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

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

Питер Б
источник
1

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

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

Джон Рейнор
источник
1
Только что сделал, вот что вызвало всю дискуссию. Я только представил 3-4 абстракции поверх существующей функциональности
ThuneGrill