오늘 TIL 3줄 요약

• Don't write code by Coincidence. Don’t assume it, prove and try it.

• Write test code, when you write code. Try to Unit test, Property-Based Test

• Whenever you create a name, you need to think of the reason.

TIL (Today I Learned) 날짜

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.

Topic 37. Listen to Your Lizard Brain

• 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 of your screen.

Topic 38. Programming by Coincidence

• 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.

Topic 39. Algorithm Speed

• the fastest one is not always the best for the job.

Topic 40. Refactoring

• Code needs to evolve; it’s not a static thing.

• Rather than construction, the 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.

Topic 41. Test to Code

• 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 avoid creating a “time bomb”—something that sits around unnoticed and 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.

Topic 42. Property-Based Testing

• 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

Topic 43. Stay Safe Out There

• 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 the 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 a database or some other external file.

• As we’ve said elsewhere, rely only on reliable things

Topic 44. Naming 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.