반정도의 시간이 지나간 스터디 2주차

섹션 6) 코드 다듬기

1. 좋은 주석

   우리가 가진 모든 표현 방법을 총동원해 코드에 의도를 녹여내고, 그럼에도 불구하고 전달해야 할 정보가 남았을 때 사용하는 주석

2. 변수와 메서드의 나열 순서

   • 객체는 협력을 위한 존재

   • 외부 세계에 내가 어떤 기능을 제공할 수 있는지를 드러냄

     • (정해진 답은 아니지만.. ) 공개 메서드를 상단에 배치하는 것이 좋음

       • 공개 메서드 : 객체에서 외부 세계에 제공할 수 있는 기능

   • 공개 메서드들끼리도 기준을 가지고 배치하는 것이 좋음

     • 중요도 순, 종류별로 그룹화하여 배치

   • 공개 메서드 중요도가 높은 순

     1. 메서드에서 상태 변경

        • 메서드가 가지고 있는 상태를 변경하는 메서드

     2. 판별

        • boolean값으로 반환받는 상태

     3. 조회

        • 값을 가져오는 조회 메서드

   • 비공개 메서드는 공개 메서드에서 언급된 순서대로 배치

   • 공통으로 사용하는 메서드라면 (가장 하단과 같은) 적당한 곳에 배치

   • 중요한 것은, 나열 순서로도 의도와 정보를 전달할 수 있다는 것

3. Intellij IDE 활용

   • 코드 포맷 정렬 단축키 : Ctrl + ALT + L

   • Sonarlint : 오류, 버그, 스타일 등을 알려주어 문제점 개선을 도와주는 Plugin

   • .editorConfig : 확장자마다 스타일을 다르게 줄수 있게 도와주는 설정파일

섹션 8) 기억하면 좋은 조언들

1. 능동적 읽기

• 복잡하거나 엉망인 코드를 읽고 이해하려 할 때, 리팩토링하면서 읽기

  • 공백으로 단락 구분하기

  • 메서드와 객체로 추상화 해보기

  • 주석으로 이해한 내용 표기하며 읽기

• git reset --hard 가 있다

• 핵심목표는 우리의 도메인 지식을 늘리는 것, 그리고 이전 작성자의 의도를 파악하는 것

1. 오버 엔지니어링

   • 필요한 적정 수준보다 더높은 수준의 엔지니어링

     • ex) 구현체가 하나인 인터페이스

       • 인터페이스 형태가 아키텍처 이해에 도움을 주거나 근시일 내에 구현체가 추가될 가능성이 높다면 Ok

       • 구현체를 수정할 때마다 인터페이스도 수정해야 함

       • 코드 탐색에 영향을 줌. 애플리케이션이 비대해 짐

     • ex) 너무 이른 추상화

       • 정보가 숨겨지기 때문에 복잡도가 높아진다.

       • 후대 개발자들이 선대의 의도를 파악하기가 힘들다.

2. 은탄환은 없다.

   • 만능해결사는 없다!

   • 클린 코드도 은탄환이 아니다.

   • 실무 : 2가지 사이의 줄다리기

     • 지속 가능한 소프트웨어의 품질 VS 기술 부채를 안고 가는 빠른 결과물

     • 대부분의 회사는 돈을 벌고 성장해야 하고 시장에서 빠르게 살아남는 것이 목표

     • 이런 경우에도 클린 코드를 추구하지 말라는 것이 아니라 미래 시점에 잘 고치도록 할 수 있는 코드 센스가 필요하다. 결국은 클린 코드의 사고법을 기반으로 결정하는 것

   • 모든 기술과 방법론은 적정 기술의 범위 내에서 사용되야 함

   • 도구라는 것은 일단 그것을 한계까지 사용할 줄 아는 사람이 그것을 사용하지 말아야 할 때도 아는 법

     • 적정 수준을 알기 위해, 때로는 극단적으로 시도해보자

   • 클린코드는 도구이다. 필요한 상황에서 적정 기술을 사용하도록 하자