Legacy-code monoliths are one of these challenges which lead often to controversy discussions and questions like:
In this post I’d like to describe a way how to create the first code-sketch which could lead to an insight into the possibilities to tackle the beast step by step. Weiterlesen
Writing code to sketch the first core feature of an application could lead to a point where the next feature has to be realized roughly, too – just because of trivial dependencies. The code-base grows and when you are unlucky the overview of the sketches gets lost. However keeping the code-base clean and open for the future has to be a goal and can be achieved by applying the SOLID principles. Weiterlesen
Writing code that uses external APIs is not trivial and testing it neither. This post describes how to drive code around external APIs initially and is the second part of How to drive code by sketching it. The test-approach is only one of a couple of possibilities and used just to outline how to drive code via Quick-Fix of an IDE like eclipse. Weiterlesen
Actually, there are numerous of ways to sketch software or pieces of it. Drawing with a pen on a paper or on a white-board, using an UML tool et cetera. The goal is just to get things simplified and get an abstract view of it to find the core issues. With the introduction of Test-driven Development (TDD) a new way appeared end of the 90ties. TDD is controversially discussed and I don’t want to dig into the pros and cons of this approach. Rather I’d like to pick up one aspect of this methodology: drive code and design by coding.
Weiterlesen
the data backyard 