Community

개발자 99% 커뮤니티에서 수다 떨어요!

← Go back
TIL 7장. 코딩하는 동안
#pragmatic
2년 전
450

오늘 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.