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

называй по нормальному, веди документацию в вики с полнотекстовым поиском (о, этот идеальный мир...)
не используй "глобальные" модули

В общем, что-то типа встроенного СП

(0) Ну, по смыслу они как-то в общих модулях организованы

(0)Фигня это все.  Ты представь сколько функций в конфе?  Запаришься все их описывать.

+(4)И да же если опишешь- это такой объем инфы получится, что все равно толком ничего не найдешь.

(3)
Согласен, но все равно иногда неудобно копаться в сотне функций, идущих одно за другой - удобнее как в СП (по разделам)
(4)
Все не нужно - хотя бы начать описывать функции, добавленные сегодня и все последующие дни, и изредка старые функции, попадающиеся на глаза

// Формирует структуру, содержащую значения реквизитов шапки документа.
//
// Параметры:
//  СправочникОбъект - объект документа для формирования структуры шапки,
//
// Возвращаемое значение:
//  Сформированная структура.
//

Это разве не описание?

(7)
Как мне, не зная, что данный метод существует, найти в конфигураторе вышеописанный метод хотя бы по области применимости ("ДокументОбъект") или по параметрам? Только глазами рыскать

Хотелось бы :

Глобальным поиском(правильным)

Хотелось бы искать по таким параметрам, как:

1) Тип объектов, используемых в методе (конкретный документ/любые документы/числа и т.п.). Т.е. для функции, контролирующей, включена ли какая-то строка документа А в какой-либо документ Б в описании такой ф-и в "типах объектов" будут числиться документы А и Б.
2) Тип возвращаемых значений (для функций)

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

+(11)

3) в СП (зачем далеко ходить) есть разделение по смыслу, пример:

Веду такую базу, но конечно глупо документировать каждую процедуру. Урупненно - да.

Глобальный контекст / Функции для вызова диалога ввода данных / ВвестиСтроку

это тоже можно учесть в описании

+ Опять же нахрена документировать каждую процедуру если всё это можно прекрасно посмотреть в коде?

(14)
Где ведешь? Можно пример процесса заведения описания какого-нить метода в студию?
И потом пример поиска этого метода по каким-либо критериям?

(16)
Всякую фигню типа:

Процедура тч_Конкурс_блокировка(Элемент, СтандартнаяОбработка)
   СтандартнаяОбработка = Ложь;
   Сообщить("Форма доступна только для просмотра. Изменение конкурса невозможно");
КонецПроцедуры

точно не нужно документировать.
Обработчики событий тоже - они явно будут использованы только в данной форме.
Документировать хотелось бы в основном важные частоиспользуемые методы общих модулей (и модулей менеджеров, модулей объектов).

(17) В самописке.

Например:

Есть список функций, каждая функция имеет версию (релиз в котором она реализована). Плюс к функциям атачатся "изменения" - тоже имеют версию.

Например функция "Проведение по взаиморасчетам" (типовая функция), а к ней атачится изменение "Проведение по взаиморасчетам с доп аналитикой ХХХ". К каждой функции или изменению привязываются задачи на реализацию функции/изменения. Код задачи пишется в комментах в коде типа "// Вася дата (Код задачи) add{

По коду задачи в конфе сразу определяется что зачем напилено.

(19)
Т.е. у функции есть "название", "версия", "№ бага".
И как человек, который не знает о существовании функции, найдет ее? Будет копаться в багах/названиях/описаниях методов?  Получается это просто база информаии о функциях, но без "человеческого" поиска (если я правильно понял)
Вот нужно мне написать ф-ю, которая осуществляет некий контроль документа А с учетом справочника Б. Прежде, чем ее писать, я посмотрю - а есть ли существующие ф-и с присутствием А и Б. И окажется, что она есть. Или есть похожая, написанная 2 года назад, я ее код посмотрю и пойму, что ее немного можно подпилить и заюзать. В этом и смысл

(20) Ну они сгруппированы: пользовательские по подсистемам, системные по назначению.

Т.е. чтобы в будущем не искать ты хочешь заранее найти все функции типовых и задокументировать?

Цель не совсем понятна.

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

Можно сказать с уверенностью, что если и возникнет подозрение что это уже написано, то разве что в модуле "ОбщегоНазначенияХ". Я не о том, что при дописках не используются функции "прикладных" модулей, а о том, что они обычно жостко завязаны на объекты из которых вызываются. Т.е. например, мутишь ты свой док с табчастью "Услуги". Состав таб части копипистишь из типовых объектов, за ними тянутся события, а там и вызовы типовых функций общих модулей. Короче, ХЗ, толку все эти функции помнить не вижу.

Вот есть в УПП в модуле повторного использования функция ПолучитьЗначенияРеквизитовОбъекта, которая весь сеанс возвращает по ссылке одни и те же реквизиты. Будешь ею пользователься? Типовые разработчики так видимо и не решились, висит процедура одиноко никем не вызываемая... :)
Впрочем, может у меня старая версия УПП.

(24)
У нас нетиповая конфа, к тому же как раз и хочу уйти от того, что наизусть функции помнить было бы необязательно. Ну и по твоей логике выходит так: один программист делал какой-то баг, создал ф-ю, что-то контролирующую, поместил ее в общий модуль, написал к ней комментарий и номер бага и т.п. После другой программист делает другой баг, но в котором эта ф-я может быть использована. Получается, что он должен зайти в общий модуль (или в несколько модулей), заюзать полнотекстовый поиск (и то может не сработать - не найти), а он после недолгих поисков плюнет на все это и накатает свой "велосипед". Так в системе будет 2 одинаковых процедуры. А потом потребуется изменить что-то и будет изменена лишь одна из них и окажется, что в каком-то месте конфигурации какие-то данные не стыкуются с другими данными. И придется все равно сводить все к использованию одного метода :)

(25)
Может кому и пригодилась бы (хоть одному из 1000), но мало кто о ней знает, наверное - в этом и проблема :)

(26) По хорошему программисты делают функционал, а не баги. Впрочем зачастую выходит только второе.

А по теме, опять же говорю одиночные функции, за редкими исключениями, тупо сидят в модуле общего назначения разбитые по тематике :работа со строками с массивами и т.п. В другом случае одиночными функциями никто не оперирует. Оперируют т.н. паттернами. Например, разработали в 1С паттерн (счиатай правило) проведения документов и все ему следуют. Соответственно этот реализованный паттерн, как кусок функциональности имеет ряд интерфесов (экспортных методов), которые и описаны в его документации. Оперируя такими вот кусками легко находится где и что сидит. А вот тупо поиск определенной функции чтобы её заюзать, это верный признак того, что разработка ведется "каждый в свою сторону".

(27)
Все равно я ответа на свой вопрос не нашел.
"А вот тупо поиск определенной функции чтобы её заюзать, это верный признак того, что разработка ведется "каждый в свою сторону" " - не понял. Если есть готовая функция - ты ее заюзаешь или будешь писать новую не думая? Конечно заюзаешь старую (чуть подпилив)!
Вопрос: как ее по-человечески найти?

(8) Учи фреймворк

(28) Приведи пример такой функции.

Мне только одна приходит на ум, получение ставки НДС числом по значению перечисления. Сидит она в модуле УчетНДС. Какого рода документацию на это, ты бы хотел придумать?

У нас нетиповая. Пример:

модуль "Общие функции".
"Функция ОпределитьСписокПодчиненныхДоговоров(Договор)"

лежит в модуле "ОбщиеФункции". При этом есть несколько кусков кода, где вместо этой ф-и напилено то, что возвращает тот же самый результат. А можно было всего лишь использовать готовое.

Че то вспомнилось...    

Я придумал средство от выпадания волос. Волосы почему падают? Потому, что свисают вниз. А надо взять палочку и поставить ее на голову, чтобы волосы вились вокруг нее, как плющ. Они вьются вверх, а вверх падать невозможно, вот! Это мое собственное изобретение! Можешь использовать его, если хочешь!

       Белый Рыцарь Л.Кэрролла — Алисе

Либо люди просто не думая писали что-то новое ( = хорошо забытое старое), либо была попытка найти, не увенчавшаяся успехом.

по ценности примерно подобное рацпредложение.

(34)
Что же делать?

Забить, т.к. времени на внедрения подобной фигни ты потратишь больше чем она тебе сэкономит.

(35) распилить помойку под названием "Общие функции" на нормальные модули.

И чо за название для функции такое "Определить...." ? В типовых тоже самое. Что программа должна определять? Ясен пень никто прохавать не может что она делает.

*то же самое

Офф: нашел ф-ю

Функция обБольшаяДата() Экспорт
   Возврат('21000101');
КонецФункции

вот что это ? :)

В общем итоге все свелось к РасПилу модулей, на что тоже уйдет тонна времени(

Mort, выложи плз скрин своей системы учета функций

Ещё актуально?

(0)Можешь взять любой древообразный текстовый редактор и каждая ветка - процедура.

Это если только текст.

Если нужно рисовать дерево блок-схем, можешь посмотреть у меня в демо версии, как организованы вложенные блок схемы алгоритмов.
Демка  лежит здесь http://www.forum.optimasoft.info/viewtopic.php?f=6&t=44

Любой древовидный редактор позволит искать по словам.

Посмотри MyNotesKeeper.

(44, 45) Смысл в том, чтобы не только я мог просматривать и модифицировать эти данные, а еще и другие разработчики
(42) Ага

http://s2.ipicture.ru/uploads/20120927/NjznuYyF.png

(0) не изобретай волосопедов http://v8.1c.ru/model/