Как эффективно управлять модулями Perl для повторного использования кода?

Question

Моя компания разрабатывает веб-приложения, используя комбинацию mod_perl, axkit и apache. У нас есть тонны модулей Perl, JavaScript и т. Д., Все в операционной системе Unix.

Всякий раз, когда мне нужно написать новую функцию, я пытаюсь сделать некоторое повторное использование кода, но дело в том, что все модули Perl и JavaScript разбросаны по папкам.

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

Есть ли лучший способ сделать это? Или, что еще лучше, есть ли бесплатные инструменты, которые я могу установить, которые могут помочь мне правильно управлять всеми функциями и модулями, и даже позволяют разработчикам регистрировать комментарии и т. Д.

EDIT

Существует это обсуждение по обнаружению дублирования кода на c ++ с использованием инструментов, есть ли у нас что-то подобное для perl-кодов на платформе Unix?

спасибо ~ Стив

Answer 1

Организуйте ваш исходный каталог, чтобы у каждой функции было только одно место, где она должна быть, и что-то легко найти.

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

Разработайте ваш модуль так, чтобы он делал только одну вещь - и делал это хорошо.

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

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

Не стоит недооценивать время для обобщения существующего компонента, чтобы он мог эффективно использоваться повторно.

Документ Модули с документацией API и / или юнит-тестами.

Общайтесь в Команде, чтобы каждый имел хорошее представление о том, что, возможно, уже было написано, кто имеет или знает, кто мог работать над / использовал модуль.

Answer 2

Полагаю, у вас есть какая-то версия программного обеспечения для контроля версий ( svn , Mercurial , git, как угодно, но не VSS)? Если вы этого не сделаете сейчас, пришло время получить его и начать использовать его. Таким образом, у вас есть хотя бы представление о том, какие модули вы используете и где находится код. Вы также можете использовать ctags-like для индексирования всех модулей, которые вы написали (или используете).

IDE (насколько мне это не нравится) также может помочь в поиске кода и рефакторинга.

Answer 3

Если ваши модули включают документацию POD и установлены в общем каталоге или наборе каталогов, то для генерации документов HTML должно быть относительно просто использовать pod2html . Получив документацию по HTML, добавьте индекс полнотекстового поиска (SQLite с fts3, MySQL, Lucene, KinoSearch и т. Д.) И приложение для простой формы поиска (CGI или mod_perl), и все будет готово.

Если вы используете trac, есть плагин , который будет создавать страницы вики-страниц trac из ваших файлов .pod и .pm, опять же, упрощая поиск документации.

Answer 4

Это то, что меня очень интересует.

Использование простых программ контроля версий, таких как SVN, GIT или Bazaar, не совсем то, что я хочу. В дополнение к такой системе обязательна VCS, но это не та система. После некоторых исследований мне было предложено изучить упаковку, чтобы достичь этого, и я думаю, что какая-то система упаковки - это путь.

Если вам нужен пример систем упаковки, посмотрите Debian APT. Каждый пакет имеет зависимости с версиями, описанием и исходным кодом, и при наличии хорошей системы упаковки вы можете перейти к «точке фиксирования уравнения магического набора поиска», и система волшебной упаковки найдет модуль, который решит проблему. Если вы включите пакет в свой исходный код, он также добавит все отсутствующие зависимости, например, график и тому подобное.

Однако, исследование этого началось незадолго до смерти жесткого диска моего ноутбука, что отложило дальнейшие исследования и реальные результаты в этом направлении, но, возможно, вам удастся найти что-то интересное (и скажите мне толчок, толчок )

НТН, Tetha

Answer 5

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

Итак, у нас есть один perl-файл для каждой основной таблицы в базе данных, по одному perl-файлу для каждой сущности, чтобы манипулировать своими бизнес-операциями и так далее ... благодаря этому легко избежать дублирования кода, потому что вы точно знаете, где искать заданную функцию.