진소희

1. 📌 핵심 개념 정리

✅ 요약하기

1. 나쁜 코드
   우리는 모두 나쁜 코드를 짠 경험이 있을 것이다. 이유는 아마 급해서, 코드 짤 시간이 없어서 등등 많은 이유가 있겠지만, 결국 나중에 수정하겠지라는 가벼운 생각을 가졌을 것이라고 생각한다. 나중이라는 것은 없었다.
   • 나쁜 코드는 개발 속도를 크게 떨어트린다. 매번 코드를 고칠 때마다 엉뚱한 곳에서 문제가 생기고, 얽힌 코드에서 또다시 얽힌 코드를 덭붙인다.
   • 나쁜 코드가 쌓일수록 팀 생산성은 떨어진다. 생산층은 복구를 시도하여 인력을 추가한다. 하지만 새 인력은 시스템 설계에 대한 조예가 깊지 않고, 생산성을 높여야 한다는 압력에 시달려 결국 나쁜 코드를 더욱 양산한다. 따라서 생산성은 0에 수렴한다.
   • 따라서, 나쁜코드의 위험을 이해하지 못하는 관리자의 압박을 그대로 따르는 행동은 전문가답지 못하다.

2. 깨끗한 코드
   • 교묘하고 단순해 보기에 즐거운 코드이다.
   • 프로그래머들이 대충 넘어가는 부분 중 하나인 오류 처리를 세세한 사항까지 꼼꼼히 신경써야 한다.
   • 한가지를 잘 아는 것이 깨끗한 코드이다.
   • 가독성이 좋아야 한다.
   • 다른 사람이 고치기 쉬워야 한다.
   • 중복이 적고, 표현력있는 이름을 포함해야 한다.
   • 초반부터 간단한 추상화를 고려해야 한다.

2. 🤔 이해가 어려운 부분

🔍 질문하기

1. 한가지를 잘 아는 코드
   • 어려웠던 부분
     • 한 가지에 집중하는 코드.
     • 함수와 클래스와 모듈이 주변 상황에 현혹되거나 오염되지 않은 채 한 길만 걷는다.
   • 궁금한 점
     • 한 가지를 잘 아는 코드란 어떤 뜻인가?
     • 의존성을 최대한 줄인 코드와 클래스, 메서드가 한가지 역할만 하는 코드라고 생각하는데, 그렇다면 클래스와 메서드가 무수히 많아질 수 있지 않는가? 그 중간 선이 무엇인가 고민해보아야 할 것 같다.

2. 명쾌한 추상화
   • 어려웠던 부분
     • 모순적인 단어들을 합쳐 어떻게 깨끗한 코드의 특징을 나타냈는지.
     • 코드는 추측이 아니라 사실에 기반해야 한다는 뜻.

3. 작게 추상화하라!
   • 어려웠던 부분
     • 함수나 클래스를 더 작은 단위로 분리하고 명확한 역할을 가지도록 설계하라는 뜻.
     • 명확한 역할이 추상화
   • 이해한 점
     • 이해하기 쉬움 → 짧고 명확한 함수는 읽기 쉽고 유지보수하기 좋음
     • 재사용 가능성 증가 → 작은 단위로 분리하면 다른 곳에서도 활용 가능
     • 변경에 유연함 → 한 가지 변경이 전체 코드에 영향을 미치지 않음

3. 📚 참고 사항

📢 논의하기

1. 관련 자료 공유
   • 깨진 유리창 이론

2. 논의하고 싶은 주제
   • 한가지를 잘 아는 코드
     의존성을 최대한 줄인 코드와 클래스, 메서드가 한가지 역할만 하는 코드라고 생각하는데, 그렇다면 클래스와 메서드가 무수히 많아질 수 있지 않는가?
   • 설명
     • 그 중간 선이 무엇인가?