Among the major decisions prior to actual commencement of Software Development using MyCodeFactory, one has to be clear as to how the source generated would be used in future.
These are the major ways to look at it:
A. To use the generated code as a springboard (only once during start), develop business logic tightly coupled to it.
B. To keep the generated code loosely coupled with business logic such that it can be regenerated if necessary with minimal impact on business logic.
C. To keep the generated code so loosely coupled that iterative development of Models (and subsequent Code Generation) can be easily supported throughout the life cycle of the solution.
Any experienced professional would see very limited use of first scenario and would prefer to go for the other ways and prefer the third option.
And that is where this article wants to help by providing some directions for loose coupling required in the context of MyCodeFactory. In general most of the modern languages provide rich features like inheritance and/or splitting class code in more than one file (e.g., partial class in .net). One can take advantage of such features to keep Generated Code and Business Logic well separated. Of course this decision would be platform/language/solution specific.
1.
Clarity of Code Organization: There must be explicit, specific guidelines for the development & testing teams as to how the code would be organized.
For Development team, depending upon your platform/language, you may be able to keep generated code and business logic in different files/folders or areas within same file (this is not supported at present directly by MyCodeFactory but it would be possible to do that with a wrapper or utility or script in build/CI/CT workflow)
Similar approach is applicable for testing team for organization of generated tests, generated test data and manually created tests.
Practically, this would mean having uniformity in approach that is self evident. For example, if you decide to keep Generated Code in a base class, make sure that the file name has something obvious in its name like as suffix ‘BaseMCF’ (MCF as an indicator for MyCodeFactory Generated File)
2.
Documentation of change management process: When there is a change and new code is generated, how the new code should be incorporated to raise the solution to higher level.
Practically, this would mean clarity on deciding whether Development/Testing teams wait for next version of Generated Code or commence related work simultaneously.
Again this would be highly solution specific and also depend upon the lifecycle stage e.g., you may want to adopt different approach during support stage than development stage.