Що ви робите, коли перегляд коду надто важкий?

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

Що робити у цій ситуації? Злитися і сподіватися, що нічого не проскочить? (Не рекомендуючи це!) Чи найкращий може зробити і намагатися лише виявити якісь явні недоліки (можливо, це найкращий огляд коду, в якому разі слід прагнути?) Об'єднайте і випробуйте додатково ретельно як кращу альтернативу, ніж перегляд коду взагалі?

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

EDIT: У мене складається враження, що деякі відповіді / коментарі до цього моменту підхопили мою фразу "широко впливати", і, можливо, це означає, що зміна включала велику кількість рядків коду. Я можу зрозуміти, що це інтерпретація, але насправді це не було моїм наміром. Під «широким впливом» я маю на увазі, наприклад, потенціал для регресії високий через взаємозв’язок бази даних коду чи сфери дії ефектів, не обов'язково що саме зміна є великим. Наприклад, розробник може знайти спосіб виправити помилку однією лінією, викликавши існуючу програму високого рівня, яка каскадує викликами до багатьох підпрограм нижчого рівня. Тестування та переконання, що виправлення помилки працювало легко. Вручну перевірити (за допомогою перегляду коду) вплив усіх вибійних ефектів набагато складніше.

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

То як впоратися з цією ситуацією? Спочатку не вникайте в нього в першу чергу:

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

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

• Напишіть набір автоматизованих тестів. Очевидно.

• Не вносити широких змін. Зробіть ряд невеликих цілеспрямованих змін, кожну з яких можна визнати правильними.

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

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

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

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

Цитата на закінчення:

"Якщо ти хочеш швидко піти, йди наодинці. Якщо ти хочеш далеко піти, йди разом"

Ласкаво просимо у світ старого розробки програмного забезпечення.

У вас є 100 тисяч, мільйони, 10 мільйонів рядків коду.

Ці рядки коду цінні тим, що вони створюють потік доходу, а їх заміна неможливо.

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

У ідеальному світі ваша величезна база коду є одиницею, перевіреною вазо. Ти не живеш у досконалому світі.

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

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

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

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

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

Виконуючи це, ви можете вдосконалити підсистему, додавши функції, за які клієнти готові платити.

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

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

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

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

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

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

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

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

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

Ті, які я помічав поки що:

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

1. Ви можете надіслати огляд коду назад і сказати розробнику розбити його на менші, більш додаткові набори змін і надіслати менший огляд коду.

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

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

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

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

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

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

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

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

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

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

Хитрий біт виникає, коли ви натрапляєте на помилок. Ваше гніздо з кодом щурів зробить неправильні речі в деяких випадках, оскільки речі такі крихкі і складні, що все піде не так. Коли ви виймаєте одиниці, решта код стане зрозумілішим. (У мене був випадок, коли після деякого рефакторингу функція починалася з "if (condition1 && condition2 && condition3) crash ();" яка була саме поведінкою перед рефакторингом, тільки ясніше. Я потім видалив цей рядок :-) Ви побачите дивна та небажана поведінка чітко, тому ви можете це виправити. З іншого боку, саме тут ви повинні змінити поведінку існуючого коду, так що це потрібно зробити обережно).

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

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

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

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

Крім того, є THE інструмент усіх інструментів для створення ваших інтеграційних тестів. Так, я кажу про контейнери та спеціально про Docker і Docker Compose . Це прекрасно надає нам можливість швидко створити складне середовище додатків, з інфраструктурою (база даних, mongodb, сервери черг тощо) та додатками.

Інструменти є, використовуйте їх! :)

Я не знаю, чому це ще не було згадано, але ці 2 є найважливішими творами:

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

* Приклад: Ви замінюєте бібліотеку А на бібліотеку B. Один список змін вводить бібліотеку B, різні різні списки змін замінюють використання A на B по частинах (наприклад, один список змін на модуль), а останній список змін видаляє бібліотеку А.

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

Не варто недооцінювати потенційне значення відмов коду. Вони можуть бути гарними у виявленні помилок:

• Знайдіть помилки, які важко було б виявити за допомогою тестування
• Знайдіть помилки, які важко було б ідентифікувати / виправити через тестування

Вони також корисні з інших причин:

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

Що робити у цій ситуації?

У кращому / ідеальному випадку перевірка проходження коду не означає просто "відсутність явних помилок": це означає "очевидно, що немає помилок" (хоча, звичайно, ви хочете також перевірити це).

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

Немає доступного вичерпного набору одиничних тестів або одиничних тестів, які не піддаються зміненому фрагментованому коду

А як щодо тестів на інтеграцію, систему та прийняття?

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

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

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

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

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

Ви чітко відхилилися від цього плану. На щастя, ви це визнаєте. Хороша робота! Кажуть, знання - це половина битви; якщо так, то обізнаність значно перевищує половину! Тепер потрібне рішення. З вашого опису видно, що бізнес-середовище, в якому ви перебуваєте, розвинулося до того моменту, коли нудна порада «перейдіть на перегляд коду, найкраща практика» не збирається його скорочувати. Для цього я рекомендую ключове правило, яке я використовую, коли мова йде про найкращі практики програмного забезпечення:

Жодна найкраща практика розробки програмного забезпечення не наштовхує на потребу бізнесу.

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

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

Відповідь на це, обов'язково, конкретний сценарій випадку. Схоже на спроби передбачити, чи буде кидання монети головами чи хвостами. Найкращі практики говорять про те, щоб перевернути його в 100 разів, і очікується приблизно 50 голів і 50 хвостів, але у вас немає часу перевернути його 1 раз. Тут важливі деталі вашої ситуації. Чи знали ви, що монета, як правило, приземлятиметься в тій же орієнтації, яку вона викидала приблизно з 51% часу? Ви витратили час на спостереження, яким способом була монета перед її киданням? Це може змінити значення.

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

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

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

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

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

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

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

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

Що робити, коли огляди коду "занадто жорсткі?"

1. Поверніться до гілки основного рядка коду
2. Напишіть тести на функціональність, яку ви відновили (наприклад, функціональні тести)
3. Пройдіть тести для здачі
4. Об’єднайте тести в код, який "важко перевірити"
5. Чи проходять ще тести?

Так

Ви, розробники, були чудовими! Коти назад для всіх!

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

Немає

Продовжуйте рефакторинг та додавати тестові покриття, поки тести не пройдуть.

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

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

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