Therefore DSM solutions
should be applied whenever it is possible. DSM is not a solution for every development
situation though. We need to know what we are doing before we can
automate it. A DSM solution is therefore implausible when building an application
or a feature unlike anything developed earlier. It is something unique that we don??™t
know about. In such a situation we usually can only make prototypes and mock-up
applications and follow the trial-and-error method, hopefully in small, agile, and
iterative steps.
In reality, we don??™t often face such unique development situations. It is much
more likely that after coding some features we start to ?¬?nd similarities in the code
and patterns that seem to repeat. In such situations, developers usually agree that it
does not make sense to write all code character by character. For most developers,
it would then make sense to focus on just the unique functionality, the differences
between the various features and products, rather than wasting time and effort
reimplementing similar functionality again and again. Avoiding reinventing the
wheel is good advice for a single developer, but even more so if colleagues are
implementing almost identical code too.
In code-driven development, patterns can evolve into libraries, reusable components,
and services to be used.
Pages:
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54