[1+2] 깨끗한 코드&의미있는 이름

Introduction

코드 리뷰 시간을 줄이기 위해 클린코드라는 책을 읽고, 매주 책 내용에 대한 토의 및 개발한 코드 중 개선할 부분을 찾아보기로 하였다.

 

---

Clean-Code

1장. 깨끗한 코드

Software

• 유연해서 소프트웨어라지만 아니다!
  • models 같이 low한 영역일수록 고치기가 더 어려워짐
• 코드는 항상 클린한 상태를 유지하도록!
• 더러운 코드에 기능만 붙이다가 어느 순간 기능을 추가할 수 없는 코드로 변질 -> 몰락
  • 넷스케이프 흥행과 몰락

추상화는 어려워

• Minter 앱 개발 당시, Queue -> Serial Pool로 변형
• 클래스의 상속이나 캡슐레이션 같은 추상화말고 기능적인 측면에서 어떤 부분을 추상화시킬지는 항상 고민하면서 구현해야 한다

---

Clean-Code. Meaningful names

2장. 의미있는 이름

data라는 변수를 툭 사용하지 말것

# data = {

not_valid_response_data = {
    "canWithdraw": False,
    "reasons": []
}

destroy_response_data = {}

그릇된 정보를 피하라

• 프로그래머에게 List라는 단어는 특수한 의미이다. 실제 List가 아니라면 사용하지 않도록 한다.
• 예시 1
• issue_list -> issue issue_history -> issue_detail history도 쌓아가는 느낌이여서 daniel도 헷갈려하셨음.
• 예시 2
• mcard_id = data.get('mcard_id', None) if not mcard_id: mcard_id = data.get('mcard_serial', None) # python은 변수명에 의존성이 높기 때문에, serial 데이터인데, mcard_id라는 값으로 칭하면 오해의 소지가 크다.

단수 V.S. 복수

db_table: 복수형
model(entity): 단수형
app: 복수형

*_history history와 같이 자체적으로 collection을 나타내는 경우, 의미전달에 모호할 수 있음을 인지한다.

(history를 대체할 만한 네이밍으로는 *_event, *_log, *_record등이 존재함)

URL naming && path

1. 큰 순으로 정렬

• minter/api/v1/{collections}/{id}
• 쿠버네티스에 일일히 매핑을 해줘야해서 api/minter 순으로 네이밍해서 묶으면 안될까요?
  • ㅇㅇ 안됨
  • 그룹이 큰순으로 path가 정의되는데 api가 앱보다 앞으로 나가는게 이상해

2. 동사를 사용해도 될까?

• 상황에 따라 다름
• 단 행위의 주체가 되는 colleciton(개체)이 드러나도록 구성한다.
• RESTful API 설계 가이드

TODO

• is_withdraw_finished -> 다른 네이밍이 없을까
• collection을 추가해서 fantem/api/fantem/is_withdraw_cb_finished ?
• minter/api/verify -> minter/api/user-verification