Что такое код? (перевод)

Специальный выпуск Bloomberg Businessweek, 11.06.2015

Содержание:

Часть 1. Человек в бежевом пиджаке

Часть 2. Что такое компьютер?

Часть 3. Почему программисты так болезненно относятся к языкам?

Часть 4: Почему программисты такие злые?

Часть 5: Совещание о валидации email-адресов

Часть 6: Как создаются приложения?

Часть 7: Триумф менеджера среднего звена

Часть 6: Как создаются приложения?

Внутри Xcode — целые миры, которые можно исследовать. Например, один из компонентов — это iOS SDK (Software Development Kit — «комплект средств разработки»). С его помощью создаются приложения для iPhone и iPad. Этот SDK состоит из множества API (мы уже его упоминали — это способ общения программ между собой). Есть API для отслеживания местоположения пользователя, есть для анимации картинок, есть для проигрывания звуков, для передачи и отрисовки текста на экране, и несколько для сбора информации от пользователей. Там много всего.

Начинаешь замечать здесь что-то знакомое? Помнишь, как была устроена среда Smalltalk — экран с кучей окон, в которых программы отправляют друг другу сообщения? В Xcode звучит мощное эхо этих идей.

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

Когда кто-то из Apple выходит на сцену и объявляет очередную новую штуку, оканчивающуюся на «Kit» (вроде ResearchKit, или HealthKit, или WatchKit — набор специальных методов для Apple Watch), — именно в Xcode все эти новые возможности для разработчиков и приземлятся, полностью задокументированные, чтобы с их помощью любой желающий мог создавать новый качественный софт.

Некоторые функции в этих наборах зарезервированы за производителем. Помнишь, как Apple расхваливает, что с помощью Apple Watch можно отслеживать сердечный ритм? Так вот, Apple пока не задокументировала, как это делается, — не для всех желающих. Может, компания опасается, что вы как-нибудь это не так используете. Возможно, мониторинг сердечного ритма требует аккуратного управления батареей, а поскольку у часов и так проблемы с батареей, Apple хочет избежать новых проблем, не пуская туда кого попало. Впрочем, наверняка кто-то прямо сейчас пытается вычислить, как получить доступ к этому API сердечного ритма. Просто люди уж так устроены.

Допустим, ты делаешь приложение для подкастов, и проигрывание аудиофайла в нём — ключевая функция. Отлично. Ты создаёшь объект класса AVAudioPlayer, добавляешь на экран кнопку, а затем связываешь эту кнопку с кодом так, чтобы при нажатии она отправляла сообщение «play».

Это приводит к одновременному запуску многих процессов, к которым выбранная операционная система уже готова. Задача IDE — помочь тебе сориентироваться и подключить к твоему проигрывателю аудиофайлов нужные методы. А их там тысячи и тысячи: аудиофайл можно проиграть, перемотать, изменить скорость, перейти к следующей записи, можно отслеживать, сколько раз и когда файл проигрывали (а значит, тебе нужно ещё и держать в уме часовые пояса), или отслеживать название подкаста (а значит, нужно держать в уме язык названия — и знать, отображается ли оно слева направо или справа налево).

Ещё тебе следует знать длительность аудиофайла, а значит, нужен механизм извлечения длительностей из музыкальных файлов. Как только он у тебя есть — скажем, длительность в миллисекундах, — тебе нужно поделить её на 1000, а затем на 60, чтобы получить минуты. Но что, если твой подкаст длиной в 90 минут? Захочешь ли делить дальше, чтобы получить часы? Столько переменных. А-а-а!

Похоже, задачи, которые нужно решать, у тебя всё-таки ещё есть. IDE делает за тебя не всё.

Величайшее коммерческое озарение технологической индустрии состоит в том, что, контролируя вычислительную среду, ты можешь двигать рынок. Ты можешь влиять на то, как люди делают привычные вещи, как они слушают музыку, смотрят видео и реагируют на рекламу. Люди, работающие в технологических компаниях, могут взять любую идею и умножив её на несколько миллионов человек, получив несколько миллиардов долларов.

Отличный способ сделать это — упаковать свои намерения в API, SDK и IDE. Вот почему существует так много бесплатного софта для создания софта: это стимулирует разработку ещё большего количества софта.

Иногда это результат чисто корпоративных амбиций: Java был во многом продуктом Sun; то же верно и для C#, созданного Microsoft. Но значительная часть кода в мире доступна свободно — её десятилетиями создавали щедрые добровольцы, чтобы удовлетворить собственные нужды. Взаимоотношения между корпорациями и языками программирования очень непростые. Некоторых разработчиков языков нанимают, чтобы они работали над своими опенсорсными языками; Go и Python, например, в той или иной степени финансировались Google; а создатель PHP работает в Etsy.

Apple и Microsoft, Amazon и Google — это фабрики фабрик. Их API — плод многих тысяч часов труда множества программистов. Только вдумайтесь, сколько это работы. Кто-то должен планировать работу и управлять SDK. Сотни программистов должны писать для него код. Кто-то должен его тестировать, писать документацию и готовить демо. Кто-то должен пробить финансирование и доведение какой-то фичи до ума. Кто-то должен проследить, чтобы перевод на немецкий был доделан и чтобы в нём не оказалось конфузных ошибок, которые разлетятся вирусом по Twitter. Кто-то должен, собственно, написать софт, благодаря которому заработает сама IDE.

С вариациями они продают это ежегодно вот уже 30 лет.

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

Когда твоё приложение готово, ты можешь продавать его в магазине приложений. И если пользователи в восторге от твоего приложения, у них появляется стимул покупать другие твои приложения. Петли на петлях, питающие друг друга, — и капитал стекается в закрома терпеливых софтверных гигантов. Экосистема. «Экосистема» — ещё одно затасканное слово, особенно если вспомнить, что мы творим с настоящей, физической экосистемой вокруг нас. Но когда несколько сотен тысяч человек создают свои детища для миллионов и миллиардов, это называют именно так.

6.1 Фреймворк: младший и более безбашенный кузен SDK

Скорее всего, если ты занимаешься хоть каким-то программированием, особенно веб-программированием, ты взяла на вооружение какой-нибудь фреймворк. Если SDK — это выражение корпоративной философии, то фреймворк больше похож на рекламный питч: «Хотите сэкономить время? Устали писать один и тот же код? Любопытно, что там за новая штука на подходе?» Ты используешь графический фреймворк, чтобы строить графические приложения, веб-фреймворк — чтобы строить веб-приложения, сетевой фреймворк — чтобы строить сетевые серверы. Фреймворков на свете сотни; практически у каждого языка программирования есть свой.

Допустим, мы всё ещё мечтаем сделать наш собственный книжный магазин — тот самый, амазоноподобный, с реляционной базой данных, который мы начали пару страниц назад. В Django мы запускаем команду startproject. Затем ты «настраиваешь свои модели» — то есть начинаешь описывать, как выглядят твои данные на языке Python, которые фреймворк переведёт на язык баз данных для дальнейшего с ними общения:

from django.db import models

class Book(models.Model):
    title = models.CharField(max_length=140)
    description = models.TextField()
    price = models.DecimalField(max_digits=6,decimal_places=2)

И вот теперь мы можем наполнять наш каталог. (Понятно, что нужно ещё добавить авторов и тому подобное.) Невероятно изящно тут то, что ещё с парой строк настройки у тебя появится полностью функциональный, рабочий веб-редактор для любых статей; а именно:

Это называется «admin»-представление, и оно всегда было одной из главных фишек Django. Твоя работа как программиста только-только началась, но уже очень скоро после самого старта твои пользователи — сотрудники твоего магазина, или журналисты, если ты строишь издательскую платформу, или может, просто ты сама в тестировочном настроении — могут начать играть с твоим детищем: добавлять книги, пробовать разное.

Помнишь все те заморочки с вводом почтовых адресов? Если ты используешь Django, ты можешь взять EmailField — и о многих из этих проблем можно уже не беспокоиться. То же касается и многих вопросов безопасности, возникающих при создании сайтов, — типичных пакостей, которые устраивают люди из странных побуждений. Ты вступила в мир, где уже обитают многие тысячи других программистов. Которые пользуются этим же фреймворком, работают с ним и предлагают улучшения; которые пишут туториалы; которые пишут плагины, помогающие решать задачи, связанные с паролями, ведением блогов, борьбой со спамом, календарями, ускорением сайта, созданием форумов и интеграцией с другими сервисами. Ты можешь мыслить в терминах архитектуры.

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

Фреймворки очевидным образом влияют на то, какую работу могут делать разработчики. Некоторые считают, что фреймворки слишком всё упрощают и превращаются в костыль. Довольно легко закодить саму себя в угол и обнаружить, что ты пытаешься заставить фреймворк делать то, чего он делать не хочет. Django, например, не тот инструмент, чтобы строить приложение для чатов, да и тягаться с Google Docs на бэкенде из Django кажется не лучшей идеей. За всё это удобство ты платишь цену в скорости и контроле. Проблема, по сути, в том, чтобы понимать, сколько скорости, контроля и удобства тебе нужно.

В среде разработки существует такой термин — «преждевременная оптимизация» — когда ты переусердствуешь с обдумыванием кода прежде, чем узнаешь, в чём будут настоящие проблемы. А тех, кто тратит на обдумывание архитектуры слишком много времени, называют «архитектурными астронавтами». Есть и другая крайность — NIH («not invented here» — «изобретено не здесь»), которая всплывает сплошь и рядом, когда программисты пытаются переизобрести существующие рабочие решения.

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

Внутри фреймворка обычно существуют твёрдые правила и убеждения, но не такие твёрдые, как у SDK. Вторые идут туго упакованными, часто коммерческими, и являются на свет под фанфары пиара — особенно если они от Apple или Microsoft. Фреймворки же обычно рождаются из отчаяния и при первом релизе, кое-как перемотанные скотчем, вбрасываются на всеобщий суд обычным постом в чьём-то блоге. А дальше — выживают или нет.

Если ты строишь веб-приложение, глупо было бы поначалу не воспользоваться фреймворком. Они бывают крохотные, для помешанных на контроле. А есть исполинские, вроде Django или Rails, которые преследуют те же цели, про которые ещё в стародавние времена говорили амбициозные системы вроде Smalltalk: сделать возможной разработку больших систем, где данными можно совместно управлять и делиться.

Бери решения, которые уже сделаны за тебя. DRY (don't repeat yourself — «не повторяйся»).

6.2 Что такое отладка?

В программировании способов что-нибудь поломать ровно столько же, сколько способов что-нибудь создать. Достаточно одного заблудившегося символа. Скажем, ты забыла точку с запятой или где-то употребила «é» с акутом, а код к такой диковинке не готов, — и БАБАХ!

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

Когда я начинал программировать, я чувствовал, что каждый раз, когда программа падает, я потерпел неудачу. Я ловил себя на том, что съёживаюсь, отчаиваюсь и не могу двигаться дальше. Есть даже роман Эллен Аллман, «The Bug», — о тревогах и социальных хитросплетениях, возникающих, когда серьёзный баг в коде никак не удаётся найти.

Но со временем я научился смиряться. Я научился мыслить на языке компьютера, вспоминать математику, которую знаю, всё то, что я понимаю про типы, категории, списки и синтаксис. Иногда баги приводят к тому, что выскакивают сообщения об ошибках; иногда — к тому, что программа просто испускает дух и внезапно останавливается; иногда ошибки попадают в жуткие циклы, заполняют память и душат все ресурсы компьютера, пока его не перезагрузить. Это называется переполнением стека (stack overflow). Иногда вызов какой-то функции выходит из-под контроля, и, например, вызывает сам себя столько раз, что стек, будучи конечным ресурсом, заполняется и больше не выдерживает. Отсюда и название сайта Stack Overflow, куда программисты приходят отвечать на вопросы и помогать друг другу разбираться с багами. Это 62-й по посещаемости сайт в мире, отстающий от Craigslist на пару позиций.

Вот случайно выбранный запрос пользователя со Stack Overflow, чтобы дать тебе прочувствовать вкус программирования:

Angular 1.3 + ui-router + generator-hg-poly embedding nested(?) views not working

— TheOncomingCode, StackOverflow.com

Попробую перевести. TheOncomingCode, похоже, говорит, что использует фреймворк AngularJS и какой-то кусок кода под названием «ui-router». Судя по названию, он должен помогать настраивать маршруты (routes) к компонентам пользовательского интерфейса — то есть помогает управлять тем, как отображаются твои данные.

Разбираемся дальше: generator-hg-poly — похоже, тут ошибка — на самом деле это generator-ng-poly, ладно… который… Я взял и посмотрел на этот инструмент, а он описывает себя как — держись крепче — «Yeoman-генератор для модульных AngularJS-приложений с Gulp и опциональной поддержкой Polymer», что… — да вы издеваетесь! В этой фразу вообще есть какой-то смысл? Вдох-выдох… Раз назвался груздем, поехали разбираться.

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

Что такое Angular, мы знаем; это фреймворк…

Gulp, гласит его сайт, будет «автоматизировать и улучшать твой рабочий процесс». По контекстным подсказкам можно догадаться, что это инструмент, который помогает тебе писать софт. Как-то. Ни за что не поймёшь этого по лососёвому фону его сайта…

Polymer — это библиотека «веб-компонентов», то есть она даёт тебе маленькие переиспользуемые компоненты кода, которые можно использовать на веб-страницах, — выдвижные панельки и выпадающие меню, кнопки и прочее. Ясно.

Итак, теперь мы знаем, что сочетание Angular, ui-router, Yeoman, Gulp и Polymer у пользователя с ником TheOncomingCode почему-то не работает. Все эти штуки, которые он использует — это инструменты, призванные упростить программирование. Но каждый из них привносит собственную сложность. Человек пытается заставить браузер сделать что-то на JavaScript, а оно почему-то отваливается.

На этот вопрос кто-то пришёл ответить. «Чтобы можно было использовать состояние header внутри состояния home, — написал пользователь по имени Мэтт Тестер, — их нужно вложить (сцепить) друг в друга. Это неочевидно, но ты можешь спокойно сделать одно состояние родителем другого в отдельных файлах/конфигах — ровно так же, как работает регистрация». Ну вот. Готово. Решение проблемы нашлось.

JavaScript сейчас несётся вперёд как угорелый. Слишком многое из того, что ты знаешь сегодня, через полгода окажется бесполезным. Каждый добытый потом и кровью факт о единственно верном способе или инструменте решения проблемы к концу года превратится в протухший музейный мусор. И какой-нибудь бледный бородатый мужчина будет смотреть мимо тебя на собеседовании и неловко бормотать: «Ага, тут написано, что ты много применяешь Gulp и Angular, но ты, я так понимаю, не используешь Fleejob или Grimmex с расширениями Snurt? (Глубокий вздох.) Даже не знаю, понравится ли тебе у нас работать».

В общем, вот это — только один вопрос на Stack Overflow.

6.3 Ничего не сделано

Проходят ешё несколько месяцев. Ничего не запущено. Старый сайт остаётся на месте — стареющий, бесящий всех и каждого. Внутри компании давление нарастает. Давление сверху и снизу. Перепроектирование архитектуры провалилось. Новый технический директор — шарлатан. ЧБП, судя по всему, всё своё время провёл на конференциях и ни минуты — за настоящей работой.

Вслух этого не произносят; наша компания не из таких. Всё передаётся закатыванием глаз и пожиманием плечами в коридоре, порядком адресатов в письмах и через скрытую копию. Ты включаешь свои радары. Ты слышишь слова вроде «проект-пустышка», «просрочено» и фразы вроде «операционно несостоятельно». Много про несогласованность и вопросы к управлению проектом.

Раньше, в начале карьеры, ты бы, возможно, запаниковала. Вместо этого ты чувствуешь спокойствие.

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

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

6.4 Как работает тестирование?

Если потусоваться какое-то время рядом с программистами, можно обратить внимание, что довольно часто они говорят о тестах — о написании тестов, о прохождении тестов. Некоторые вообще не начинают программировать, пока не напишут тесты, которые должен пройти код, который они только планируют написать. Это называется разработкой через тестирование (test-driven design).

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

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

Один из самых хорошо оттестированных кусков кода в мире называется SQLite — та самая упомянутая ранее база данных, которая, вероятно, стоит у тебя в смартфоне. Её разработал Д. Ричард Хипп, работающий над ней вот уже 15 лет. Она полностью открыта, полностью бесплатна и прошла 33,402 теста. Это одна из самых широко используемых и одна из самых уважаемых программ в мире.

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

6.5 А теперь — кое-что прекрасное

По моему мнению, контроль версий — одна из самых прекрасных вещей в программировании. Это один из даров культуры мира разработчиков всему миру. Контроль версий ни разу не то же самое, что «отслеживание изменений» в Microsoft Word. То — позорное чудовище, способное заставить заикаться даже мощный компьютер, и любить его может разве что юрист.

Нет, контроль версий — это нечто другое…

— Что, если я скажу тебе…

— Продолжай…

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

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

— …и запись того, кто и когда их внёс, с точностью до минуты, — постоянная и неизменяемая…

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

— …и каждое изменение может быть просмотрено кем угодно, абсолютно прозрачным образом…

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

— …и ты можешь связывать изменения в определённые наборы и превращать их в ветки, и кто угодно может создавать сколько угодно веток, не нарушая целостности других веток…

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

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

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

— …и у каждого может быть история каждого изменения, когда-либо внесённого в код, даже если кодовой базе уже десятки лет…

— Замолчи, замолчи и забирай всё, бестелесный голос кода, забирай всё! Забери меня!

— …и всё это совершенно, абсолютно бесплатно и является стандартным способом распространения исходного кода по всему миру!

— (Падает в обморок.)

Вот почему все в восторге от GitHub. Тебе стоит зайти на GitHub, правда стоит. Тебе стоит там покопаться, полистать тысячи хранящихся там репозиториев, почитать их описания в README-файлах. Тебе стоит заглянуть и в код, даже если ты его не понимаешь, и посмотреть на «коммиты». «Коммит» — это зафиксированный и принятые изменения кодовой базы. Ты можешь сравнить один коммит с другим и увидеть «дифф» — визуальное представление того, что было добавлено, что исправлено, а что удалено. Посмотри, что сможешь разобрать.

Взгляни на скриншот ниже.

Во-первых, мы смотрим на кодовую базу (репозиторий) Django. Тут хранится, обсуждается и обновляется настоящий, живой код, благодаря которому работает тот самый фреймворк Django, с помощью которого мы делали наш книжный интернет-магазин. За ним следит 668 человек, 14,325 человек отметили его звёздочкой как избранный, и есть 5,692 форка — то есть люди скопировали себе его код с некими намерениями его использовать, крутить, дополнять или менять. Эти числа отражают вовлечённых пользователей. Ещё, вероятно, есть сотни тысяч тех, кто просто скачал код, чтобы использовать его для своих задач.

Далее, мы видим, что пользователь под ником claudep закоммитил какое-то изменение в общую кодовую базу. Он это сделал пять часов назад, добавив комментарий: «Fixed #24826 — Accounted for filesystem-dependent filename max length» («Исправлена ошибка #24826: учтена зависящая от файловой системы максимальная длина имени файла»). Он внёс исменения в файл под названием tests.py, мы видим конкретные изменения, которые, он внёс (строчки, подсвеченные зелёным и с «+» в начале каждой строки)и можем сделал вывод, что это, вероятно, либо тестовый код, либо код для поддержки тестов. И благодаря пользователю claudep код фреймворка Django стал лучше, чем был шесть часов назад.

Чтобы начать использовать Git и скопировать какой-то код со всеми когда-либо внесёнными в него изменениями, тебе нужна одна команда:

git clone git@github.com:nodejs/node.git

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

git add .

что соберёт все файлы, которые ты изменила; а затем

git commit

что попросит тебя ввести комментарий с объяснением того, что ты сделала; а затем

git push origin master

что вызовет ошибку — потому что кто ты такая, чтобы заявляться из ниоткуда и начинать менять основной код уважаемого проекта? Но если бы у тебя всё же были права, это отправило бы твои изменения в основную ветку репозитория (она называется master), и этот обновлённый код считался каноническим для всех участников проекта.

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

Иногда изменения в отдельных ветках накапливаются до момента, когда ты можешь взглянуть на них и сказать: «Это хорошо. Мы готовы выпустить в мир немного нового кода». Где-то это принято делать каждые две недели; где-то это происходит раз в год. А где-то, как Facebook, это делается постоянно.

Если твой софт был на версии 2, ты можешь связать все накопленные изменения в пучок и пометить код новым тегом. Узри, мир, это Версия 3!

А через пару секунд тебе приходит предложение изменения от программиста из другого полушария; это всё равно версии 3. С названиями версий всё строго: с версией 3 ты закончила. Версия 3 — часть всей вашей общей цепочки неизменяемых записей. Ты можешь исправить пару новых ошибок и назвать это версией 3.1. Или ты можешь добавить в свой код ещё одну важную фичу и назвать это Версией 4.

Инструменты вроде git дают программистам общий язык. «Ты это закоммитил?» — спрашивают они. «В каком это было коммите?» «Это должно было войти в 2.4, но мы перенесли в 2.5». Поскольку каждый коммит получает уникальный идентификатор, ты можешь точно определить его положение в пространстве и времени и быть уверенной в истории изменений кода так, как редко бываешь уверена хоть в чём-то.

Побочный эффект этой уверенности — рост автоматизации. Скажем, у тебя есть программа, она очень популярная, она обслуживает сотни миллионов людей каждый месяц. Чтобы обслужить всех пользователей, она работает на 50 разных серверах в разных точках планеты. Ну ты и молодец!

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

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

1. Вся работа над кодом должна происходить в отдельной ветке.
2. Когда работа сделана, она сливается обратно с основной веткой; после чего

• Запускаются автоматические тесты;
• Если ошибок не возникло, код отправляется на GitHub.

3. Запускается автоматический сервис отслеживания новых версий, который
4. Заставляет каждый из 50 твоих серверов, скачать обновлённый код из GitHub; и
5. Установить его себе, перезаписывая старую версию;
6. Затем останавливает работу каждого сервера;
7. Затем перезапускает, чтобы новый код мог загрузиться и приняться за работу.

Видишь, тесты и контроль версий теперь и есть спусковой крючок для собственно выпуска нового кода. Если ты можешь следовать такому процессу, ты можешь выпускать софт по несколько раз в день — что в эпоху коробочного софта было бы безумием. (Часто сборки делались по ночам большими «сборочными серверами», и наутро ты приходила узнать результат сборки.) Но теперь, когда софт работает через веб или магазин приложений, зачем ждать? Почему бы не выпускать обновления непрерывно, каждый день, всякий раз, когда у тебя есть что-то готовое к отправке?