추운남자

오랜 만에 윈도우 10 에서 11로  재설치 하니 변경된 환경들이 많이 낯설다. 

그 중에 키보드 관련해서 난 fn 키들을 많이 사용해서 , Fn Lock 를 Default 로 사용하고 있었는데 fn lock 이 

안되는 것이다. 검색을 해도 도통 관련 내용이 나오지 않았다. 

그 와중에 혹시나 싶어서 블루투스 키보드 드라이버를 설치하니 정상적으로 fn lock 이 되었다.

추가로 LED 가 없어서 Caps Lock 이 걸려있는지 모를 때도 있는데, 아이콘으로 알려주니 좋다. 

참고로 노트북 본체 키보드에서는 BIOS 에서 변경해줘야 한다. 

오늘 TIL 3줄 요약

• 클래스는 작아야 한다. 
• 변경하기 쉬운 클래스

TIL (Today I Learned) 날짜

  2022. 05.10 ~ 11

오늘 읽은 범위

 10장 클래스 

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

• 의도가 드러나는 이름을 사용하면 코드 이해와 변경이 쉬워진다. 
• 그릇된 정보를 피하라 
• 발음하기 쉬운 이름을 사용하라 
• 검색하기 쉬운 이름을 사용하라
• 클래스 이름 : 명사(구), 메소드이름: 동사(구)
• 의미있는 맥락은 추가 , 불필요한 맥락은 없앤다. 

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

• 클래스를 만들 때 첫번째 규칙은 크기다. 클래스는 작아야 한다. 두번째 규칙도 크기다. 더 작아야 한다. 
• 단일 책임 원칙은 클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다는 원칙이다. SRP는 '책임'이라는 개념을 정의하며 적적한 클래스 크기를 제시한다. 클래스는 책임, 즉 변경할 이유가 하나여야 한다는 의미다.
• 소프트웨어를 돌아가게 만드는 활동과 소프트웨어를 깨끗하게 만드는 활동은 완전히 별개다. 깨끗하고 체계적인 소프트웨어보다 돌아가는 소프트웨어에 초점을 맞춘다. 전적으로 올바른 태도다. 문제는 우리들 대다수가 프로그램이 돌아가면 일이 끝났다고 여기는 데 있다. 
• 규모가 어느 수즌에 이르는 시스템은 논리가 많고도 복잡하다. 이런 복잡성을 다루려면 체계적인 정리가 필수다. 그래야 개발자가 무엇이 어디에 있는지 쉽게 찾는다. 그래야 직접 영향이 미치는 컴포넌트만 이해해도 충분하다. 큼직한 다목적 클래스 몇 개로 이뤄진 시스템은 당장 알 필요가 없는 사실까지 들이밀어 독자를 방해한다.  
• 일반적으로 메서드가 변수를 더 많이 사용할수록 메서드와 클래스는응집도가 더 높다. 모든 인슨턴스 변수를 메서드마다 사용하는 클래스는 응집도가 가장 높다. 

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

• 특별히 없다. 

오늘 읽은 다른사람의 TIL

오늘 TIL 3줄 요약

• 경계 살피고 익히기 ( 학습 테스트 )
• 깨끗한 테스트 코드 유지하기 
• F.I.R.S.T

TIL (Today I Learned) 날짜

2022. 05.07

오늘 읽은 범위

8장 경계 , 9장 단위 테스트

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

• 우리쪽 코드를 작성해 외부 코드를 호출하는 대신 먼저 간단한 테스트 케이스를 작성해 외부 코드를 익히면 어떨까? 이를 학습테스트라 부른다. 학습 테스트에 드는 비용은 없다. 어쨋든 API를 배워야 하므로...., 오히려 필요한 지식만 확보하는 손쉬운 방법이다. 학습 테스트는 공짜 이상이다. 투자하는 노력보다 얻는 성과가 더 크다. 패키지 새 버전이 나온다면 학습 테스트를 돌려 차이가 있는지 확인한다. 
• 1) 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 2) 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 3) 현재 실패하는 테스트를 통과할 정도록만 실제 코드를 작성한다.   
• 테스트 코드를 깨끗하게 유지하지 않으면 결국은 잃어버린다. 그리고 테스트 케이스가 없으면 실제 코드를 유연하게 만드는 버팀목도 사라진다. 맞다, 제대로 읽었다. 코드에 유연성, 유지보수성, 재사용성을 제고항는 버팀목이 바로 단위 테스트다. 이유는 단순하다. 테스트 케이스가 있으면 변경이 두렵지 않으니까! 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다. 아키텍처가 아무리 유연하더라도, 설계를 아무리 잘 나눴더라도 , 테스트 케이스가 없으면 개발자는 변경을 주저한다. 버그가 숨어들까 두렵기 때문이다. 
• F.I.R.S.T 깨끗한 테스트는  다음 다섯 가지 규칙을 따르는데, 각 규칙에서 첫 글자를 따오면 FIRST가 된다. 빠르게 , 독립적으로 , 반복가능하게 , 자가 검증하는, 적시에 

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

• 경계에서는 다른 라이브러리를 사용할 때 보편적으로 생각해던 테스트를 하고 , 적용했던 과정을 테스트 케이스를 사용해서 익히고 추후 버전업이 되더라고 그대로 적용할 수 있다는 사실에 고무되었다. 
• 단위테스트는 그동안 익히 많이 들었고 이미 시행도 많이 되고 있다. 일정이 촉박하다거나 아니면 테스트 하기가 힘들어서 , 레거시 코드여서 테스트 케이스가 많이 무식되고는 하는데 일단 써보니 도움이 되는 것 같다. 적용함에 있어서 많은 어려움이 있겠지만 남들이 좋다고 강조하는 것을 나도 적용하여 도움을 받아보자. 

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

• 특별히 없다. 

오늘 읽은 다른사람의 TIL

오늘 TIL 3줄 요약

• 오류 코드보다 예외를 사용하라. 
• Try-Catch-Finally 문부터 작성하라. 
• null을 반환하지 마라 

TIL (Today I Learned) 날짜

2022. 05.06

오늘 읽은 범위

 7장 오류 처리 

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

• 위와 같은 방법을 사용하면 호출자 코드가 복잡해진다. 함수를 호출한 즉시 오류를 확인해야 하기 때문이다. 불해이도 이 단계는 잊어버리기 쉽다. 그래서 오류가 발생하면 예외를 던지는 편이 낫다. 그러면 호출자 코드가 더 깔끔해진다. 노리가 오류 처리 코드와 뒤썩이지 않으니까.
• 코드가 예외를 던지므로 이제는 테스트가 성공한다. 이 시점에서 리팩터링이 가능하다. catch 블록에서 예외 유형을 좁혀 실제로 FileInputStream  생성자가 던지는 FileNotFoundException을 잡아낸다. 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하는 방법을 권장한다. 그럼녀 자연스럽게 try 블록의 트랜잭션 범위부터 구현하게 되므로 범위 내에서 트랜잭션 본질을 유지하기 쉬워진다.  
• 위 코드는 null 확인이 누락된 문제라 말하기 쉽다. 하지만 실상은 null 확인이 너무 많아 문제다. 메서드에서 null을 반환하고픈 유혹이 든다면 그 대신 예외를 던지거나 특수 사례 객체를 반환한다. 
• 깨끗한 코드는 일기도 좋아야 하지만 안정성도 높아야 한다. 이 둘은 상충하는 목표가 아니다. 오류처리를 프로그램 논리와 분리해 독자적인 사안으로 고려하면 튼튼하고 깨끗한 코드를 작성할 수 있다

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

• 절차지향 프로그래밍과 다르게 OOP 에서는 좀 더 배워야 될 개념이 들이 많은 것 같다. throws 를 던져 에외 처리를 하는 경우가 그것인데 , 가독성을 높이기 위해서 논리 로직과 에러 로직을 분리할 수 있다. 가독성을 높일 수 있는 여러 케이스를 스터디해서 적용하면 좋을 것 같다. 

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

• 특별히 없다. 

오늘 읽은 다른사람의 TIL

오늘 TIL 3줄 요약

• 자료를 세세하게 공개하기 보다는 추상적인 개념으로 표현하는 편이 좋다. 
• 객체와 자료구조는 근본적으로 양분된다. 
• 디미터 법칙은 잘 알려진 휴리스틱으로, 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙이다. 

TIL (Today I Learned) 날짜

2022. 05.03

오늘 읽은 범위

 6장 객체와 자료구조 

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

• 변수 사이에 함수라는 계층을 넣는다고 구현이 저절로 감춰지지는 않는다. 구현을 감추려면 추상화가 필요하다. 그저 조회 함수와 설정 함수로 변수를 다룬다고 클래스가 되지는 않는다. 그보다는 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스다. 
• 객체는 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개한다. 자료구조는 자료를 그대로 공개하면 별다른 함함수는 제공하지 않는다. .. 반면 새함수를 추가하고 싶다면 도형 클래스 전부를 고쳐야 한다.  
• 복잡한 시스템을 짜다 보면 새로운 함수가 아니라 새로운 자료 타입 필요한 경우가 생긴다. 이때는 클래스와 객체 지향 기법이 가장 적합하다. 반면, 새로운 자료타입이 아니라 새로운 함수가 필요한 경우도 생긴다. 이때는 절차적인 코드와 자료구조가 좀 더 적합하다. 
• 시스템을 구현할 때, 새로운 잘 타입을 추가하는 유연성이 필요하면 객체가 더 적합하다. 다른 경우로 새로운 동작을 추가하는 유연성이 필요하면 자료 구조와 절차적인 코드가 더 적합하다. 우수한 소프트웨어 개발자는 편견없이 이 사실을 이해해 직면한 문제에 최적인 해결책을 선택한다. 

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

• 이 장은 객체 지향의 자세한 설명보다는 , 객체일 때 내부구조의 은닉과 , 절차지향과 객체지향을 이해함으로서 적절하게 사용을 권고하고 있다. 

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

• 내용을 100% 이해는 하지 못한 것 같다. 좀 더 읽어봐야 겠다. 

오늘 읽은 다른사람의 TIL

오늘 TIL 3줄 요약

• 오늘 구현한 기능이 다음 버전에서 바뀔 확률은 아주 높다. 
• 신문 기사처럼 작성하라
• 범위로 이뤄진 계층을 표현하기위해 우리는 코드를 들여쓴다. 

TIL (Today I Learned) 날짜

2022. 05.02

오늘 읽은 범위

 5장 형식 맞추기 

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

• 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다. 오랜 시간이 지나 원래 코드의 흔적을 더 이상 찾아보기 어려울 정도로 코드가 바뀌어도 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다. 
• 신문 기사처럼 작성하라 아주 좋은 신문 기사를 떠올려보라. ( 중략 ) 소스 파일도 신문 기상와 비슷하게 작성한다. 이름은 간단하면서도 설명이 가능하게 짓는다. 이름만 보고도 올바른 모듈을 살펴보고 있는지 아닌지를 판단할 정도로 신경써서 짓는다. 
• 함수 이름과 이어지는 괄호 사이에는 공백을 넣지 않는다. 
• 승수 사이는 공백이 없다. 
• 프로그래머는 이런 들여쓰기 체계에 크게 의존한다. 왼쪽으로 코드를 맞춰 코드가 속하는 범위를 시각적으로 표현한다. 그러면 이 범위에서 저 범위로 재빨리 이동하기 쉬워진다. 

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

• 결국에는 가독성에 대한 애기를 여러 장에 걸쳐서 하고 있는 것 같다. 변수 이름 클래스 이름도 중요하지만 ,형식에 맞게 코드를 작성해야 읽는 사람이 잘 읽힌다. 타자는 자기가 이해해야 잘 한다고 한다. 

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

• 특별히 없다. 

오늘 읽은 다른사람의 TIL

오늘 TIL 3줄 요약

• 함수나 변수로 표현할 수 있다면 주석을 달지 마라 
• 나쁜 주석 
• ToDo 주석 

</예시>

TIL (Today I Learned) 날짜

2022. 04.28

오늘 읽은 범위

 4장 주석 

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

• 나쁜 주석 : 대다수 주석이 이 범주에 속한다. 일반저긍로 대다수 주석은 허술한 코드를 지탱하거나, 엉성한 코드를 변명하거나, 미숙한 결정을 합리화하는 등 프로그래머가 주절거리는 독백에서 크게 벗어나지 못한다. 
• 있으나 마나 한 주석 : 때때로 있으나 마나 한 주석을 접한다. 쉽게 말해, 너무 당연한 사실을 언급하며 새로운 정보를 제공하지 못하는 주석이다. 
• 의무적으로 다는 주석 : 모든 함수에 javadocs를 달거나 모든 변수에 주석을 달아야 한다는 규칙은 어리석기 그지없다. 이런 주석은 코들르 복잡하게 만들며, 거짓마을 퍼뜨리고 혼동과 무질서를 초래한다. 
• 함수나 변수로 표현할 수 있다면 주석을 달지마라. 

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

• 어지간하면 주석을 달지 말자. 단 어떠한 방법으로도 코드로 표현이 되지 않는 경우에만 조금씩 사용하자. 

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

• 특별히 없다. 

오늘 읽은 다른사람의 TIL

• https://nomadcoders.co/community/thread/4793

오늘 TIL 3줄 요약

• 작게 만들어라 
• 서술적인 이름을 사용하라!
• 함수를 어떻게 짜죠? - 처음부타 탁 짜내지 않는다. 그게 가능한 사람은 없으리라. 

</예시>

TIL (Today I Learned) 날짜

2022. 04.27

오늘 읽은 범위

 3장. 함수

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

• 내가 함수를 짤 때도 마찬가지다. 처음에는 길고 복잡하다. 들여쓰기 단게도 많고 중복된 루프도 많다. 인수 목록도 아주 길다. 이름은 즉흥적이고 코드는 중복된다. 하지만 나느 그 서투른 코드를 빠짐없이 테스트하는 단위 테스트 케이스도 만든다. 
• 함수를 만드는 첫째 규칙은 '작게'!다. 
• 한가지만 해라. 한가지를 해야 하고, 한 가지를 잘 해야 한다. 그 한가지만을 잘 해야한다. 
• 서술적인 이름을 사용하라  이름은 길어도 괜찮다. 겁먹을 필요없다. 길고 서술적인 이름이 짧고 어려운 이름보다 좋다. 

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

• 구현하다 보면 , 막 짜기 쉬운데 , 계속 코드 노려면서 테스트 하면서 
• 합치고 줄이고 다듬는 노력이 필요하다. 처음부터 나오지 않았다. 

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

오늘 읽은 다른사람의 TIL

• https://nomadcoders.co/community/thread/4726

내용이 자세해서 뽑아보았습니다. 

https://nomadcoders.co/community/thread/4546

공부를 실제로 열심히 한것 같네요. 

https://nomadcoders.co/community/thread/4527

요 부분은 찾아보기 계속 찾아다니다가 마음에 들어서 뽑았습니다. 

https://nomadcoders.co/community/thread/4470

오늘 TIL 3줄 요약

• 의도를 분명히 밝혀라
• 발음하기 쉬운 이름을 사용하라 
• 자신의 기억력을 자랑하지 마라 ..

</예시>

TIL (Today I Learned) 날짜

  2022. 04. 24

오늘 읽은 범위

 2장. 의미있는 이름 

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

• 의도가 드러나는 이름을 사용하면 코드 이해와 변경이 쉬워진다. 
• 그릇된 정보를 피하라 
• 발음하기 쉬운 이름을 사용하라 
• 검색하기 쉬운 이름을 사용하라
• 클래스 이름 : 명사(구), 메소드이름: 동사(구)
• 의미있는 맥락은 추가 , 불필요한 맥락은 없앤다. 

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

• 사실 로직 구현도 바빠죽겠는데 , 이름까지 잘 만들라니
• 그런데 이것을 추후에 유지보수 할 때 진가가 드러나는 것 같다. 
• 책에 나와있는 내용을 너무 그대로 암기하려 하지말고 제일 중요한 것은
• 싸그리 구현 내용을 잊어버리고 다시 봤을 때 , 제대로 이해가 
• 되는지가 중요한 것 같다. 

</예시>

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

• 단위 테스트? 인수 테스트?

오늘 읽은 다른사람의 TIL

• https://nomadcoders.co/community/thread/4462