ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 2주차 리뷰
    우아한 테크코스/테크코스 2020. 2. 15. 18:31
    반응형

    중복 코드 유의하기

     코딩할 때 중복 코드에 유의하기

     유의해야 되는 이유 - 불필요한 작업 제거하여 성능 향상(시간 단축, 불필요한 리소스 감소)도 있지만 로직이 변경되었을 때, 중복 로직을 모두 수정해줘야 함(불필요한 리소스). 또한 중복 로직을 체크하지 못하는 경우 문제(사이드 이펙트)가 생길 수 있음.

    String 비교시 ==와 equals

     ==는 String 객체의 주소값을 비교하고, equals는 String 객체의 문자열 값을 비교. Java 7 ~ String Pool의 위치가 Perm 영역에서 Heap영역으로 변경됨(즉, String Pool에 위치하는 String 상수의 경우에도 GC가 가능하다는 의미), 이에 꼭 equals로 비교해야 함

    깔끔한 코드를 위하여

     클래스 변수와 인스턴스 변수 사이에 공백 라인을 하나 넣어주면 가독성을 향상할 수 있음

    toString에서 View로 내보낼 값을 가공해서 보내주면 안되는 이유

     클라이언트의 요구가 변경되어 View를 바꿀 경우, toString을 매번 변경해주어야 함. 또한 여러 View 형태를 표시할 수도 없음. 도메인은 View가 변경된다고 변경되어서는 안 됨.(객체지향)

    검증 로직은 도메인에서

     검증 로직이 도메인이 아닌 View나 Controller에 위치할 경우, 비슷한 View나 Controller 생성시 중복 코드가 발생할 수 있고, 다른 사람이 작성할 경우 검증을 Skip할 수도 있기 때문에, 검증 로직은 Domain에서 하는 것이 좋음

    변수명에 자료구조 타입 넣지 않기

     리팩터링을 하다보면 자료구조를 변경할 일이 생기는데 (예 List > Set), 변수명에 자료구조를 넣어두다보면 자료구조를 변경할 때마다 변수명을 변경해줘야 하거나, 변수명으로 해당 변수를 오해할 수 있게 되기 때문에, 자료구조 타입 넣지 않기

    한 클래스에서 많은 일을 하지 않기

     한 클래스가 많은 일을 하다보면, 테스트 및 검증이 어려워짐, 또한 역할이 섞여버릴 수도 있음. 이는 바람직하지 않기 때문에 각자 역할에 맞는 일을 시켜주기

     한 클래스에서 많은 일을 할 경우 리팩토링도 힘들어지고, 재사용시에도 불편함(무거움), 중요도가 너무 높아져버려 수정도 쉽지 않아짐

    생성 비용이 큰 객체의 경우, 재사용할 수 있도록 하기

     생성 비용이 큰 객체는 반복문 등에 인해 계속 생성해줄 경우 성능에 영향을 줌, 객체는 재사용시 훨씬 빠르고 효율적임

     단, 생성 비용이 작은 객체의 경우 명확성이나 간결성을 위해 객체를 새로 생성하는 것도 나쁘진 않음(JVM 신뢰)

    equals("")와 isEmpty()의 차이

     isEmpty의 경우 length가 0인지만 검증 

     equals의 경우, 비교시 Type과 Length가 일치한지 확인하고, 일치한 경우 문자열 ""와 비교를 하게 되어 더 느림

    +""를 사용하지 말고, toString을 사용하자

     API 사용하기 귀찮아서 +""로 하는 버릇이 있었는데, toString으로 변환해주기

    문자열 또는 값을 메서드 내에 하드코딩하지 말고, 클래스의 상수로 빼내주기

     두 번 이상 사용할 경우 중복 제거 효과도 있고, 관리시 위에서 수정해주는 것이 더 편리함. 또한, 긴 문자열이나 메서드의 경우 해당 값이 왜 들어갔는지 와닿지 않는 경우도 있는데, 상수로 빼두면 이름을 지어둘 수 있기 때문에 작성자의 생각을 조금 더 빨리 알아챌 수 있는 장점도 있는 것 같음

    객체에서 값을 빼는 경우엔, 그 객체에서 꼭 값을 필요할 때만!

     객체 생성한 이후에 (생성시 검증 작업), 바로 그 값을 꺼내서 옮기지 말자. 객체에서 값을 꺼낼 때는, 꼭 그 객체에서 값을 꺼내와야하는 그 타이밍에만! 하는 것이 좋다.

     그래야만 진짜 필요한 작업에서 어떤 타입이 필요한지 정확하게 명시할 수 있고, 데이터의 변조도 막을 수 있고, 코드 확장시 혼선을 빚지 않을 수 있다 :)

     원시값으로 받으면 가공은 편할 수 있지만, 사용시 어떤 검증이 있는지 확인할 수가 없음!

    Factory에 대한 부분

     클래스명이 Factory인 것은 보통, 해당 객체들을 외부에서 생성하기 위한 클래스

     즉, setter와 getter가 모두 외부에 열려있어야 함!

     단순히, 객체들을 가지고 있다고 해서 그것이 Factory인 것은 아님을 유의

     Factory는 생성자를 가지고 있지 않음!

    공부해야 할 부분

     mvc, dto, 자주 쓰이는 명명 규칙, 자바 API 등

    반응형

    댓글

Designed by Tistory.