#000#IT_Knowledge#020#Operation_Knowledge#020.00#Versioning#020.00 c#Proper_dividing_for_reusable_modules

Proper dividing for reusable modules

#Module #methodology

Audience

For who considered about what is proper dividing standard for making module

Overview

I make class for milvus. Because some features were not properly worked, So I had to create it.
After I create , I was stuck in
how to package it.

There is no relationship Basic RAG.py and new milvus.py initially.
But I have to import it. It is easy if just import it.
However if I import without thinking, some dependencies problem can occur.

From a function perspective, one function as one function
From the file perspective, when a problem occurs, log whether the problem is caused by a function using an external package or a problem that can be solved in the internal file.
These two methods are appropriate

The first step is to edit the class in such a way that it can be included.
The second step is to create a log function
The third step is to save only the existing independent function.

If the first step references an external package that is difficult to include, it will be handled separately.

Content

Here's the problem situation
First, you have external class files, then you have external independent function files
You put them into one external class file.
We reference the class in another file

The first step here is how to properly divide them for operational purposes, as mentioned above.
The proper standard for functions is that one function acts as a function, which maximizes re-use
A good criterion for a file is to be able to solve problems and manage classes within a single file. For example, if you have an external problem and you try to find it in an internal class file, you won't get the answer, so I think the class file should be clear about it. Is it an error in the file that used or an external package?

So to properly implement these concerns, there are two steps to take

1. Modify indepedent function to class function
2. Use a function to track it
3. Consider the dependencies and create a separate external standalone type

For step 1, modify the dependencies and parameters of the external independent function so that it can be used inside the class, as shown in the figure. Fortunately, in this case, all the packages used by the external independent function were in milvus_class, so we only needed to change the parameters. If the external independent function uses a module that is not used in the class file, and we want to migrate the external independent function into the class file, we will need to go through one more step.

For step 2, the traceback package traceback now edits the error log appropriately. For example, categorization now tells you whether the function is internal or external on try except, etc.

The final step is to create the entity_update_external function. The original entity_update has had dependencies added and parameters changed to allow it to be managed within a single file, so we're leaving it in its original form in case we want to use it independently in the future.

Conclusion

Consider the following steps when moving an external function into a class

Changing parameters and packages inside the external function class to make it dependent on the
Displaying error ranges with tracebak functions
Create a frame for future use of independent functions