Building New Features

Another random thought:

When adding new features to code, you should always expect a constant level of work. If you’re thinking about adding a feature, think about what other cases of that feature may be added in the future.

For example, imagine you’re writing code for a game with a CPU. Let’s say at first, you want to create a CPU with a greedy behavior. You should write the code for this with an assumption that some time in the future, you’re going to want to create infinite types of CPU behavior.

The way you design this code should be such that adding the n-th CPU behavior should be little to no more work than adding the n-1-th CPU behavior.

To loosely put it into code, imagine this:

def cpu_turn(is_greedy):
	if is_greedy:
		take_all_from_pile()
	else:
		take_some_from_pile()

Now, let’s say the next day you want to add safe strategy for this CPU. Then your code may turn into this:

def cpu_turn(is_greedy, is_safe):
	if is_greedy:
		take_all_from_pile()
	elif is_safe:
		take_one_from_pile()
	else:
		take_some_from_pile()

Ideally, you want to reduce the need to duplicate this work each time. The more places you reference these flags, the more things you have to change. Things get even messier when strategies overlap / are interconnected, and then you have to change behavior 1 when adding beahvior n.

Instead, consider an option like this:

def cpu_turn(cpu_strategy):
	cpu_strategy.take_from_pile()

Now, regardless of what changes are made, we only have to be concerned about passing in the right strategy instead all the flags involved. Each strategy now becomes a separate piece of code that’s easily testable and interchangeable. Even better (and you should), you can wrap these strategies in an interface that ensures future developers implement new strategies correctly, or update the code in specific places if needed.