How to administer function modules, groubs, mehtods and classes

[rainer_hbenthal]

Hi,

how do you administer your functional objects? The developper who worked on them has knowledge about these objects, but often the others do not have a glue that there are objects already written which might be suitable for them.

How do you make these objects public to every developper and do you document these objects? Are there special tools on the market to build a kind of softwarelibrary or how is this organized in your company?

//Rainer

[rainer_hbenthal]

Hi,

how do you administer your functional objects? The developper who worked on them has knowledge about these objects, but often the others do not have a glue that there are objects already written which might be suitable for them.

How do you make these objects public to every developper and do you document these objects? Are there special tools on the market to build a kind of softwarelibrary or how is this organized in your company?

//Rainer

[Former Member]

Hello,

I have suggestions

1. Group the related objects which is FM, report, program under one package

So that when new \ existing developer see object list under that package they can able to see all related objects and use

suitable one.

2. We generally document function module (FM) and try to make all related FM under one function group, so that developer can see these in one glimpse

3. If possible rename related objects starting with suitable key word - so that all related are available in one search query

Thanks

[Former Member]

Documentation is there and supported, but since even SAP often doesn't document FM or classes/methods, it's easy to understand why programmers also omit the documentation. Of course, if you document, the programmers still have to read it. The where-used function is the tool I use most often to see if there is a function module, etc., that does something with the field or table that I'm looking at.