6.2 Что такое отладка?
(Debugging отладка поиск и исправление ошибок в разрабатываемой программе. Когда в начале 1945 г. ЭВМ Mark I был остановлен для ремонта, Грейс Хоппер (Grace Hopper) заметила в одном из реле мотылька, попадание которого, возможно и вызвало сбой. После этого операция восстановления работоспособности стала именоваться ею debugging. Это вполне вероятно, так как выделяемое компьютером тепло привлекает насекомых. – примечание переводчика)
В программировании существует много возможностей, как для создания, так и разрушения программы. Для этого достаточно одного бессистемного символа. Например, вы забыли поставить точку с запятой, или “é” со знаком ударения, однако код не готов к такой особенности – и бабах! Или вы добавляете два знака вместе, но один – это цифра 4, а второй «4» в виде строки, ведь вы можете сказать «4 и 20 черных дроздов испекли в пироге». Для компьютера эти «4 и 20» не имеют цифрового значения.
Такие вещи происходят в действительности, и часть работы состоит в том, чтобы запомнить, что 4 + 20 это 24, а 4 + “20” это “420”. Программирование является отладкой. Это ожидание, что что-нибудь не сработает. Это не то, чем принято хвастаться, люди не раскрывают свою медицинскую историю во время первого свидания. Большинство языков обладают такой конструкцией, чтобы можно было быстро обнаружить изъяны, захватить их в ловушку, исследовать и удалить. Со временем, когда ваши взаимоотношения с языком программирования достигнут расцвета, вы придете к пониманию того, что настоящей характеристикой языка является не ее способность выполнять задачи, а талант сообщить вам, что вышло из строя. Большая часть вашей жизни программиста будет потрачена на то, чтобы определить, что сломано, и если компьютер помогает вам, возможно, вы еще увидите, как ваши дети с азартом играют в футбол.
Когда я начинал заниматься программированием, я ощущал, что каждый раз, когда программа давала сбой, я «выходил из строя». Я чувствовал досаду и отвращение, безысходность и отчаяние, неспособность двигаться вперед. Существует повесть Эллен Аллман, «Сбой» (Ellen Ullman, The Bug), в которой автор описывает страхи и сложности в общении, которые возникают, когда тяжело обнаружить серьезные сбои в программе.
В конце концов, я научился подчиняться. Я погружался в компьютер, чтобы вспомнить математику, которую когда-то учил, а также типы, категории, списки и синтаксис. Иногда сбои вызывали ошибки в сообщениях, иногда из-за них программа «испускала дух» и внезапно исчезала, иногда возникали страшные циклы, которые заполняли память и забивали все ресурсы компьютера настолько, что его нужно было повторно запускать. Это называется переполнение стека (stack overflow). Иногда запрос идет слишком медленно, например, многократный вызов создавал ситуацию, когда стек, будучи невозобновляемым ресурсом, полностью заполняет его и не выдерживает. Отсюда появилось название веб-сайта Stack Overflow, куда заходят программисты, чтобы дать ответы на вопросы и помочь друг другу решить проблемы, связанные со сбоями. Сайт занимает 62 место в мире по количеству посещений, отставая от Craigslist на несколько пунктов.
Произвольно выбранное сообщение из Stack Overflow, чтобы дать вам возможность ощутить аромат программирования:
Angular 1.3 + ui-router + generator-hg-poly embedding nested(?) views not working
(Angular 1,3 + ui-роутер + генератор – гектограмма – поли вложенный (?) изображения не работают)
—TheOncomingCode, StackOverflow.com
Предположительно на сайте OncomingCode утверждается, что платформа AngularJS на языке JavaScript и другой части кода называется ui-router (маршрутизатор для интерфейса пользователя). Судя по названию, последний помогает установить маршруты для адресации компонентов интерфейса пользователя – то есть помогает контролировать, каким образом вы просматриваете свои данные.
Но подождите, выясняется, что generator-hg-poly – это фактически generator-ng-poly, то есть… Ух ты. Я просмотрел этот инструментарий и нашел, что он описывает себя, как – соберитесь с духом – «генератор Yeoman для модульных приложений AngularJS с Gulp и опционной поддержкой Polymer». Черта с два! Однако знаете что? Назвался груздем, полезай в кузов. Давайте сделаем.
Поиск Yeoman дал следующий ответ. Это инструментарий для создания временных платформ (scaffolding tool), что означает – он создает маленькие папки для ваших веб-приложений, которые помогают вам начать разработку программ. Полезная вещь…
Теперь мы знаем, что означает Angular. Это инфраструктура/платформа…
Gulp, как утверждает веб-сайт «автоматизирует и улучшит ваш технологический процесс.» Вы можете постигать внутренним чутьем, что это инструментарий, который помогает вам создать программное обеспечение. Тем или иным образом. Вы никогда этого не узнаете из оранжево-розового фона сайта, а иногда вы просто так, так устаете…
Polymer – это библиотека «Веб-компонентов». Это значит, что она обеспечить вас маленькими кодовыми компонентами многократного пользования, которые вы можете применить на своих веб-страницах – выдвижные ящики, меню с вытесняемой нижней строкой, кнопки и так далее.
Что нам сейчас известно, так это то, что комбинация Angular, ui-router, Yeoman, Gulp, и Polymer каким-то образом не работает для TheOncomingCode. Все они являются инструментами для упрощения процедуры написания кода. Однако все они вносят свои собственные сложности. Упомянутый ниже пользователь пытается заставить веб-браузер выполнять задачи в JavaScript, и он заартачился.
Кто-то зашел на форум, чтобы ответить на вопрос. «Чтобы можно было использовать структуру заголовка в исходном состоянии», написал пользователь Stack Overflow Мэтт Тестер, «их необходимо вложить (сцепить), учитывая работу системы регистрации». Итак. Вот это другой разговор. Вот так решается проблема.
В настоящий момент JavaScript развивается очень быстро. Многое из того, что вы знаете сегодня, через шесть месяцев будет бесполезным. Каждый доставшийся в нелегкой борьбе любопытный, но бесполезный факт или домысел об абсолютно лучшем и наиболее принципиальном пути применения языка будет мусором со зловонным запахом в конце этого года. И некий хныкающий бородатый «мальчик» будет искоса смотреть на вас своим тусклым, заумным взглядом и неуклюже мямлить: «Ну да, нет, ух ты, у вас много Gulp и Angular, но я предполагаю, что вы не использовали Fleejob или Grimmex с расширениями Snurt? (Глубоко вздыхает). Я не уверен, что вам понравится здесь работать». В любом случае, это вопрос для Stack Overflow.
6.3 Ничего нового
Прошло несколько месяцев. Ничего не создано. Остался старый веб-сайт, демонстрируя свой возраст и действуя всем на нервы. Усиливается давление как сверху, так и снизу. Повторное создание архитектуры не увенчалось успехом. Главный технический директор оказался шарлатаном. Человек в темно-сером пиджаке, очевидно, все свое время провел на конференциях, и у него не было возможности фактически работать.
О подобных вещах не говорят вслух, это не та фирма. О них можно прочитать по глазам, используя язык пожимания плечами в коридорах, по порядку адресов в электронной почте и по полю копии. Вы включаете свою антенну и слышите такие слова, как «пустой труд» и «поздно», или фразы типа «не логично с точки зрения функциональности». Также много слов касательно соответствия и управления.
Вначале своей карьеры, вы, наверное, стали бы паниковать. Вместо этого, вы ощущаете чувство спокойствия. Вы приглашаете в свой офис Генерального технического директора и Человека в темно-сером пиджаке, как только они появляются в ближайшей окрестности. Они заходят с застенчивым видом. Генеральный технический директор выглядит напряженно, жестко расправив плечи. На лице человека в темно-сером пиджаке скромность смешалась со злостью. «Люди верят,» вы говорите, указывая пальцем на верх, где расположено руководство компании, «что пришло время обрезать наши затраты и закрыть проект».
6.4 Как работает система тестирования?
Если вы слоняетесь возле помещений, где работают программисты, то наверняка слышали, как они обсуждают вопросы тестирования – написание тестов, прохождение тестов. Некоторые из них даже не приступают к созданию программы, пока не напишут перечень тестов, которые должен пройти код, который, как они надеются, разработают. Это называется «Разработка через тестирование».
Конечно, тесты – это просто коды. Они проверяют функции других кодов. Они, как вы надеетесь, запускаются автоматически, поэтому вы можете выяснить, если работа, на которую вы потратили целый день, разрушила что-то или нет.
Безжалостное испытание – это один из вариантов следить за собой и убедиться, что сбои с вашего компьютера не встретили своих коллег с компьютера вашего напарника холодным зимним вечером, когда все уже дома сидят у камина, и не сломали сервер за час до Рождества, активируя все виды автоматического сигнала тревоги, и не заставили программистов по нескольку раз дико извиняться перед своими страшно раздраженными супругами за отсутствие дома.
Одним из самых лучших в мире тестируемых компонентов кода является SQLite, база данных, о которой уже ранее упоминалось и которая, наверное, загружена в вашем смартфоне. Она была разработана Ричардом Хиппом, который работал над ней на протяжении 15 лет. Она полностью открытая, полностью бесплатная и прошла 33 402 теста. Это один из наиболее широко используемых видов программного обеспечения и к тому же один из наиболее уважаемых программных продуктов.
Сбои не являются первородным грехом программирования. Это просто часть жизни, как нежелательные волосы на теле, или политические кампании. Первородный грех программирования – это мошенничество или взламывание кода других создателей с помощью ваших новых функций, попытка заполнить своими изменениями основную базу исходных текстов до того момента, когда они будут готовы. Автоматическое тестирование – не единственный способ препятствовать появлению сбоев; это только способ предположить, что вы пишете респектабельный код, который заслуживает похвалы.
6.5 А теперь несколько слов о красивом
По моему мнению, автоматизированное управление версиями программных документов – это один из самых прекрасных моментов в программировании. Это один из даров культуры создания кода миру. Управление версиями – это не режим отслеживания исправлений Microsoft Word, похожее на позорное уродство, которое способно даже мощный компьютер заставить спотыкаться. Нет, управление версиями – это абсолютно иная вещь.
—
Что, если бы я тебе сказал…
Продолжай…
… что ты мог бы вести реестр всех изменений, которые вносятся во многие документы, что входят в твою базу исходных текстов…
Ну, это интересно. В том смысле, что я могу использовать его для многих вещей, например, чтобы обнаружить, откуда появились сбои в системе.
… и зарегистрировать того, кто это сделал с точностью до минуты, в виде постоянной записи…
Ну, это мощно. Я бы мог использовать для того, чтобы изучить достигнутый моим коллективом прогресс, если бы я был руководителем. И делать это можно на основании тех изменений, которые происходят каждый день.
… и любой человек может проверять каждое изменение, получив абсолютно прозрачный доступ…
Каждый может быть в курсе всех изменений и понимать, каким образом развивается код и каждое изменение?
… и ты можешь связать все изменения в одно целое и превратить их в ответвления, и любой может создавать эти ответвления по мере необходимости без нарушения целостности других ветвей…
Я бы сказал, что это звучит, как безумная фантастика из параллельного мира. Кто-то может полностью изменить код без вмешательства в работу других программистов?
… и затем ты сможешь «привить» законченную ветвь назад к основному стволу кода, исследуя и отлаживая несоответствия по мере продвижения…
О, Боже, это похоже на то, что ты читаешь мои мысли. Даже если мой код представляет собой огромный набор хрупких взаимозависимых компонентов, моя команда может работать на собственными ветвями, а затем, поскольку я потратил время на создание мощного тестового комплекта, то мы можем в подходящее время соединить сделанные ими изменения и провести автоматизированные испытания, чтобы убедиться, что все функционирует нормально.
… и каждый может иметь архив со всеми изменениями, которые были внесены в код, даже, несмотря на то, что базе исходных текстов несколько десятков лет…
Замолчи, замолчи, и возьми все, зазвучал отдаленный цифровой голос, бери все! Возьми меня!
… и программу можно полностью и абсолютно бесплатно скачать и по умолчанию исходный код можно распространять по всему миру!
(Затихает.)
Именно поэтому все так волнуются о веб-сервисе GitHub. Вам нужно зайти на GitHub, обязательно посетите. Я рекомендую вам пошарить по нему и просмотреть тысячи репозиториев, прочитать некоторые файлы с необходимой для пользователя информацией под названием «Прочитай меня» (Read Me). И вам также нужно будет заглянуть в код, а затем на commit (фиксация/подтверждение транзакции). Commit – это момент действия, который зафиксирован и сохранен. Вы можете сравнивать их и увидеть разницу, увидеть, что было внесено в виде дополнения, а что удалено. Увидеть, что вы способны постичь и понять. Посмотрите на прилагаемый скриншот:
Прежде всего, мы проверим репозиторий Django. Это, фактический, опробованный на практике код, который запускает веб-платформу Django. За ним наблюдают 668 лиц, 14 325 лиц считают его своим любимым, а также имеется 5 692 разветвления. Это значит, что люди скопировали данный код в собственный репозиторий с намерением внести дополнения или изменения. Эти цифры представляют заинтересованных пользователей. Вполне вероятно, что есть еще сотни тысяч, которые загрузили этот код для того, чтобы активно использовать его.
Мы видим, что некий пользователь под ником claudep зарегистрировал код. Он сделал это пять часов назад, добавил «commit message» (сообщение о завершении транзакции), в которой было написано «Исправлено №24826 – Учтено для максимальной длинны названия файла в зависимости от файловой системы». Он работает с файлом под названием tests.py, это означает, что данный конкретный новый код (обозначенный зеленым цветом с префиксом «+» в начале каждой строки) является, вероятно, или тестовым кодом, или кодом, который используется для поддержки тестов. Благодаря пользователю claudep этот код сейчас лучше, чем он был шесть часов назад.
Перед вами опыт использования программы управления версиями, которая представляет в себе сочетание службы подачи новостей и системы резервного копирования. Веб-сервис GitHub не изобрел программу управления версиями. Он взял программу под названием git, разработанную Линусом Торвальдом, главным архитектором Linux, и начал дополнять его инструментарием и сервисами. Программа git работает таким образом, что вы можете скопировать все изменение, которые были внесены в код, с помощью одной команды:
Эта программа скопирует все компоненты кода, которые есть и были в Node.js, на свой локальный компьютер. Теперь вы можете зайти и внести изменения, как подсказывает вам ваше сердце. После этого вы можете напечатать:
Что добавляет файлы с внесенными вами изменениями; а затем:
Что просит вас ввести commit message (сообщение о завершении транзакции) с описанием выполненной работы; а затем:
Что вызовет ошибку, потому что кто вы такой, чтобы войти и начать перемещать код в узловом репозитории? Но если у вас есть разрешение, тогда вы сможете внести свои изменения в мастер-ответвление репозитория программы git, которая находится на GitHub.
Данные команды в настоящее время являются частью смысловой памяти многих программистов. Они десятки раз в день печатают различные варианты, регистрируя код, чтобы вести учет выполненных работ с тем, чтобы вернуться в любую точку, если они зайдут слишком глубоко и напартачат там, испортив много вещей.
Иногда изменения нагромождаются таким образом, что вы смотрите на них и про себя говорите: «Это хорошо. Мы готовы выдать миру новый код». Может быть, вы делаете это каждые две недели, может быть раз в год. Может быть, как Facebook, вы делаете это все время.
Если ваше программное обеспечение было в Версии 2, вы могли бы «связать» все изменения и поставить соответствующую метку (тэг) на коде. Трепещи, Версия 3. Изменение приходит через несколько секунд от кодирующего устройства, расположенного на огромном расстоянии. Вы закончили работу с Версией 3, которая теперь вошла в разряд документа постоянного хранения. Вы можете исправить некоторые ошибки и назвать этот вариант Версией 3.1. Вы можете добавить еще одну функцию и дать новое название – Версия 4.
Такие инструменты, как программа git, позволяют программистам использовать универсальный язык. «Вы зарегистрировали его?», спрашивают они. «Какой это был номер подтверждения?». «Это должен был быть 2.4, но мы разогнали до 2.5.» Поскольку каждое подтверждение получает произвольный уникальный идентификатор, вы можете точно определить это подтверждение в пространстве и во времени, а также уверенно ориентироваться в учетной записи изменений кода так, как вы вряд ли были уверены в чем-либо другом.
Побочным эффектом подобной уверенности является повышенный уровень автоматизации. Скажем, у вас есть программа веб-сервера, которая очень популярна и ежемесячно обслуживает сотни миллионов пользователей. Она запускает 50 разных компьютеров в «облаке».
Ваш старательный «децентрализованный» коллектив часто пишет новый код, который запускается на серверах. И здесь возникает проблема. Как лучше всего установить этот код на эти 50 компьютеров? Кликнуть и перетащить с помощью мыши? О, Боже, только не это. Вы что, животное? Вы берете непрерывный интеграционный сервер и устанавливаете плагины, а затем роботы обслуживают вас.
Программисты почти не говорят о коде. Они болтают о данных. Они непринужденно беседуют о требованиях и интересных подходах и постоянно дискутируют о применении. Что звучит логично, поскольку это является целью их работы – извлечь код из мозга через тестирование и распространить в мировом масштабе с помощью интернета, приложения или других форм. Программисты, особенно хорошие, хотят идти дальше и решать следующие проблемы, которые их сильно волнуют. Существует огромное количество принципов и методик, буквально тысячи, для развертывания кода. Например:
Вся работа, связанная с программированием, должна проходить в ответвлениях. Когда работа выполнена, мы сведем отдельные части в одно целое на основной ветви и проведем тестирование.
Затем, перенесем код на GitHub. С этой точки будет запущено автоматическое обслуживание и затем на каждом из 50 компьютеров эти «сервисы» проверят код и установят его поверх предыдущей версии. Затем остановят веб-серверы, после чего снова запустят их, чтобы код смог загрузиться и начать работать.
Видите, испытания и управление версиями служат триггером для «поставки» кода. Если вы можете следить за процессом, то сможете осуществлять выпуск программного обеспечения несколько раз в день, что в период «оберточного/упаковочного» программного обеспечения (доступ к ПО предоставляется пользователю путем изложения типовых условий на передаваемых экземплярах: вскрыв упаковку, покупатель соглашается с условиями лицензии – примечание переводчика) является непредусмотрительным шагом. (Часто «билды» собираются в ночное время с помощью крупных серверов сборки приложений – и пришедший на следующее утро получает готовый результат). Но сейчас, когда это программное обеспечение можно распространять через Сеть, или с помощью приложений, возникает вопрос – а зачем ждать? Почему не выпускать программное обеспечение непрерывно каждый день, когда у вас уже есть готовый продукт?