Чи нормально використовувати метапрограмування, хоча не всі мої колеги цього розуміють?

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

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

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

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

Моє запитання, хто правий, що мені робити?

Уточнення: Намагаючись використовувати весь потенціал мови, це не означає, що я кидаю TMP на кожну проблему. C ++ - це набір інструментів, і для мене вміння C ++ полягає в тому, щоб мати можливість використовувати всі інструменти з коробки та про вибір правильного для певної роботи.

Метапрограмування нормально. Те, що ви намагаєтеся зробити, це не нормально.

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

Проблема не в метапрограмуванні, а в цьому:

З іншого боку, ми всі професійні розробники C ++, і я думаю, що ми повинні прагнути до вищого стандарту, ніж писати C на уроках.

Тут ви потрапляєте в біду. Ви маєте думку. Добре думати, що метапрограмування добре. Добре думати, що всі ми повинні прагнути бути кращими розробниками C ++.

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

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

Якщо ви хочете заохотити їх до нормального метапрограмування, почніть з малого . Почніть з синглу, enable_ifякий полегшує читання API. Тоді прокоментуйте про це денні світила . Тоді, можливо, знайдете один випадок, коли метафункція шаблону перетворює 10 великих повторюваних класів у 1 клас з 10 маленькими помічниками. Прокоментуйте чорт із цього. Отримати відгуки. Знайдіть, що люди думають про це. Будь добре, якщо вони скажуть вам цього не робити. Знайдіть нішу, де метапрограмування заробляє її так ретельно, що всі ваші колеги (нащадно) згодні, що це був правильний інструмент для роботи.

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

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

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

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

Зауважте, що використання метапрограмування шаблонів у C ++ завжди є компромісним: впевнено, іноді це може допомогти розробити певні частини програми більш DRY, і це, безумовно, корисно для створення високоефективних і багаторазових бібліотек.

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

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

• Повторно введіть багато нетривіальних структур коду вручну;
• Використовуйте метапрограмування шаблонів C ++ для автоматизації генерації коду;
• Використовуйте якийсь інший механізм генерації коду, наприклад, макроси чи іншу мову програмування для створення вихідних файлів C ++

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

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

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

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

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

Аргумент співчуття:

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

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

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

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

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

Для мене трохи більше набору тексту, можливо, навіть дублювання коду, але те, що я можу поставити перед містером "C з класами плюс STL", коли йому потрібна модифікація, набагато корисніше, ніж якась неймовірно елегантна річ TMP, яку тільки я можу підтримувати (І тому буде назавжди збереженням). Пам’ятайте також, що спеціаліст з класу C може виявитися експертом з предметів, і що експертиза, як правило, набагато цінніше, ніж бути юристом з мови.

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

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

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

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

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

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

На це питання немає єдиної правильної відповіді.

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

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

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

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

Вони переживають, що ти краще за них. Добре. Ти будеш новим експертом. Ви просто знищили їхній статус-кво світ.

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

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

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

Я не. Я думаю, що це показує вашу експертизу.

Моє запитання, хто правий, що мені робити?

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

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

EDIT

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

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

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

Тепер ви думаєте, що це дурно і шалено, чи не так? Але так забороняється інші функції. Деякі поепли можуть їх використовувати, а інші не хочуть їх вивчати.

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

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