[Week] 1주차 진도

[DaehunGwak]

• 발표자를 제외한 인원은 느낀점, 질문사항을 코멘트로 남겨주세요.
• 발표자는 발표자료를 준비하시고 공유해주세요.

이번 주 발표자

• @DaehunGwak

진도

• chapter 1 : 깨끗한 코드
• chapter 2 : 의미있는 이름

발표자료

• 발표자료 링크는 여기에!

[ChoMk]

chapter 1

느낀점

좋은 코드란?

• 한 함수가 한가지 일
• 명쾌한 추상화 단순한 제어문(가독성)
• 의존성 최소화, 좋은 네이밍
• 주의 깊게 짜기
• 중복 최소화
• 짐작한 기능을 그대로 수행하는 함수

좋았던 부분

• 보이스카우트 규칙에 대한 설명 --- 공감 100%%

질문

• 고치기 쉬운 코드란?

chapter 2

느낀점

좋은 이름이란?

• 의미 없는 이름은 피하자
• 중복되는 내용은 피하자(nameString, name과 같이)
• 쉬운 이름으로 정하자(검색하기 위하여)
• 인코딩을 피하자(타입을 바꾸더라도 이름은 변경되지 않는다.)
• 이름으로 말장난 하지 말자(add, insert, append,,등..) 다른 행동이면 다른 이름으로..?>?>?
• 문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다.

좋았던 부분

• 의미를 해독할 책임이 독자에게 있는 논문 모델이 아니라 의도를 밝힐 책임이 저자에게 있는 잡지 모델이 바람직하다.
• 교육이 달라서 이름을 정하는 수준도 다르고 그러다 보니 서로의 이름을 지적하는 건 힘들 수 있다. 그래서 그런 지적에 기분이 나빠지지 않도록 하는 문화와 각자의 커뮤니케이션에 대한 노력이 필요하지 않을까 한다.

질문

• 이름에 대하여 고민했던 경험?

[minSW]

[Chapter 1] 깨끗한 코드

📖 기억에 남는 부분

마감기한과 좋은 코드 사이의 딜레마?

• 유일한 방법 => 언제나 코드를 최대한 깨끗하게 유지하는 습관

좋은 코드가 중요한 이유

• 나중에 리팩토링해야지 => 르블랑의 법칙 "나중은 결코 오지 않는다"
• "우리는 저자면서 독자"
  • 주변코드를 읽기 쉽게 만들면 새 코드짜기도 쉬움
• 우리는 이미 나쁜코드로 인한 '고행' 을 겪음으로써 좋은 코드의 중요성을 알고 있다
  • 나쁜코드를 짬으로써 클린코드의 중요성을 확인할 수 있다(..)

느낀점

[Chapter 2] 의미있는 이름

📖 기억에 남는 부분

의미있게 구분하라(3) & 불필요한 맥락을 없애라(16)

• (동일한 범위 내) 같은 이름을 사용할 수 없어 의미없는 단어를 추가하는 것은 적절하지 X
  • 내 평소 코딩 습관 감시당한 줄... 뼈맞고 반성함...
  • ABCCustomerInfo (ABC 어플리케이션/모듈 이름 + Customer + Info 불용어) => Customer

의미있는 맥락을 추가하라(15)

• 스스로는 의미가 불분명한 경우 => 클래스, 함수, 이름공간에 넣어 맥락 부여
  • 접두어를 추가함으로써 맥락을 추가 하는 방식만 생각해왔는데 그건 마지막 수단 으로
  • 예제의 하나의 긴 method <-> 맥락이 분명한 class 가 와닿았음

그 외 인상깊었던 부분

• 의도를 분명히 밝혀라 (주석이 필요하다면 X)
• 발음/검색하기 쉬운 이름을 사용하라
• 한 개념에 한 단어를 사용하라

🤔 질문

• 의미있는 이름에서 지양하는 흡사한 이름 vs 지향하는 유사한 표기법 의 차이?
• 멀티 모듈(대형 프로젝트)에서의 좋은 네이밍?

[DaehunGwak]

질문

• 이름을 짓는다고 배려하고 고민을 많이 하면 생산성은 어떻게 하죠?
  • 이름을 잘지으면 나중에 훨씬 생산성이 좋아진다는 건 동의
  • 하지만 언제까지 이름만 고민할 수 는 없을 것 같음...

[jin5335]

Chapter1. 깨끗한 코드

• "읽기 쉬운 코드가 깨끗한 코드다" - 아무리 강조해도 지나치지 않다는 생각이 든다.
• 보이스카우트 규칙 - 사용하고 나면 이전보다 깨끗하게!!, 정신없이 짠 코드들을 사용하다 보면 코드의 더러움에 마음이 무거워지는데, 이제부터는 사용하고 나면, 조금씩이라도 정리해야겠다.

Chapter2 의미있는 이름

• 주석이 필요없는 명명
• 발음하기 쉬운 명명
• 중복으로 전달되는 정보들은 변수명에서 과감히 빼야겠다. -이름을 정하는 것은 언제나 어려운 일이고, 영어를 못해서 더 어렵고,,,,,

Q. 가독성면에서 긴이름을 좋아하지 않는데, 의미를 분명히 전달하기 위해서는 내가 원하는 길이보다 길어진다. 이럴 때 어떻게하는 것이 좋을까??

[KimYealynn]

Chapter01. 깨끗한 코드

업무 기한을 맞추기 위해 나쁜 코드를 양산 한다 ?

기한을 맞추는 유일한 방법은 코드를 깨끗히 유지하는 습관이 중요!

깨끗한 코드의 다양한 정의 중 기억에 남는 부분

• 한가지를 제대로 (특정 목적을 달성하는 방법을 하나만 제공)
• 고칠 궁리를 하면 제자리로 돌아오는 코드
• 짐작했던 기능을 그대로 수행 -> 이렇게 많은 사람들이 깨끗한 코드의 중요성에 대해 말하고 있다. 무작정 돌아가도록 하는 것 보다 깨끗한 코드에 대해서 한 번 더 고민해보고 손가락 움직이기

Chapter02. 의미있는 이름

한개념에 한 단어만 사용하라

요즘 많이 고민하던 부분인데,,,, 자주 쓰이는 함수 앞부분 동사 들의 미묘한 차이??? 때문에 고민하다가 결국 그때 그냥 맘 가는 거 선택했던 것 같다 ㅎ 샘플코드를 많이 보고 어떤 동사가 어떤 때 쓰이는 지 한 번 더 찾아봐야겠음

불필요한 맥락을 없애라

이름이 길어도 된다, 정보를 다 포함하도록 하라 이런 말들을 듣다보니 이런 실수가 좀 많았던 것 같다. 무조건 다 이름에 때려 넣기 전에 다른 곳에서 충분히 그 정보를 알 수 있는데 중복으로 적는 건 아닌지 고민해보기

Q

• 깨끗한 코드를 유지하는게 빨리 코드를 짜는 거라고 하지만 아직 개발을 얼마 안해봐서 그런지 코드 품질까지 신경쓰면서 하기엔 시간이 너무 오래걸리는 것 같다. 경력이 더 많은 개발자 분들한텐 코드 품질을 신경쓰는 거라고 보일지 그냥 느린 편이라고 생각할지 가끔 걱정이 됨.. 실제 구현시간 VS 코드 품질에 대한 고민시간 비율은 어느정도가 좋을까??
• 함수 맨 앞에 붙는 동사들.... 어떤 때 뭘 써야 할 지 가끔 헷갈릴 때가 있는데 이런 거 정리해 둔 사이트는 없을까??

[DaehunGwak]

Q & A

• Q: 이름에 대하여 고민했던 경험?

• Q: 의미있는 이름에서 지양하는 흡사한 이름 vs 지향하는 유사한 표기법 의 차이?

  • 너무 어려워ㅓㅓㅓㅓㅓㅓ
  • 결국 경험의 차이?
  • 기존 코드에 어떻게 쓰고 있는지 먼저 훑어보고 물어보거나 (문서보면서) 알아보는게 베스트

• Q: 멀티 모듈(대형 프로젝트)에서의 좋은 네이밍?

  • 결국 대형프로젝트에서 고려하는건 공수가 너무 많이 들어 절충을 찾아야 하는게 아닌가?
  • 디자인 패턴을 미리 고려해보며 하면 베스트

• Q: 다른분의 코드 어떻게 건드리지?

  • 논이슈라면 괜찮지 않을까
  • 커밋 추적해서 마지막 만드신 분에게 물어보고 협의가 좋지 않을까

• Q: 이름을 짓는다고 배려하고 고민을 많이 하면 생산성은 어떻게 하죠?

  • 이름을 잘지으면 나중에 훨씬 생산성이 좋아진다는 건 동의
  • 하지만 언제까지 이름만 고민할 수 는 없을 것 같음

• Q: 가독성면에서 긴이름을 좋아하지 않는데, 의미를 분명히 전달하기 위해서는 내가 원하는 길이보다 길어진다. 이럴 때 어떻게하는 것이 좋을까?

• Q: 깨끗한 코드를 유지하는게 빨리 코드를 짜는 거라고 하지만 아직 개발을 얼마 안해봐서 그런지 코드 품질까지 신경쓰면서 하기엔 시간이 너무 오래걸리는 것 같다. 경력이 더 많은 개발자 분들한텐 코드 품질을 신경쓰는 거라고 보일지 그냥 느린 편이라고 생각할지 가끔 걱정이 됨.. 실제 구현시간 VS 코드 품질에 대한 고민시간 비율은 어느정도가 좋을까??

• Q: 함수 맨 앞에 붙는 동사들.... 어떤 때 뭘 써야 할 지 가끔 헷갈릴 때가 있는데 이런 거 정리해 둔 사이트는 없을까??

  • bool 변수 짓는 참고 블로그

[DaehunGwak]

https://github.com/strange-study/ss-start-clean-code/pull/3 완료되어 종료합니다! 👍👍👍