오늘 TIL 3줄 요약

리팩터링 을 상시적으로 하자!

테스트 코드도 프로그램의 일부다.

이름을 잘짓자.

TIL (Today I Learned) 날짜

2022.04.03

오늘 읽은 범위

7장 코딩하는 동안

책에서 기억하고 싶은 내용을 써보세요.

1. 테스트는 버그를 찾는 작업이 아니다. 여러분의 코드에 대한 피드백을 받는 작업이다.(p.274)

2. 설계 측면에서, API나 결합 측면에서 등 다양한 피드백을 받을수 있다. 이 말인즉슨 테스트의 긍정적인 효과는 대부분 테스트를 수행할 때나타나는 것이 아니라, 테스트에 대하여 생각할 때 그리고 테스트를 작성할때 나타난다는 것이다.(p.275)

3. 여러분의 뇌가 정리를 좀 할 수 있도록 약간의 시간과 공간을 확보하라. 코드에 대해 생각하지 말고 키보드에서 떨어져서 잠깐 머리를 비운 채로 할 수 있는 일을 하라. 산책을 하고 점심을 먹고 다른 사람과 수다를 떨어라. 아예 하룻밤 자면서 생각해 봐도 된다. 생각이 저절로 여러분의 뇌 층층이 스며들도록 놔둬라. 억지로 쑤셔넣을 수는 없다. 언젠가는 다시 생각이 의식의 영역으로 올라와서 ‘아하!’하는 순간이 찾아올 것이다.( p.278 )

4. 파충류와 이야기 하는법 ( 코딩할때 안될때 기억하면 좋을듯해서.. )( p.278 )

5. 꺼림칙했던 느낌이 코딩 도중에 갑자기 명확한 문제로 구체화되면 즉각 해결하라. 실험을 끝마쳤는데도 여전히 불안한 마음이 들면 다시 처음부터 시작하라. 첫 단계는 산책과 수다, 그리고 휴식이다.( p.280 )

6. 1.포스트잇에 “프로토타이핑 중”이라고 써서 모니터 옆에 붙여라. 2. 프로토타이핑은 원래 실패한다고 자신에게 상기시켜라. 실패하지 않더라도 프로토타입은 버리는 것이라는 점도 함께 상기시켜야 한다. 프로토타 이핑으로 손해 볼 일은 없다. 3. 텅 빈 에디터 화면에 여러분이 배우고 싶은 것 혹은 하고 싶은 것을 한 문장의 주석으로 표현해 보라. 4. 코딩을 시작하라.( p.280 )

7. 다른 루틴을 호출할 때도 문서화된 동작에만 의존하라. 어떤 이유로든 그럴 수 없다면 추측을 문서로 상세히 남겨라.p285

8. Tip 62 우연에 맡기는 프로그래밍을 하지 말라.

   ex) 사용자의 언어가 언제나 한국어 이거나 영어 일꺼라고 가정. ( 우연 )

9. 의도적으로 프로그래밍하기 ( 내용 전부 )(p.288 )

10. 대문자 O 표기법 (p.292 ,p.294)

11. 어떤 정렬 루틴이 원소 n개를 정렬하는 데 O(n 2 ) 시간이 걸린다고 말할 때, 이는 그저 최악의 경우에 걸리는 시간이 n의 제곱에 비례하여 늘어난다고 얘기하는 것이다 원소 수가 두 배로 늘어나면 걸리는 시간은 대략 네 배가 된다.

    ( p.292 )

12. ‘성급한 최적화 premature optimization ’ 9 를 조심하라. 언제나 어떤 알고리 즘을 개선하느라 여러분의 귀중한 시간을 투자하기 전에 그 알고리즘이 정말로 병목인지 먼저 확인하는 것이 좋다.( p.298 )

13. 소프트 웨어 개발을 정원가꾸기에 빗대서 설명하는것.( p.301 )

14. 소프트 웨어 개발을 정원가꾸기 와 메타포 에 빗대서 설명하는것.( p.301 )

15. 소프트 웨어 개발을 정원가꾸기 와 건물 건축 에 빗대서 설명하는것.( p.301 )

16. 리팩터링은 그런 게 아니라 잡초 제거나 갈퀴질처럼 위험하지 않은 작은 단계들을 밟는 일상 활동이다. 무질서하게 대규모로 코드를 다시 쓰는 것이 아니라, 정확한 목적을 가지고 정밀하게 접근하는 활동 이다. 그래서 코드를 바꾸기 쉽게 유지하는 것이다.( p.302 )

17. 리팩터링은 언제 하는가? 리팩터링은 여러분이 무언가를 알게 되었을 때 한다. 여러분이 작년이나 어제, 심지어 10분 전과 비교해서 더 많이 알게 되었다면, 리팩터링을 한다. 어쩌면 코드가 더는 잘 맞지 않아서 장애물에 부딪혔을 때, 두 가지가 사실은 하나로 합쳐져 있어야 한다는 것을 발견했을 때, 무엇이든 ‘잘못’되었다는 생각이 들 때가 있을 것이다. 주저하지 말고 변경하라. 언제나 바로 지금이 최적기다. 코드를 리팩터링할 이유는 아주 많다.( p.302 )

18. 중복 , 직교적이지 않은 설계, 더이상 유효하지 않은 지식( 코드는 지금 상황에서 뒤떨어지지 않아야한다 ), 사용사례(꼭 필요하지 않은 기능), 성능,테스트 통과 리팩토링 해야할 이유 ( p.302 )

19. 리팩터링이 필요한 코드를 일종의 ‘종양’이라고 생각하자.( p.304 )

20. Tip 65 일찍 리팩터링하고, 자주 리팩터링하라.( p.304 )

21. 리팩토링 하는 몇가지 방법에대한 조언 ( p.305 )

22. Tip 66 테스트는 버그를 찾기 위한 것이 아니다.( p.307 )

23. 테스트를 먼저 생각하는 것의 이점이 이렇게 많다 보니 아예 테스트를 먼저 작성하자고 주장하는 프로그래밍 유파도 있다. 그들은 ‘테스트 주도 개발 test- driven development, TDD ’이라고 부르는 기법을 사용한다. Tdd기본주기 ( p.310 )

24. 동일한 테스트를 코드 수정 후 다시 돌려보는 것을 회귀 테스트 regression testing 라고 한다.( p.315 )

25. Tip 70 여러분의 소프트웨어를 테스트하라. 그러지 않으면 사용자가 테스트하게 된다. 명심하라. 테스트는 프로그래밍의 일부다. 다른 사람이나 다른 부서에 떠넘길 수 있는 것이 아니다.( p.320 )

26. 나머지 90%의 내용( p.331 )

27. 코드의 복잡성은 공격 매개체 attack vector 를 유발한다.( p.333 )

28. 입력 데이터는 공격 매개체다.( p.333 )

29. 인증을 요구하는 서비스도 공격 매개체다 인증 받은 사용자의 수를 언제나 최소로 유지하라. 쓰이지 않거나, 오래되 고, 유효하지 않은 사용자나 서비스를 정리하라.( p.334 )

30. 인증이 없는 서비스는 공격 매개체다 최근 데이터가 공개적으로 유출된 사고 중 상당수가 개발자가 실수로 데이터를 인증 없이 누구나 접근할 수 있는 클라우드 저장소에 두었기 때문에 발생했다.( p.334 )

31. Tip 72 단순함을 유지하고 공격 표면을 최소화하라.( p.335 )

32. Tip 73 보안 패치를 신속히 적용하라.( p.338 )

33. 이 팁은 인터넷에 연결된 모든 장비에 해당한다. 전화, 자동차, 가전, 개인 노트북, 개발용 컴퓨터, 빌드 장비, 실제 서비스용 서버, 컨테이너 이미지 등 모든 것을 업데이트하라. 꼭 업데이트를 해야 하나 싶은 생각이 든다면, 지금까지 발생한 데이터 유출 사고 중 가장 큰 사고는 업데이트를 하지 않은 시스템 때문에 발생했다는 사실만 기억하기 바란다. 여러분에게 이런 사고가 터지지 않게 하라.( p.338 )

34. 다른 이유 없이 일정 기간이 지났다는 이유만으로 사용자에게 비밀번호를 바꾸라고 요구 하지 말라. 데이터 유출 사고가 발생한 경우 같이 합당한 이유가 있을 때만 비밀번호 변경을 요구해야 한다.( p.339 )

35. 상식 대 암호 암호학 cryptography 에 있어서는 여러분의 상식이 맞지 않을 수 있다는 점을 명심해야 한다. 암호화에 있어서 첫 번째 규칙이자 가장 중요한 규칙은 절대 직접 만들지 말라는 것이다. 30 비밀번호처럼 간단한 것마저도 일반적인 관행이 틀렸을 수 있다.(338쪽의 “잘못된 비밀번호 사례” 상자를 보라.) ( p.339 )

36. 이름이란 게 무슨 의미가 있나? 32 프로그래밍에서는 이름이 “모든 것!”이다.( p.341 )

37. Tip 74 이름을 잘 지어라. 필요하면 이름을 바꿔라.( p.347 )
    

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

코딩이 안될때나 막히는 부분이 있을때 이장의 내용을 다시 보거나 생각해보면 좋을거같다.

그만큼 기억하고 싶은 내용이많아 졋다..

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

1. 메타포 ?

오늘 읽은 다른사람의 TIL

newywg 님의 TIL (https://nomadcoders.co/community/thread/4151)