Як я можу довести чи спростувати "Божі об'єкти" неправильно?

Зміст проблеми:

Коротше кажучи, я успадкував кодову базу та команду розробників, яку мені не дозволяють замінювати, і використання об'єктів God є великою проблемою. Йдучи вперед, я хочу, щоб ми переосмислили речі, але я отримую відштовхування від команд, які хочуть зробити все з об'єктами Бога, "бо це простіше", а це означає, що мені не дозволять повторно визначати фактори. Я відштовхнувся, посилаючись на свій багаторічний досвід розвитку, що я є новим начальником, якого найняли знати ці речі тощо, і так зробила третя сторона офшорних компаній, яка займається продажем рахунків, і це зараз на рівні виконавчої влади та моєї зустрічі це завтра, і я хочу використати багато технічних боєприпасів, щоб пропагувати кращі практики, тому що я вважаю, що в довгостроковій перспективі це буде дешевше (і особисто я відчуваю, що це хвилює третю сторону) для компанії.

Моя проблема - з технічного рівня, я знаю її хороший довгостроковий термін, але у мене виникають проблеми з ультракоротким терміном і 6-місячним терміном, і хоча це щось, що я "знаю", я не можу довести це посиланнями та цитованими ресурсами за межами однієї людини (Роберт К. Мартін, він же дядько Боб), тому що мене просять зробити так, як мені сказали, що мають дані від однієї людини, і лише одна людина (Роберт Мартін) недостатньо аргументує .

Питання:

Які ресурси я можу навести безпосередньо (Назва, рік опублікованого, номер сторінки, цитата) відомими фахівцями в цій галузі, які прямо говорять про те, що використання об'єктів / класів / систем "Бог" є поганим (або хорошим, оскільки ми шукаємо для найбільш технічно обґрунтованого рішення)?

Дослідження я вже робив:

1. У мене є низка книг, і я шукав їхні покажчики для використання слів «об’єкт бога» та «клас бога». Я виявив, що, як не дивно, його майже ніколи не використовується, а копія книги GoF, яку я маю, наприклад, ніколи не використовує (принаймні, згідно з індексом, що переді мною), але я знайшов це в двох книгах нижче, але мені хочеться більше Я можу використовувати.
2. Я перевірив сторінку Вікіпедії на предмет "Бог Об'єкт" та його наразі заглушку з невеликими посиланнями, тому, хоча я особисто згоден з цим, він говорить, що це не так багато, що я можу використати в умовах, коли особистий досвід не вважається дійсним. Цитована книга також вважається занадто старою, щоб бути дійсною людьми, з якими я обговорюю ці технічні моменти, оскільки аргумент, який вони висловлюють, - це "колись вважалося поганим, але ніхто не міг цього довести, а тепер сучасне програмне забезпечення каже" бог "об'єкти корисні для використання". Я особисто вважаю, що це твердження невірне, але я хочу довести правду, якою б вона не була.
3. У творі Роберта К. Мартіна "Agile Principles, Patterns and Practices in C #" (ISBN: 0-13-185725-8, тверда обкладинка), де на сторінці 266 сказано: "Усі знають, що заняття богом - це погана ідея. Ми не хочемо сконцентрувати весь інтелект системи в одному об'єкті або єдиній функції. Однією з цілей OOD є розподіл і розподіл поведінки на багато класів і багато функцій ". - А далі продовжує говорити, що іноді краще використовувати класи God Canyatly (посилаючись на мікроконтролери як приклад).
4. У статті "Чистий код: Роберт С. Мартін: Посібник з гнучкої майстерності програмного забезпечення" сторінка 136 (і лише ця сторінка) розповідає про "клас Бога" і називає це головним прикладом порушення правила "класи повинні бути малі". він використовує для просування єдиного принципу відповідальності ", починаючи з сторінки 138.

Проблема, яку я маю, - це всі мої посилання та цитати, що надходять від однієї і тієї ж людини (Роберт К. Мартін), і я з тієї самої людини / джерела. Мені кажуть, що оскільки він є лише одним поглядом, моє бажання не використовувати «Класи Бога» є недійсним і не сприймається як стандартна найкраща практика в галузі програмного забезпечення. Це правда? Чи роблю я неправильно з технічної точки зору, намагаючись дотримуватися вчення дядька Боба?

Об'єкти та об'єктно-орієнтоване програмування та дизайн:

Чим більше я думаю про це, тим більше я вважаю, що це більше щось, що ви дізнаєтесь, коли вивчаєте ООП, і це ніколи прямо не викликається; Яке неявне для хорошого дизайну - це моє мислення (Не соромтеся виправляти мене, будь ласка, як я хочу дізнатися). Проблема полягає в тому, що я "знаю" це, але це не всі, тому в цьому випадку його не вважають коректним аргументом, оскільки Я фактично називаю це універсальною істиною, коли насправді більшість людей її статистично не знають, оскільки статистично більшість людей не є програмістами.

Висновок:

Я втрачаю те, що шукати, щоб отримати найкращі додаткові результати, оскільки вони висловлюють технічну заяву, і я хочу знати правду і мати можливість довести це цитатами, як справжній інженер / вчений, навіть якщо Я упереджений об'єктами бога через свій особистий досвід з кодом, який їх використовував. Будь-яка допомога чи цитування були б вдячні.

Обґрунтування будь-якої зміни практики здійснюється шляхом визначення больових точок, створених існуючою конструкцією. Зокрема, вам потрібно визначити, що важче, ніж це повинно бути через існуючу конструкцію, що є крихким, що зараз ламається, що поведінка не може бути реалізована просто, як прямий (або навіть дещо опосередкований) результат поточна реалізація або, в деяких випадках, як страждає продуктивність, скільки часу потрібно, щоб довести швидкість нового члена команди тощо.

По-друге, робочий код перемагає будь-які аргументи щодо теорії чи гарного дизайну. На жаль, це стосується навіть поганого коду. Таким чином, вам доведеться запропонувати кращу альтернативу, а це означає, що вам, як прихильнику кращих моделей і практик, вам потрібно буде переробити фактор, щоб дратувати кращий дизайн. Знайдіть вузьку площину стилю відстежувальної кулі за допомогою існуючої конструкції та застосуйте рішення, яке, можливо, для ітерації підтримує реалізацію об'єкта бога, але відкладає фактичну реалізацію на новий дизайн. Потім напишіть код, який використовує перевагу цього нового дизайну, і покажіть, що ви виграєте через цю зміну, будь то продуктивність, ремонтопридатність, функції, виправлення помилок або перегонових умов або зменшення пізнавального навантаження для розробника.

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

Нарікати на об'єкт Бога працює лише тоді, коли ти проповідуєш хору. Це інструмент для іменування проблеми, і він працює лише для вирішення проблеми, коли у вас є сприйнятлива аудиторія, яка є старшою та достатньо мотивованою, щоб зробити щось з цього питання. Виправлення об'єкта God виграє аргумент.

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

Я думаю, ви знайшли достатньо ресурсів, щоб обґрунтувати свій аргумент; люди на таких зустрічах звернуть увагу лише на підсумки вашого дослідження, і вони перестануть слухати, коли ви згадаєте два-три підтверджуючих джерела. Спочатку слід зосередитись на тому, щоб викупити, щоб вирішити проблему, яку ви бачите, а не обов'язково доводити, що хтось інший помиляється чи ви самі маєте рацію. Це соціальна проблема, а не логічна.

У ролі технологічного лідерства вам потрібно прив’язати будь-яку свою ініціативу до бізнес-цілей, тому найважливішим для того, щоб зробити свою справу керівникам, це те, що буде робити для досягнення цих цілей. Оскільки вас також вважають "новим хлопцем", ви не можете просто розраховувати, що люди кинуть свою роботу або очікують, що вони швидко припадуть до черги; вам потрібно вибудувати деяку довіру, доводячи, що ви можете досягти. Що стосується довгострокової турботи, то в ролі керівництва вам також потрібно навчитися зосереджуватися на результатах, але не обов'язково бути прив’язаними до специфіки результату. Ви зараз там, щоб надати стратегічне керівництво, усунути тактичні перешкоди від прогресу вашої команди та запропонувати наставникам своєї команди, а не вигравати битви за довіру з власними членами команди.

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

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

По-перше, ви повинні продемонструвати, що будь-яка вимірювана організація повинна прийняти передовий досвід галузі. Кажучи, що "це просто працює на нас!" не можуть бути виміряні ні часом, ні ресурсом, оскільки це просто непередбачувано. Інженерія програмного забезпечення - це наука настільки ж, як і будь-які інші галузі науки, і ці концепції вивчені, досліджені, апробовані та задокументовані.

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.

У випадку неможливої ​​події, що це не є незрозумілою проблемою культури ...

Тепер припускаючи, що люди на вершині дуже сприйнятливі до змін, і вони насправді готові довіряти вам, щоб це зробити, вам дійсно потрібно лише переставити всі свої аргументи грошима та втраченою можливістю.

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

Просто визнайте, що особливо вперта і дурна культура підтримуватиме статус-кво за будь-яку ціну, навіть якщо фактична фізична покрівля компанії насправді загорілася.

Ви можете навести деякі основні принципи OOP, такі як слабке з'єднання та висока згуртованість. "Бог об'єкт" звучить так, що він поєднує непов'язані класи і має низьку згуртованість.

Ви завжди могли запитати самого дядька Боба.

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

Інші умови, з якими ви можете почати, шукаючи джерела:

• Твердий
• Закон Деметра
• Велика кулька бруду

Усі ці експрес-пов'язані поняття, які можуть дати життєздатні довідкові джерела, хоча вони насправді не називають його таким.

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

Як я можу довести чи спростувати «богові» об'єкти неправильно?

Ти не можеш.

Цей вид припущень не піддається математичному доказуванню, а математичний доказ - єдиний вид доказу, який є звуком.

Навіть якщо ви спробуєте замінити емоційне слово "неправильно" кількісно вимірюваними ефектами використання об'єктів бога, ви виявите, що:

1. наявні заходи є неочищеними,
2. Є кілька достовірних досліджень, де ці заходи були кількісно визначені для коду, виробленого професійними програмістами
3. мало таких правдоподібних досліджень, де мовні конструкції чи конструктивні (анти-) зразки були пов'язані з цими заходами.

І це ігнорування питання вирішення, коли конкретний об’єкт є "богом".

У кращому випадку ці види дослідження могли лише демонструвати емпіричну кореляцію. Не справжній доказ.

Те, що ви насправді робите, - це обговорення плюсів і мінусів "богових" об'єктів з метою зміни думок інших людей ... а потім практики вашої організації.

Не використовуйте такі слова, як "доказ", або люди, з якими ви обговорюєте, можуть сміятися вам в обличчя.

Ви можете побачити гуру тижня # 84 . Вся справа в об'єктах бога (монолітах) і тому, як вони погані.

Витяг:

(Основний) Він виділяє потенційно незалежну функціональність всередині класу [...] (Незначний). Це може перешкодити розширенню класу новою функціональністю [...]

Я не заперечую, якщо ваша команда справді зацікавлена ​​в академічній доказі того, що "Божі об'єкти не відповідають".

З психологічної точки зору, ваш підхід до рефакторингу може бути неправильно сприйнятий як атака на компетентність команди a la: "команда зробила погану роботу", хоча програма працює так, як очікувалося.

Те, що ви насправді хочете зробити, - це впоратися з негативними побічними ефектами "коду спагетті" та "Божих об'єктів": вибудовує кошти на додавання нових функцій через збільшення помилок, викликаних побічними ефектами.

Бджілка дуже конкретна і запитання замість надання відповідей можуть бути кориснішими:

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