Офіс в Україні: +38 (063) 50 74 707

Офіс у США: +1 (212) 203-8264

Ручне тестування

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

Мобільне тестування

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

Автоматизоване тестування

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

Функціональне тестування

Вдосконалюйте основний функціонал вашого додатку за допомогою наших послуг з функціонального тестування

ПЕРЕГЛЯНУТИ ВСІ ПОСЛУГИ

Обговорення -

0

Обговорення -

0

Послуги з тестування безпеки: Чистий код - чиста совість. Війна з кодовими клонами

Чому кодові клони небезпечні?

На перший погляд, клони коду не є небезпечними. Наприклад, якщо розглядати дану проблему з точки зору сервісів тестування продуктивності додатків, то вплив клонів на неї зводиться до збільшення коду, що викликає так зване “роздування” кінцевого додатку. Таке “здуття” стикається з додатковим обсягом оперативної пам’яті, який необхідний для роботи додатку. Якщо не впадати в крайнощі (коли 90% вашого коду - це непотрібні клони), в цілому, клони погано впливають на кінцеву продуктивність програми. Але є і зворотна сторона медалі: клони можуть негативно впливати на продуктивність вашої роботи, як це не дивно. Розглянемо цю проблему з точки зору простоти підтримки та розробки додатків. Якщо ваш додаток має клони, то в разі зміни функціоналу або виправлення помилок, які впливають на роботу з цими клонами, розробник повинен внести такі ж зміни. Якщо розробник знає, де саме потрібно вносити зміни - це добре. А якщо ні?

Чому з’являються клони?

Щоб зрозуміти це, давайте розберемося в природі появи клонів:

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

Вплив клонів на продуктивність

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

0 коментарів

Вам також може сподобатися

Кипарис проти Драматурга у 2026 році: посібник зі стратегії, а не підручник

Кипарис проти Драматурга у 2026 році: посібник зі стратегії, а не підручник

Порівняння пліч-о-пліч, матриця варіантів використання та реальний вердикт TestMatick - адже вашій команді потрібна...

Вартість виробничої помилки - це найпростіша частина

Вартість виробничої помилки - це найпростіша частина

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

Чому платіжні помилки - тихий вбивця доходів iGaming

Чому платіжні помилки - тихий вбивця доходів iGaming

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