Convention 정하지 않고 작업하게 될 경우, 서로 다른 작성 방식으로 인해 코드 가독성 저하를 일으키고 장기적으로 볼 때 유지 보수 함에 있어 큰 문제를 야기할 수 있습니다. Team Convention - 코드 스타일을 통일 시키는데 있어 Prettier 미사용하기로 함 - 규칙이 상대적으로 적고, 인텔리제이에서 제공하는 기능을 활용하는게 더 나은 것으로 판단했기 때문 설정 파일 .editorconfig 인텔리제이 설정 [File > Settings> Editor > Code Style] 이동 General Tab 에서 Enable EditorConfig Support 옵션 ✔ (=.editorconfig 설정 파일 허용) Formatter Tab에서 Do not format 에 제외 대상 gl..

stash 명령어 Stash 명령을 사용하면 워킹 디렉토리에서 수정한 파일들만 저장한다. Stash는 Modified이면서 Tracked 상태인 파일과 Staging Area에 있는 파일들을 보관해두는 장소다. 아직 끝내지 않은 수정사항을 스택에 잠시 저장했다가 나중에 다시 적용할 수 있다 - 'git-scm.com' ① 도움말 확인 $ git stash --help ② stash 저장 목록 확인 $ git stash list ③ 작업 내용 임시 저장 $ git stash push -m "메시지 작성" 👉 이 경우 Tracked 파일이면서 Modified 상태이거나, Staging Area에 있는 파일만 대상이 됨 $ git stash push -um "메시지 작성" // untracked 파일까지 전부..

1. 형식/포맷팅 중요한 이유 ✔ 가독성에 필수적이기 때문 ① 코드를 수월하게 읽어 나갈 수 있다. ② 아마추어처럼 보이지 않는다. ③ 형식을 맞춤으로써 버그 위험을 줄인다. 2. 클린코드 포맷팅 - 행 간격 ✔ 적절한 길이 유지 행(row, 세로) : 200Lines 이하 또는 500Lines 미만 → 현업에서의 대부분의 코드들도 200Lines 정도를 유지한다. → 코드 길이가 200Lines을 넘어간다면, 클래스가 여러 개의 일을 하고 있을 수 있다.(SRP위배) "코드 길이를 200줄 정도로 제한하는 것은 반드시 지킬 엄격한 규칙은 아니지만, 일반적으로 큰 파일 보다는 작은 파일이 이해하기 쉽다." ✔ 밀접한 개념은 가까이, 개념은 빈행으로 분리 - 행 묶음은 완결된 생각 하나를 표현하기 때문에 ..

해당 장을 통해 중복👎, 가독성👍, 재사용성👍 할 수 있는 함수 작성 방법에 살펴 보았다. 1. 함수명 ✔ 동사 + 명사 # init public void initData(){..} // 데이터 초기화 # is/has/can public boolean isNumber(){..} // 숫자 여부 판단 public boolean hasData(){..} public boolean canOrder(){..} # create public Board create(){..} // 새로운 객체 생성 후 리턴 # find public Element findElement(int number){..} ✔ 전치사 + 명사 || 전치사 # to public String toString(){..} // String 변환 pub..

클린코드란 성능이 좋은 코드 의미가 명확한 코드 가독성이 좋은 코드 중복이 제거된 코드 나쁜 코드 1) 성능이 나쁜 코드 불필요한 연산이 들어가서 개선 여지 있는 코드 2) 의미 모호한 코드 이해가 어려운 코드 ( ex. 네이밍과 그 내용이 다른 코드 ) 3) 중복된 코드 비슷한 내용이 중복되는 코드 → 버그💣 발생 가능성 증가 나쁜 코드가 나쁜 이유 1) 깨진 유리창 법칙 🔳 나쁜 코드는 깨진 유리창처럼 계속 나쁜 코드가 만들어지도록 한다. 깨진 유리창 하나를 방치해 두면, 그 지점을 중심으로 범죄가 확산되기 시작한다는 이론으로, 사소한 무질서를 방치하면 큰 문제로 이어질 가능성이 높다는 의미를 담고 있다 ( 위키 백과 참조 ) 2) 생산성 저하 🕛 기술 부채를 만들어 수정을 더 어렵게 한다. ( + ..