Зміст:
Відео: Маленькое королевство Бена и Холли - Вылазка ⭐Лучшие моменты (Вересень 2024)
19 липня 2019 року контрактний програміст Девід Тінлі визнав свою вину за звинуваченням у тому, що навмисно пошкодив комп'ютери, що належать корпорації Siemens. Згідно з поданнями у справі, Тінлі посадив логічні бомби до коду, який він розробляв для Сіменса, в його місті Монровілл, штат Пенсильванія. Ті логічні бомби, що представляли собою розділи коду, які були призначені для зриву через тижні чи місяці після закінчення проекту, мали на меті забезпечити постійний потік доходу Тінслі від виправлення проблем, які вважалися помилками. Коли йому зателефонували, щоб вирішити проблему, Тінслі просто змінив дату на логічній бомбі, щоб вона пішла знову пізніше.
Наймання резервних кодерів
Отже, чому я вам все це говорю? Зрештою, шанси на те, що ти можеш найняти програміста, який навмисно вкладає логічні бомби у свій спеціальний код, не великі. І хоча ці шанси не дорівнюють нулю, є будь-яка кількість інших речей, які можуть піти не так, коли хтось пише код для вашої організації.
"Що станеться, якщо ця людина залишить або впаде мертвим?" питає Джек Голд, головний аналітик компанії J. Gold Associates. Золото говорить про те, що коли ви наймаєте когось для розробки, вам завжди потрібна резервна копія. Зрештою, спеціальний код - це ваш код. Немає третьої сторони, до якої можна звернутися, якщо щось піде не так, якщо ви цього не плануєте. Він також припустив, що є кілька інших кроків, які потрібно зробити компаніям, щоб захистити себе під час процесу розробки, головним з них є необхідний перегляд коду.
"Огляд коду - це, мабуть, найкращий спосіб з’ясувати, що у вашому коді", - сказав Алан Зейчик, головний аналітик Camden Associates, "включаючи такі речі, як логічні бомби, вразливості безпеки або дурні помилки".
"Є й інші причини робити перевірку коду", - додав Зейчик. "Це допомагає вашій команді розробників краще зрозуміти, як працює розробка, допомагає молодшим програмістам краще зрозуміти. Огляди коду також хороші для того, щоб допомогти менеджеру команди зрозуміти якість команди розробників та отримати оцінку тривалості. знадобиться, щоб закінчити роботу.
Проведення кодових оглядів
Зейчик сказав, що існує кілька способів проведення огляду коду. "Ви можете мати команду, в якій працюють двоє людей, або ви можете зустрітися в конференц-залі, щоб переглянути код."
Команди, в яких кожен член переглядає чужий код, набувають популярності, оскільки програмістів все важче знайти. Але у більших організаціях періодичні зустрічі з метою перегляду коду все ще корисні, оскільки тоді декілька очей отримують допомогу в процесі перегляду. Зейчик сказав, що навіть найстарші програмісти повинні переглянути свій код.
Отже, чому Siemens дозволив Тінлі пройти всі ці роки без перегляду коду? Згідно з коментарями свого адвоката під час судового розгляду, Тінлі вважав його код власником і використовував це як привід не переглядати його код.
Чому це було дозволено статися, незрозуміло, але і Zeichick, і Gold зазначають, що вимога щодо перегляду коду повинна бути частиною будь-якого контракту між бізнесом та незалежним програмним обладнанням. Золото пропонує, що в контракті не тільки згадуються перегляди коду, але вказується, як і коли вони проходять.
Зейчик зазначив, що деякі великі розробкові магазини можуть робити власні огляди коду, що, за його словами, має сенс. "Найкращі люди, які роблять перегляд коду, - це люди в команді розробників", - сказав він.
Уникання шкідливих кодерів
Огляди коду існують майже назавжди. Коли я керував командою програмістів для великого урядового закладу, ми щодня п’ятницею ввечері переходили задумливі лінії COBOL. Хоча це було нудно, ми часто знаходили огляди, помилки, неправильні посилання або інші помилки кодування. Справа в тому, що ми всі робимо помилки, а розумний огляд робить код кращим для всіх.
На жаль, програмісти іноді обурюються відгуками коду, вважаючи, що вони марнують час. Інші кажуть, що не хочуть, щоб люди вдруге вгадували свій код. Але факт відмови в дозволі перегляду коду повинен бути червоним прапором. Якщо ви платите за написання коду, ваш контракт може обґрунтовано містити вимогу до оглядів. Відмова в цьому є підставою для звільнення.
На жаль, знайти хороших програмістів сьогодні важко. Попит великий, і в деяких випадках контрактні програмісти вважають, що вони можуть вказати, що їм не доведеться переглядати свій код, навіть якщо їхній контакт каже, що це буде так.
Найкращий спосіб уникнути подібних проблем - спочатку попросити, а потім зателефонувати за попередніми роботами. По-друге, застосувати огляди коду з першого дня. Таким чином, вони перетворюються на звичку, і програмістів, які відмовляються від огляду, можна негайно звільнити - перш ніж вони стануть критичними для процесу розробки.
- Що робити, коли ви зламали, що робити, коли вас зламали
- 6 Речей, які не потрібно робити після порушення даних 6 Речей, які не робити після порушення даних
- Флорида-Сіті заплатить 600 000 доларів хакерам після атаки викупу Флорида виплатить 600 000 доларів хакерам після нападу викупу
На жаль, ризики в процесі розвитку можуть бути великими. Золото вказує на те, що неетичний програміст може вставити задній двері у ваш код, знайти способи викрасти ваші клієнтські дані чи інтелектуальну власність або передати критичні дані іншій компанії чи іноземній державі.
Спосіб запобігання цьому - це постійне управління, перегляд робочого продукту персоналу програмування та перегляд коду, перш ніж він буде прийнятий вашою системою управління кодами.
