Чи підвищує якість коду якість коду?

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

Ми використовуємо XML-файли для опису взаємозв'язків сутності в нашій схемі бази даних, тому вони допомагають нам генерувати наші рамки ORM та форми HTML, які можна використовувати для додавання, видалення та зміни сутності.

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

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

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

Генератори коду не можуть генерувати кращий код, ніж людина, яка написала генератор.

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

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

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

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

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

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

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

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

Генерація коду сама по собі не впливає на якість коду , настільки як послідовність коду .

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

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

Генерація коду добре, якщо:

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

У такому випадку код, якість якого потрібно враховувати, - це код, який вводиться в генератор.

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

Підвищена якість коду за рахунок DRY (не повторюйте себе).

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

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

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

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

Немає навіть «коду» для підтримки. Ви просто розміщуєте вузли всередині графіка і малюєте посилання між ними, і, вуаля, він генерує шейдерний код для вас. Хто підтримує цей матеріал і каже: " Ви знаєте, моє життя було б набагато простішим, і я мав би набагато більше вільного часу, якби це було просто написано в коді GLSL замість використання креслення. " Напевно, ніколи.

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

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

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

Генератори коду чудово, але будьте обережні з ними!

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

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

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

Всього мої 2 копійки.

На додаток до відповіді Мартіна, я додам, що генерація SQL-коду дуже хороша, коли ви працюєте в основі запису (виберіть * з табл.1, де tab1.pkcolumn =: параметр, оновлення tab1 встановлено [будь-яка кількість стовпців], де tab1.pkcolumn =: параметр тощо). І ваш ORM буде світити в такому сценарії, оскільки SQL, який потрібно створити, справді повторюється.

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

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

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

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

Додаток: звичайно, інші фактори, такі як час виконання, можуть зіграти певну роль.

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

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

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

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