Skip to content

Instantly share code, notes, and snippets.

View alisalehi1380's full-sized avatar
😊
Always smile at problems

Ali Salehi alisalehi1380

😊
Always smile at problems
View GitHub Profile
@alisalehi1380
alisalehi1380 / working_effectively_with_legacy_code.md
Created October 8, 2024 07:47 — forked from jonnyjava/working_effectively_with_legacy_code.md
Working effectively with legacy code summary

WORKING EFFECTIVELY WITH LEGACY CODE

To me, legacy code is simply code without tests. I’ve gotten some grief for this definition. What do tests have to do with whether code is bad? To me, the answer is straightforward, and it is a point that I elaborate throughout the book: Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.

Chapter 1 Changing Software

Four Reasons to Change Software: For simplicity’s sake, let’s look at four primary reasons to change software.

# SETUP #
DOMAIN=example.com
PROJECT_REPO="git@github.com:example.com/app.git"
AMOUNT_KEEP_RELEASES=5
RELEASE_NAME=$(date +%s--%Y_%m_%d--%H_%M_%S)
RELEASES_DIRECTORY=~/$DOMAIN/releases
DEPLOYMENT_DIRECTORY=$RELEASES_DIRECTORY/$RELEASE_NAME
# stop script on error signal (-e) and undefined variables (-u)