Защото понякога вашият спагети код трябва да се запази само за вас.

Когато разработвате множество приложения, повтарянето на един и същи код в множество проекти е нещо, което аз лично считам против „DRY“. Копирането и поставянето на файловете или използването на символни връзки звучикато добра идея, но има начин да се централизира този код, без да се публикува в Интернет.

Например в моето приложение Podcast споделя код с друго приложение. По-специално, код за регистриране на действия, извършени от потребител в базата данни, така че сега мога да знам кой е главният виновник, когато се случи нещо, което не е трябвало да се случи. Също така, не искам хората да надничат в кода ми, направих го пиян и изглежда като крещеща Roomba.

Добър начин да използвате повторно същата кодова база е да намерите кода на някое място и да кажете на вашите проекти любезно да използват файловете, намиращи се там. Разбира се, няма нужда да хаквате файловата система, да използвате символни връзки или дори да публикувате кода си в Интернет.

Това може да се направи магически от Composer, използвайки локално хранилище, в две стъпки.

Стъпка 1 — Настройване на кодовата база

Ако се чувствате професионалист, използвайте composer init, за да създадете манифеста, който описва вашия пакет. Отидете в главната папка на вашата кодова база, натиснете терминала и следвайте инструкциите.

За по-лесно ще ви насоча към Laravel Package Boilerplate, който задава почти всичко готово, за да започнем да правим нашия Composer пакет. Просто изберете „PHP“, поставете някои подробности и след това изтеглете на безопасно място в компютъра си, за да го използвате по-късно, като /Users/Local/SpaghettiCode.

Ще получите много файлове в ZIP архив, но този, който ни интересува, е composer.json. Можете да изтриете всичко с изключение на този файл, ако не планирате да качвате пакета си в интернет в бъдеще.

Този нов composer.json инструктира Composer да третира кодовата база като пакет Composer. Трябва само да коригираме и опростим някои неща, като каква PHP версия изисква.

Ако имате нужда от допълнителни пакети, няма проблем, можете също да ги посочите тук. Просто се уверете, че не ги инсталирате вътре в пакета, както когато използвате composer install. Проектът, който ще се нуждае от този пакет, автоматично ще го направи.

Можем да поставим нашите файлове така, че да съответстват на пространството от имена по PSR-4 стандарти, като ги поставим в папката src.

Стъпка 2 — Добавяне на локално хранилище

Сега, когато имаме готови файлове, трябва да кажем на нашите проекти да използват този пакет. За това трябва да инструктираме composer.json на нашия проект да проверява „локален път за пакети“.

След като сте готови, вие сте готови да използвате пакета във вашите проекти като всеки друг пакет, от който се нуждаете:

Ползи

Да, това е всичко. Много е лесен и чист за изпълнение, но това не е единственото предимство от използването на този начин за обработка на често използван код във вашите проекти.

  • Използвайте повторно същата кодова база, без да се налага да се грижите за актуализиране на модификации в множество проекти.
  • Тествайте кода веднъж, вместо да го тествате във всеки проект.
  • Не е нужно да се занимавате с Packagist или който и да е интернет базиран VCS като Github, Gitlab или Bitbucket.
  • Работи с VCS, ако го използвате във вашия пакет, като git.
  • Тъй като се счита за пакет, той няма да се намесва във вашите файлове на проекта по никакъв начин.

Няма нужда ръчно да свързвате папки със символи, да копирате и поставяте файлове ръчно или да се занимавате с публикуване на пакета в Packagist или Github, така че всеки да може да се посмее на вашия топъл код на топка коса.