Можно ли использовать метапрограммирование, хотя не все мои коллеги это понимают?

102

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

Недавно я перешел на новую работу, где я работаю в более крупной команде, и это беспокоит некоторых моих коллег, потому что они этого не понимают.

Я всегда стараюсь использовать весь потенциал языка, но некоторые (не все) мои коллеги воспринимают это как риск (некоторые приветствуют такой подход).

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

У меня вопрос, кто прав, что мне делать?

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

камикадзе
источник
38
Это в конечном итоге основано на мнении. Лично я устанавливаю правило не использовать функции, настолько сложные, что они случайно завершаются по Тьюрингу, такие как метапрограммирование шаблонов C ++.
Килиан Фот
24
Шаблоны @KilianFoth не "случайно" завершены по Тьюрингу. Они всегда были призваны стать мощными инструментами абстракции
Caleth
73
Код, который никто не может понять, не является более высоким стандартом.
Гбертон
37
@Caleth Херб Саттер называет их случайно завершенными по Тьюрингу . Конечно, они предназначались для того, чтобы быть мощными функциями абстракции, но я не думаю, что они предназначались для того, чтобы допускать столь запутанные, неразрешимые конструкции, как позволяет полнота по Тьюрингу. И, конечно, их синтаксис не был разработан, чтобы сделать такое метапрограммирование менее прозрачным, чем необходимо.
оставил около
26
Ложная дихотомия. Вы можете программировать по «более высокому стандарту» и оставить C с классами, охватить современный C ++, использовать шаблоны (например, STL), а также метод const, no (), арифметику без указателей, семантику значений, много хорошего, без заголовка ИБНТО ТМП. Если вы не видите дневного света между C-with-classes и TMP, значит, вы делаете это неправильно.
Кейт Грегори

Ответы:

185

Метапрограммирование в порядке. То, что вы пытаетесь сделать, не в порядке.

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

Проблема не в метапрограммировании, а в следующем:

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

Это где вы попали в беду. У вас есть мнение. Хорошо иметь мнение, что метапрограммирование это хорошо. Хорошо иметь мнение, что мы все должны стремиться быть лучшими разработчиками C ++.

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

Это нормально, чтобы хотеть метапрограмму. Хорошо, если вы хотите научить других метапрограмме. Но поймите, что для других также хорошо выбрать не учиться метапрограмме, и это будет правдой, пока вы не окажетесь во власти. (и, как отраслевой секрет: когда вы, наконец, являетесь ведущим разработчиком, на позиции власти, вы совсем не на позиции власти. Есть кто-то, кто контролирует кошельки, которые находятся у власти).

Если вы хотите побудить их к метапрограммированию, начните с малого . Начните с одного, enable_ifчто облегчает чтение API. Затем прокомментируйте дневные лучи. Тогда, возможно, найдите один случай, когда метафункция шаблона превращает 10 больших повторяющихся классов в 1 класс с 10 маленькими помощниками. Комментарий, черт возьми, из этого. Получать отзывы. Узнайте, что люди думают об этом. Будь в порядке, если они скажут тебе не делать этого. Найдите нишу, где метапрограммирование зарабатывает так тщательно, что все ваши коллеги (неохотно) соглашаются, что это был правильный инструмент для работы.

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

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

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

Корт Аммон
источник
72
Замените «метапрограммирование» другим стилем, техникой, технологией, библиотекой, и ответ по-прежнему великолепен!
Андрейс
4
Ваш начальник должен заботиться о том, чтобы ваш код в дальнейшем можно было поддерживать. Большинство боссов даже не знают, что такое сопровождение кода. У них практически нет технических знаний, поэтому я бы не стал доверять их решениям, носящим скорее политический характер.
t3chb0t
4
@ t3chb0t: опытный руководитель знает, сколько денег нужно потратить на обслуживание клиентов (например, исправление ошибок и новые функции) и как минимизировать эти затраты. Ремонтопригодность - самый мощный инструмент для этой цели. Этот босс, возможно, не знает технических деталей, но должен иметь возможность создать команду, которой можно доверять в этом вопросе.
Mouviciel
25
@DDrmmr Я установил тон для тех, кто считает, что программисты должны использовать метапрограммирование для повышения стандарта. Я не думаю, что это должно быть скрыто от того, где наименее опытный член команды может поддерживать его. Он должен быть скрыт от того, где команда может поддерживать его, и, возможно, даже сильнее, он должен быть скрыт от того, где команда может поддерживать его без вас . В противном случае вы пишете себе работу.
Cort Ammon
15
@ Джошуа Я обнаружил, что не существует такой вещи, как «код, который не нуждается в обслуживании».
Корт Аммон
39

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

Обратите внимание, что использование шаблонного метапрограммирования на C ++ всегда является компромиссом: конечно, иногда оно может помочь сделать некоторые части приложения более СУХИМЫМИ, и это определенно полезно для создания высокоэффективных и многократно используемых библиотек.

С другой стороны, эти преимущества связаны с определенными затратами: код становится более абстрактным, часто намного труднее для чтения, намного сложнее для отладки и гораздо труднее поддерживать. Это делает полезность метапрограммирования в прикладном программировании часто сомнительной. Итак, предполагая, что вы не собираетесь создавать следующий STL, каждый раз, когда вы испытываете желание использовать метапрограммирование, спросите себя, действительно ли эти недостатки того стоят. И если вы не уверены, обсудите это со своим рецензентом во время проверки кода.

Док Браун
источник
Я согласен, но обсудите это с QA, прежде чем поместить это в код. Нет смысла создавать то, что будет отвергнуто.
Shawnhcorey
8
Как насчет: «Я согласен. Но ...» Изменение его на «полностью» полностью меняет смысл. Всегда нужно обсуждать что-то необычное с QA, прежде чем тратить на это время. Вы заявили, что это обсуждение должно проходить при проверке кода, после того как время потрачено.
Shawnhcorey
@shawnhcorey: конечно, если «QA» в вашей организации отвечает за стандарты кодирования. Тем не менее, это ИМХО не типичная роль «QA» - в большинстве организаций, которые я знаю, термин «QA» относится к группе людей, которые осуществляют контроль качества в «черном ящике», не отвечая за то, какие элементы языка программирования должны быть использованы, а какие нет. Эти люди редко достаточно квалифицированы в программировании, чтобы обсуждать такие детали.
Док Браун
2
@shawnhcorey: это именно моя точка зрения, роль QA сильно варьируется в разных организациях. Во многих организациях специалисты по QA не имеют представления о программировании, поэтому они, вероятно, не подходят для обсуждения такой темы.
Док Браун
2
@shawnhcorey: ну, с одной стороны, вы написали «QA - это общий термин», с другой - у вас очень специфическая роль и ответственность QA - звучит для меня немного противоречиво.
Док Браун
18

Мое общее мнение: если у вас есть выбор, как это часто бывает, между следующими тремя вариантами:

  • Набирайте вручную много нетривиальных структур кода;
  • Используйте метапрограммирование шаблона C ++ для автоматизации генерации кода;
  • Используйте другой механизм генерации кода, такой как макросы или другой язык программирования, для генерации исходных файлов C ++

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

Когда вы используете шаблонное метапрограммирование ( TMP ), чтобы избежать повторения, вы должны использовать его для создания хорошо документированных, тщательно протестированных абстракций, которые локализуют сложность в коде TMP, облегчая написание правильного клиентского кода. Это дизайн стандартной библиотеки C ++.

Я не думаю, что мы можем судить, кто прав или нет, не видя пример кода, который вы пытаетесь написать.

Брайан
источник
2
Вы также можете использовать copy + paste вместо того, чтобы печатать его вручную ;-)
Pa --lo Ebermann
4
@ PaŭloEbermann: Черт, нет!
Джошуа,
2
@ PaŭloEbermann, один магазин, в котором я был, назвал этот подход «начало-отметка-ошибка, конец-отметка-ошибка, копирование-ошибка, копирование-ошибка, копирование-ошибка».
Келли С. Френч
12

Разработчики программного обеспечения должны стремиться написать работающий код, который работает, очевидно, который можно протестировать, который можно проверить, который можно отладить и который можно адаптировать, когда требуются изменения. Если запись "C с классами" достигает этого, то это просто прекрасно.

И это те стандарты, которым вы должны оценивать свой код. Особенно: работает ли он очевидно, может ли он быть проверен, может ли он быть проверен, может ли он быть отлажен, и может ли он быть адаптирован при необходимости?

gnasher729
источник
9

Аргумент из сострадания:

Предоставляет ли ваша работа свободное время для обучения или, альтернативно, можете ли вы убедить своих боссов выделить несколько часов на изучение этих языковых возможностей?

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

Андре Парамес
источник
8

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

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

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

Для меня немного больше печатания, возможно даже некоторое дублирование кода, но то, что я могу поставить перед «C с классами плюс STL», когда это требует модификации, гораздо полезнее, чем какая-то невероятно элегантная вещь TMP, которую может поддерживать только я. (И поэтому будет вечно поддерживать). Помните также, что специалист по C с классами может оказаться экспертом в предметной области, и этот опыт обычно намного ценнее, чем быть юристом по языку.

Я забыл, кто это сказал, но «Все знают, что отладка сложнее, чем писать ее в первую очередь, поэтому, если вы запрограммируете ее настолько умно, насколько сможете, как вы будете когда-либо ее отлаживать?».

Даже если я действительно могу написать современный C ++, я обычно предпочитаю этого не делать, это означает, что я должен меньше заниматься программированием обслуживания.

Дэн Миллс
источник
7

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

Дэррил Скотт
источник
3
Вы заняты для производства кода, который удовлетворяет спецификации. да, но вы забываете об этом также в меру знаний .
t3chb0t
2

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

Если это последнее, я бы посоветовал вам продолжать делать это вместе с вашей командой.Каждая хорошая команда должна делать содержательные обзоры кода, которые обсуждают не только проблемы стиля, но также и то, использует ли решение программиста наилучший подход, использует ли соответствующие языковые функции, является ли оно обслуживаемым и тестируемым и т. Д. Ваше решение для метапрограммирования должно заполнить один такой сеанс обзора, вероятно, весь день Программисты, которые отвергают ваш подход, должны изложить альтернативы (например, генерацию кода с помощью perl, дублирование кода и т. Д.) И показать, как он работает в соответствии с указанными критериями по сравнению с вашим решением. Ваша задача, как их дружелюбного «оппонента» в этом аргументе, состоит в том, чтобы показать, что это способ выполнить работу быстро, что обслуживание простое, тестирование простое, и код действительно читабелен, как только вы преодолеете препятствие Разбор смешной грамматики.

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

Питер А. Шнайдер
источник
0

На этот вопрос нет правильного ответа.

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

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

Ichthyo
источник
-4

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


Недавно я перешел на новую работу, где я работаю в более крупной команде, и это [метапрограммирование] беспокоит некоторых моих коллег, потому что они этого не понимают.

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


Я всегда стараюсь использовать весь потенциал языка, но некоторые (не все) мои коллеги воспринимают это как риск (некоторые приветствуют такой подход).

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


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

Я не. Я думаю, что это показывает ваш опыт.


У меня вопрос, кто прав, что мне делать?

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


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


РЕДАКТИРОВАТЬ

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

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

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

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

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

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

t3chb0t
источник
10
Этот ответ ужасен. Мета-программирование не предполагает превосходства и наоборот
polfosol
9
По моему опыту, любой, кто сильно чувствует, что у него значительно более высокий уровень знаний, чем остальная часть их команды, фактически стал жертвой эффекта Даннинга-Крюгера. Это не означает, что некоторые люди не намного опытнее других, или что в этом случае остальная часть команды на самом деле не является некомпетентной ... но настоящий эксперт всегда сосредоточится на простом коде и общей картине. инженерия (включая учет командных эффектов во времени), а не просто программирование для стилевых очков.
Даниэль Приден
3
Написание кода, который другие не могут прочитать, не доказывает, что вы лучше их. Это доказывает, что вы не можете написать читаемый код.
Стиг Хеммер
3
@ СтигХеммер, видимо, вы не поняли вопрос, и вы меняете тему. Речь идет не о нечитаемом коде, а о коде, непонятном для других из-за недостатка знаний.
t3chb0t
4
@ t3chb0t Я хотел сказать, что это одно и то же.
Стиг Хеммер