[Pragmatic Programmer] Chapter 7. While coding

DAY 15, 16 Today’s reading range: Chapter 7. While coding

? What do you want to remember from the book?

Programmers who do not actively think about their code are leaving programming to chance.

Listen to your inner reptile.

Let’s take a break from work and create a prototype.

Don't leave programming to chance.

When calling other routines, rely only on documented behavior. If this is not possible for any reason, document your guesses in detail.
Don't assume, prove.
Things to check 1. Can you explain the code in detail to other programmers? 2. Don’t create code you don’t know much about. 3. Make a plan and proceed based on it. 4. Lean on what you can trust. Don't depend on your family. 5. Keep records of your home. 6. Don't guess, try it out. 7. Set priorities. 8. Don't let existing code dominate future code. If it is not an appropriate code, you should be able to socialize at any time. Refactoring

Estimate the order of the algorithm used.

Pragmatic programmers estimate the resources their algorithms use every day: time, processor, memory, etc.
Algorithms are mostly not linear.
The capital O notation O(n) means that the maximum time it takes for this function to execute does not increase faster than n.

Use the code profiler to count the number of executions of each step as the algorithm runs, and then draw a graph of the number of executions by input size.
Beware of hasty optimization. If the input data is small, the time it takes to prepare the data may take longer.

Refactor early, refactor often.

SW development is an organic activity similar to gardening.
Refactoring is a systematic technique to reorganize existing code by changing its internal structure while maintaining its external behavior.
Advice on how to refactor 1. Do not refactor and add features at the same time. 2. Before you start refactoring, make sure you have solid tests in place. Run the test as often as you can. 3. Break the steps into small steps and work carefully. You need to work in small units, such as moving one field of a class to another class, splitting a method, or changing the name of a variable.

Testing is not about finding bugs.

We believe that the main benefits of testing come from thinking about tests and writing them, not from running them.
Tests are the first users of your code.
Test Driven Development TDD 1. Decide on one small feature you want to add. 2. Write a test that will pass when the feature is implemented. 3. Run the test. The other tests should pass and the test you just added should fail. 4. Write only the minimum amount of code that can pass a failing test. 5. Refactor the code.
Don't be a slave to TDD. ← Duplicate
Build it from end to end, not bottom up or top down.
Unit test = Test to see if the contract is followed. Add ad hoc tests to unit tests.

Test your assumptions with attribute-based tasks.

def order(warehouse, item, quantity):
if warehouse.in_stock(item, quantity):
warehouse.take_from_stock(item, quantity)
return ("완료", item, quantity)
else:
return ("재고 없음", item, quantity)

It allows you to focus on the situation in which the problem occurs.
Unit tests act as ‘rare tests’.

Pragmatic programmers have a healthy dose of paranoia.

Minimize your attack surface. Simple, small code is better. Never trust external data. Services without authentication can be called by anyone in the world, and DoS is possible. Always keep the number of authenticated users to a minimum. Debugging information is an attack vector. ▶ Keep it simple and minimize the attack surface.
Principle of least privilege: Grant the shortest possible privileges. All programs and all special privileged users on the system must operate with only the minimum privileges necessary to complete their tasks.
safe defaults
Encrypt sensitive information
Apply security updates

Give yourself a good name. Change the name if necessary.

Otherwise, every time a new person joins the team, you'll have to make a fuss and explain that getData actually writes data to a file.

? How do you feel about what you read today?

While reading this book, I felt like this chapter was the part that touched me the most and was worth remembering. I think this is because the part about writing test code overlaps with the part I am currently studying.

When I read about the incorrect password example, I thought it was the most surprising thing.

They said that a strict password policy actually lowers the level of security. Don't ask for specific information, such as what was your first pet's name, and don't ask users to change their passwords just because it's been a while and for no other reason.

So, this article made me think about whether the password policy used on most web sites is wrong. In my last project, I created something that encouraged password changes over time.

It is said that imposing such artificial restrictions will only help user account takeover by lowering the randomness and encouraging bad password habits.

❓ Anything you have questions about or something you don’t understand

The author of Robert Sedgwick and Donald Knuth's algorithm book has it in his library and recommends reading it, so I should read it when I get the chance.
Regarding the test code, I think it would be a good idea to study the content you are currently learning separately and look at it again!

http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788966261031