개발새발 블로그

오늘 읽은 범위

• 9장: 단위테스트

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

• TDD법칙

1. 테스트 코드를 먼저 작성하고 실제 코드를 작성한다.

2. 컴파일은 통과하면서 실행이 실패하는 정도로 단위 테스트를 작성한다.

3. 현재 실패하는 테스트를 통과할 만큼만 실제 코드를 작성한다.

• 테스트 케이스가 있으면 안심하고 설계를 개선할 수 있다. 가독성을 생각하여 실제 코드 못지 않게 깨끗하게 짜야 한다.
• FIRST 규칙

1. FAST

  테스트는 빨라야한다

2. INDEPENDENT

  각 테스트는 서로 의존하면 안되며 순서에 상관없이 실행 가능해야 한다.

3. REPEATABLE

  테스트는 어떤 환경에서도 반복 가능해야한다,

4. SELF-VAILDATING

  테스트는 성공/실패 두가지로 결과를 내야한다.

5. TIMELY

  테스트는 실제 코드를 작성하기 직전에 구현한다. 테스트 코드를 나중에 작성하게 되면 테스트를 포기 할 수 있다.

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

• 현재 환경에서는 테스트 주도 개발을 하지않아 테스트 코드를 많이 작성해보지 않았다. 이번 챕터를 통해서 테스트 코드를 어떻게 작성할지 가닥을 잡았다.

오늘 읽은 범위

• 7장. 오류처리

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

• 오류 코드보다 예외를 사용하라.

오류 코드를 사용하면 함수를 호출하면 바로 오류를 체크해야한다.

그래서 try~catch문을 이용하여 예외를 던지도록 처리하는 것이 낫다.

• try~catch~finally문 부터 작성하라

try블록에서 코드를 실행하면 어떤 시점이든 에러 발생시 catch문으로 넘어갈 수 있다.

catch 블록은 프로그램 상태를 일관성 있게 유지해야한다. 그래서 try~catch~finally 문을 먼저 작성하고 시작하면 좋다.

• null을 반환, 전달하지 마라

null을 반환하는 경우에는 일일히 null 확인이 필요하다. 애초에 null을 넘기는 것을 금지하면 합리적이다.

Java의 경우 Optional 같은 Wrapper 클래스를 사용하거나 List의 경우 빈 리스트를 반환하는 방식으로 nullPointerException을 막을 수 있다.

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

• try~catch 문을 사용하고 있긴하지만 오류코드와 함께 사용하고 있어 코드가 깨끗하지 않고 혼돈을 야기한 것 같다.
• 개발시 null 체크를 꼼꼼하게 하도록 신경을 썼는데, 처음부터 null을 못넘기게 금지하면 된다는 점이 센세이션했다.

오늘 읽은 범위

• 6장 객체와 자료구조

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

• 자료구조

별다른 동작 없이 자료를 노출한다,

새로운 자료구조를 추가하기 어렵다.

기존 자료 구조를 변경하지 않으면서 새 함수를 추가하기 쉽다

• 객체

동작을 공개하고 자료를 숨긴다

새로운 함수를 추가하기 어렵다.

기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다.

• 기차 충돌

//전
final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

//후
Option opts =ctxt.getOpthons();
File scratchDir = opts.getScratchDir();
final String outputDir = scratchDir.getAbsolutePath();

위와 같이 함수를 줄줄히 호출하는 코드를 기차충돌이라고 부른다.

각 함수를 끊어서 선언하는 방식으로 변경하면 좋다.

• 구조체 감추기

//전
final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

//변경 1 -해당 방법도 노출되는 부분이 많다...
final String outputDir = ctxt.getAbsolutePathOfScratchDirectoryOption();

// outputDir를 쓰이는 코드를 보니 파일을 생성하기 위해서였군! 
String outFiel = outputDir + "/" + classNm.replace('.','/') +".class";
FileOutputStream fout =new FileOutputStream(outFile);
BufferdOutputStream bos = new BufferdOutputStream(fout);

//변경 2 - ctxt 객체에서 해결하도록 변경
BufferdOutputStream bos = ctxt.createScratchFileStream(classNm);

내부 구조를 감출 수 있도록 코드를 변경한다.

변경 2 같은 경우 해당 코드의 히스토리까지 파악해야 하므로 연습이 많이 필요할 것 같다.

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

짧은 분량인데 어려워서 여러 번 읽었다. 일단 많이 쓰는 기차 구조부터 피해보자.

절차적인 코드, 객체지향적인 코드는 각자 적합한 상황이 있으므로 최적의 조건을 선택하자.

오늘 TIL 3줄 요약

• 불필요한 주석은 달지 말자.
• 주석을 남길 때는 오해가 없도록 명확하게 전달되게 작성한다.
• 주석보다는 코드 자체로 의도가 전달 되도록 하자.

TIL (Today I Learned) 날짜

• 2022-04-29

오늘 읽은 범위

• 4장. 주석

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

• 주석은 언제나 실패를 의미한다. 주석 없이 코드로 의도를 표현하도록 노력해야한다. (p.68)
• 코드에 주석을 추가하는 이유는 보통 코드품질이 나쁘기 때문이다. (p.69)

• 좋은 주석
  • 결과를 경고하는 주석 - 실행시간이 긴 테스트 케이스 등을 경고하는 용으로 사용가능. (p.73)
  • TODO주석 - 앞으로 할일을 TODO 주석으로 남겨보자. IDE에서 TODO 주석을 추적하는 기능이 있다. (p.75)
• 나쁜 주석
  • 의무적으로 다는 주석 - 너무 당연한 정보를 제공하거나, 쓸모 없는 내용
  • 오해할 여지가 있는 주석 - 명확하게 전달되도록 적자.
  • 사용하지 않는 코드 주석처리, 코드 수정내용 주석으로 남기기 - 버전관리에 남아있으니 안심하고 지우자.

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

• 좋은 주석 파트에서 나온 TODO은 한번도 사용한 적이 없는데 써봐야겠다.
• 나쁜 주석 파트를 보면서 불필요한 주석을 많이 단 것 같다. 주석이 중요하다고 말만 들었지 어떤 식으로 써야하는지 몰랐는데 도움이 되었다. 남기기 위한 주석을 작성한 경험도 있고, 갓 취직 했을 때는 한동안 API 위에 꼭 author를 남기며 뿌듯해 했던 기억이 난다 ㅎㅎ..
• 이번 파트를 보면서 좋았던 점은 그나마! 잘하고 있던 점도 있었기 때문이다. 나는 코드를 쪼개서 변수 선언하는 것을 좋아하는데, 길고 멋있는 코드를 짜는 지인이 내 코드가 쉽다고 비웃은 적이 있기 때문이다. 역시 가독성이 짱짱
  주석 파트이지만 주석 없이 코드로 의도를 표현하는 법을 배워서 많은 도움이 되었다.

#코딩 #개발자 #노마드북클럽 #노개북 #클린코드 #CleanCode

오늘 TIL 3줄 요약

• 함수는 한 가지만 잘 수행해야 한다.
• 길이가 짧고 서술적인 이름을 가지도록 한다.
• 읽는 사람을 생각하며 작성하자.

TIL (Today I Learned) 날짜

2022-04-27

오늘 읽은 범위

3장. 함수

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

• 작게 만들어라! (p.42)
  • 함수는 작을 수록 좋다.
  • 중첩 구조가 생길 만큼 함수가스 커져서는 안된다.
• 한 가지만 해라! (p.44)
  • 함수는 한 가지만 해야 한다. 그 한 가지를 잘해야 한다. 그 한 가지만을 해야 한다.
  • 함수에서 의미 있는 이름으로 다른 함수를 추출 할 수 있다면 여러 작업을 하는 셈이다.
• Switch문 (p.46)
  • Switch 문은 분기가 여러개이므로 한 가지 작업만 하게 작성하기 어렵다.
  • 예시는 다형성을 이용하여 해결하는데, Switch문을 추상 팩토리로 이동시키고 파생 클래스의 인스턴트를 생성하는 것으로 중복을 피한다.
• 서술적인 이름을 사용해라! (p.49)
  • 짧고 어려운 이름보다 길고 서술적인 이름이 좋다.
  • 함수 기능을 가장 잘 표현하는 이름을 선택한다.
• 함수 인수 (p.50)
  • 인수 개수는 0개가 가장 좋다. 3개 이상은 피하자.
  • 인수가 많아지면 가독성이 떨어지고 테스트도 어렵다.
  • 인구 개수가 3개 이상이면 클래스 선언을 고려해보자.
• 부수 효과를 일으키지 마라! (p.54)
  • 함수명으로 예측되지 않는 작업을 하지말자.
  • 예) checkPassWord(password) -> 해당 함수에서 세션 수정하기.
• 오류 코드보다 예외를 사용하라! (p.57)
  • 오류코드를 이용시 조건문을 보통 사용하게 되어 중첩 코드를 야기하고, 오류 코드 반환시 즉시 처리해야 하는 문제가 생긴다.
  • 예외를 사용하면 오류 처리 코드가 원래 코드에서 분리 가능하다.
  • try~catch 블록은 정상 동작과 오류 처리 동작을 섞는다. 각 블록을 별도 함수로 선언하면 좋다.

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

• 함수 부분 예시를 보면서 하지말라는 것은 다 하고 있었구나.. 뼈를 맞은 기분이었다. 주로 만지는 것이 레거시다 보니 몇백줄짜리 함수가 너무도 익숙하다. 특히 부수 효과를 일으키지 마라 ! 파트에서 아찔함을 느꼈다. 이런 문제로 유지보수를 하는 경우가 얼마나 많은가.. 책을 읽으면서 단호한 사수에게 코드 리뷰를 받는 것 같았다. 책의 내용을 한 번에 적용하기는 쉽지 않겠지만, 여러 번 읽으면서 체화되도록 노력해야겠다.

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

• 추상화 파트에서 이해가 안되어서 내일 찾아보려고 함.

#코딩 #개발자 #노마드북클럽 #노개북 #클린코드 #CleanCode

기다리고 기다렸던 노마드 북클럽 클린코드!

이번에야 말로 호로록 읽어봐야지

#코딩 #개발자 #노마드북클럽 #노개북 #클린코드 #CleanCode