Blueprint Driven Development, або як я писав код за TDD в еру ШІ і не вмер [ukr]

В епоху штучного інтелекту писати код стало простіше, ніж будь-коли. Молочник більше не везе молоко, а пекар не випікає хліб, бо всі генерують код. Проте що з якістю цього коду? Раніше ми писали автоматичні тести, щоб впевнитися в якості, але, можливо, тепер це не потрібно, бо ШІ краще знає, як правильно? На мою думку, юніт-тести та подібні автоматичні перевірки ще ніколи не були такими важливими, як зараз, адже потрібно контролювати те, що пишуть і ШІ, і молочник з пекарем, і ваш тімлід.

Я покажу на практиці, як ефективно працювати за TDD (Test-Driven Development), розповім, чому більшість розробників неправильно розуміють цю техніку, і доведу, що самі тести — це не головне, а концентруватися потрібно на створенні плану та архітектури. Ба більше, це лише початок — ви також дізнаєтесь:

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