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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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