Лучший код, который я когда-либо писал

Небольшой сценарий оболочки

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

По сути, это помогает вам управлять локальными репозиториями github, но это намного больше, чем кажется. Как и все отличные инструменты CLI, он предлагает вам новый, лучший рабочий процесс практически каждый раз, когда вы открываете свой терминал.

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

Проблема всегда заключалась в том, чтобы объяснить это, не садясь и не показывая это кому-то. Люди сразу понимают это, когда видят, что я использую его, но я не смог бы правильно сформулировать это без демонстрации. Я даже попытался разместить небольшой анимированный гиф, но, несмотря на восторженные отзывы, он сидел без дела уже 2 года и набрал только 16 звезд на github. :(

Сегодня я решил, что хватит. Мир должен познакомиться с gh. Вы просто тратите слишком много времени и энергии, и я могу вам помочь.

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

Это полезно для людей, которые часто переключаются между проектами. Разработчики OSS, микросервисов, Go и Node сочтут это наиболее полезным, поскольку мы часто перескакиваем от проекта к проекту много раз во время сеансов кодирования. Если это не относится к вам, вы можете не видеть в этом особой ценности.

Я вхожу в репозиторий heroku / heroku-pg-extras с помощью gh heroku heroku-pg-extras. Я уже клонировал его, так что это просто компакт-диск в ~ / src / github.com / heroku / heroku-pg-extras. Затем я запускаю gh npm npm, который я не клонировал, поэтому gh клонирует его в ~ / src / github.com / npm / npm и cd в это.

Это означает, что у вас больше нет каталога ~ / projects с кучей проектов, которые вы должны держать в уме. Конфликт имен проектов не проблема, потому что на github ничего не может конфликтовать. Больше нет ~ / projects / test-proj-22. Или ~ / projects / companyapp-jeff-fork. Вы всегда будете точно знать, где находятся ваши проекты.

Что еще более важно, вам больше не нужно помнить, клонировали ли вы конкретный проект в поле, в котором вы сейчас работаете. Где вы разместили этот проект на своем локальном компьютере? В другом месте, чем ваша рабочая коробка? Га, просто проверь еще раз. Затем через несколько недель вы замечаете, что у вас есть 4 одинаковых проекта в ~ / projects. Каталог настолько велик, что запускать ls - это так плохо, что вы должны начать передавать его по конвейеру через grep.

С gh погоня за репозиторием ls - это пережиток древних методов разработки программного обеспечения.

Вот момент, когда люди думают,

"фу. Я не хочу, чтобы мои проекты располагались в такой сверхдлинной структуре каталогов. Меня устраивает ~ / projects kthxbye. " - Непостоянный инженер

Позвольте объяснить, почему вам действительно нужна эта сверхдлинная иерархия. Во-первых, вас не волнует, что он длиннее того, что у вас есть сегодня, потому что вы редко когда-либо вводите полный путь, вы просто будете использовать gh для навигации.

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

Почему это ~ / src / github.com / npm / npm, а не просто ~ / src / npm / npm? Что ж, вы можете сделать его более короткую версию, если хотите (код крошечный, вы можете его взломать, поверьте мне), но это хорошо работает с кодом Go, который имеет много мнений о том, как вы структурируете свои проекты. Возможно, это также могло предотвратить столкновения.

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

И если вы дошли до конца и вам действительно любопытно, являются ли эти 18 строк кода оболочки тем, что я на самом деле считаю лучшим кодом, который я написал за свои почти 20 лет написания кода, ответ будет определенным да . Это программное обеспечение, которое, как я написал, я использую чаще всего, и которое сэкономило мне больше всего времени. Поскольку большая часть кода, который я пишу, - это node, я постоянно прыгаю по проектам.

"Дайте знать, понравилось ли вам!"

РЕДАКТИРОВАТЬ: Я прочитал несколько отзывов, в которых жаловалось, что мой заголовок вводит в заблуждение / кликбейт, потому что это вряд ли «отличный код». В мои намерения не входило, чтобы название вводило в заблуждение, и я думаю, что у нас, как у сообщества, есть проблема, если люди так думают. Это умный или интересный код? Нисколько. Но редко бывает «умный» прилагательное, которое я бы положительно использовал, говоря о программном обеспечении. «Умный» код часто бывает сложным и трудным в обслуживании. Конечно, это не атрибуты, которые мне нужны в моем программном обеспечении. «Лучшее» программное обеспечение - это то, что больше всего помогает людям - то, что приносит наибольшую пользу. И, по крайней мере, лично мне это очень помогло. Вот почему я говорю, что это лучший код, который я когда-либо писал.