Як поширити обізнаність щодо загального програмування серед членів команди?

Я перебуваю в оточенні, де люди вірять:

1. Java generics - це функція, яка використовується виключно для написання бібліотеки, а не для реального кодування.
2. C ++ - мова програмування ОО; templateє необов'язковою та ухиляється функцією

Хоча ці люди сильно покладаються на бібліотеки, написані за допомогою загального програмування (наприклад, STL, контейнери Java). Якщо я напишу код за допомогою templates або generics, рецензент коду, швидше за все, відхилить його і прокоментує його написати "належним / зрозумілим / елегантним" способом.

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

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

У світі все ще є люди, які не використовують джевері дженерики в "звичайному кодуванні". Я можу повірити у шаблони C ++, але генеричні? Їм навіть не важко вчитися / використовувати. Серйозно найкращі функції Java та C ++ - це відповідно дженерики та шаблони.

Найкращий спосіб переконати людей у ​​речах - це зробити переконливий аргумент, бути не загрозливим і бути правим.

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

1. Уникає дублювання коду.

Це очевидно, але поліморфний код - це загальний код. Саме тому його називають дженериком.

2. Підтримує кращу статичну перевірку.

Без параметричного поліморфізму ви в кінцевому підсумку писати такі речі , як public Object clone()або public boolean equals(object b)що є не тільки гидоти, у них є типи , які не пропонують жодної інформації про те, що вони роблять, і в кінцевому підсумку неминуче кидає виключення всюди. Альтернативою параметричному поліморфізму є ролі в усьому місці

3. Непараметричний поліморфізм OOP-код в основному не в змозі правильно обробити "бінарні методи".

Ти їх використовуєш часто.

4. Це найкраща практика

У Java використання найкращих практик вважається використанням дженериків (див. Ефективна Java Джоша Блоха). Основні мислителі С ++, такі як Саттер та Олександреску, також заохочують використання шаблонів для вирішення різноманітних проблем.

5. Він відповідає парадигмі ОО.

Люди часто цього не помічають, але поєднання підтипу та генерики створює систему НАШМО потужнішої експресивної та об'єктно-орієнтованої, ніж будь-яка система із лише однією з них.

Розгляньте міксини Scala. Це приємна функція, яка дозволяє збирати ваші предмети разом із складових частин. Загальна інформація та шаблони можуть імітувати деякі з цих переваг. Наприклад, скажімо, один з ваших об'єктів використовує базу даних. Хороший дизайн дозволить вам абстрагувати доступ до бази даних в окремий клас. Якщо зробити це правильно, це не тільки дозволяє знущатися зі сховища даних (ключ до перевірки), це також означає, що ви можете додавати альтернативні реалізації, як-от нову базу даних no-sql. Тут, можливо, у вас виникнуть проблеми, незалежно від того, яку реалізацію ви використовуєте, ви отримаєте різні можливості вашого бізнес-об'єкта.

Дженерики на допомогу!

   public class Business<S extends Datastore>{
      private S store; ...
   }

Тепер ви можете почати статично диференціювати свої Businessоб'єкти на основі вміння використовувати особливості бази даних. Вам все ще потрібні деякі перевірки часу виконання і кастинг, але ви можете почати створювати НАЙКЛІЧНИЙ код.

і

6. Звичайний код не існує.

У Всесвіті програмування є лише три речі:

1. бібліотеки,
2. конфігурації та
3. неправильний код.

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

Я вважаю таке ставлення приголомшливим. Після того, як ви звикли програмувати параметризовані типи, їх використання просто приносить біль. Крім того, у Java та C ++ є купа грубих плям, які вони допомагають виправити.

Це спеціалізована форма більш загального питання "як ти переконати начальників почати використовувати новіші та кращі технології / спосіб виготовлення речей?"

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

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

• Чи поліпшить дженерики (чи що завгодно) поліпшення цінності їх продукту? Напевно, ні.

• Чи ускладнюватиме дженерики (чи що завгодно) людям, які вони вже найняли для виконання своєї роботи? Так.

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

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

Я б передавав переваги дженериків рецензенту коду та іншим колегам перед будь-яким оглядом:

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

2) Generics забезпечують безпеку типу без накладних витрат на кілька реалізацій.

Отже, [1] та [2] знижують ризик помилки в коді. Це економить час розробника і, отже, гроші компанії.

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

Я б додав кілька тверджень про те, як інші програмісти не мають проблем з дженериками: Generics широко використовується на Java та багатьох інших мовах, таких як C #. Будь-якому серйозному програмісту було б важко життя без таких безпечних будівельних блоків.

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

Якщо ви поставите добру справу вперед і не отримаєте обґрунтованої відповіді натомість, тоді потайки почніть шукати іншу компанію, яка сприймає програмування серйозно.

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

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

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

У нещодавньому проекті Java я успішно додав деякий загальний абстрактний клас, тому що він задовольняв деякі основні речі: він полегшував речі іншим в команді, застосовував схему, яку архітектор вже запропонував, і мав якийсь загальний код, який програмістам не потрібно було копіювати і вставляти. Архитектор писав про просту схему про те, що досить компетентні люди все-таки помилилися (через складність фактичної системи в грі), але генеричні знаки, який клас куди йде.

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

А для того, щоб програмісти застосували цей шаблон, ви можете додати загальний тип, Contextщоб він використовував щось, що має Strategyтип. У кодовому варіанті це виглядатиме приблизно так на Java:

// declare the generic Context class that has a type "S" 
// that is an upper bound class of Strategy
public class Context <S extends Strategy> {
    S strategy;

    // Constructor with an initial strategy
    public Context(S initialStrategy) {
        this.strategy = initialStrategy;
    }

    public void doSomething() {
      strategy.execute(); // assumes that Strategy has an execute() method.
    }

    public void setStrategy(S strategy) {
        this.strategy = strategy;
    }
}

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

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

Завжди існує кілька способів зробити те саме. Якщо ви користуєтеся шаблонами, це неправильне використання шаблонів, тоді це не повинно перевірити код.

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

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

Однією з найбільш ефективних стратегій тут є зосередження уваги на крихітній перемозі. Я читав такий приклад у книзі : автор був непохитним користувачем, який не належить Apple. Їй вони не сподобалися, і вона не хотіла нічого спільного з ними. У неї було багато дискусій з людьми з позицією про-Apple, і кожен просто штовхав п'яти глибше. Тоді хтось купив їй iPod shuffle і подібне, її упередження зникли. Це не змусило її купувати тільки продукцію Apple, але жорсткий, закріплений анти-Apple позицію було замінено на більш збалансовану точку зору. Було місце для компромісів, і вона врешті повільно перейшла до Apple цілком.

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

Конкретний момент, на який слід зосередитися, залежить від вашої ситуації, але ось одна ідея: поділ, який ви накреслюєте між бібліотеками та «реальним кодом», здається дуже неприродним. На мою думку, програміст, який робить додаток, повинен витрачати 80% свого часу на бібліотеку для типу програми, яку він робить, і 20%, використовуючи цю бібліотеку для створення програми. Весь код, який варто зберігати, слід вважати бібліотекою. Я б запропонував вашим начальникам ви узагальнити частину свого коду у власній бібліотеці (якщо ви ще цього не зробили). За власною логікою вони повинні використовувати для цього дженерики, і згідно з оцінкою вище, 80% вашого коду може опинитися всередині бібліотеки. Як тільки ви знайдете всіх, хто використовує дженерики з іншого боку, вони повинні звикнути до цього, і упередження повинні згасати.

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

Я б запропонував ознайомитись із кількістю фактично наявних помилок (відкритих чи нещодавно виправлених), що містять у вашій базі помилок, яких можна було б уникнути, використовуючи дженерики. Шукайте ClassCastExceptions.

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

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

Ще кілька випадкових думок з мого загального шляху поки що:

• ClassCastExceptions трапляються під час виконання, але вони зазвичай з’являються на перших кількох запусках і їх легко виправити.
• У кожній статті, яку я читав про дженерики, зазначено, що іноді вони просто не працюють, і їх потрібно @SuppressWarnings(value="unchecked")періодично використовувати . Звідки ви знаєте, чи перебуваєте ви за межами дженериків чи просто ви дурні і вам потрібно думати важче?
• Це може бути важко застосувати @SuppressWarnings(value="unchecked")лише до одного рядка.
• Я додав кілька фантазійних дженериків до одного з моїх занять. Я знав декількох програмістів, які могли б покращити клас ще до того, як я сформулював його, який ніколи не міг би його торкнутися і отримав чисту компіляцію після цього.

Generics очистив мій код і занадто багато разів попереджав мене про проблеми, щоб відхилити його, але я також бачу збільшений час на розробку, додатковий час, витрачений на навчання, і Java-програмісти вимушені працювати на C #, C та Visual Basic. .. або Java 1.4. Я б зосередився на написанні коду, який можуть зрозуміти ваші колеги. Якщо ви можете засунути якісь зрозумілі дженерики, чудово. Я бачу дженерики Java як можливість / проблему, яка ще не з'ясована.