Поради щодо поширення об'єктно-орієнтованих практик [закрито]

Я працюю в середній компанії, яка налічує близько 250 розробників. На жаль, багато з них застрягли в процедурному способі мислення, і деякі команди постійно постачають великі програми Transacript Script , адже насправді додаток містить багату логіку. Вони також не в змозі керувати дизайнерськими залежностями, і в кінцевому підсумку отримують послуги, які залежать від іншої великої кількості послуг (чистий приклад Big Ball Mud ).

Моє запитання: Чи можете ви запропонувати, як поширити цей тип знань?

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

Кілька речей, які я роблю, щоб змінити це (але я або не вдається, або зміни занадто малі)

• Проведення презентацій про принципи дизайну (SOLID, чистий код тощо).
• Семінари про TDD та BDD.
• Тренерські команди (сюди входить використання сонара, пошукових помилок, jdepend та інших інструментів).
• Переговори щодо IDE та рефакторингу.

Кілька речей, які я думаю зробити в майбутньому (але я хвилююся, що вони можуть бути недобрими)

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

.

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

Вибачте, це запитання розбризкувало розчарування, але альтернативу, щоб написати це, було вдарити головою об стіну, поки я не пройду.

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

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

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

Що підводить мене до останнього моменту: OOP - це чудова ідея, і вона добре працює для певних проблем, але (і я говорю як із власного досвіду, так і перефразовуючи думку деяких великих розумів тут) для багатьох видів проблеми, це зовсім непридатно. Коли ви свіжий в OOP, а напівпроцедурний код спагетті - єдина альтернатива, з якою ви знайомі, OOP, природно, з’являється як подарунок з неба (і відносно це так), і ви, швидше за все, підходите всі проблеми, як цвяхи для вашого молотка OOP. Це єдино природно, і примушення OOP до (і за його межами) є хорошим способом набути свої навички OOP, тому це не все негативно. Але, можливо, (можливо, можливо) саме ця кодова база не потребує OOP. Можливо, це отримає набагато більше користі від процедурної архітектури,

TL; DR: Якщо ви хочете взагалі щось євангелізувати, нехай це буде (платформа-агностик) хорошими методами кодування, а не якоюсь певною парадигмою чи методологією.

Ви не можете змусити когось змінити, хто вже не хоче змінити. Ось чому команди, яких ви тренували, повернулися до своїх старих способів.

Тож справді ваше запитання повинно полягати в тому, "як змусити розробників бажати змінити підходи до ОО"?

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

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

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

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

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

Ваші ідеї оглядових команд та євангелістів ОО є хорошими. Це має бути більше, ніж лише ти, хто наполягає на цьому порядку денному.

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

Створіть команду євангелістів з ОО, які поширюють спосіб мислення OO в різних колективах (цим людям потрібно міняти команди кожні кілька місяців).

це гарна ідея. Це повинно бути ретельним, і про ОО слід говорити з нуля. Коли я вивчав ОО історичні анекдоти дуже допомагали.

Я б також запропонував,

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

Я згоден з Шуво Насером. Це велика перешкода, тому ставіться до цього більше як до підйому. Навчання, як створити всю програму за допомогою OOP, потребує часу.

1. Визначте тих, хто розуміє ООП, і перенесіть їх ближче до керівників команд, тренерів, дизайнерів, переглядачів коду тощо.
2. Використовуйте існуючий проект як навчальний посібник. Можливо, ті, хто в №1, були в цій команді.
3. Рефактор деяких існуючих проектів. Це може допомогти деяким людям будувати міст між своїм процедурним кодом до коду ОО. Почніть з основ. Вони повинні бачити, коли, де і чому ви використовуєте ці принципи.
4. Залучайте їх до сесій дизайну з людьми, які знають, що роблять.
5. Поставте їх у команди розробників разом із тим, хто може надати керівництво по розробці та переконайтесь, що проект дотримується принципів ОО (якщо припустити, що ви хочете це зробити в першу чергу, це тому, що це покращить розвиток).

Усиновлення рідко передує баченню переваг. Ми говоримо про складний дизайн і не використовуємо обкладинки звітів TPS .

У вас вже є хороші ідеї

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

Спритний або об'єктно-орієнтований?

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

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

Проблеми подолання?

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

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

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

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

База підтримки занадто мала? Зробіть тріад серед цих 250 людей та розберіть їх у три категорії: готові до участі, охочі вчитися та небажання вчитися. У вас є вагомі причини засмучуватися з деякими людьми, які не мають інтересу до змін. Ви також можете натиснути на мотузку. Це витрачені даремно зусилля. Якщо ви відчуваєте, хто підтримує зміни, ви можете дізнатися, що їх цікавить.

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

У ньому Довгостроковий? Поки ви не виробите чемпіона, який повинен вести справи за собою, слід розраховувати інвестувати відносини, будуючи час. Можливо, вам доведеться залишатися з командами, яких ви тренуєте, більше одного місяця. Поки команда не володіє вдосконаленими методами для себе, ви є лише поліцейським із технології чи методології. Наставництво - це процес, який може зайняти роки. Ваші розробники не хочуть робити те, що ви вважаєте важливим (я думаю, ви спеціально згадали про тестування модулів). Може знадобитися деякий час, щоб створити спільне бачення цінності, яку це приносить. Я знаю це на досвіді, тому що я колись виступав за інструмент висвітлення коду у компанії Fortune 500, яка мала велику репутацію якості, але менеджери та колеги так само з обережністю ставилися до цього.

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

Ви бачите лінію Свободи? Частина запровадження "Кращих практик" - це змусити людей відмовитись від свободи робити спільні речі. Визначення на розсуд програміста буде більш приємним, якщо ви шукаєте можливості залишити багато варіантів для розробників. Те, що вони обирають, відмежоване від того, що передбачено розділом, який ми можемо назвати лінією свободи. Можливо, будуть потрібні подібні, добре обґрунтовані підрозділи щодо організаційних, регіональних / конкретних сайтів, командних та особистих практик.

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

Найважливіше, що коли-небудь в цьому роді проривів (будь то OOP або будь-яка інша зміна парадигми, скажімо, функціональне програмування або що інше з'явиться в наступному році) - це КОДУВАТИ ОГЛЯД І ПЕРЕГЛЯДУВАННЯ ПЕРСОНАЛІВ . Супроводжуйте їх, переведіть команди на інший спосіб робити речі, які допоможуть їм.

Мій особистий шлях до об'єктно-орієнтованого програмування розпочався, коли деякі випадкові огляди коду, які роблять коди, піддавали мені покарання за те, що я працюю модульно і підтримую стан, не використовуючи повного C ++ OO; думати код, як

extern float clients_total;

void client_add(float sum);  
void client_substract(float sum);
float client_get_total();

(зауважте, що клієнт_тотал може бути повністю надмірним, будучи особливо погано спланованим прикладом)

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

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

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