단순히 많은 기능을 구현할 줄 안다고 좋은 개발자가 아니다.
효율적이고 확장성 있는 코드, 유지보수가 용이한 코드를 작성할 줄 아는 개발자가 좋은 개발자다.
학습의 과정에서도 많은 기능을 구현하는 것에 치중하기보다 하나의 기능을 구현하더라도 좋은 코드가 무엇인지 혼자 충분히 고민하는 것이 필요하다.
유지보수
- 코드는 한번 작성되고 끝나는 게 아니라, 계속해서 많은 추가와 수정을 겪는데, 이를 유지보수라고 한다.
- 유지보수를 용이하게 하기 위해서는 코드의 가독성과 확장성이 좋아야한다. -
**Refactoring**은 코드의 가독성과 확장성을 좋게 만드는 작업이다.
Self-Refactoring
- Refactoring: 소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법
- 리팩토링을 해서 '성능이 좋아졌다' '기능이 좋아졌다'는 것은 잘못된 말이라고 할 수 있다. 개발자가 코드를 이해하고 유지보수하기 쉽도록 만든 것이기 때문에 사용자 입장에서는 달라진 게 없다.
- 유지보수하기에 용이한 프로그램을 만들어야 소프트웨어의 변화에 대응할 수 있고, 동료 개발자와 나를 위해 꼭 필요한 절차다.
cf. 레거시 코드(legacy code): 유산처럼 남기고 간 코드. 한마디로 쓰레기라 쓸 수 없고 화나게 만드는 코드.. - 셀프 리팩토링을 해야 하는 이유는 코드 리뷰를 할 때 커뮤니케이션을 위함도 있다. 나도 알고 있는 부분만 리뷰를 받을 수도 있고, 그렇기 때문에 진짜 중요한 실수/수정사항을 놓칠 수도 있다.
- 스스로 좋은 코드의 기준을 세우고 리뷰를 받아야 더 좋은 코드를 짤 수 있다.
self-refactoring 기본 체크리스트
Basic
- console.log 지우기
- id, class, 변수, 함수 이름은 의미가 직관적으로 드러나게 작성 (코드는 쓰는 경우보다 읽히는 경우가 훨씬 많다.)
- 규칙성 있는 들여 쓰기는 가독성 측면에서 중요하다. (JavaScript는 2칸 들여 쓰기가 컨벤션)
HTML
- Semantic Tag 사용
- img tag를 사용할 때 반드시 alt 속성 부여하기
- 이미지가 로딩되지 않을 경우 alt 속성에 적힌 값이 보여진다.
- 시각 장애가 있는 경우 alt 속성을 통해 어떤 이미지가 보여지는지 알 수 있다.
- 검색엔진최적화(SEO)에서 img를 인식하는 코드는 alt 속성이다.
=> src 속성보다 alt 속성을 먼저 작성하는 것이 좋다!
- Self Closing이 가능한 Tag들은 적용시킨다. (
<br> <hr> <img> <meta> <link> <input>)
CSS
- CSS 속성 순서
- CSS 속성은 레이아웃에 영향을 많이 주는 순서대로, 인접 속성끼리 묶어서 작성해주는 것이 좋다.
- 권장되는 속성 순서
1. Layout Properties
(position, float, clear, display)
2. Box Model Properties
(width, height, margin, padding)
3. Visual Properties
(color, background, border, box-shadow)
4. Typography Properties
(font-size, font-family, text-align, text-transform)
5. Misc Properties
(cursor, overflow, z-index)- 다른 CSS 선택자들 사이 한 줄 띄우기
- 불필요한 style 속성 작성 지양
(block 요소에 불필요하게display:block;width:100%을 부여)
- CSS Default Values Reference
10. 레이아웃은 bottom-up 방식으로 구성한다. - 레이아웃을 구성할 때 부모요소의 높이를 미리 정해두고 자식요소의 크기를 정하는 top-down 방식이 아닌, 자식요소의 높이에 따라 부모요소의 높이가 유동적으로 결정되는 bottom-up 방식으로 구성한다.
- 레이아웃을 구성할 때 부모요소의 크기를 고정적으로 정해둔다면, 자식요소의 크기가 변함에 따라 부모요소의 크기가 유동적으로 변하지 않는다.
- 이런 상황에서 만약 자식요소의 크기가 변해야 한다면, 부모요소의 CSS도 같이 수정해줘야 하는 불편함이 있고,
- 이런 구성이 겹겹이 쌓인다면 추후에 CSS 유지보수가 매우 힘들어진다. (CSS 유지보수가 Javascript 유지보수보다 힘들다🤣)
// bad
.feedList {
height:100vh;
}
.feed{
height:300px;
}
// good
.feedList {
padding-top:20px;
}
.feed{
height:300px;
}- feedList안에 여러개의 feed가 들어있는 상황이라면
(feedList > feed * n)
bad case
- feed들을 감싸고 있는 feedList에 고정 height를 부여했다.
- feedList가 안에 feed가 얼마나 생성될지 모르므로 feedList의 크기는 feed의 개수에 따라서 유동적으로 조정되어야 한다.
- feedList는 고정 height를 가지고 있으므로 feed가 1개일 때도, 그리고 20개일 때도 똑같이 100vh의 height를 가지고 있다.
- 즉 자식요소의 크기에 따라서 부모의 크기가 유동적으로 조정이 안되고 있다.
good case
- feedList에는 고정 height를 부여하지 않았다. 이 경우에는 feedList의 크기가 자식요소의 크기만큼 자동으로 조정된다.
- 즉, feedList의 높이가 내부의
자식요소의 높이 + 20px(padding-top 값)로 유동적으로 변할 수 있다. - 그러므로, 레이아웃을 구성할 때는 자식요소에 따라 부모요소가 조정되도록 bottom-up 방식으로 구성하는 것이 좋다.
