TIL (Today I Learned) - Programmatic programming #7

Today's 3 Line Summary

2022.04.01~02

Chapter 7 While You Are Coding

Coding is not mechanical. There are decisions to be made every minute—decisions that require careful thought and judgment if the resulting program is to enjoy a long, accurate, and productive life.

First, stop what you’re doing.
Make doodles about the code you’re writing, or explain it to a coworker (preferably one who isn’t a programmer), or to your rubber duck
Write “I’m prototyping” on a sticky note, and stick it on the side ofyour screen.

As developers, we also work in minefields. There are hundreds of traps waiting to catch us each day. Remembering the soldier’s tale, we should be wary of drawing false conclusions.
Fred doesn’t know why the code is failing because he didn’t know why it worked in the first place.
Human beings are designed to see patterns and causes, even when it’s just a coincidence.
Don’t assume it, prove it.
Don’t code in the dark.
Don’t be a slave to history. Don’t let existing code dictate future code. All code can be replaced if it is no longer appropriate.
This decision may impact the project schedule. The assumption is that the impact will be less than the cost of not making the change.

Code needs to evolve; it’s not a static thing.
Rather than construction, software is more like gardening—it is more organic than concrete
In order to guarantee that the external behavior hasn’t changed, you need good, automated unit testing that validates the behavior of the code.
There’s no time like the present.
fail to refactor now, and there’ll be a far greater time investment to fix the problem down the road
Refactoring, as with most things, is easier to do while the issues are small, as an ongoing activity while coding.
Make sure you have good tests before you begin refactoring.
Manage the pain: if it hurts now, but is going to hurt even more later, you might as well get it over with.

We believe that the major benefits of testing happen when you think about and write the tests, not when you run them.
testing is vital feedback that guides your coding
By all means practice TDD. But, if you do, don’t forget to stop every now and then and look at the big picture.
When you can’t comprehend the whole problem, take small steps, one test at a time. However, this approach can mislead you, encouraging you to focus on and endlessly polish the easy problems while ignoring the real reason you’re coding.
Why do we go to all this trouble? Above all, we want to avoidcreating a “time bomb”—something that sits around unnoticedand blows up at an awkward moment later in the project.
A little forethought can go a long way toward minimizing maintenance costs and help-desk calls.

There are also code invariants, things that remain true about some piece of state when it’s passed through a function.
Our suggestion is that when a property-based test fails, find out what parameters it was passing to the test function, and then use those values to create a separate, regular, unit test.
a unit test is the first client of your API

It’s a big world out there, and most of it is connected. Whether it’s a bored kid on the other side of the planet, state-sponsored terrorism, criminal gangs, corporate espionage, or even a vengeful ex, they are out there and aiming for you.
Security through obscurity just doesn’t work.
The attack surface area of a system is the sum of all access points where an attacker can enter data, extract data, or invoke execution of a service.
Another key principle is to use the least amount of privilege for the shortest time you can get away with.
Don’t leave personally identifiable information, financial data,passwords, or other credentials in plain text, whether in adatabase or some other external file.
As we’ve said elsewhere, rely only on reliable things

What’s in a name? When we’re programming, the answer is “everything!”
This means that, whenever you create something, you need to pause and think “what is my motivation to create this?”
If you aren’t vigilant about updating names as you go,you can quickly descend into a nightmare much worse than meaningless names
If for some reason you can’t change the now-wrong name, then you’ve got a bigger problem: an ETC violation

Although there was a lot to read, it was a useful chapter because there were things to keep in mind when writing the programming.
Sometimes I can play the game better when I didn't play for about a week to a month. It is the same thing when writing the program.
It is important to test, but getting tired when testing many cases by manual. So, It seems important to write test code & test automation as much as possible.