«Что? Стивен Кинг „Как писать программный код“ ?! Нет такой книги! Да он вообще не программист ни разу!».
Да, так и есть. Тем не менее — книга с таким содержанием у него есть. Хотя он и не думал, что пишет её об этом. Хотя в результате написал. Хотя, наверное, и не знает об этом. О чём же я тут рассуждаю? О недавно прочитанной мною прекрасной книге «Как писать книги» (англ. — «On Writing»).
Кинг писал её как опытный писатель для писателей начинающих. Однако в результате у него получилась книга, рассказывающая не только как писать именно фантастическую литературу, но и том как писать вообще что угодно — в том числе и программный код. Прочитав за последние пару лет два десятка основных книг-икон современной программной индустрии (ну знаете, все эти «рефакторинги», «паттерны», «чистые и совершенные коды» и т.д.) я могу утверждать, что этой книге Кинга вполне себе место среди них, причём не на последнем месте. Дальше будет пару примеров (и как результат — спойлеров), поэтому самым правильным будет не продолжать читать статью, а пойти и прочитать саму книгу. Потом можете вернуться и сравнить свои выводы с моими. Ну а если времени на книгу у вас нет — под катом выдержки и выводы.
Работать, работать и еще раз работать
Гениев-творцов мало. Сам Кинг себя к ним не относит. Он рассказывает о том, как с малых лет (еще с дошкольного возраста) начинал писать небольшие рассказы, отрывки, наброски, как показывал их разным людям, отсылал в журналы и издательства. И как его полтора десятка лет футболили. Причём он сам сейчас признаёт, что писал тогда слабовато. Эти полтора десятилетия были ему нужны чтобы совершенствоваться. Чтобы в итоге написать то, что продаётся тиражом в десятки миллионов. Мысль о том, что качество — результат ежедневного труда на протяжении многих лет очень важна и для программиста. Ну знаете, сейчас модные всякие там «23-летние сеньйоры». Может быть часть из них и правда таланты от природы. Но то, что большинство из нас пишет в коде первые лет 5 своей работы годно только для операции Shift+Del. Хорошо, если это время приходится на учёбу, стажировку или позицию «младшего разработчика». Но иногда люди в силу гордыни или обстоятельств на полном серьёзе пишут так production-код. За что потом расплачиваются и они сами, и работодатель. Чудес не будет. В русских сказках модно 33 года сидеть на печи, а потом вдруг стать богатырем или поймать золотую рыбку. Тяга к халяве и вера в чудеса — эти обстоятельства присущи многим. Стивен Кинг рассказывает о том, что чудес не бывает (хотя вот парадокс — большинство его книг говорят об обратном!). Сам он до всемирной славы перебивался копейками от малоизвестных журналов, учился на преподавателя и потом работал им, а еще подрабатывал в прачечной. И всё это время писал, писал, писал.
Закрытая и открытая дверь
Кинг рассказывает о том, что всегда пишет как минимум два черновика своих произведений — один «за закрытой дверью», второй «при открытой двери». Под этим он понимает вот что: первая версия произведения должна быть продиктована головой и душой автора. Ему нужно обеспечить возможность творить и фантазировать, писать то, что ему велит муза. Но вот то, что получится в результате — ни в коем случае нельзя сразу отдавать читателю. Всё это нужно переписать «при открытой двери». Т.е. дать почитать рассказ жене, ближайшим друзьям, доверенному редактору или критику. Как правило, эти люди найдут в произведении массу ляпов, глупостей, укажут на непонятные вещи, на противоречие общеизвестным фактам и т.д. Многие из этих замечаний будут по делу. И вот тогда текст нужно переписать с учётом этих замечаний. Посмотрите, как хорошо эта мысль гармонирует с общеизвестными в ИТ-мире фактами:
- Программисту нужно обеспечить покой, тишину и отсутствие отвлекающих факторов.
- Код перед отправкой в продакшн должен пройти ревью или тесты. Хорошо, когда кодом владеют несколько разработчиков.
Казалось бы — какие разные миры: написание фантастической литературы и программирование. А видите — суть процесса получается одинакова.
Еще одно правило, о котором говорит Стивен, это то, что второй вариант черновика должен быть обязательно короче первого (ну хотя бы на 10%). И опять таки — все мы знаем, что лучший рефакторинг — это такой, при котором удаляешь код, не уменьшая функциональности системы. Несуществующий код не надо хранить, читать, поддерживать, тестировать, в нём не может быть ошибки. Это самый лучший код.
Угодить читателю
Писать то, что нравится самому или то, что понравится читателю? Некоторые авторы считают, что подстраиваться под читателя значит предать себя и стать «литературной подстилкой», способной только собирать деньги на волне моды. Кинг категорично отрицает эту мысль. Он говорит, что творчество обязательно должно иметь аудиторию. Если вы не хотите угодить читателю — пишите в стол или вообще сразу сжигайте написанное. Но если вы решите публиковаться — нужно думать о публике. Что будет для неё интересно, а что нет, что понятно, а что сложно, что вызовет восторг, а что — скуку? Все эти мысли должны вести перо писателя. Иначе он не профессионал, а любитель. Иначе можно сразу записываться в «непризнанные гении» и уходить с запасом чистой бумаги жить в тайгу. Как часто этого понимания не хватает и программистам! Ведь мы работаем не ради себя, не ради байтов в памяти компьютера, а ради конечного пользователя. Это ему должно быть удобно, полезно, быстро и комфортно с нашей программой. Это его проблемы мы решаем, а не свои. Это он является нашим работодателем. Если вы пишете в угоду лишь себе — можете называть это хобби, увлечением, но уж никак не работой профессионала.
Ритм
Стивен говорит о том, что открыв любую книгу в любом месте можно с высокой вероятностью сказать о степени её качества, даже не читая текст. Сразу видно, как слова складываются в предложения, насколько длинны абзацы, как много места занимают диалоги, формулы, цитаты и т.д. Это всё даёт понимание сложности книги, её стиля, динамики и т.д. Даже мельком просмотрев 2-3 страницы уже становится понятно, будет ли нам интересно читать эту книгу. Точно то же самое касается и кода. Открыв любой исходник мы уже чувствуем его дух — сразу видны размеры функций, средняя длина строк, количество методов у класса, наличие комментариев, тестов, и т.д. Мне не нужно читать код полностью, чтобы увидеть его ритм, 2-3 страницы уже дадут понимание, стоит ли использовать библиотеку в своём проекте. Как для автора кода это даёт мне понимание, чего ждёт от меня пользователь. Очень хочется перед ним не опозориться.
Набор инструментов
Сколь бы ни был хорош мастер, без подходящего инструмента ему работать не удобно. Сразу несколько глав в книге посвящены выбору правильного инструментария писателя. Автор рассуждает о необходимости наличия как тривиальных инструментов (типа подходящего текстового редактора, словаря, справочников), так и более высокоуровневых — типа собственных правил именования персонажей, избегания литературных клише, запретов на некоторые слова и правильном построении предложений. Для программистов, понятное дело, «нижний эшелон» инструментария состоит в подходящем железе и софте, правильно подобранным плагинам под любимую IDE, выученным хоткеям. «Верхний» уровень инструментов более сложен — это проверенные библиотеки (свои и чужие), правильные паттерны, это в общем опыт и наработанная интуиция, подсказывающая, какое решение сработает, а какое — нет. Создание всего этого инструментария — очень важная часть работы программиста. Без него он будет подобен пещерному человеку, пытающемуся добыть огонь голыми руками.
Извлечь артефакт из породы
Я слышал эту мысль не только от Кинга — дескать, создать этот шедевр было просто, он и так всегда существовал где-то, как мраморная статуя всегда находилась в куске цельного камня до своего создания. Самое сложное — это извлечь артефакт из «породы», не повредив его и не захватив лишнего мусора. Мысль очень красива. Иногда смотришь на какую-то программу и видишь её именно как вот такой артефакт — в нём всё на своем месте. Только подумаешь «вот хорошо бы, если бы вот тут была такая функция» — как смотришь, а она именно там она и есть. И именно так и работает, как тебе думалось. Образ автора такой программы наверняка очень схож с образом творца предмета искусства. Уметь извлекать такие жемчужины — большое мастерство, к нему стоит стремиться.
Литературный агент
Уметь хорошо писать (код или книги) — это еще полдела. Нужно донести свой продукт до потребителя, найти кого-то, кто будет готов заплатить за него деньги. В издательском мире есть такая профессия как «литературный агент» — человек, который представляет автора перед издательствами, определяет размеры гонораров, решает вопросы копирайта и в общем взаимных обязательств. В мире IT нынче есть очень много разных видов сотрудничества (как прямого, так и через посредников). Некоторые из них возлагают на программиста огромную кучу не-программерской работы, другие оставляют простор для чистого творчества. Как по мне — лучше уступить пару процентов своей зарплаты ради возможности делать только то, что тебе нравится, но для кого-то может быть и наоборот. Недаром до сих пор идут жаркие споры на предмет «фриланс vs обычная работа vs свой стартап vs чего-то-ещё». Каждому подходит что-то своё, главное не лениться его искать и найти.
Обо всём этом и многом другом автор пишет куда интереснее и красочнее меня, косноязычного пересказчика, поэтому даже если вы прочли все вышеуказанные спойлеры, всё-равно есть смысл прочитать оригинальную книгу. Я думаю, вам будет интересно.
Автор: tangro
