Текст — это основа мира программного обеспечения. Почти все, что мы делаем в программном обеспечении, сводится к выражению в тексте (часто в большом количестве). Текст — это то, как мы, разработчики, делаем ходы.
Думать о тексте как о коде и о коде как о форме выражения интересно. Выражение имеет форму и должно быть самосогласованным. Это значимая модель в человеческом языке, но тем более в коде, где правила настолько строги и так легко ошибиться. Зрелый, хорошо написанный код часто читается как обветренная крепость: изношенный и исправленный за годы ошибок, проблем с производительностью и усовершенствований. Хороший код — это гораздо больше, чем просто механическая функция, которую он выполняет: это узкий безопасный путь через извилистый лес опасностей. Хороший код, этот путь, также определяет форму опасностей, которых он избегает. Если нам повезет, то мы также получим указатели в виде документации и комментариев, которые сообщают нам, что произошло и почему путь здесь так круто сворачивает.
Я назову эти опасности «опасениями». Эти заботы, как правило, стоят гораздо больше, чем механическая работа с какой-либо конкретной частью кода, поскольку они дают нам руководство о том, как писать новый код, не нарушая его так сильно.
Если код — это выражение, то мы можем видеть, как трудно восстановить нюансированное выражение, которое было выветрено годами исправлений и экспериментов после того, как оно было утеряно. Мы также можем видеть, насколько изоляция этих выражений для конкретного проекта или проблемы по своей сути расточительна: даже если код механически не применим к другой проблеме, он, вероятно, по-прежнему полон проблем и решений, применимых в различных предметных областях.
Конечно, это относится не только к коду, исправленному годами. Код, на который ушло несколько часов работы, по-прежнему чрезвычайно ценен, когда он означает, что нам не нужно снова переделывать одни и те же проблемы.
Любой программный проект — это просто большое выражение: симфония или башня. Но правила строгие и непослушные, и соблюдать их очень сложно. На самом деле, улучшение выражения — это и есть разработка программного обеспечения. И ваша средняя часть программного обеспечения состоит из тысяч строк кода; миллионы забот и выражений абстрагированы. Если мы хотим писать программное обеспечение эффективно, нам нужно иметь возможность быстро и точно создавать и повторно использовать выражения — в промышленных масштабах. Нам нужно, чтобы простые проблемы были простыми, и мы должны иметь возможность склеивать готовые абстракции (например, библиотеки и фреймворки), не задумываясь.
Имея это в виду, я написал RipLine несколько лет назад. RipLine позволяет мне находить, повторно использовать и улучшать собственные фрагменты кода в проектах, а также сопоставлять этот код с тем, как я его понимаю. Более того, когда я нарезаю эти фрагменты очень детально, можно получить действительно большие выгоды: маленькие, многократно используемые фрагменты, к которым можно быстро получить доступ и которые несут в себе все улучшения, которые я когда-либо делал.
Процесс невероятно прост: напишите какой-нибудь код, прокомментируйте его, скопируйте и вставьте в RipLine с некоторыми тегами и заголовком. Например, если я хочу скопировать файл в NodeJS с помощью потоков, обычно это немного сложнее, чем должно быть. Нам нужно создать поток чтения и поток записи с обратными вызовами, а затем соединить их вместе. С RipLine это легко: я иду читаю и понимаю решение, а потом закидываю его в RipLine с тегами типа «nodejs, io, копировать, читать, писать, файл». Затем я могу в любое время выполнить поиск «копия nodejs», и у меня будет свой фрагмент. Мне не нужно беспокоиться о том, чтобы вспомнить, как именно это работает; это все для меня, чтобы быстро просмотреть и взломать. Я могу переписать эту функцию копирования менее чем за минуту в любом проекте. Если позже я решу объединить этот материал в свою собственную библиотеку ввода-вывода, то это тоже несложно — у меня уже есть все соответствующие фрагменты, проиндексированные под несколькими полезными тегами.
Почему это лучше, чем просто гуглить?
Никто не знает, что вы знаете и используете лучше вас. Адаптация фрагментов к вашим собственным предпочтениям, знаниям и точке зрения делает их простыми в использовании и по-настоящему надежными. Когда вы находите что-то в Google, вы должны убедиться, что это правильно, понять контекст автора, проникнуть в его мысли, понять его решение, а затем применить это решение к вашему контексту. Когда вы посмотрите на свое собственное решение, если оно правильно прокомментировано, то вы, вероятно, уже поймете контекст, и, скорее всего, вам вообще не нужно будет адаптировать решение. Но если есть проблема с вашим собственным фрагментом, вы можете улучшить его и упростить использование в следующий раз. Таким образом, вы будете выполнять итерации, и ваш код будет становиться для вас все более и более полезным.
Как насчет повторного использования кода?
RipLine не предназначен для замены абстракций в коде. Это сделано для облегчения их использования. Проблема с абстракциями в коде заключается в том, что они всегда оставляют желать лучшего, что не может быть строго устранено повторным использованием кода.
Например, NodeJS может использовать промисы. Но как правильно вызвать вашу библиотеку базы данных для получения промиса, и возвращает ли она нативный промис или что-то еще? Какая версия Node вам нужна, чтобы манипулировать этим промисом с помощью await? Как установить эту версию Node?
Возможно, вы знаете эти ответы навскидку, и в этом случае вам может не понадобиться фрагмент для этой конкретной вещи. Тем не менее, суть остается неизменной: почти всегда в каждом языке и в каждой проблеме есть что-то, что требует решения конкретных проблем, прежде чем можно будет правильно использовать абстракции. RipLine делает процесс решения этих очень специфических проблем почти автоматическим.
В других случаях ваши средства повторного использования кода немного ненадежны или делают штрихи слишком широкими. Так обстоит дело в C: многие вещи делаются как бы «на земле» с использованием стандартных идиом — циклов, условных выражений и аллокаций. Часто функции на самом деле не обеспечивают чистых абстракций для решения этих проблем, потому что у функций нет способа автоматизировать жизненные циклы распределения и тому подобное. Иногда мы можем обойти это с помощью макросов, но часто более разборчиво просто написать немного больше кода с небольшой избыточностью. С RipLine это легко — у нас есть фрагмент, и мы можем просто вставить его и взломать. это немного.
