Що може програміст?.

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

Ігор Корсар


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

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

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

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

Разом з розвитком швидкості та вміння в програміста з'являється ряд
додаткових якостей.

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


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

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

Техніка змінюється дуже швидко, і часто доводиться перекладати завдання
на інші машини. Не завжди виконувані модулі просто переносяться.
Часом доводиться починати з трансляції вихідних текстів.
Чи обов'язково в цьому випадку знати проблемну область завдання?

Вважаю, що зовсім не обов'язково.
У мене був такий випадок.

Великий комплекс програм, пов'язаний з розрахунками і випуском креслень,
довгий час працював на СМ-1420
Колектив, який створив його благополучно звільнився. Не відразу, звичайно,
а поступово.
Треба було перенести роботу комплексу на персональні комп'ютери.
Розбиратися, що роблять програми і як, не було часу.
Але в зразковому порядку були всі вихідні тексти.

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

Ще одна риса притаманна високої кваліфікації - вміння створити захист
для власної розробки і обійти, якщо така є, у чужий.
Але давайте про це наступного разу !..