Петер Маккі, керівник відділу розробки в Sonar – Серія інтерв’ю

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

Що спочатку привернуло вашу увагу до комп’ютерних наук?

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

Чи можете ви пояснити, як ви визначаєте Чистий Код і чому він так важливий?

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

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

• Поліпшує навички розробки – Розробники можуть виявляти, розуміти та вирішувати проблеми під час кодування, а також вивчати найкращі практики
• Збільшує ефективність та продуктивність – Зменшуючи постійну переробку та довгі цикли зворотного зв’язку, що призводить до більшої продуктивності
• Зменшує репутаційний та бізнес-ризик – Чистий Код забезпечує менше ризиків безпеки, дозволяючи командам активно вирішувати проблеми до того, як вони потраплять у виробництво
• Зменшує технічний борг на рівні коду – Чистий Код поступово вирішує борг кодової бази без потреби в великому оновленні програми та порушення
• Збільшує швидкість розробки програмного забезпечення – Стандарти Чистого Коду та оптимізовані потоки покращують швидкість DevOps, що сприяє швидшому виходу на ринок

Чи можете ви обговорити важливість послідовності та структури у коді, і які приклади послідовного та Чистого Коду?

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

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

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

Чи можете ви обговорити переваги використання Генеративного ІІ для генерації коду?

Включення ІІ до життєвого циклу розробки програмного забезпечення має свої переваги, такі як дозволяють розробникам працювати більш ефективно. Насправді, дослідження GitHub показало, що розробники можуть виконувати завдання більш ніж на 50% швидше за допомогою ІІ. Генеративний ІІ також може генерувати код швидше, і, таким чином, зняти з них тягар більш рутинних завдань – таких як документація або генерація кодових фрагментів – щоб вони могли краще зосередитися на більш цінних, винагороджувальних завданнях для вирішення більш складних проблем. Але незалежно від того, як код створюється, важливо, щоб він був перевірений на відповідність стандартам Чистого Коду, щоб забезпечити, що код є безпечним, надійним та підтримуваним.

Які потенційні підводні камені та ризики генерованого коду?

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

• Відповідальність: Код, згенерований ІІ, зменшує можливість утримувати людей відповідальними за створений код, що може зробити вирішення проблем складнішим.
• Вразливості: Оскільки це використовує в основному краудсорсингову інформацію, немає гарантії, що створений код є безпечним чи чистим. Там можуть бути помилки або проблеми безпеки, які можуть поставити бізнес під ризик.
• Якість: ІІ не перевіряє якість, і лише через те, що воно було створено ІІ, не означає, що воно є ефективним чи високоякісним.
• Відсутність контексту: Втрата людського елемента природно означає, що втрачається контекст проблеми чи проекту. Код, згенерований ІІ, повинен бути перевірений, щоб забезпечити, що він виконує свою роботу повністю.

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

Які інші змінні слід враховувати при створенні коду, придатного для виробництва?

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

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

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

 Через нашу індустріально-лідируючу аналітику, Sonar ідентифікує проблеми кодування у всебічній манері та рекомендує виправлення з короткими циклами зворотного зв’язку, навчаючи розробника в контексті, в кінцевому підсумку забезпечуючи організації можливість створювати відповідальний, безпечний, високоякісний код швидко та систематично. Основні елементи рішення Sonar – це SonarLint, SonarQube (самостійний; відкритий код), і SonarCloud (SaaS), з широким покриттям, яке підтримує понад 30 мов програмування, фреймворків та інфраструктур, 11 IDE, і понад 5 000 правил кодування та мовних правил.

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

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

Як Sonar допомагає забезпечувати, що код відповідає вимогам та стандартам галузі?

Sonar допомагає розробникам отримувати негайну та контекстнулу зворотню зв’язок, виділяючи проблеми, де вони знаходяться у кодовій базі, у межах робочого процесу розробки на основі років досвіду аналізу мов. Розробники отримують доступ до чітких пояснень, чому відбувається проблема та як швидко виправити її, а також додаткових ресурсів для більш глибокого вивчення. У нас є освіта, побудована протягом усього робочого процесу, від IDE до CI/CD. Наприклад, у Sonar є конкретні правила MISRA C++ 2023 у SonarLint, щоб допомогти командам створювати код, який є найкраще підготовлений для майбутньої сертифікації. Це пропонує керівництво з кодування, пояснюючи, чому проблема підкреслена, і як виправити її, щоб забезпечити, що код, який пишеться, є сертифікованим MISRA.

Яка ваша бачення того, як ІІ буде трансформувати кодування в майбутньому?

 Я думаю, що ІІ буде продовжувати доставляти велику цінність у вирішенні проблеми вигорання розробників. Хоча я не думаю, що ІІ коли-небудь зможе позбутися думок розробників та людського елемента, я думаю, що навіть через кілька місяців ми побачимо зовсім новий набір GPT – не кажучи вже про те, що буде через кілька років. Я не вірю, що технологи чи розробники зникнуть, але спосіб, яким вони працюють кожного дня, безумовно зміниться. Спосіб використання ІІ розробниками буде таким же простим та звичайним, як пошук чогось у Google (GOOGL ) як скорочення. Є багато чого, що потрібно дослідити про використання ІІ, але ми повинні все ж таки враховувати людський елемент на передньому плані, щоб перевірити недоліки ІІ. Є трансформаційний потенціал для розробки програмного забезпечення, але ми не повинні допустити, щоб це відбувалося без перевірок – особливо коли цифрові бізнеси сьогодні залежать від програмного забезпечення, яке підтримує його.

Дякую за велике інтерв’ю, читачам, які бажають дізнатися більше, слід відвідати Sonar.