Программизмы

Работаю в некрупной софтверной конторке, клепающей проги под заказ. По причине близкого дедлайна не спал четыре дня. В ночь с первого на второй день сон составил хорошо если полчаса, на второй день — 15 минут, а третий и четвёртый дни я не спал вообще.

Утро пятого дня. Вид у меня соответствующий: красные щёлки глаз, оплывшее заросшее лицо со следами насильственной смерти, взъерошенные волосы и полное отсутствие эмоций во внешнем виде. Сознание в похожем состоянии. Если быть точнее, то его нет вообще — оно аварийно отключено. Подсознание работает хрен пойми как, а за адаптацию в обществе отвечает резервная система на базе шаблонов. Шаблонов мало, они примитивны, и вообще система проста до безобразия и тоже начинает давать сбои.

6:30. Тушу комп, как-то одеваюсь, иду на остановку. На остановке народ подозрительно на меня косится. Пропускаю автобус с цифрами 292 на номерах. Мысль: «Переполнение, я на нём не поеду». Понимание приходит минут через десять, следующий автобус — через тридцать.

Гружусь в автобус, сажусь. Пацан лет четырнадцати просит передать на проезд за двоих. Я поворачиваюсь к нему и говорю: «Переполнение буфера, попробуй разбить пакет на два». На меня странно смотрит пацан и пол-автобуса.

Краем уха слышу, как меня матерят на чём свет стоит три бабки: «За#$@ли наркоманы, до чего уроды страну довели!» — и недвузначно тыкают в меня пальцами. Сознание делает робкую попытку проснуться, и я говорю: «Я не наркоман, я программист». Сознание падает в процессе загрузки; последнее, на что я обращаю внимание, это слова бабки: «Зомби компьютерные, б#я».

Проехав на две остановки больше, чем нужно, выхожу из автобуса и понимаю, что забыл, зачем я здесь. Останавливаюсь и тупо стою посреди улицы, смотря в одну точку. Я не пытаюсь вспомнить, я даже не осознаю, что происходит вокруг. Народ косится на меня и обходит стороной. Вероятно, терминатор, полностью выполнивший свою программу, выглядел бы примерно так же.

Через двадцать минут я всё же вспоминаю, что мне надо на работу, и начинаю свой путь. Его я не помню.

К обеду появляюсь на работе. Все разбежались по «Макдональдсам» и прочим забегаловкам, на работе человека три, включая шефа. Иду на нашу маленькую кухню, где и находятся эти трое. Не реагируя на них, делаю себе адский коктейль, состава которого я толком не помню, но в него я насыпал пять ложек красного перца и налил кетчупа. Будто так и надо, выпиваю кружку, делаю ещё одну и выливаю её в мусорное ведро со словами: «Грязная какая-то кастрюля». Иду в кабинет, за мной шеф. Захожу в абсолютно пустой кабинет, говорю: «О, здоров всем, чё так рано и уже на работе?» — сажусь за комп, не включая его, начинаю что-то набивать на клавиатуре и засыпаю. Даже нет — не засыпаю, а отключаюсь. Проваливаюсь куда-то в темноту.

22:00. Меня будит шеф. Рассказывает мне что-то про отпуск и отдых, довозит до дома на своей машине, провожает до дверей. Переступив порог, на полном автомате добираюсь до кровати, падаю и снова проваливаюсь в бессознательность.

Программисты, берегите своё здоровье. Его вам никто не вернёт.

Мы с друзьями садились в пригородный автобус. Заранее просчитав стоимость проезда на калькуляторе смартфона, я чётко приготовил сумму без сдачи. При расчёте я был крайне обескуражен заявлением водителя: дескать, тут не хватает. Доплатив и заняв место, я всю дорогу задавался лишь одним вопросом: что это было?

Ответ всплыл уже по приезде, когда я снова заглянул в калькулятор. Я вдруг обратил внимание, что использовалось шестнадцатеричное счисление, которое я однажды забыл поменять обратно. Более того, разница в суммах между DEC и HEX действительно составила всего несколько рублей. Долго смеялись над этим. Так-то вот, будьте внимательны при использовании программистских калькуляторов в быту!

Процесс разработки программного обеспечения делится на четыре главных стадии: планирование продукта, разработка, тестирование, внедрение (то есть распространение, продажа, снятие сливок) — то, ради чего вся бодяга и затевалась. Если пропустить хоть одну стадию, продукт до конечного потребителя не дойдёт. Важное уточнение: момент перехода от одной стадии к другой необратим. Нельзя во время разработки менять планы этой же версии. Нельзя во время тестирования заниматься разработкой. Это краеугольный камень всей науки о создании программ.

А теперь — собственно, рецепт.

Стадия планирования. Планировщики строят какие-то планы. Менеджмент эти планы утверждает, планы передаются отделу разработки.

Стадия разработки. Все работают согласно приготовленным планам.

Стадия тестирования и стабилизации. QA проверяют функциональность, согласно утверждённым планам, находят какие-то баги, разработчики их чинят.

Две недели до выхода Release Candidate. Приходит крутой спец из отдела продаж и говорит: «А я тут был на презентации конкурента, у них такая классная фича есть! Давайте, чтобы быть конкурентоспособными, мы забацаем вот эдакую фичу? Продаваться наш продукт будет в …дцать раз лучше! А без неё этот наш продукт вообще никто не купит».

«У-у-у… Без продаж нам будет туго. А давайте!» — соглашается менеджмент.

Планировщики ударными темпами вписывают фичу в готовые планы. Отдел разработки до сих пор вообще не поставлен в известность. Менеджмент даёт разрешение поменять готовые планы, что, в общем-то, нарушает все правила этики, логики и разработки ПО.

QA, скрупулёзно следуя планам, добираются до только что вписанного куска. Описанная в нём функциональность, естественно, не работает, потому что её никто не писал. Открывается баг на тему «Мегаважная фича не работает!!111»; ему присваивается экстравысшая категория важности.

Только тут разработчики офигевают от бага, смотрят в планы (которые не должны были меняться ни при каких условиях), офигевают ещё раз и интересуются: «Это ваще что было?! А нас кто-нибудь спрашивал?»

Всё это сопровождается беготнёй, мейлами через три континента, криками, воплями и инфарктами. Менеджмент убеждает разработчиков поднапрячься. Кого-нибудь делают крайним и спихивают весь проект на этого бедолагу. Он выполняет задачу, держась исключительно на кофе и на мотивирующих пинках начальства. Ну, как «выполняет»… За неделю трёхмесячный проект не написать. Поэтому пишется только good path, и новая фича будет работать, если пользователь ни в коем случае не попытается отойти от описанной в документах процедуры. Всё остальное (а 80% работы обычно занимает обработка граничных и нестандартных значений) закрывается заглушками — иногда прочными, иногда не очень. Поведение программы в том случае, если пользователь всё-таки отошёл от good path, вообще никем не гарантируется. Если повезёт, заглушка сработает, и пользователь ничего не заметит. Если не повезёт… Значит, не повезет. Программист сдаёт проект, получает премию и уходит спать.

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

Менеджмент радостно объявляет о включении новой функциональности в продукт. Продавцы готовят новые буклеты. Все счастливы.

Клиенты получают новую версию программного продукта. Поскольку пользователь — это такое периферийное устройство хаотичного ввода, а инструкции написаны для дураков, от good path отходят почти все. В результате — разрыв шаблонов, потому что программа, в общем-то, очень неплохая, внезапно начинает вести себя как студенческая самоделка, стоит только воспользоваться одной из новых функций и проявить чуть-чуть изобретательности. Хорошо, если дело ограничивается разрывом шаблонов. Иногда разрыв шаблонов переходит в стадию разрывов контрактов.

До следующей версии разработчики отлаживают этого мегамонстра, написанного на коленке за неделю, и приводят его во вполне симпатичный вид.

За две недели до выхода следующей версии кому-нибудь из продавцов приходит в голову идея великой фичи, которая поднимет продажи в …дцать раз.

Резюме № 1: инициативных дураков из отдела продаж надо убивать-убивать-убивать Ржавой Секирой Ужоса, желательно сразу после их трудоустройства.

Резюме № 2: с момента начала разработки у планировщиков надо забрать физическую возможность менять планы этой версии.

Резюме № 3: менеджмент, который этого не понимает, ведёт компанию к краху.

Работаю недалеко от дома, хожу каждый день через железную дорогу.

И вот снится мне, что стою я на той самой железной дороге и слышу шум приближающегося поезда. Тут меня охватывает паника, ведь поезд — это функция, но у неё не задано ни одного аргумента! И если я не успею их задать, она вылетит по эксепшну, то есть поезд сойдёт с рельс, произойдёт крушение и будет много жертв… В панике пытаюсь прописать какие-нибудь валидные значения прямо на рыхлом снегу вокруг рельс, но исходник недоступен (мчится на меня по рельсам), о логике можно только догадываться, ТЗ нет…

Просыпаюсь в холодном поту под эхо длинного автомобильного гудка где-то вдалеке. Видно, меньше надо работать. И через железную дорогу не ходить.

Все, наверное, слышали золотое правило: работает — не трогай! Это действительно хорошее правило, проверенное жизнью.

Но есть и другое, так сказать, серебряное: если сломалось, ты полез в чужой код и не понял, зачем оно там так было сделано — подумай ещё раз. А потом ещё раз. И ещё — пока не поймёшь, зачем и почему. И только потом, может быть, переделывай.

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

Потому что внешняя библиотека на другой версии ОС может быть реализована совсем иначе, но для программы это должно остаться незамеченным.

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

Ты увидел, но не понял зачем? Подумай ещё раз, пока корона на голове не рассосётся: возможно, это не мусор на полу, а кто-то более опытный просто заранее подстелил соломки?

Программисты пишут на разных языках. С уважением, ваш К. О. Следствием этого факта является то, что некоторым программистам легче и проще работать с джаваскриптами, DOM, объектами и прочим в том же духе: совсем не вопрос написать скрипт, который получит от сервера данные в JSON, разберёт их, создаст необходимые DOM-структуры и встроит их в документ.

А вот другим программистам легче и проще написать 100500 шаблонов страниц, которые будут генерировать HTML на стороне сервера, а затем одним AJAX-запросом готовый код вместе с используемыми в нем скриптами будет просто вставлен в нужное место на странице.

Какой подход правильнее?

Спец по JS считает, что первый: по сути, он пишет программу, которая выполняется на компьютере пользователя, обращаясь к удалённой БД на сервере. Сервер в этом случае просто транслирует AJAX в запросы к базе данных.

Другой специалист думает, что первый вариант вовсе не так хорош и имеет недостатки:

— программа получается достаточно сложной и объёмной, написать корректно работающий большой скрипт сложнее, чем сто маленьких простых;

— её работа зависит от корректности обработки браузером;

— её можно модифицировать на стороне пользователя, поэтому сложнее обеспечить безопасность и целостность данных;

— она сложнее в поддержке и развитии, так как более интегрирована сама в себя, чем множество независимых шаблонов.

Это чем-то напоминает сравнение Windows и UNIX: в одной из них принято писать многофункциональные приложения со множеством возможностей, очень большие и сложные, и потом выпускать новые версии с новыми возможностями;
в другой же считается правильным писать множество мелких утилит, каждая из которых мало что умеет, зато умеет хорошо и предсказуемо, и собирать из них системы разной сложности, как из кубиков.

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

Конкретно задолбали юные программисты, косящие под крутых.

Неужели вам ни разу не встречались личности, хвалившиеся знаниями в своём юном возрасте? А мне встречались, причём не раз в два года, а намного чаще, поскольку я сижу на многих форумах, посвящённых разработке игр (чаще всего программисты начинают с мечты создать игру). Я сейчас распространяюсь не о тех, кто в силу своей наивности думает, что сделать GTA или «Крусис» легче, чем оно на самом деле, хотя и такие есть. Больше меня заботят (и умиляют) те, кто кидают понты, хвалятся, что аж семь лет сидят за компом и «изучают» десять языков программирования (и это в 14 лет!), в другой теме копипастя урок про WinForms, а также те, кто красочно расписывают свою школьную жизнь, быдлизм одноклассников и небыдлизм и программисткость самого себя.

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

Объясняю таким личностям раз. Частично это ответ на вопрос, почему такой офигенный народ мне так часто встречается. Секрет в том, что скачать Game Maker или Unity3D, достать бесплатные модели, посмотреть два урока от Васяна527 на Ютубе — в этом нет ничего сложного. Ничего! Тому, кто не пропускал уроки информатики и что-то рубает в теме, не составляет ну никакой сложности пройти курс начинающего девелопера. Возможно, не стоит спорить в срачах, кто главнее и дольше учится программировать?

Объясняю два. Когда вы сравниваете себя с одноклассниками и прочим «быдлом» (в свою пользу, ага), вы берёте за кальку те области, в которых разбираетесь только вы. Более чем вероятно, что лет через шесть-восемь, выйдя из вуза, вы с удивлением обнаружите, что ваш сокурсник Петька, никогда ничем не выделявшийся, поднял себе финансовое положение на быдляцком способе «купи-продай» и приобрёл себе крутой джип, пока вы работаете стажёром в каком-нибудь «Нивале», записывая гениальные скрипты взаимодействия монстриков и корпея над книгами о маркетинге.

Всем спасибо, можете расходиться.

Индусский код, рядом лежащие папки? Терминология выдаёт программиста, который, кроме своего Виндоус-десктопа, где всё рядом, похоже, мало что повидал. Вот вам другая история.

Некая организация заказывает себе сайт с прайс-листом. Разработчики делают сайт, налаживают импорт данных, размещают всё это на хостинге. Данные ручками вносит лично главбух.

Проходит год, программу дописывают. Теперь она сама забирает данные с FTP-сервера, на который их заливает скрипт из офиса, потому что залить прямо на хостинг нельзя. Данные берутся из каталогов на файловом сервере в офисе, что стоит на столе у главбуха.

Проходит год, фирма развивается, клиентов много, деньги есть, сайт подтормаживает. Покупают свой сервер, размещают на колокейшне, переносят сайт туда, частично переделывают. Файловый сервер переводят на нормальное железо и переносят в отдельное помещение.

Проходит ещё пара лет. Фирма развивается, в новый офис заведено оптоволокно, в серверной гудят шкафы с оборудованием, сайт на отдельной машине, файловый сервер стоит рядом. Чтобы лишний раз ничего не переписывать, теперь скрипт заливает на FTP на тот же сервер, где сайт, но сайт тоже не переписывают, поэтому он забирает сам у себя.

Да, теперь на первый взгляд получается как-то глупо: лишние операции, которые можно было бы заменить копированием! Оптимизаторы негодуют, кроют матом тупых индусов и убедительно доказывают свою точку зрения очевидными фактами: да, действительно, можно ведь просто скопировать!

Но если завтра вдруг возникнет потребность разделить сервера, например, перенести сайт обратно на хостинг, чтобы не потерять при очередном переезде, или на виртуалку, чтобы утилизировать по максимуму процессор и упростить восстановление из образа VM — то всё, что будет нужно, это поменять в коде адрес. Работы на пару минут.

Так было бы, если бы оптимизаторы не оптимизировали то, что в оптимизации не нуждалось. Теперь придётся переписывать — а с разработчиком уже разобрались, верно? Будете извиняться или искать другого?

Эта история, конечно, несколько притянута за уши, но суть именно такая: иногда правильнее изобразить «индуса», добавив лишний транспортный протокол, или вынеся в настройки то-что-никогда-не-поменяется, или добавив лишнюю функцию, или даже написав формулу типа А = А*1, чем потом получить непереносимое, немасштабируемое решение, на которое придётся молиться с бубном и сдувать с него пылинки.

Было время, и я стремился к оптимизации: зачем нам вот эта функция, если внутри она просто вызывает другую? Зачем нам лишняя проверка, если исключение никогда-никогда не возникнет? А потом менялись внутренние функции библиотек, менялись алгоритмы, программы вешались, заставляя ночами ковырять древние исходники в поисках очередного «оптимального хода».

Годы программизма заставили смотреть на вещи с запасом на два-три хода вперёд. Хотя очередные юные оптимизаторы, «проверяя, что он там написал», уже говорили про индусский код — что же, приятных и неожиданных граблей вам.

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

— Понимаете, молодой человек, во время операции отказала система жизнеобеспечения, закупленная нашей больницей. Вашу жену не удалось спасти.

Василия прошиб холодный пот. Мобильный телефон выпал из его руки на пол, но он не обратил внимания. Ведь это его фирма продала эти системы. Ведь это он разрабатывал больничное ПО. Это он написал закладку, которая выключает системы жизнеобеспечения, если вовремя не зашить специальный файл-ключ. Именно его закладка сработала. Во время операции, которую делали его жене.

Василий стал белее муки. Казалось, его волосы седеют на глазах. Он опустился на колени и заорал во всю глотку…

* * *

Василий сидел на кровати и тяжело дышал. То, что всё это — лишь сон, до него дошло только полторы секунды назад. Всё, кроме наличия закладки в оборудовании, которое купила больница два месяца назад, о чём он узнал только вчера вечером. Но было уже поздно. Телефон завибрировал, и на экране отобразился текст SMS: «Меня везут на операцию».

* * *

А теперь вопрос «героям», которые оставляют закладки в оборудовании и хвастаются этим здесь: а вы бы хотели, чтобы из-за вас пострадали люди? Ваши родные и близкие? Нет? Тогда призадумайтесь, ребята.