Культура кода девяностых: как писали программы до Git, Jira и бесконечных Pull Request’ов

В девяностых код писали иначе. Без систем контроля версий, без удобных IDE, без привычных методологий. Программисты строили проекты на интуиции, инстинктах и личной дисциплине. В этой статье — живая реконструкция той культуры: от стиля кода и комментариев до методов отладки и документирования. Без романтизации, но с уважением к эпохе, которая воспитала инженеров, умеющих думать головой, а не кнопками.

Когда код пах маслом и кофе

Помните запах офисов, где ЭЛТ-мониторы гудели тихим фоном, а клавиши имели ход как у пишущей машинки? Это было время, когда код не просто писали — его лепили. И не ради спринта или OKR, а потому что хотелось заставить машину делать невозможное.

Разработка шла на честном слове и личной ответственности. Никто не «пушил» коммиты — просто копировал проект на дискету и клал на стол коллеге. Так выглядела «система контроля версий». А чтобы не потерять изменения, оставляли файлы main_old.c, main_new2.c, main_really_final.c — и все знали, что реальный финал где-то между вторым и третьим.

Код был не просто функциональным — он был личным. Стиль кода часто выдавал автора так же, как почерк. Кто-то ставил фигурные скобки на новой строке, кто-то — после условия. Но спорить о стиле никто не стал бы — времени не было, надо было заставить модем дозвониться до сервера, а не настраивать линтер.

Комментарии как дневник инженера

Если сегодня комментарий в коде — вспомогательный инструмент, то в девяностых он был настоящим рассказом. Автор писал туда мысли, сомнения, шутки, а иногда и ругательства. Комментарий был частью инженерной психотерапии.

Пример кода тех лет (язык C):

/* 
  Этот кусок кода работает, но я не знаю почему.
  Не трогать без крайней необходимости!
*/
int adjust_voltage(int level) {
    if (level > 220) level = 220;   // потому что выше — сгорит блок питания
    if (level < 180) level = 180;   // ниже — начнут моргать лампы
    return level;
}

Такой комментарий мог прожить в коде годами. Никто не требовал документировать бизнес-логику или UML-диаграммы — достаточно было, чтобы следующий разработчик понял, что лучше не лезть в эти строчки ночью перед релизом.

И в этом была честность. Люди писали код для других людей, даже если не знали, кто эти люди. Комментарии были не формальностью, а продолжением мысли, моментальной фотографией состояния сознания программиста.

Отладка через светодиоды и интуицию

Сейчас, когда можно поставить breakpoint в IDE и наблюдать стек вызовов в реальном времени, трудно представить, что раньше отладка происходила «наощупь». Если программа падала — печатали дамп памяти, искали адрес, открывали справочник процессора и вручную считали смещение.

Многие пользовались printf как основным инструментом анализа. Иногда для микроконтроллеров — вообще без вывода. Тогда отладка выглядела примерно так:

  ; Ассемблер, 1994 год
; Если диод на порту A мигает — значит цикл работает
MOV PORTA, #0xFF
CALL DELAY
MOV PORTA, #0x00
CALL DELAY
JMP START

Это был hardware-driven debugging, и в нем было что-то почти медитативное. Каждый байт имел значение. Ошибка в одном флаге могла стоить недели. И всё же программы запускались, устройства работали, а чувство контроля было куда острее, чем сегодня.

Как оформляли и хранили код

Когда не было Git, код передавали на дискете или по локальной сети Novell. Существовали «сетевые папки», где лежал общий исходник, и кто успел — тот и главный. Иногда накладки приводили к тому, что проект внезапно переставал собираться, и тогда вся команда искала виновного не в тикетах, а в глазах.

Файловая структура обычно выглядела так:

/src
    main.c
    utils.c
    utils_old.c
    test.c
/docs
    readme.txt
    hardware_specs.doc
/bin
    release.exe

Вместо issue tracker были бумажные тетради, где писали:
“При нажатии F5 в меню вылетает в DOS. Проверить указатель на структуру меню.”

Документация создавалась в Word 6.0 или вообще в текстовом редакторе с фиксированной шириной шрифта. Её можно было распечатать, положить на клавиатуру и заметить следы от кофе.

Почему стоит помнить эту культуру

Можно смеяться над этими историями, но в них — дух инженерии. Люди, писавшие код в девяностых, не имели автосохранения, юнит-тестов или интеграций с CI/CD, но они знали, что делает каждый байт в их программе.

Сегодня мы живем в эпоху комфорта. IDE подсказывает синтаксис, система сборки всё делает сама, CI проверяет каждый коммит. Но вместе с этим мы теряем осязание машины — ту связь, когда программист понимал железо и систему на уровне регистров.

Может быть, стоит иногда писать маленькие программы без фреймворков, просто ради ощущения контроля. Без зависимостей, без модных библиотек, без слоёв абстракции. Просто чтобы вспомнить, зачем вообще мы начали программировать.