найкращий спосіб «представити» OOP / OOD команді досвідчених інженерів C ++


17

Я шукаю ефективний спосіб, який також не може образитись, щоб представити поняття ООП діючим членам команди? Мої товариші по команді не є новими мовами OO. Ми давно займаємось C ++ / C #, тому сама технологія знайома.

Однак я оглядаюсь і без великих вкладень зусиль (здебільшого у вигляді оглядів коду), здається, що ми виробляємо це код C, який трапляється всередині класів. Майже не застосовується єдиний принцип відповідальності, абстрагування або спроби мінімізувати зв'язок, лише декілька. Я бачив класи, які не мають конструктора, але отримують memset до 0, кожного разу, коли вони створюються.

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

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

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

Чи існує інший підхід, який би охопив широку аудиторію, ніж перегляд коду, але в той же час не буде відчувати покарання?

Я не свіжа дитина з коледжу, яка має утопічні ідеали ідеально розробленого коду, і цього не чекаю від когось. Причина, про яку я це пишу, полягає в тому, що я щойно робив огляд людини, яка насправді мала пристойний дизайн високого рівня на папері. Однак якщо ви класуєте малюнки: A -> B -> C -> D, в коді B, C і D всі реалізують майже один і той же публічний інтерфейс, а B / C має одну функцію вкладиша, так що вищий клас A робить абсолютно вся робота (аж до управління пам'яттю, розбору рядків, переговорів про налаштування ...) насамперед у 4-х методах mongo і, за всіма намірами та цілями, викликає майже безпосередньо в D.

Оновлення: Я технічний керівник (6 місяців на цій ролі) і маю повну підтримку менеджера групи. Ми працюємо над дуже зрілим продуктом, і витрати на обслуговування, безумовно, дають про себе знати.


Можливий дублікат - programmers.stackexchange.com/questions/67579
ChrisF

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

Після того, як я зробив цю публікацію, з'явилося пов'язане зв’язане, що дуже схоже на мою ситуацію: programmers.stackexchange.com/questions/43214/… . Мене хвилює точно те саме. Проблема полягає в тому, що в їхній команді було 2 розробника, і я точно міг би це впоратися з кодовими оглядами. Я шукаю підхід, який би працював з нашою командою (10+), я просто не можу спілкуватися з кожним розробником один на один стільки, скільки хотів би.
DXM

Відповіді:


5

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

Коли я навчався, я потребував певного часу, щоб шукати патологічні "погані" приклади в існуючому коді (різних проектів), і переробляв їх у презентації, крок за кроком, використовуючи принципи. Це продемонструвало це

  1. Зробити ці рефактори не так складно
  2. Це не займе багато часу
  3. Кінцевий результат (ретельно вибраний ;-)) явно кращий за вихідний код.

5

Огляди коду були дуже корисними, але проблема з переглядом коду полягає в тому, що вони виникають лише після факту.

На одному проекті ми робили дизайнерські огляди.

15 хвилин. На білій дошці. Обговорити дизайн перед кодуванням.

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

У нас також були "Огляди критичного дизайну", які були великою, спітнілою угодою. Вони передбачали безліч документів та тривалу презентацію. Їх важко було запланувати, і майже завжди їх витісняли, поки не почалося кодування, зменшивши їх значення до нуля.

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


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

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

1
@DXM: Що? Ви їх робите? Або не робити їх? Якщо великий, то ви не робите дизайнерські огляди - ви займаєтесь дизайном для когось іншого - хто вчиться, коли ви займаєтесь дизайном? Якщо маленький, то ви не робите дизайнерські огляди - "існуючий дизайн досить хороший" - хто нахиляється, коли ви ігноруєте дизайн? Якщо середній, ви не займаєтесь дизайном, а також не переглядаєте їх дизайни? Це не здається, що ви насправді робите фактичні огляди дизайну. Чому ти кажеш, що ти є, а потім наводиш три приклади, коли тебе немає?
S.Lott

@Lott: Після роздуму над вашою відповіддю, мій єдиний висновок - це ви абсолютно праві. Я здогадуюсь, що я повинен був сказати, що я виховував цю точну ідею принаймні 8 разів, і всі завжди погоджувалися, але так, якщо я оглянуся на ритм, який ми влаштували, ми насправді нічого не робимо. Я хотів би обговорити це далі, але мене вже дисциплінували модники за те, щоб обговорити на суворому веб-сайті Q&A. Чи можемо ми перейти до чату? Я хотів би пояснити ситуацію докладніше і, можливо, трохи підберіть свій мозок (або когось іншого, хто хоче приєднатися). Ніколи не спілкувався в чаті, ви знаєте, як це працює?
DXM

@DXM: тривіальність чату. І не надто корисно. Якщо у вас є додаткові запитання - більш детальні, ніж це початкове запитання, - вам слід задати ці більш детальні запитання. В тім-то й річ. У кількох випадках "подальше обговорення" означає "мені не подобається ваша відповідь на моє запитання з наступних причин ...", що є дурним. Не подобається відповідь - це просто не подобається відповідь і не потребує обговорення. У кількох випадках дискусія означає «моє запитання неясне, ви просто не можете прочитати». Непомітно, справді. Задавайте свої запитання. Як питання.
S.Lott

4

Я припускаю, що ви молодші за розробників, але вище в харчовому ланцюжку.

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

Старий код, як правило, був оптимізований для швидкого запуску обладнання на той час; Крім усього іншого, це означає зменшення рівнів успадкування та уникнення закликів функцій / методів до тривіальних операцій.

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

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


0

Намагання на тестування одиниць із 100% покриттям гілок кожного нового / зміненого методу не призведе до мінімізації зв'язку між методами.


УТ - це гарна ідея, але я не впевнений, що це дозволить досягти бажаного результату. Крім того, одним з основних принципів ОО є те, що з'єднання між функціями неминуче, тому вам краще зробити явні та згрупувати такі сполучені функції в одному класі.
MSalters

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

0

Можливо, ви захочете забрати книгу "Шаблони дизайну" у "Банди чотирьох". Це не характерно для C ++, тому ви не відкрито критикуєте своїх колег C ++ знань, коли ви посилаєтесь на нього. Але в той же час він стосується тем, які ви вважаєте актуальними. Крім того, книга широко прийнята як актуальна, тому вони не можуть легко відкинути її як теоретичну чи непрактичну.

З іншого боку, вважайте, що C ++ не є чистою мовою ОО, ні в дизайні, ні на практиці. Вся історія конструктора / мемсета звучить, що вам слід запровадити RAII, який зовсім не є технікою OO, а є специфічним для C ++ (на жаль -. Net's IDispose показує, що відбувається, коли RAII - це подумка). Тут є відповідні книги (Більше) Ефективний C ++ та (Більше) Винятковий C ++.


2
Але автори чітко заявляють, що дизайнерські зразки - це не вступ до ООП / OOD взагалі! Глядачам слід спочатку ознайомитись з технікою, яку пропонує OOP, перш ніж зануритися у каталог моделей жорсткого коду! "Head First Design Patterns" зробить хороше вступ.
Сокіл

2
З опису ОП виходить, що вони знають OOP / OOD, вони просто не користуються ним (можливо, з остраху, це буде занадто складно), і в цьому випадку книга, яка пояснює, чому це корисно, може мотивувати найкраще, ніж приклади коду.
wildpeaks

@wildpeaks: ОП говорить навпаки. Вони не знають OOP / OOD. Вони програмують OOP процедурно. Їм потрібно щось познайомити з техніками дизайну, і книга GoF не відповідає цьому сценарію.
Сокіл

Я мав у виду пропозицій But every time I bring up OOP, everyone always nods and makes it seem like they know exactly what I'm talking aboutі My teammates are not new to OO languages, але я можу бачити , як це трохи розпливчатим , дійсно , як вони можуть бути просто валяється знаючи ООП , коли ОП каже їм про це.
wildpeaks

1
@MSalters - передмова моделей дизайну: "Ця книга не є вступом до об'єктно-орієнтованої технології чи дизайну. Багато книг вже добре справляються з цим. Ця книга передбачає, що ви досить добре володієте принаймні однією об'єктно-орієнтованою мовою програмування, і ви повинні мати певний досвід і в об'єктно-орієнтованому дизайні ". Ця книга не відповідає вимогам. Вони повинні прочитати деякі матеріали початкового рівня.
Сокіл
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.