1. 사전 조건을 미리 반환해 방어해라

    def some_fun(data: object):
    	someThing...
    	if condition:
    		"어쩌구 저쩌구 로직..."
    		return 결과값
    	else:
    		return 결과값  
    
    # Better 
    def some_fun(data: object):
    	someThing... 
    	if not condition: # 예외 케이스들을 먼저 파악해 분리
    		return 결과값 
    	preprocessLogic.. # 조건에 맞는 데이터 라고 가정하고 동작한다! 읽기 쉬워짐!!
    	return 결과값 
    
  2. 안쓰는 코드는 지워라, 필요하다면 형상관리 툴을 이용해 복구 하라

  3. 코드의 일관성을 유지해라

    // Bad | Cause: Many Running Case!
    var value
    if (value == null){
    	Some Code...
    }
    return value
    
    var value
    return value ?: SomeCode...
    
    var value
    return value?.let{SomeCode} ?: run {SomeThingCode} // 모두 다른 동작 같은 결과.
    
    // Better 
    var value
    return value?.let{...}
    
    var value
    return value?.let{...} // 여러 방법 보다 일관성 있게 작성해두면 읽기 편해진다
    
    
  4. 기존 인터페이스가 복잡하면 이를 호출하는 인터페이스를 작성해서 개발해라?

    1. 점진적으로 대체 하라
  5. 독자의 입장으로 코드를 정렬해두어라

  6. 결합도가 높은 코드끼리는 같이 두어 응집도를 높여라(같은 폴더, 같은 파일)

    1. 결합도를 제거 하는게 가장 좋지만 현실적인 이유로 못한다면 차후에 진행해도 괜찮다
  7. 초기화와 선언은 같이 두어라 미리 초기화 해두면 복잡해진다

    value = None
    data = None 
    변수 value사용안함.. 
    변수 value사용... 
    변수 data사용.. 
    변수 value, data 사용... 
    
    # Better
    변수 value사용안함.. 
    value = None
    변수 value사용...
    data = None
    변수 data사용..
    변수 value, data 사용... # 초기화와 선언을 같이 두니 훨씬 읽기 편해졌다!
    
  8. 설명하는 변수를 두어 읽기 편하게 하라

    return DataType(
    	LongFunc... 
    	LongLongFunc...
    ) 
    # Better
    data_value = LongFunc...
    data_location = LongLongFunc...
    return DataType(
    	data_value, data_location # 인자가 구체적으로 어떤것인지 파악 가능해졌다!
    )
    # NamedParameter를 사용하고 매개변수의 명칭이 명확하다면 NamedParameter가 더 깔끔한것 같다
    
  9. 상수에 이름을 붙여 설명하는 상수로 변경해라, 의미가 모호한 매직넘버 금지…

    if status == 404: 
    # Better 
    if status == PAGE_NOT_FOUND:
    # 명시적! 한눈에 바로 알아 볼 수 있다.
    
  10. 명시적인 매개 변수, 내부 데이터를 명확하게 알 수 있게 하자

    person = {
    	"age": 20, ...
    }
    # Better
    class Person:
    	age: int = 20 
     
    person = Person() 
    person.age # Wow!
    
      1. 비슷한 코드 끼리, 도우미 함수 추출, 하나의 더미(응집도 높이기)
    def some_thing():
    	some_thing_a...
    	some_thing_a...pre_process 
    	# 공백을 두어 뭉쳐두자!
    	some_thing_b...
    	some_thing_b...pre_process 
    	
    def some_thing_helper():
    	some_thing_a...
    	pre_process(some_thing_a)
    	# 공통되는 부분은 도우미 함수를 추출해 재사용하자!
    	some_thing_b...
    	pre_process(some_thing_b) 
    	
    def pre_process(func: Callable[[some], value]): ... 
    	
    # 응집도를 높여 하나의 더미로 만들자! 관련된 기능을 찾기 편해진다!
    def some_thing_cohesion():
    	a_logic(), b_logic()
    
    def a_logic():
    		value = some_thing_a...
    		pre_process(value)
    
    def b_logic(): ...
    
  11. 문제를 주석없이 묻어두는것 보다 이유와 배경, 문제를 적어두는게 차라리 낫다

  1. 필요없는 주석은 지우자 ㅎㅎ.. 2번과 이어지는듯

    def func():
    	# return a ?왜 존재하는가  
    	return a
    
    def func2():
    	if value:
    		# 값이 존재하면!
    		... 
    	else value:
    		# 값이 없으면!
    		... 
    # Better 
    def better_func():
    	# Guard Clause
    	if not value:
    		return ... 
    	...Code!
    
  2. 코드 정리 구분 ex: PR

    1. 개인적으로 선호하는 방식 최대한 작게 쪼개면 리뷰도 간단해진다 → Readable
    2. 최대한 작은 단위로 Feature를 나누어 개발 하면 복구도 쉽더라
  3. 연쇄적인 정리

    1. 코드를 정리 및 관리 하다보면 연쇄적으로 하고싶은 욕구가 든다
    2. 하다가 지칠수도 있고 비용이 많이 들 수 있기에 작은 단계부터 하나하나 적용 해보자
    3. 너무 많이, 빠르게 변경하지 않도록 조심해라 순차적으로 천천히 하는게 무리해서 하다가 실패하는것 보다 낫다
  4. 코드 정리의 일괄 처리량

    1. 코드 정리를 많이 할수록 다른이 와 통합과정은 지연된다
    2. 다수의 코드 동작을 변경 하면 이와 상호 작용하는 코드들의 병합 비용이 늘어난다
    3. 팀과 함께 검토하고 조금씩 자주 해라
  5. 리듬

    1. 코드 정리에 한시간 이상이 걸리면 구조 변경 시기를 놓쳤을수도 있다..
    2. 하지만 때로는 시간을 많이 들여서라도 정리하는게 장기적으로는 더 좋을수 있다(기술부채)
    3. 통행로를 만들때 잔디를 모두 심고 나중에 닳아 없어진 부분을 길로 만들어도 된다
      1. dry, yagni!
  6. 얽힘 풀기

    1. 코드끼리 얽힌걸 풀려고 할때
      1. 작업하던걸 그대로 배포하거나 (빠른 배포, 기술 부채)
      2. 정리와 변경을 나눠 pr을 여러번 하거나 (작업 횟수 증가, 커밋 일관성 부재)
      3. 진행 중인 작업을 버리고 코드 정리를 먼저 진행 할 수도 있다 (작업 횟수 증가, 커밋 일관성)
    2. 컴퓨터에게 만 지시하는게 아니라 사람에게도 지시하려는 의도를 설명해야 한다
    3. 3번으로 가자 명확함은 나중에 작업할때 유리하다
  7. 코드 정리 시점

    1. 코드를 정리하기에 적절한 시점은 없다 → 흥미를 가질때 즉시 시행하자
    2. 때로는 동작을 먼저 변경하고 코드 정리를 수행하는것도 좋은 방법이다.
      1. 얼마후 또 고쳐야 하거나, 정리와 변경에 드는 시간이 비슷하거나, 지금 정리하는게 더 싸거나
    3. 대부분은 코드 정리후 동작 변경이 이롭다
      1. 지저분한 상태에서 코드 정리를 하면 일이 얼마나 더 어려울지 생각하자.
      2. 코드를 잘 모르고있을때
    4. 정리와 변경중 무엇을 우선시 할지 선택 팁
      1. 코드 정리 하지 않기
        1. 앞으로 다시는 코드를 변경할 일이 없을때 → 아마 최소 1~2년은 사용할때
        2. 설계를 개선해도 배울 것 이 없을때 → 분석하지 않아도 될때 → 도메인 지식 높음
      2. 나중에 정리 하기
        1. 정리할 대상은 많지만 보상이 바로 피드백이 되지 않을때
        2. 작게 쪼개어 정리가 가능할때
      3. 동작 변경후 정리
        1. 다음 코드 정리를 기다릴수록 비용이 상승할때
        2. 코드 정리를 하지않으면 일이 안끝났다고 생각될떄
      4. 코드 정리후 동작 변경
        1. 코드 정리를 했을때 이해도가 높아질때
        2. 어떤 코드를 어떻게 정리할지 생각이 정리 되었을때
  8. 요소들을 유익하게 관계 맺는법

    1. 시스템은 여러가지 작은 부분들이 집합체를 이루고 이런 집합체들을 다시 묶어 시스템을 만들어낸다
    2. 전역 네임스페이스를 사용한 어셈블리가 외부에선 빠르게 동작하고 좋아보이겠지만 그만큼 변경에는 약해질것이다 → 드러나지 않는 관계가 많아지기 때문이다
    3. 특정 함수를 위한 보조 함수를 만들면 더 명확한 관계와 구조를 표현 할 수있다
    4. 핵심은 요소 계층 구조와 그 관계 그리고 이러한 관계가 만들어내는 이점이다
      1. 단일 책임, 명확한 역할, 명확한 구조