Как мне доказать или опровергнуть, что «объекты Бога» не правы?

Краткое описание проблемы:

Короче говоря, я унаследовал кодовую базу и команду разработчиков, которую мне не разрешено заменять, и использование God Objects является большой проблемой. В дальнейшем я хочу, чтобы мы перефакторили вещи, но я получаю отпор от команд, которые хотят делать все с Богом-объектами «потому что это проще», и это означает, что мне не позволят пересматривать факторы. Я отодвинулся, сославшись на свой многолетний опыт разработки, на то, что я новый начальник, которого наняли, чтобы узнать эти вещи и т. Д., И так же, как и у представителя сторонних компаний, занимающегося продажами аккаунтов в оффшорных компаниях, и теперь это на уровне руководства и моей встречи это завтра, и я хочу пойти с большим количеством технических боеприпасов, чтобы защищать лучшие практики, потому что я чувствую, что это будет дешевле в долгосрочной перспективе (и я лично чувствую, что это то, о чем беспокоится третья сторона) для компании.

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

Вопрос:

Какие ресурсы я могу прямо процитировать (название, год публикации, номер страницы, цитата) от известных экспертов в этой области, которые прямо говорят, что использование «божьих» объектов / классов / систем плохо (или хорошо, так как мы ищем для наиболее технически обоснованного решения)?

Исследования, которые я уже сделал:

1. У меня есть несколько книг здесь, и я искал в их указателях слова «объект бога» и «класс бога». Я обнаружил, что, как ни странно, он почти никогда не использовался, и копия книги о GoF, которая у меня есть, например, никогда не использует ее (по крайней мере, согласно индексу передо мной), но я нашел ее в двух книгах ниже, но я хочу больше Я могу использовать.
2. Я проверил страницу Википедии на предмет «Объекта Бога», и в настоящее время на нем есть заглушка с небольшими ссылочными ссылками, поэтому, хотя я лично согласен с этим, в ней говорится, что на ней мало что можно использовать в среде, где личный опыт не считается действительным. Упомянутая книга также считается слишком старой, чтобы быть действительной для людей, с которыми я обсуждаю эти технические моменты, поскольку аргумент, который они выдвигают, заключается в том, что «когда-то это считалось плохим, но никто не мог доказать это, и теперь современное программное обеспечение говорит:« Бог » «объекты хороши в использовании». Я лично считаю, что это утверждение неверно, но я хочу доказать правду, что бы это ни было.
3. В книге Роберта С. Мартина «Гибкие принципы, шаблоны и практики в C #» (ISBN: 0-13-185725-8, в твердом переплете), где на странице 266 говорится: «Все знают, что уроки богов - плохая идея. Мы не хотим сконцентрировать весь интеллект системы в одном объекте или одной функции. Одной из целей OOD является разделение и распределение поведения на множество классов и функций ». - А потом продолжает говорить, что иногда все равно лучше использовать классы Бога (в качестве примера приводим микроконтроллеры).
4. В книге Роберта С. Мартина «Чистый код: руководство по гибкому программному обеспечению» на странице 136 (и только на этой странице) говорится о «классе Бога» и приводится его в качестве основного примера нарушения правила «классы должны быть маленькими». он использует для продвижения принципа единой ответственности », начиная со страницы 138.

У меня проблема в том, что все мои ссылки и цитаты происходят от одного человека (Роберт К. Мартин) и принадлежат одному и тому же человеку / источнику. Мне говорят, что из-за того, что он всего лишь одна точка зрения, мое желание не использовать «Бог-классы» недопустимо и не принимается как стандартная лучшая практика в индустрии программного обеспечения. Это правда? Я делаю что-то неправильно с технической точки зрения, пытаясь придерживаться учения дяди Боба?

Бог-объекты и объектно-ориентированное программирование и дизайн:

Чем больше я думаю об этом, тем больше я думаю, что это больше то, что вы изучаете, когда изучаете ООП, и это никогда явно не вызывается; Это подразумевает хороший дизайн - мое мышление (не стесняйтесь поправлять меня, пожалуйста, поскольку я хочу учиться), проблема в том, что я «знаю» это, но не все знают, поэтому в этом случае это не считается действительным аргументом, потому что Я фактически называю это универсальной правдой, когда на самом деле большинство людей статистически не знают об этом, поскольку статистически большинство людей не являются программистами.

Заключение:

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

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

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

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

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

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

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

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

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

Но учитывая то, где вы сейчас находитесь, я бы сказал, что вам лучше всего утверждать, что ваш подход принесет ощутимые долгосрочные выгоды, основанные на вашем опыте, и что он соответствует работе известных практиков, таких как дядя Боб и коллеги. и что вы хотели бы потратить несколько дней / недель на пример с узким рефакторингом с наивысшим качеством, чтобы продемонстрировать, как должен выглядеть ваш взгляд на хороший дизайн. Однако вам нужно будет согласовать все, что у вас есть, с конкретными бизнес-целями, выходящими за рамки ваших личных предпочтений.

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

1. Бог Объект является анти-модель , которая гласит , что

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

2. На конференции Google IO 2009 года эта тема была частично объяснена, когда была объяснена модель MVP. Это может не относиться к объекту Бога, но может дать вам боеприпасы.

3. Кроме того, использование этого анти-паттерна нарушает принцип единой ответственности в объектно-ориентированных проектах, который гласит:

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

4. Decaying Кодекс блог также говорит об этом и о том, что это решение.

5. Мы не можем говорить о принципе единой ответственности, не говоря о связывании объектов .

   [...] связь или зависимость - это степень, в которой каждый программный модуль опирается на каждый из других модулей.

   Если наличие тесно связанной системы может привести к assembly of modules [to] require more effort and/or time [to maintain] due to the increased inter-module dependency.более высокому уровню связывания объектов, это означает меньшую сплоченность и наоборот. Бог-объекты являются хорошим примером тесной связи, поскольку они знают больше, чем должны, поэтому перегружают их ответственностью, что значительно ограничивает возможность повторного использования кода.

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

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

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

   Что я обычно преподаю студентам, так это то, что может потребоваться больше усилий для принятия хороших стандартов программирования, но это всегда окупается в долгосрочной перспективе. Хорошим примером может быть тот, кто просит программиста написать функцию сортировки. У программиста есть два варианта; 1) написать функцию быстрой пузырьковой сортировки (менее 5 минут), которая не будет устойчивой при увеличении списка элементов, или 2) написать более сложный (или оптимизированный) алгоритм сортировки (быстрая сортировка и т. Д.), Который будет лучше масштабироваться с большими списками.

О, вот и я, еще один старый вопрос, но думаю, вы не выиграли этот спор, и вот почему.

Это звучит как проблема культуры

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

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

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

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

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

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

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

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

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

Вы можете привести некоторые из основных принципов ООП, такие как слабая связь и высокая когезия. «Объект Бога» звучит так, как будто он соединяет несвязанные классы и имеет низкую сплоченность.

Вы всегда можете спросить самого дядю Боба.

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

Другие термины, с которых вы можете начать поиск источников:

• SOLID
• Закон Деметры
• Большой шарик грязи

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

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

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

Тебе нельзя.

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

Даже если вы попытаетесь заменить эмоциональное слово «неправильный» количественно измеряемыми эффектами использования объектов бога, вы обнаружите, что:

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

И это игнорирует проблему принятия решения, когда конкретный объект является «богом».

В лучшем случае такого рода исследования могут продемонстрировать только эмпирическую корреляцию. Не подлинное доказательство.

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

Не используйте слова типа «доказательство», иначе люди, с которыми вы спорите, могут посмеяться над вами.

Вы можете увидеть гуру недели # 84 . Все дело в божественных объектах (монолитах) и в том, как они плохи.

Выдержка:

(Major) Он изолирует потенциально независимую функциональность внутри класса [...] (Minor) Он может препятствовать расширению класса новой функциональностью [...]

Я не уверен, что ваша команда действительно заинтересована в академическом доказательстве того, что «Бог не прав».

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

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

Быть очень конкретным и задавать вопросы вместо предоставления ответов может быть более полезным:

manager > Why did implement the new tax-calculation schema took more than 4 weeks
team > because {reason a}
manager > And why was {reason a}?
team > because {reason b}
manager > And why was {reason b}?
...
team > because {reason z}
manager > what could we do to avoid {reason z} ?
team > refactor code