Що небезпечно довіряти програмісту?

У наш комп'ютерний століття не можна уявити собі ні велике підприємство, ні маленький офіс, де обходяться без обчислювальної техніки. І всюди потрібні програмісти. Не скрізь, щоправда, знаходять кошти на їх утримання, але затребуваність кваліфікованого інженера, який з комп'ютером на «ти», відчувається повсюдно.
Під словом «програміст» я маю на увазі не тільки людини, що створює програми, а більш широкий діапазон: системні роботи, адміністрування мереж та баз даних, підтримка працездатності робочих місць і так далі. Це не зовсім відповідає поняттю «програміст», але цілком відображає сучасні уявлення про нього. Візьмемо їх за основу.
Отже, програмісти - це гаранти налагодженої роботи цілих заводів, боги Інтернету! Так що ж їм не можна довірити? Та й чи можливо це? Візьмемо приклад.
- Валерочка! Швиденько откорректируй програму, щоб при аналізі чергового працівника перевірялася дата надходження. Після обіду потрібен результат.- Антон Павлович, тільки завтра до кінця зміни.- Кинь все! Займайся тільки датами! Завтра до обіду крайній термін!- Зрозумів…
Валерочка встиг сьогодні, що призвело начальство в захват. Але коли запустили програму, при скануванні кожного з п'яти тисяч людей на екрані висвічувалися дві дати і потрібно натискання клавіші «введення» для продовження. Антон Павлович схопився за голову. А Валерочка, скориставшись швидкої перемогою, взяв на кінець дня відгул. Програма працювала правильно, але налагоджувальна друк зводила на «немає» всі , красивые картинки пасха, зручність. Швидше було перевірити результати вручну. Начальник дав вказівку відновити попередню версію програми. Але ніхто не знав, де її шукати. На комп'ютері Валери їх було кілька. Системник Сергій запропонував скористатися позавчорашній копією, але не був упевнений, що Валера за два дні не встиг внести зміни. Він постійно вдосконалював свою дітище.
Ось я і навісив на вуха читачеві пару кілограм локшини. Чому локшини? Ситуація, треба сказати, неприпустима. З багатьох причин. Розкладемо їх по поличках.
1. Налагоджувальна друк - це бич програмістів. Він не щадить нікого, навіть асів, швидше, особливо асів. Залишити її у програмі - легко. Головне - основне завдання виконана, нові команди програми перевірені і протестовані, причому за допомогою цієї самої налагоджувальної друку, а прибрати її просто забули.
2. Начальник не повинен був сподіватися на успіх похапцем. Результат потрібно всебічно перевірити і краще надати це зробити користувачеві. Дуже не завадить мати комплекс контрольних прикладів, які варто пропускати після кожної зміни.
3. Програмісту не можна торкатися програми перед відгулом, відпусткою або відрядженням.
4. Останнє та найголовніше. Програмісту дуже небезпечно мати доступ до зданими в експлуатацію розробок. Їх краще займатися іншого фахівця, причетному до програмування.
А автора так і тягне поліпшити ті або інші режими або потихеньку виправити власну помилку. Навіть останнє може поставити під удар ціле підприємство, коли програміст, виправляючи одне, випадково зачепить інше. І це не халатність. Це природний процес роботи. Помилок при створенні і зміну програм робиться досить багато. Але досвідченим фахівцем вони дуже швидко виправляються ще в ході налагодження, і на «люди» виходить дуже мала частина їх: або вимагає дуже складного контролю, або просто непомічена з-за її легкості, типу налагоджувальної друку.
Я вніс описану ситуацію в розряд неприпустимих. На жаль, вони мають місце, і завжди трапляються дуже недоречно. Головний висновок наступний: не можна допускати програміста до експлуатації власних розробок, хоча автори до цього дуже рвуться. Я - не виняток. Пам'ятаю, як я міняв працюють варіанти програм, незважаючи на офіційну політику начальника.

Доступ? А хто його проконтролює?
Ще одну думку хочу висловити. Крім контрольних прикладів, бажано мати працівника для прогону різноманітних тестів. Йому необхідно розбиратися в суті предмета і зовсім необов'язково знати програмування.
Розглянемо приклад.
У зв'язку зі звільненням працівника мені було доручено супроводжувати його тему - розрахунок зарплати. Програма була написана давно, але не передавалася розраховувачам. Занадто складна технологія. Доробка з року в рік відкладалася і врешті-решт втратила актуальність. На підході була нова система управління підприємством, в якій зарплата також була присутня. Я витрачав півдня (частіше півночі) на запуск і розрахунок модулів, створених ще на старій техніці. Спочатку було цікаво. Я вхопив суть і за чотири місяці не зробив жодної помилки. В голові визрів план вдосконалення окремих шматків для прискорення роботи. Але реалізувати його я не встиг, завдяки текучці. Це виявилося позитивним моментом. Те, що я задумав, полегшило б роботу чисто зовні. А на глибинному рівні могли накопичитися похибки. Ряд команд звертався безпосередньо до ядра старих систем, а нові їх інтерпретували не так.
На п'ятий місяць я відчув себе настільки впевнено, що розслабився. Машинально запускаючи програми, я думав про нововведення. В результаті одна невелика операція була опущена, та п'ятдесят чоловіка неправильно розрахувалися. На щастя, п'ятдесят - не так багато, і ми спішно викрутилися, написавши додаткову гілку. Зарплату інститут отримав вчасно. Який висновок я хочу зробити? Програмісту, особливо просунутому, небезпечно доручати операторську роботу. У нього психологія мислення зовсім інша. Вирішити складну проблему, врятуватися від аварії - поки мізки зайняті, все йде нормально, і навіть з блиском. Але нудне виконання серійних завдань - не для нього. Тут потрібно методичне дотримання технології, не більше.
Ще одна ситуація. Програміст дає роботу. Всі перевірив на налагоджувальної базі даних і підключився до реальної. Програма працює. Начальник задоволений, користувачі не дзвонять. Робота рухається. Програмісту видають наступне завдання. Необхідний час на опрацювання, консультації з замовниками, все зрозуміло! Можна починати. З ранку з телефоном начальника відбувається щось незрозуміле. Дзвонять з усіх відділів і скаржаться, що програма зійшла з розуму, видає повний абсурд. Начальник збирає термінову нараду. На ньому з ’ ясовується, що програміст забув відключитися від реальної бази даних і справляв налагодження прямо на ній. Природно, багато дані були запорчены.
Висновок: не можна програмісту мати вільний доступ до експлуатованої інформації! Адже так легко переплутати базу реальну і налагоджувальну. Для створення програми це несуттєво. Програмісту все одно, ніж отримати результат. Тому схаменутися він може не відразу. Я кілька разів ловив себе на аналогічному. Але, на щастя, катастрофи не було. Я вчасно помічав невідповідності.
Так що і працюючі програми і дані, до яких вони звертаються, повинні бути за сімома паролями від лихого нічого не боїться програміста. А доопрацюванням необхідно витримати інкубаційний період. Під час нього виходить на сцену специалист по тестированию. Зрештою нову версію приймає проблемний адміністратор. Він відповідає за збереження зданих модулів і блокує всі спроби кого-або несанкціоновано їх змінити.
Цікаво, чи є хоч де-то така «ідеальна» система роботи? Боюся, що частіше програміст, адміністратор і тестувальник поєднуються в одній особі. Однак роз'єднати це особа ніколи не пізно.
Є такий вислів: «Не боги горщики обпалюють». Якщо програмісти - і є боги, то їх справа розробити технологію випалу, а обпалити можуть і інші. І вони при цьому не обпаляться самі, як це може трапитися з програмістом, якщо він полізе не в свою справу.
Текст: Ігор Корсар