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

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

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

Отже, програмісти - це гаранти налагодженої роботи цілих заводів, боги Інтернету! Так що ж їм не можна довірити? Та й чи можливо це? Візьмемо приклад.

- Валерочка! Швиденько відкоригує програму, щоб при аналізі чергового працівника перевірялася дата надходження. Після обіду потрібен результат.

- Антон Павлович, тільки завтра до кінця зміни.

- Кинь все! Займайся тільки датами! Завтра до обіду крайній термін!

- Зрозумів ...

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

Ось я і навісив на вуха читачеві пару кілограм локшини. Чому локшини? Ситуація, треба сказати, неприпустима. З багатьох причин. Розкладемо їх по поличках.

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

2. Начальник не повинен був сподіватися на успіх похапцем. Результат потрібно всебічно перевірити і краще надати це зробити користувачеві. Дуже не завадить мати комплекс контрольних прикладів, які варто пропускати після кожної зміни.

3. Програмістові не можна торкатися програми перед отгулом, відпусткою або відрядженням.

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

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

Я вніс описану ситуацію в розряд неприпустимих. На жаль, вони мають місце, і завжди трапляються як не можна до речі. Головний висновок - наступний: не можна допускати програміста до експлуатації власних розробок, хоча автори до цього дуже рвуться. Я - не виняток. Пам'ятаю, як я міняв працюють варіанти програм, незважаючи на офіційну політику начальника. Доступ? А хто його проконтролює?

Ще одну думку хочу висловити. Крім контрольних прикладів, бажано мати працівника для прогонки всіляких тестів. Йому необхідно розбиратися в суті предмета і зовсім необов'язково знати програмування.

Розглянемо приклад.

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

На п'ятий місяць я відчув себе настільки впевнено, що розслабився. Машинально запускаючи програми, я думав про нововведення. В результаті одна невелика операція була опущена, і п'ятдесят чоловік неправильно розрахувалися. На щастя, п'ятдесят - не так багато, і ми спішно викрутилися, написавши додаткову гілку. Зарплату інститут отримав вчасно. Який висновок я хочу зробити? Програмісту, особливо просунутому, небезпечно доручати операторську роботу. У нього психологія мислення зовсім інша. Вирішити складну проблему, врятуватися від аварії - поки мізки зайняті, все йде нормально, і навіть з блиском. Але нудне виконання серійних завдань - не для нього. Тут потрібно методичне слідування технології, не більше.

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

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

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

Цікаво, чи є хоч десь така «ідеальна» система роботи? Боюся, що частіше програміст, адміністратор і тестувальник об'єднуються в одній особі. Однак роз'єднати ця особа ніколи не пізно.

Є такий вислів: «Не боги горщики обпалюють». Якщо програмісти - і є боги, то їхня справа розробити технологію випалу, а обпекти можуть і інші.

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