공부하는개미

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

• 추이적 탐색을 피하라(395p)
  • 일반적으로 한 모듈은 주변 모듈을 모를수록 좋다.
    => A가 B를 사용하고 B가 C를 사용한다 하더라도 A가 C를 알아야 할 필요는 없다는 뜻이다.
  • 디미터의 법칙이라 부른다.
  • 내가 아는 모듈이 연이어 자신이 아는 모듈을 따라가며 시스템 전체를 휘저을 필요가 없다는 의미다.
    
    
• 서술적인 이름을 사용하라(399p)
  • 이름은 성급하게 정하지 않는다.
  • 소프트웨어 가독성의 90%는 이름이 결정한다.
    => 시간을 들여 현명한 이름을 선택하고 유효한 상태로 유지한다.
  • 신중하게 선택한 이름을 보고 독자는 모듈 내 다른 함수가 하는 일을 짐작한다.
    
    
• 적절한 추상화 수준에서 이름을 선택하라(401p)
  • 구현을 드러내는 이름은 피하라.
  • 작업 대상 클래스나 함수가 위치하는 추상화 수준을 반영하는 이름을 선택하라.
    
    
• 커버리지 도구를 사용하라!(404p)
  • 커버리지 도구는 테스트가 빠뜨리는 공백을 알려준다.
  • 커버리지 도구를 사용하면 테스트가 불충분한 모듈, 클래스, 함수를 찾기가 쉬워진다.

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

1. 이전 프로젝트에서 커버리지 도구에서 테스트가 불충분한 모듈도 포함을 시켰었던 게 생각났습니다.
   • 카카오 로그인 API 였었는데 예전에는 그것을 포함시켜야 하나 고민이 되었었습니다.
     이 책을 읽고 불필요한 테스트는 제외해도 된다는 걸 알게 되었습니다.

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

• 코드 커버리지란?
  • 코드 커버리지는 소스 코드를 기반으로 수행하는 화이트 박스 테스트를 통해 측정한다.
    • 블랙박스 테스트
      => 소프트웨어의 내부 구조나 작동 원리를 모르는 상태에서 동작을 검사하는 방식
      => 올바른 입력과 올바르지 않은 입력을 입력하여 올바른 출력이 나오는지 테스트하는 기법
      => 사용자 관점의 테스트 방법이라 볼 수 있다.
      
      
    • 화이트 박스 테스트
      => 응용 프로그램의 내부 구조와 동작을 검사하는 테스트 방식이다.
      => 소프트웨어 내부 소스 코드를 테스트하는 기법이다.
      => 개발자 관점의 단위 테스트 방법이라 볼 수 있다.

👀 소감 3줄 요약

• 일군의 규칙만 따른다고 깨끗한 코드가 얻어지지 않는다.
• 휴리스틱 목록을 익힌다고 소프트웨어 장인이 되지는 못한다.
• 전문가 정신을 가진 개발자가 되자!!

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

• 알고리즘을 이해하라(383p)
  • 알고리즘을 안다고 생각하지만 실제는 코드가 '돌아갈' 때까지 이리저리 찔러보고 굴려본다.
  • '돌아간다'는 사실은 어떻게 아느냐고? 생각할 수 있는 테스트 케이스를 모두 통과하니까.
    * 이 방식이 틀렸다는 말이 아니다.
  • 구현이 끝났다고 선언하기 전에 함수가 돌아가는 방식을 확실히 이해하는지 확인하라.
    =>  테스트 케이스를 모두 통과한다는 사실만으로 부족하다.
  • 알고리즘이 올바르다는 사실을 확인하고 이해하려면 기능이 뻔히 보일 정도로 함수를
    깔끔하고 명확하게 재구성하는 방법이 최고다.
    
    
• if/Else 혹은 Switch/Case 문보다 다형성을 사용하라(385p)
  1. 대다수 개발자가 switch 문을 사용하는 이유는 그 상황에서 가장 올바른 선택이기보다는
     당장 손쉬운 선택이기 때문이다.
     => switch를 선택하기 전에 다형성을 먼저 고려하라는 의미다.
  2. 유형보다 함수가 더 쉽게 변하는 경우는 극히 드물다. 그러므로 모든 swtich 문을 의심해야 한다.
     
     

// 변경 전
if (shouldBeDeleted(timer))

// 변경 후
if (timer.hasExpired() && !timer.isRecurrent())

• 조건을 캡슐화하라(388p)
  • 부울 논리는 이해하기 어렵다.
  • 조건의 의도를 분명히 밝히는 함수로 표현하라.

• 부정 조건은 피하라(389p)
  • 부정 조건은 긍정 조건보다 이해하기 어렵다.
  • 가능하면 긍정 조건으로 표현한다.

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

1. Switch/Case 문은 잘 사용하지 않았지만 if/else로 도배된 코드는 많이 봤습니다.
   • 우선적으로 가독성이 상당히 안 좋았습니다.
   • if에 해당하는 조건을 전부 거치기 때문에 상당히 비효율적이라고 느껴졌습니다.
2. 제가 추상화에 대한 개념이 아직 덜 정립되어 있는 것 같습니다.
   • 우선 책을 읽어야겠다는 생각 때문에 '대략적인 이런 거구나?'라는 생각으로 넘어가고 있습니다.
     추상화의 개념과 예시를 좀 더 찾아보고 고민해봐야 할 것 같습니다.

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

• 추상화란?
  
  • 컴퓨터 과학에서 추상화는 복잡한 자료, 모듈, 시스템 등으로부터
    핵심적인 개념 또는 기능을 간추려 내는 것을 말한다.
  • 결국 핵심은 불필요한 코드를 제거하고 중요한 부분을 살리는 것입니다.
• 다형성이란?
  • 하나의 객체가 여러 가지 타입을 가질 수 있는 것을 의미합니다.
  • 자바에서는 이러한 다형성을 부모 클래스 타입의 참조 변수로 자식 클래스 타입의 인스턴스를
    참조할 수 있도록 하여 구현하고 있습니다.

👀 소감 3줄 요약

• 알고리즘을 이해하지 않고 우선 코드부터 했던 적이 많은데, 책을 읽고  반성하게 되었습니다.
• 객체지향의 개념이 중요하다는 걸 이번 챕터를 읽고 더욱 강하게 느꼈습니다.
• 클린코드를 읽었나 보다 그걸 바탕으로 코드에 적용해 봤나 가 중요하다고 생각했습니다.

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

• 주석(368p)
  • 부적절한 정보
    => 일반적으로 작성자, 최종 수정일, SPR(Software Problem Report)번호 등과 같은 메타 정보만 주석 사용
    => 주석은 코드와 설계에 기술적인 설명을 부연하는 수단이다.
  • 주석 처리된 코드
    => 누군가에게 필요하거나 다른 사람이 사용할 코드라 생각해 아무도 삭제하지 않는다.
    => 주석으로 남겨진 코드는 그 자리에 남아 매일매일 낡아간다.
    => 주석으로 처리된 코드를 발견하면 즉각 지워버려라!
    
    
• 일반(371p)
  • 한 소스 파일에 여러 언어를 사용한다.
    => 이상적으로는 소스 파일 하나에 언어 하나만 사용하는 방식이 가장 좋다.
    * 혼란스럽고 조잡하다.
    
    
  • 경계를 올바로 처리하지 않는다.
    => 스스로의 직관에 의존하지 마라.
    => 모든 경계 조건을 찾아내고, 모든 경계 조건을 테스트하는 테스트 케이스를 작성하라.
    
    
  • 중복
    => 코드에서 중복을 발견할 때마다 추상화할 기회로 간주하라.
    => 중복된 코드를 하위 루틴이나 다른 클래스로 분리하라.
    => 이렇듯 추상화로 중복을 정리하면 설계 언어의 어휘가 늘어난다.
    => 추상화 수준을 높였으므로 구현이 빨라지고 오류가 적어진다.
    
    
  • 과도한 정보
    => 잘 정의된 모듈은 인테페이스가 아주 작다.
    => 하지만 작은 인터페이스로도 많은 동작이 가능하다.
    => 우수한 소프트웨어 개발자는 클래스나 모듈 인터페이스에 노출할 함수를 제한할 줄 알아야 한다.
    => 클래스가 제공하는 메서드 수는 적을수록 좋다.
    => 정보를 제한해 결합도를 낮춰라.

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

1. 지금까지 읽은 내용이 정말 많은 내용이 담겨 있다는 걸 느꼈습니다.
   => 단순히 읽고 끝내는 것이 아닌 그 이론에 해당하는 코드를 보고 직접 타이핑
   
   
2. 클린 코드를 하나의 방향성 같다는 느낌을 받았습니다.
   => 클린코드의 내용과 내가 작성한 코드를 보면서 한번 더 생각하게 만들어 줬습니다.
   => 하나의 방향성을 보여주는 것이지 꼭 지켜야 하는 룰은 아닌 것 같다고 생각했습니다.
   => 우선 클린코드 저자가 절대로 하지 말아야 한다는 규칙은 지키도록 노력해야겠습니다.

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

• 디자인 패턴은 어떻게 공부 할지?
  • 클린코드를 읽으면서, 해당 디자인 패턴을 사용해야 하는 상황을 직접 보고 공부해야 한다는걸 알게되었습니다.
  • 당연하겠지만 단순히 암기를 하는 식의 공부는 휘발성이 심하다는걸 다른 책을 읽고 느꼈습니다.
    => 다른 책은 개념을 알려주고 코드를 보여주고 요약본을 보여주는 형태였습니다.

👀 소감 3줄 요약

• 친절한 저자의 책에 대한 복습 챕터를 만들어 놔서 복습을 편하게 할 수 있었습니다.
• 요약본을 통한 읽은 부분을 정확히 이해했는지 확인 할 수 있어서 좋았습니다.
• 클린코드는 두고두고 읽을 명저라고 느꼈습니다.

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

• 불필요한 주석은 거짓말과 잘못된 정보가 쌓이기 좋은 곳이다.
  
• 일반적으로 기반 클래스(base class, 부모 클래스)는 파생 클래스(derivative, 자식 클래스)를 몰라야 바람직하다.
  • ABSTRACT FACTORY 패턴을 적용
  • 추상 메서드로 위임하는 정적 메서드는 SINGLETON, DECORATOR, ABSTRACT FACTORY 패턴 조합을 사용한다.
• 보이스카우트 규칙
• 다음 사람은 우리보다 코드를 좀 더 쉽게 이해하리라.
  그래서 보다 코드를  좀 더 쉽게 개선하리라.

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

1. 너무 사소한 코드는 테스트할 필요가 없다.
   • 이전 프로젝트에서 코드 커버리지를 채우는 데에만 급급했었던 경험이 있습니다.
     => 중요한 메서드에 테스트를 집중 하고 사소한 건 테스트할 필요 없다는 걸 알게 되었습니다.

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

• 싱글톤이란?
  • 소프트웨어 디자인 패턴에서 싱글턴 패턴을 따르는 클래스는,
    생성자가 여러 차례 호출되더라도 실제로 생성되는 객체는 하나이고 최초 생성 이후에
    호출된 생성자는 최초의 생성자가 생성한 객체를 리턴한다.

👀 소감 3줄 요약

• 예전에도 나왔지만 불필요한 주석을 다는 위험을 강조하고 있습니다.
• 테스트 커버리지 도구를 통해 지표를 확인하면서 테스트 코드를 작성해야 한다는 걸 알게 되었습니다.
• 리팩터링을 통해 나중에 해당 코드를 개선할 사람까지 생각하는 것이 인상 깊었습니다.

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

• 코드를 리팩터링 하다 보면 원래 했던 변경을 되돌리는 경우가 흔하다.
  => 리팩터링은 코드가 어느 수준에 이를 때까지 수많은 시행착오를 반복하는 작업이기 때문이다.
  
  
• 세상에 개선이 불필요한 모듈은 없다.
  
  
• 코드를 처음보다 조금 더 깨끗하게 만드는 책임은 우리 모두에게 있다.

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

1. 처음 장에서 저자가 얘기했던 지켜야 할 규칙들을 바탕으로 리팩터링 하는 파트였습니다.
   => 이미 깨끗한 코드도 리팩터링할 것이 있다는 것을 알게 되었습니다.
   => 코드를 더욱 깨끗하게 만들어가는 과정은 진짜 장인들의 모습과도 같다고 느꼈습니다.
   
   
2. 클린코드를 읽으면서 매번 느끼지만 내가 작성한 코드를 꼭 둘러보면서 리팩터링 해야겠다고 느꼈습니다.
   => 기능을 만들고 그냥 놔버리는 경우가 많았었습니다.
   => 리팩터링을 아주 조금하면서 많은 성장을 이뤄냈습니다.
   => 테스트코드가 없는 코드는 리팩터링 하는게 힘들다는 것을 느꼈습니다.

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

• 테스트코드 리팩터링은 어떻게 할까?
  
  • 중복되는 코드는 @Before 어노테이션으로 옮긴다.
  • 하나의 assert 문으로도 충분히 테스트할 수있는 케이스로 리팩터링
    => 너무 많은 assert(단언문)을 가진다면 테스트 케이스가 두 개 이상 포함되어 있는지 의심해본다.
  • 참고한 블로그 -> 링크

👀 소감 3줄 요약

• 코드를 리팩터링 하다가 예전 코드로 돌리는 경우는 흔한 일이다.
• 세상에 개선이 불필요한 모듈은 없다.
• 코드를 처음보다 조금 더 깨끗하게 만드는 장인정신

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

public String compact(String message) {
	if (shouldNotCompact())
    	return Assert.format(message, expected, actual);
        
    findCommonPrefix();
    ...
}

private boolean shouldNotCompact() {
	return expected == null || actual == null || areStringsEqual();
}

• 의도를 명확히 표현하려면 조건문을 캡슐화해야 한다.
  
  • 조건문을 메서드로 뽑아내 적잘한 이름을 붙인다.

public String compact(String message) {
	if (canBeCompacted()) {
    	findCommonPrefix();
        ...
    } else {
    	return Assert.format(message, expected, actual);
    }
}

private boolean canBeCompacted() {
	return expected != null &&  actual != null && !areStringsEqual();
}

• 부정문은 긍정문보다 이해하기 약간 더 어렵다.
  그러므로 첫 문장 if를 긍정으로 만들어 조건문을 반전한다.

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

1. 책을 통해 캡슐화를 하는 과정을 직접적으로 보게 되면서 이해를 할 수 있었습니다.
   => 하나의 과정을 보여주면서 더 클린한 코드가 되가는 모습
   => 클린한 코드와 객체지향적 설계 코드가 비슷하다는 것을 느꼈습니다.

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

• 보이스카우트 규칙이란?
  • 클린코드 18쪽에 나오는 내용이다. 
  • 잘 짠 코드가 전부는 아니다.
    시간이 지나도 언제나 깨끗하게 유지해야 한다.
  • 지속적인 개선이야말로 전문가 정신의 본질
• 캡슐화란?
  • 객체의 속성(data fields)과 행위(메서드, methods)를 하나로 묶고,
    실제 구현 내용 일부를 외부에 감추어 은닉한다.
  • 캡슐화를 private이라고 단순하게 이야기하면 안된다는 이유를 알게 되었습니다.

👀 소감 3줄 요약

• 객체지향 설계의 캡슐화가 클린한 코드를 만드는 과정
• 부정문은 긍정문보다 이해하기 약간 더 어렵다
• 코드를 직접 보면서 이론을 설명해줘서 이해하기 수월했습니다.

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

• 소프트웨어 설계는 분할만 잘해도 품질이 크게 높아진다.
  • 적절한 장소를 만들어 코드만 분리해도 설계가 좋아진다.
  • 관심사를 분리하면 코드를 이해하고 보수하기 훨씬 더 쉬워진다.
• 그저 돌아가는 코드만으로는 부족하다.
  • 돌아가는 코드가 심하게 망가지는 사례는 흔하다.
  • 단순히 돌아가는 코드에 만족하는 프로그래머는 전문가 정신이 부족하다.
  • 나쁜 코드는 썩어 문드러진다.
• 나쁜 코드도 깨끗한 코드로 개선할 수 있지만 비용이 엄청나게 많이 든다.
  • 모듈은 서로서로 얽히고설켜 뒤엉키고 숨겨진 의존성이 수도 없이 생긴다.

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

1. 프로젝트를 하면서 분할에 대한 것을 팀원분에게 배웠습니다.
   => 작동하는데 문제가 없었던 코드였지만 분할을 하면서 중복되는 코드가 확연하게 줄어들었습니다.
   => 다른 사람의 습관과 코드를 통해 배울게 많다는 것을 느꼈습니다.

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

• 관심사란?
  • 컴퓨터 프로그램의 코드에 영향을 미치는 특정한 정보 집합이다.
  • 프로그래밍 관점에서 보면 하나의 기능이나 모듈이라고 이해하면 쉽다.
• 의존성이란?
  • 코드에서 두 모듈간의 연결.
  • 객체지향언어에서는 두 클래스 간의 관계라고도 말함.
  • 일반적으로 둘 중 하나가 다른 하나를 어떤 용도를 위해 사용함.

👀 소감 3줄 요약

• 소프트웨어 설계는 분할만 잘해도 품질이 크게 높아진다.
• 나쁜 코드는 썩어 문드러진다.
• 코드는 언제나 최대한 깔끔하고 단순하게 정리하자.

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

private void setBooleanArg(ArgumentMarshaler m) {
	try {
    	m.set("true"); // 이전 코드: booleanArgs.get(argChar).set("true");
    } catch (ArgsException e) {
    }
}

• 변경 전 booleanArgs.get(argChar).set("true");  코드
  • 위 코드는 클린코드 6장에 나왔던 기차 충돌 코드 사례와 비슷하게 생겼습니다.
  • 변경 후 코드가 훨씬 간결해졌습니다.
    
    
• 리팩터링을 하다보면 코드를 넣었다 뺐다 하는 사례가 아주 흔하다.
  • 단계적으로 조금씩 변경하며 매번 테스트를 돌려야 하므로 코드를 여기저기 옮길 일이 많아진다.
    => 리팩터링은 루빅 큐브 맞추기와 비슷하다.
    => 큰 목표 하나를 이루기 위해 자잘한 단계를 수없이 거친다.
    => 각 단계를 거쳐야 다음 단계가 가능하다.

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

1. 이 챕터를 읽고 저자는 한번에 완벽한 코드를 작성할 수 없다는 것을 보여주는 것 같았습니다.
   => 챕터 제목 그대로 점진적인 개선을 보여주고 있습니다.
   
   
2. 모든 코드를 다 리팩터링 하고 테스트를 돌려보는 방식이 아녔습니다.
   => 한 부분을 리팩터링 하고 테스트를 돌리는 과정이 많았습니다.
   
   
3. 이전 장에서 배웠던 내용을 코드에 적용해 하나씩 리팩터링 하는 게 인상 깊었습니다.

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

• 코드가 엄청 방대해서 전체를 다 이해하기는 힘들다고 느꼈습니다.
  => 눈으로만 읽고 생각해서 그런지 가독성이 안 좋았습니다.

👀 소감 3줄 요약

• 큰 목표 하나를 이루기 위해 자잘한 단계를 수없이 거친다.
• 점진적인 개선과 리팩터링
• 저자도 계속해서 리팩터링 과정을 거치면서 깨끗한 코드를 만들어가는 과정이 인상 깊었습니다.

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

• 프로그램을 망치는 가장 좋은 방법 중 하나는 개선이라는 이름 아래 구조를 크게 뒤집는 행위다.
  • 어떤 프로그램은 그저 그런 '개선'에서 결코 회복하지 못한다.
    => '개선' 전과 똑같이 프로그램을 돌리기가 아주 어렵기 때문이다.
• TDD는 언제 어느 때라도 시스템이 돌아가야 한다는 원칙을 따른다.
  • TDD는 시스템을 망가뜨리는 변경을 허용하지 않는다.
    => 변경을 가한 후에도 시스템이 변경 전과 똑같이 돌아가야 한다는 말이다.

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

1. 테스트 코드의 중요성을 오늘 또 느꼈습니다.
   => 테스트코드는 처음 의도에서 벗어나지 않게 해줍니다.
   => 테스트코드는 안정적으로 프로그램을 개선 할 수 있게 도와줍니다.

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

• 이 책을 읽으면서 TDD는 필수라는 느낌을 많이 받았습니다.  그렇다면 TDD의 단점이 궁금합니다.
  • SI프로젝트에서는 소프트웨어의 품질보다 납기일 준수가 훨씬 중요하기 때문에
    TDD방식을 잘 사용하지 않는다고 합니다.
  • 블로그의 글을 찾아보니, 테스트 코드를 작성해야 하는 번거로움 때문에 생산성 저하가 발생한다고 합니다.
    => 가장 큰 이유는 TDD를 배워야 한다는게 큰 것 같습니다.

👀 소감 3줄 요약

• 그저 그런 프로그램 개선은 결코 회복되지 않는다.
• 개선을 하면서 로직이 틀어진 적이 상당히 많았어서 공감이 되는 파트였습니다.
• TDD! 테스트! 테스트!!

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

• 프로그래밍은 과학보다 공예(craft)에 가깝다는 사실이다.
  • 깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다는 의미다.
    
    
• 대다수 신참 프로그래머는 무조건 돌아가는 프로그램을 목표로 잡는다.
  • 일단 프로그램이 '돌아가면' 다음 업무로 넘어간다.
  • '돌아가는' 프로그램은 그 상태가 어떻든 그대로 버려둔다.
  • 경험이 풍부한 전문 프로그래머라면 이런 행동이 전문가로서 자살 행위라는 사실을 잘 안다.

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

1. 오늘 시작한 [14장. 점진적 개선]을 읽으면서 느낀 점
   => 우선 코드 위주로 되어 있으니 타이핑해보자.
   => 타이핑 한 곳에 주석을 달면서 코드에 대해 이해해보자.
   => 작성 후 북 스터디에서 다른 분들이 올린 글을 보고 어떻게 공부했는지 참고해야 할 것 같습니다.
   
   
2. 깃허브 레포지토리 숫자를 상당히 많지만 그 코드를 개선하는 경우가 적었습니다.
   => 이전에 작성한 코드를 리팩터링 하지 않기 때문에 코드가 내 것이 되지 않는 문제 발생.
   => 예전에는 왜 이렇게 작성했는지 생각하면서 개선하고 어떻게 개선했는지 글로 남겨야겠습니다.

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

👀 소감 3줄 요약

• 프로그래밍은 과학보다 공예(craft)에 가깝다.
• 한 번에 완성되는 작품은 없으니 꾸준히 개선을 해나가야 한다.
• 예전에 작성한 코드들을 리팩터링 하면서 개선해야겠다고 느꼈습니다.