L14: Avoiding the "Bad"

Question 1

Code, design, and architecture smells (or anti-patterns)

Answer 1

Bad software is describe sing the methaphor of smells
- Code smells: any property of code that can hint at deeper problems
- Design smells: design structures that violate a design principle
- Architecture smells: undesired structures in the software architecture

Just symptoms, not defects by themselves!
Related, subjective, language/methodology-dependent, and overlapping

Question 2

Technical debt (or design/code debt)

Answer 2

Metaphor for future rework needed due to poor software design/code
- Describes impact of poor software design (e.g. software smells)
- Can get worse over time (accumulates interest)
- Increases costs of implementing future changes (or makes future changes necessary)

Essentially:
- Long-term negative consequences of poor design…
- …that was motivated by short-term benefits

Question 3

What causes technical debt?

Answer 3

• Deadlines
• Inappropriate planning
• Lack of well-defined processes
• Not adopting best practices
• Experience, knowledge, …
• Outdated/incomplete documentation

Question 4

What are the consequences to technical debt?

Answer 4

• Low software quality
• Delays
• Low maintainability
• Rework
• Financial loss
• Dissatisfaction (team, stakeholders, …)
• Inadequate document

Question 5

Refactoring

Answer 5

• Changes to a software’s internal structure…
• …to make it easier to comprehend, maintain, and modify …
• … without changing its (observable) behavior (so, fixing a bug, is not a refactoring, since it changes behavior)

Question 6

Large and long/complex method

Answer 6

Properly abstracted methods/classes start small but often grow over time

Developers add new concerns to existing ones (i.e. do not separate concerns properly)
- Longer methods/classes are harder to understand
- May hide duplicate code and/or specific behavior

Closely related to “Spaghetti code” (code without a structure that is hard to maintain and comprehend)

Question 7

What to do about the blob or god class?

Answer 7

• Separate concerns
• Extract classes/methods
• Introduce inheritance
• Separate into MVC
• Define interfaces

Question 7

God class or the blob

Answer 7

A large (previous smell) class acts as controller of many data classes

Defines all functionalities and decisions (violating: separation of concerns, cohesion and coupling, single responsibility principle)

Question 8

Long parameter list and what to do?

Answer 8

• Methods with too “many” parameters
• Merging different algorithms and controlling them via parameters
• Can be challenging to understand and use

So what to do?
- Check whether parameters are needed
- Define reference types for passing data

Question 9

Alternative class with different interface

Answer 9

Exchangeable classes provide different interfaces (public methods) (remember strategy design pattern)

Makes it
- Harder to understand code
- Impossible to exchange behavior

Question 10

What to do about long parameter list and alternative class with different interface?

Answer 10

• Following established design patterns and principles (strategy, template, abstract data types, …)
• Renaming methods, changing parameters, …
• Defining an inheritance hierarchy
• Contracts, documentation, and communication

Question 11

Shotgun surgery and what to do?

Answer 11

• Modifying any code requires changes to various classes
• Violating single-responsibility as well as cohesion/coupling

What to do?
- Define proper software design
- Move methods or parameters
- Redefine units

Question 12

Code clones or duplicate code

Answer 12

Code that occurs multiple times at different locations
- Copy and paste programming
- Clone and own development

Often used due to simplicity

Can lead to maintenance issues…
- Fixing bugs or updating each location
- Additional code
- Not properly separated

Question 13

The problems of dealing with duplicated code

Answer 13

In the small (copy and paste):
- Identifying clones in a system (type 1 to type 4 clones)
- Deciding where to move a clone
- Duplicated abstractions
- Dealing with variations (e.g. template method)

In the large (clone and own):
- Merging long-living clones variants
- Redundant/new testing and features
- Identifying commonality and variations
- Expensive and time consuming

Question 14

Dead code

Answer 14

Code that is (no longer) used or executed
- Unused variable
- Condition that is never reached
- Class that is not relevant/used anymore

Extensive support in modern IDEs (as far as identifiable considering the given visibility)

Question 15

Feature envy

Answer 15

Methods rely more on data/behavior of another object than their own (often arises when moving data to different classes, but not the methods)

Careful with some design patterns (e.g. strategy)
- Purposefully separate data and behavior
- Aim to achieve a specific goal via this strategy (e.g. changing behavior dynamically)
- Still couple data and behavior (and keep it decoupled from other units)

Question 16

Cyclic hierarchy or dependencies

Answer 16

• A supertype relies on one of its subtypes (inheritance)
• 2 or more abstraction depend on each other, directly or indirectly

Question 17

Definitions of the following software smells: Middle man, Missing abstraction, Poltergeist

Answer 17

• Middle man: A class has only the purpose of delegating to one other class
• Missing abstraction: Using data clumps or strings instead of an abstract/reference type
• Poltergeist: Classes with limited responsibility and short-lived objects (garbage collected right after creation)

Question 18

Software smells recap

Answer 18

• Based on experiences and design principles
• Subjective and interpretable
• Perceived as symptoms for quality problems
• Not defects