Програмна інженерія

Книга: The Programmers

Програмна інженерія - розподілене програмування

Традиційний погляд на роботу полягає в тому, що команда виконує роботу, а окрема людина робить внесок у спільні зусилля. Але як картобудівники ми можемо спробувати подивитися на речі всіма можливими способами, щоб перевірити, наскільки вони є інформативними. Ми можемо описати межу системи навколо програмуючої команди та помітити, що там немає нічого, що не зміг би зробити окремий програміст. Такі дії, як формулювання вимог, проектування, реалізація, тестування, управління, рецензування, компілювання (build), архівування та управління конфігурацією повинні бути виконані окремим програмістом навіть для виконання невеликої роботи. Тому ми можемо розглядати діяльність у програмній інженерії як розподіл того, що одна людина могла робити абсолютно ефективно в «аматорському» («непрофесійному») режимі під час навчання!

Ми розподіляємо програмування з тих самих причин, з яких розподіляємо будь-який вид обробки: придатність (availability), паралелізм та спеціалізація.

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

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

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