클리코드

• 책 이름
• 어떻게하면 코드를 깔끔하게 짤 수 있는가?
  • 유지보수가 쉽고 다른사람이 보았을 때 이해가 쉬운 코드

클린코드 작성하기

• 르블랑의 법칙

  • Later equals never
  • '더러운 코드를 치고 나중에 깔끔하게 바꿔야지' 라고 결심하면 결국 더러운 코드가 남는다
  • 처음부터 깔끔한 코드 만들기

• DEBT

  • 기술 부채
  • 지금 당장 편하려고 더러운 코드를 짜면 나중에 유지보수가 매우 어렵게됨
  • 해결하는 방법
    • 리팩토링

• 리팩토링

  • 돌아가는 코드를 클린코드로 바꾸기 위해 코드를 수정하고 class간의 의존성을 떨어트리는 일, 매개변수등으로 하는 입력을 class로 바꾸기
  • 매우매우매우 중요!
  • 코드를 처음 짤 때 완벽하게 짤수 없으니 나중에 수정하고 추가를 해야되는데 그 과정이 매우 힘들 어짐
  • 모듈화를 잘 해놔야됨
  • 코드를 작성하는 시간 vs 코드를 고치는 시간
    • 코드를 고치는 시간의 비중이 더 큼
    • 작성을 다 하였더라도 추후에 발생할 모순 등을 찾기 위해 고쳐야함

• 객체 지향의 5 원칙: SOLID

  • SRP : Single Responsibility Principle
    • 소프트 웨어(변수, 함수)의 부품은 단 하나의 책임(기능)만을 가져야 한다
    • 어떤 언어를 하더라도 중요 한것
    • 하나의 객체, 함수는 하나의 기능만 수행하게 만들기
    • ex) 걷기와 점프를 하나의 함수로 만드는게 아니라 걷기 함수, 점프 함수 따로 만들기
  • OCP : Open - Closed Principle
    • 기존의 코드를 변경하지 않고 기능을 수정하고 추가하는것
    • 모듈식으로 따로따로 만들어놔서 합쳐야함
    • 구현이 어려움 하지만 구현하면 매우 좋음
  • LSP : Liskov Substitution Principle
    • 자식 Class가 부모 Class에서 가능한 행위를 할 수 있어야 한다.
    • ex) 자동차 : 부모 , K5: 자식, → 자동차가 시동이 걸리면 K5 도 시동이 걸려야함
  • ICP : interface Segregation Principle
    • 인터페이스를 하나의 일반적인 인터페이스 보단 구체적인게 낫다.
    • 인터페이스가 참조될 때 또 다른 인터페이스를 참조 하면 안됨
    • 만들일이 많이 없을 것
  • DIP : Dependency Inversion Principle
    • 의존 관계 역전
    • Class A 를 정의 할때 Class B 를 가져다 쓴다면 의존 관계이다.
    • 변환하기 쉬운것 보단 어려운 것에 의존해야 함

• 예외 처리

  • Unity에서는 특히 중요!
  • 물리 엔진을 사용하면 예외 발생이 많음 (non- inception : 존재 하지 않는 것에 접근)

• 유니티 에서의 적용

  • component에 접근해야 하는데 해당 component가 존재 하지 않으면 non- inception 발생
  • Try Catch
  • Null일수 있는것에 접근한다면 일단 Null 인지 확인하기
  • 무한루프가 발생하면 프로그램이 꺼지면서 Scene에서 작업하던게 다 날아감
    • 항상 저장하고 Play 누르기!
    • while(1){}을 사용하지 않고 int T =100000; while(T—){}같이 작성하기
  • 유