Прежде чем приступить к новой задаче кодирования, простое упражнение по просмотру связанного рабочего примера может сильно повлиять на производительность, особенно когда задача касается незнакомых библиотек или концепций. Если я могу найти хороший пример, бегло просматривая его, мой мозг переключается в правильном направлении, и мне кажется, что я усваиваю некоторые из его уроков. Мой проект, скорее всего, пойдет гладко, даже если я не использую ни одной строчки кода из примера.
Однако найти этот хороший пример не всегда так просто, а сам поиск может занять много времени. Эта статья предлагает советы о том, как быстро найти хорошие примеры кода.
Охота за сокровищами занимает слишком много времени
Обычно я надеюсь найти репозиторий, который использует библиотеку или контекст, который я исследую, какой-нибудь репозиторий, который в целом хорошо написан и не слишком велик или перегружен.
Я обнаружил, что поисковые системы, даже предназначенные для поиска по коду, в основном разочаровывают и непродуктивны.
Простой поиск с использованием разумных ключевых слов редко работает, настойчивость приводит к безумию.
Фильтры поисковых систем
Вместо того, чтобы использовать прямые ключевые слова, мы будем использовать более сторонний подход к поиску, используя операторы расширенного поиска, в основном фильтры Google inurl: и site:. Мы будем использовать эти расширенные фильтры для поиска файлов без кода, которые должным образом проиндексированы поисковой системой, даже если код рядом с ним не индексируется.
С помощью inurl мы можем искать только текстовые файлы, такие как Dockerfiles или README, или, более эффективно, файлы манифеста зависимостей, такие как package.json Node, requirements.txt, Ruby's Gemfile и т. д. Некоторые сайты явно предлагают поиск по графу зависимостей в качестве функции (включая менеджеры пакетов и GitHub), но магия ранжирования страницы Google по-прежнему превосходит их.
Фильтры кроме inurl и сайта тоже могут пригодиться, вот хорошая ссылка: шпаргалка поисковых фильтров. Bing предлагает похожие, но не фильтр URL, хотя их intitle: обычно является хорошей заменой inurl.
Пример успешного поиска
Допустим, моя текущая задача — набросать тестовый фреймворк для проекта Электрон.
Я мог бы начать свою охоту с: inurl:package.json "electron" "mocha". (Если вы не знакомы с Node, mocha — это популярная среда тестирования.) Фильтр inurl ограничивает результаты страницами с package.json. в URL.
Я начну открывать вкладки, которые выглядят многообещающе, время от времени меняю условия поиска, возможно, заменяю «мокко» на «шутка» (еще одна тестовая среда), а затем снова пробую с фильтром site, чтобы ограничить результаты до GitHub. (с site:github.com), затем GitLab. Хотите свой пример на TypeScript? Добавьте "tsc" поисковый запрос.
Через пару минут мы находим Facebook Flipper и Rocket.Chat, репозитории, которые популярны, актуальны и хорошо поддерживаются. Они также огромны и подавляющи. Я уверен, что внутри нас можно многому научиться, но мы спешим. Наш поиск также находит несколько небольших полезных репозиториев, которые легче просмотреть, например: sindresorhus/electron-serve и checksum-validator.
Я не скажу, что мы нашли золото, но оценка этих рабочих примеров дает значительный прирост производительности, и мы нашли их всего за несколько минут. Один из небольших проектов показывает нам, как использовать spectron для безголового тестирования, а другой помогает нам рассмотреть возможность использования дымовых тестов. (Лично это упражнение помогло мне также принять решение о переносе всех прямых вызовов Electron из пользовательского интерфейса через @wranggle/rpc, что сделало это упражнение особенно стоящим.)
Местные коллекции
Допустим, мы новичок в Django и хотим увидеть некоторые реальные примеры того, как он выполняет GROUP BY запросы к базе данных.
Некоторые потенциальные ключевые слова для поиска всплывают при беглом просмотре официальной документации по агрегации баз данных. Мы могли бы попробовать вкладку поиска Code GitHub на некоторых (требуется вход в систему; отправьте поиск, затем нажмите вкладку Код), но мне в основном не повезло с этим. Мы могли бы попробовать выполнить поиск в Google по "from django.db.models import Q" filetype:py, и это дало бы несколько примеров, но есть и лучший способ.
Вместо прямого поиска вариантов использования нашего запроса агрегации давайте создадим локально сохраненную коллекцию хороших, хорошо написанных примеров проектов и найдем их.
Возможно, вы видели Темы GitHub, но знаете ли вы, что вы также можете искать темы? Отправьте поиск, затем нажмите на вкладку Тема. Они помечены владельцем репозитория, но это все равно отличный способ найти образцы репозиториев.
Скорее всего, есть хорошая CRM, CMS, блог и приложение для электронной коммерции практически на любом языке. (Плюс, возможно, даже список дел!)
Вкладки «Тема» и «Репозиторий» GitHub помогают нам находить отточенные, популярные и хорошо поддерживаемые проекты, которые мы можем добавить в нашу локальную коллекцию.
Я предлагаю сохранить локальную копию всего, что выглядит хорошо. Затем вы можете искать их, используя свою собственную IDE, гораздо эффективнее, чем любой онлайн-инструмент, который я когда-либо пробовал. У вас будут гораздо лучшие результаты, чем при использовании поиска в репозитории GitHub, и вы сможете вернуться к тем же примерам в будущем.
Разумеется, этот подход показывает множество примеров использования этого запроса агрегации, и, что еще лучше, мы можем оценить, как они их тестируют.
Человеческий и потрясающий человеческий контент
При исследовании какой-либо проблемы с кодированием регулярные поисковые запросы выдают статьи/учебники, ответы на StackOverflow/Gitter, обсуждения на HackerNews/Reddit и т. д. С точки зрения поиска учебника перед выполнением задачи вам лучше знать, будет ли одно из них более полезным. чем образец кода. Несмотря на это, высококачественные ресурсы любого типа часто можно найти в тщательно отобранных списках, а проще всего найти потрясающие списки.
Когда я снова забываю синтаксис CSS для элементов flexbox, простой поиск всегда приводит меня к css-трюкам, и это достаточно приятно. Но если я потрачу немного больше времени на поиск отличного списка на awesome.re или с помощью поиска наawesome flexbox, я найду отличный ресурс.
Сайты поиска кода
Если вы хотите найти конкретную аннотацию с кодом, возможно, стоит попробовать searchcode.com. Из инструментов прямого поиска по коду кажется лучшим, когда у вас еще нет списка известных репозиториев. Для этого запроса агрегации поиск по "from django.db.models import Q", похоже, дает достойные результаты.
Тот же поиск с использованием функции поиска по коду GitHub дает гораздо худшие результаты. Надеюсь, GitHub/Microsoft продолжит инвестировать в поиск кода. (Мне бы хотелось, чтобы они добавили функцию «точное совпадение» и функцию, которая выполняет глубокий поиск кода в каждом репозитории, на который я подписан или отмечен звездочкой.)
SourceGraph, коммерческий инструмент для поиска кода, может быть полезен командам, которые хотят делиться и искать в своем собственном курируемом списке репозиториев. Однако вам нужно заранее знать, какие репозитории вы хотите проиндексировать. (Я никогда не пробовал это, но эта функция кажется полезной.)
Замечать, когда это пустая трата времени
Рассмотрим более грубый процесс поиска. Скажем, наша следующая задача — добавить разделение кода Webpack в другой проект. Мы еще не начали, и мы (пока?) не застряли, мы просто следуем хорошей общей практике проведения нашего первоначального исследования.
Поиск по "splitChunks" inurl:webpack.config.js завершился неудачей, и было возвращено очень мало результатов. Изменение inurl на intitle:webpack.config возвращает немного больше, но по большей части это шум. Мы находим несколько примеров, но тратим много времени на просеивание.
Мы не можем выполнять поиск зависимостей, как мы делали это для нашей задачи Electron, потому что splitChunks является частью ядра WebPack и не добавляет зависимости. Дальнейший поиск в зависимости от чего-то еще в общем окружении (mini-css-extract-plugin) дает неплохие результаты, но поиск этого ключевого слова требует ненужных исследований.
Поиск Gist ("splitChunks" site:gist.github.com) также приводит нас к хорошим примерам использования, но не к полному репозиторию примеров. (Я не знаю, почему Gist проиндексирован, но главный репозиторий — нет. Robots.txt разрешает и то, и другое.)
В целом, в этом случае использование ресурсов, курируемых людьми, было бы лучшим использованием времени. Или я должен был остановить поиск пораньше, чтобы, возможно, вернуться к нему снова после того, как попытаюсь выполнить задание самостоятельно.
Когда остановиться?
Поиск примера кода может быть упражнением с открытым исходом. Очень легко потратить непродуктивные часы на поиск и чтение образцов. Имейте в виду, что поиск или понимание данного образца не является целью, вам нужно закончить свой собственный проект кодирования. Это упорное стремление закончить то, что вы начали, обычно является положительной силой, но если поиск образца не является жизненно важным, и вы не обнаруживаете ничего полезного, лучше двигаться дальше.
В противном случае, возможно, установите диапазон времени для упражнения. Если вы не знакомы с текущей темой, дайте ей относительно более высокую верхнюю границу. Если вы достигли предела, но упражнение по-прежнему кажется продуктивным, увеличьте его. Напротив, двигайтесь вперед раньше, если образцы бесполезны или если вы просто чувствуете, что готовы приступить к своей собственной задаче. Лучший признак того, что упражнение было успешным, — это если у вас появляются идеи о том, как сделать что-то лучше, чем образец.
Что касается нижней временной границы, рассмотрите возможность потратить некоторое минимальное время на просмотр примера кода, прежде чем начинать новую задачу. Чтение кода менее увлекательно, чем его написание, но в чужих репозиториях можно многому научиться, даже если вы уже знаете, как выполнить свою задачу.
Если у вас есть другие идеи или способы поиска примеров кода, поделитесь ими!
Эта статья не связана с платным доступом Medium с ограниченным доступом.
