Часть IV. Передача

Комплект владельца

Глава о том, где лежит проект, закончилась обещанием: репетиция передачи скоро понадобится. Наступило.

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

Мы в этом положении живём постоянно, и это стоит сказать сразу. Наша система собрана и обслуживается с участием агентов, а рабочая сессия агента конечна: она заканчивается, и продолжает другая, которая не помнит ничего. Каждый вечер проект переходит к исполнителю без памяти о вчерашних решениях и без возможности переспросить. У нас «полгода» наступает ежедневно – и всё, что написано в этой главе, добыто именно там, в режиме, где передача повторяется до тех пор, пока не начнёт получаться.

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

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

Вы владеете тем, что можете унести

Начнём с неудобного тезиса, который стоит примерить на себя до того, как передавать что-то кому-то.

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

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

Четыре предмета

Репозиторий с историей. Репозиторий целиком, со всеми изменениями от первого дня; архив с файлами «на всякий случай» этого не заменяет. Разница принципиальная. Архив отвечает на вопрос «что есть сейчас». История отвечает на вопросы, которые встанут позже: что менялось перед тем, как сломалось; как это выглядело, когда работало; куда вернуться. В части про изменения мы называли откат решением, доступным одной командой, – так вот, у получателя архива этой команды нет. Ему отдали фотографию проекта вместо проекта.

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

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

Список известных ограничений. Письменный. Что работает наполовину, что держится на удаче, что решено не делать и почему, где лежат долги. Этот предмет выглядит наименее обязательным и на деле самый показательный: он отличает передачу от избавления. У любого работающего проекта такой список есть – вопрос только, существует он на бумаге или всплывёт у получателя по одному пункту в месяц, в самые неподходящие моменты. Вы составляли его ещё в части 0, когда записывали границу первой версии; теперь он просто повзрослел вместе с проектом.

Заметьте, чего в комплекте нет. Нет красивой документации на сорок страниц – её никто не прочтёт, а устареет она раньше, чем дочитают. Нет комментариев к каждой строке кода. Нет обещания «я всегда на связи, если что – пишите»: обещание предметом не является, это та самая добрая воля, которая имеет свойство заканчиваться.

Как это выглядит у нас

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

Выживать в таком режиме нас научили три правила, и все три – прямые родственники комплекта владельца.

Первое: журнал, куда записывается каждое изменение. Что сделано, где, что проверено, как откатить. Следующая сессия начинает с чтения журнала, как ваш преемник начнёт с чтения README и списка ограничений. День, не записанный в журнал, для следующей сессии не существовал – со всеми последствиями, включая повторную работу и противоречащие правки.

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

Третье правило – самое важное и наименее очевидное: инструмент не считается сданным, пока не подключён к расписанию и не имеет сигнала тревоги. Оно появилось после случая, который звучит как загадка: инструмент был написан, проверен, работал безупречно – и не работал вовсе. Разгадка скучная: его написали и проверили руками, а подключить к расписанию забыли. Он существовал и бездействовал одновременно, четыре дня, пока разрыв не заметили. С тех пор «сделано» у нас означает: работает без человека, и если перестанет – кто-то узнает. Примерьте это определение на всё, что вам сдают.

Если переложить три правила на язык комплекта, соответствие получится точным: журнал – это README и список ограничений, растянутые во времени; отметка о занятой задаче – дисциплина репозитория; определение «сделано» – готовность к приёмке. О ней – следующая глава.

Проверка комплекта

Комплект, как и всё в этой книге, считается существующим после проверки, и проверка здесь одна.

Отдайте его. Не на словах – буквально: попросите другого человека развернуть и запустить проект, пользуясь только тем, что вы передали. Сами молчите. Каждый вопрос, который он вынужден вам задать, – дыра в комплекте: недописанная строка инструкции, незафиксированный файл, доступ, о котором вы забыли, решение, которое живёт только в вашей голове. Записывайте вопросы – это готовый список доработок.

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

Комплект собран и проверен – значит, вам есть что передавать. Следующая глава смотрит на ту же сцену с другой стороны стола: как принимать работу, которую сделали для вас, и как по трём вопросам отличить сданный проект от проекта, с которым вас оставили наедине.

Приёмка

Теперь другая сторона стола. Работу сделали для вас – подрядчик, помощник, знакомый мастер на все руки, – и наступил день, когда её сдают. На экране всё красиво, исполнитель доволен, вам предлагают принять.

Слово «приёмка» звучит казённо и как будто подразумевает недоверие. Ни то ни другое неверно. Приёмка – это способ узнать, что именно вы получили, пока за это ещё можно спросить. Через месяц те же самые вопросы превратятся из рабочих в неудобные, через полгода – в риторические. Хороший исполнитель приёмки не боится, ему есть что показать; для него это возможность сдать работу один раз вместо бесконечного «а ещё вот тут посмотрите».

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

Три вопроса и три ответа, которые ответами не являются

Начнём с разговора, который мы рекомендуем провести при любой сдаче. В нём три вопроса, вы все их знаете по части III. Интересны здесь не вопросы – ответы. Есть три типовых ответа, которые звучат успокаивающе и означают ровно противоположное тому, как звучат.

Вопрос первый: «Как проверяется, что заявка с сайта доходит до менеджера?»

Типовой ответ: «Мы всё тестировали».

Перевод: проверок нет. Есть память о том, что однажды, во время разработки, оно работало. Прошедшее время в этом ответе – главное слово: тестировали. С тех пор проект менялся, а каждая правка, как вы знаете из части про изменения, имеет соседей. Ответ делом выглядит иначе: вот тест, вот его запуск при вас, вот он зелёный; а вот мы ломаем сохранение – и он красный. Двухминутная сцена, после которой слова не нужны.

Вопрос второй: «Если заявки перестанут приходить – кто и через сколько узнает?»

Типовой ответ: «Мы следим за системой».

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

Вопрос третий: «Как вернуть предыдущую версию, если после обновления что-то сломается?»

Типовой ответ: «У нас всё под контролем».

Перевод: возвращаться не пробовали. Контроль, у которого нет названия механизма и числа минут, – это самочувствие, а не контроль. Ответ делом: название инструмента, история версий при вас на экране, возврат тестовой правки за названное время.

Общее свойство трёх пустых ответов – в них нет ничего, что можно увидеть. «Тестировали», «следим», «под контролем» – глаголы без предъявляемых предметов. Это и есть признак, по которому уклончивый ответ распознаётся без всякой техники: попросите показать, а не рассказать. Всё, что существует, показывается за минуты.

Приёмочный лист из четырнадцати пунктов

Три вопроса – это разговор. Для полной приёмки у вас уже есть инструмент серьёзнее: разворот «Четырнадцать вопросов к работающему проекту» в конце части III. Мы собирали их как вопросы владельца к собственному проекту, но у них есть второе применение, дословное: это приёмочный лист. Проект, который сдают вам, обязан отвечать на них так же, как ваш вечерний.

Разворот отвечает на вопрос «что должно быть». Приёмка отвечает на другой: как это выглядит, когда вам показывают. Ниже – по пункту на строку, и ни одна из них не требует от вас чтения кода.

1. Путь целиком – при вас отправляют заявку с настоящей страницы и показывают её в базе и в уведомлении.
2. Проверка на рабочей площадке – показывают, где она прогонялась, и чем эта площадка отличается от той, куда ходят люди.
3. Проверка краснеет – при вас ломают сохранение, при вас проверка краснеет.
4. Вывод по запуску – на «работает ли» отвечают прогоном; чтение кода вслух в ответ не принимается.
5. Сигнал на тишину – называют событие, порог и адресата, показывают, что придёт.
6. Вход и выход рядом – показывают экран, где числа «сколько пришло» и «сколько обработано» стоят рядом.
7. Пульс наблюдения – показывают последнее сообщение «всё в порядке» с датой.
8. Состояния в отчёте – перечисляют состояния обращения и показывают каждое на экране.
9. Соседи правки – показывают список мест, где живут цена, телефон, название услуги.
10. Правка применилась – показывают, какой код исполняет работающая служба и что видит посетитель в чистом браузере.
11. Возврат назад – называют механизм, показывают историю версий и откатывают тестовую правку при вас за названное время.
12. Единственные экземпляры – называют перечень того, что существует в одном месте.
13. Развёртывание с нуля – при вас разворачивают проект по инструкции на чистой машине. Самый ёмкий пункт: один прогон закрывает сразу несколько остальных.
14. Восстановление из копии – показывают восстановленную копию и дату последней проверки.

Ни один пункт не требует от вас квалификации. Все требуют времени – приёмка по такому листу занимает часы. Сравните с ценой альтернативы: почти все истории этой книги, от кнопки в никуда до тридцати потерянных файлов, были бы пойманы этим листом за один проход. Каждая из них стоила дороже.

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

Приёмка у самого себя

Теперь случай, ради которого эту главу стоит читать даже тем, кто никогда ничего не закажет.

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

Худшая альтернатива этому часу – привычный сценарий: открыть код, «быстренько поправить» нужное место и запустить цепочку, которой была посвящена целая глава. В чужом проекте – а трёхмесячный ваш именно таков – соседей правки не знает никто.

Если проект уже принят давно и без всего этого

Частый случай: сервис работает год, сдавали его без листов и вопросов, исполнитель давно занят другим. Что теперь – всё пропало?

Ничего не пропало. Проведите приёмку задним числом, у себя, без исполнителя. Тот же лист, те же «покажите» – только показывать будете себе. На выходе получится список расхождений: чего нет, что не проверяется, куда нет доступа. Этот список – не приговор и не смета на переделку. Это карта, и следующая глава целиком про то, что делать с такой картой: что чинить, что переписывать, а что осознанно отпустить.

Приёмка отвечает на вопрос «что мне сдали». Следующая глава – про вопрос, который встаёт следом и мучает каждого владельца поработавшего проекта: это чинить, переписывать или пора отпустить.

Чинить, переписывать или отпустить

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

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

Решение принимается иначе, и мерило у него одно.

Мерило: воспроизводимость

Считать недостатки бесполезно: их список есть у любого работающего проекта, включая образцовые. Смотреть надо на другое – предсказуемо ли поведение проекта и проверяемы ли последствия правок.

Чинить, когда главный сценарий работает; поломки локальны – починка одного не разваливает соседнее; есть история изменений и возможность вернуться; понятно, где что лежит, или это можно выяснить. Такой проект – зрелый организм с болячками. Болячки закрываются по одной, по правилам части про изменения, и каждая закрытая делает следующую проще.

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

И есть третий исход, о котором почти не говорят, потому что он звучит как поражение. Отпустить – когда проект решает задачу, которая больше не стоит. Дело даже не в качестве решения – самой задачи больше нет: направление закрыто, процесс изменился, сервисом давно не пользуются, и единственное, что он производит, – расходы на поддержание и чувство вины. Держать такой проект живым – то же, что чинить лестницу к двери, которую замуровали. Отпустить – значит выключить осознанно, сохранить то, что стоит сохранить, и освободить руки. С «бросить» это не совпадает.

Как это выглядело у нас

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

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

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

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

Дерево решений на одну страницу

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

Два примечания к таблице. Первое: «переписывать» в нижнем правом углу – это самый дорогой исход, и попадание туда почти всегда означает, что у проекта не было ни репозитория, ни копий, ни комплекта. Всё, чему учила эта книга, – способы никогда не оказаться в этой клетке. Второе: решение «чинить» без письменного списка и сроков само собой превращается в «работает – не трогай». Это четвёртый исход, единственный по-настоящему плохой: он выглядит как решение, а является его отсутствием, и заканчивается всегда одинаково – аварией в момент, который выберет не владелец.

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

Дальше – финал книги. Он короткий: о том, что изменилось за эти страницы, что не изменится никогда, и где проходит граница, за которой наша книга заканчивается, а ваш проект продолжается.

Финал книги

Книга началась с формы, которая говорила «Спасибо» и выбрасывала обращение. Закончим тем, что между той страницей и этой изменилось – и что осталось как было.

Что изменилось

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

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

Всё это вы делали руками, по одному шагу за главу. В книге не было ни одной строки кода и ни одной команды, которую вы не запускали.

Изменилось и кое-что менее осязаемое. В первый вечер убедительная картинка на экране вызывала доверие. Теперь она вызывает вопросы – те самые шесть, потом четырнадцать. Это профессиональное зрение, и с подозрительностью его путают только те, у кого его нет; самая дешёвая из всех страховок: она куплена за один сломанный вечерний проект и десяток наших историй, а страхует от историй, цену которых вы теперь знаете.

Что не изменилось

Агент по-прежнему достраивает недосказанное, и достраивает правдоподобно. Это его природа. Она не исправится в следующей версии и не лечится удачной формулировкой запроса – она вообще не болезнь. Ровно та же способность, которая заполняет пробелы вашей задачи самыми дешёвыми решениями, пишет за минуты код, на который недавно уходили недели. Инструмент не станет отвечать за результат. Отвечает владелец – и после этой книги слово «владелец» для вас, надеемся, звучит конкретно: тот, у кого репозиторий, копии, сторож и список ограничений.

Не изменилось и главное соотношение, с которого книга начиналась: собрать – быстро, содержать – работа. Генерация закрыла первое. Второе осталось людям, и это надолго.

Чем написана эта книга

Признание, которое вы, возможно, уже заподозрили: эта книга написана вместе с агентом – по её же собственным правилам. Каждая команда прогонялась на чистом окружении до попадания в текст, и прогон исправно ловил то, чего не увидел бы никакой редактор: пакет, без которого не работают формы; учебную поломку, которая падала эффектно, вместо того чтобы падать поучительно; сторожа, который на пустой базе умер бы с трассировкой вместо внятного сигнала. Главы вычитывала отдельная свежая сессия, потому что сессия, написавшая текст, повторов в нём не видит – она их и породила. А проверка фактов нашла в нашем собственном рабочем каноне ошибочную цифру, которая прожила там неделю и едва не уехала в эту книгу как «документально подтверждённая».

Рассказываем это не ради занятности. Это ответ на вопрос, который висит над каждой страницей любой книги про вайбкодинг: можно ли с агентом делать настоящие вещи? Можно. Ровно тем способом, который здесь описан: с проверкой запуском, свежим взглядом на вычитке и владельцем, который отвечает за результат. Книга, которую вы дочитываете, – ещё один проект, собранный по этой методике, и вы только что проверили её работоспособность самым надёжным из способов.

Где заканчивается эта книга

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

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

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

Последнее

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

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

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