Подскажите если кто сталкивался, как нужно разрабатывать и сопровождать ФМ которым будут пользоваться ~5 программистов. ФМ планируется использовать в 60-70% отчетов, так как все они примерно одинаковые, все одинаково тяжелые и ошибки лезут до сих пор. Решили, что чтобы исключить исправления во всех отчетах лучше написать такой ФМ. ФМ уже существует, но сыроват, как лучше его сопровождать? Есть 2 варианта сопровождения:
Какой из них предпочтительней?
1. ФМ делает один разработчик, остальные только говорят что по их мнению не правильно работает с точки зрения их отчета. Отсюда сразу выплывают минусы: разработчик загружен, заболел, ушел в отпуск, в ФМ никто не разбирается или не хочет брать на себя это крест ) в результате простой...
2. Каждый ознакамливается с ТЗ для этого ФМ, разбирается с самим кодом ФМ и при необходимости вносит в него изменения как-то оповещая остальных о произведенных изменениях, например через документацию к ФМ-у + в устной форме. Тут минусом может быть как в басне про лебедя рака и щуку... но при желании конечно можно было бы правильно и четко построить работу...

ну и второй вопрос, стоит ли вообще идти по пути создания универсального ФМ?

ФМ сделать стоит.
Преимуществ масса, только
1. обсудить интерфейс сделать максимально удобным, чтобы в случае исправлений из интерфейса ничего не исключалось, добавлять можно не обязательными параметрами.
2. хорошие коментарии по внутреннему коду. Лучше пусть пишет один программер(обсуждение с другими ни кто не отменял), коментариев должно хватить, чтобы остальные в случае чего разобрались.

Еще как вариант если задачу можно разбить на несколько частей, можете написать несколько ФМ, потом внутри основного просто вызовете их в нужной последовательности.

ФМ сделать стоит.
Преимуществ масса, только
1. обсудить интерфейс сделать максимально удобным, чтобы в случае исправлений из интерфейса ничего не исключалось, добавлять можно не обязательными параметрами.
2. хорошие коментарии по внутреннему коду. Лучше пусть пишет один программер(обсуждение с другими ни кто не отменял), коментариев должно хватить, чтобы остальные в случае чего разобрались.

Еще как вариант если задачу можно разбить на несколько частей, можете написать несколько ФМ, потом внутри основного просто вызовете их в нужной последовательности.

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

Да и вообще - теория ведения разарботок довольна обширна, многообразна, тонны бумажной литературы, гигабайты электронной.


Данное решение не снимает проблем, озвученных в варианте для одного разарботчика, а только их усугубляет.
Зависит от степени универсальности, востребованности, потребляемых на эту универсальность ресурсов, времени(как на разработку, так и с точки зрения времени работы кода) и многого другого.

Ни фига себе ФМ. Пять нормальных разработчиков могут спокойно переписать какю-нибудь область учета, к примеру. Но чтоб один ФМ...

Посоветовал бы вынести в один общий ФМ базовую выборку. Сделать один раз (постараться сделать его максимально простым и понятным) и больше не трогать! А потом этот ФМ крутить в дргуих, которые будут принадлежать и правиться конкретными разработчиками. В них то уже и вести изменения под конкретные отчеты.

Согласен, только сделал бы это все на классах.
И один

Вы сами ответили на свой вопрос. Иначе под каждый отчет делать одинаковое ТЗ и при этом разные реализации разными людьми? Это сколько ж надо доп. ресурсов, чтобы все выверить хотя бы. Лучше наверняка убедиться 1 раз, что ФМ полностью адекватный.

Насчет того, кому лучше делать. Одному человеку намного проще донести замысел и намного проще проверить его реализацию. А когда заработает ФМ - НЕ ТРОГАТЬ, старый закон ))).

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

С другой стороны такой ФМ уменьшает кол-во техзаданий, разработок и т.д. Бывают ситуации, когда это не выгодно. Тогда надо на бумаге делать вид со всеми вытекающими...