ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 파이브 라인스 오브 코드
    기타/내용 2023. 8. 23. 00:06

    완벽은 더 이상 추가할 것이 없을 때가 아니라 더 이상 뺄 것이 없을 때 이뤄진다.

    배운 것을 활용하라.

    가장 단순한 리팩터링은 기능의 변경 없이 코드를 변경하는 것이다.

    리팩터링은 순전히 경제적인 이유이다.

    변경하기 쉽게 만들어라.

    더 잘알 때까지 규칙을 따르라.

    코드 조사가 오래 걸리면 나쁘다.

    함께 변해야 하는 것 끼리 같이 있어야 한다.

    성능 최적화는 리팩터링과는 다른 단계이다.

     

    상속보다는 컴포지션을 활용..

    사용하지 않는 코드를 삭제하라

    보이스카우트 규칙.

    번거롭지만 안전한 코드가 낫다.

    자신감이 떨어지는 이쁜 코드보다 특이한 안전한 코드가 낫다.

     

    동일 수준의 추상화를 사용하자.

    호출 또는 전달 하나만 하자

    sum(arr)과 arr.length는 공존하면 나중에 추상화 수준이 모호해진다.

     

    인생에서 결정은 어려운 것이다.

    그렇지만 if-else는 왜 막힘없이 쓰나. if-else는 컴파일 시점에 동작이 결정된다.

    클래스로 타입 코드 대체

    모든 값에 대한 메서드를 갖는 것은 스멜이다. 

    흔히 한 줄만 있는 경우 인라인화를 한다.

    낮은 수준의 연산이 있는 경우 인라인화가 독일 수 있다.

    작은은 동일한 추상화 수준에 있어야 한다.

    출금 없이 돈을 인출할 수 있는 메서드 -> 인라인화

     

    메서드가 일반적이어서 너무 만능이면 의도하지 않은 기능을 할 수 있다.

    담당 메서드를 만들어서 메서드 전문화를 시킬 수 있다.

    반대 의견도 있지만 더 적게 호출되며 삭제가 간편하다.

    체스 말의 이동의 경우 일반화를 할 수도 있고 말 개인의 고유한 메서드를 만들 수 있다.

     

    switch는 모든 값에 대한 처리가 필요가 없으며 default값에 때려 넣을 수 있다. 새로운 값이 추가되면 잊어서 OR default로 실행시켜야 하는 것 인지 알 수 없다.

    default를 사용하지 않는 것이 좋다.

    인터페이스 대신 추상 클래스를 사용하면 코드의 중복을 줄일 수 있지만 나중에 새로운 유형을 만들 때 override 하지 않아서 문제가 생길 수 있다. 

    커플링도 유발한다. 여러 클래스가 코드를 공유해야 할 때 다른 공유 클래스를 넣을 수 있다.

    상수메서드, 

    조건은 항상 순수 조건이어야 한다.

    질의와 명령을 혼합 x 

    많은 패턴은 전략 패턴의 다른 형태이다. 

    풀 방식의 아키텍처는 내부 구조를 알아야 하지만 푸시방식은 알 필요 없다.

     

    너무 적게 확인하는 것보다 많이 확인하는 것이 낫다.

    주석을 달기보다는 코드를 정리하라.

    도메인 복잡성은 기본적이다. 본질적으로 복잡하다.

    의도적인 연습, 연습을 대신할 수 있는 것은 없다.

     

    최근 개발한 코드가 가장 익숙하다.

    레거시가 많은 곳에서 사용된다면 먼저 익숙해져라. 점진적으로 줄여나가라.

    브랜치는 무료이지만 정신적 오버헤드가 있다.

    문서는 관련성, 정확성, 정답 발견 가능성이 있어야 한다.

    실패한 적 없는 테스트를 신뢰하지 마라.

     

    고통스러울수록 더 시도하라.

    겁을 먹으면 일을 할 수 없다.

    소프트웨어 개발은 결국 도메인을 학습하고 그 지식을 프로그래밍언어로 코드화시키는 것이다.

    지식을 구축하는 가장 효과적인 방법은 실험, 연습.

    불확실한 것을 두려워하지만 그 영역이 우리가 배워야 하는 영역이다.

    위험에 뛰어들라.

    임포스터 신드롬

     

    쉽게 확장하려면 리팩터링과 선견지명이 필요하다.

    코드를 공유하면 변경점이 줄어들지만 한 부분만 수정하는 것이 어렵고 코드를 복제하면 변경점이 많지만 수정이 쉽다.

    복제는 초기 테스트를 하기에 빠르다.

    모든 것을 확장가능하게 만드는 것은 코드를 불필요하게 복잡하게 만든다.

    도메인 관련된 복잡성은 존재할 수밖에 없다. 본질적 복잡성이다.

     

    변경되지 않았다면 아무것도 하지 마라.

    체스는 500년 동안 규칙이 변하지 않았다.

    일반화해야 하는 것은 컨택스트뿐

    단순함을 추구하라.

    피해야 하는 것은 복잡한 코드를 관리하거나 특이한 패턴과 해결책을 통해 창의성을 입증함으로써 똑똑해 보이려는 사람들의 욕망이다.

    시간이 촉박할 때 적당히 깔끔한 코드보다 엉망인 코드를 만듦으로써 리팩토링 표시를 남긴다.

    규칙은 법이 아니라 도구이다.

    팀에서 더 읽기 쉽다고 생각하는 것을 하라.

    댓글

Designed by Tistory.