[인프런 워밍업클럽 3기 백엔드 코드] 1주차 발자국
회고
https://github.com/myc0603/MineSweeper
지뢰찾기 코드를 가지고 리팩토링하는 방식으로 강의가 진행된다고 해서 강의 시작전에 혼자서 지뢰찾기 코드를 짜보았다. 강의를 들으면서 내 꺼에도 적용해볼랬는데, 시간이 모자라.. 다음에 시간내서 해야겠다.
강의를 들으면서 어렴풋이 알고있는 추상화를 비롯한 여러 내용들이 어설프게 적용되어 있는 내 코드를 어떻게 발전시켜 나가야겠구나라는 생각을 할 수 있었다.
원래 하던 코딩테스트 알고리즘 공부를 하면서 같이 할 수 있을 거라 생각했는데 강의하나하나 오래 듣게 돼서 그런지 생각보다 시간을 많이 쓰게 된다. 자연스럽게 걍 빨리빨리 들어버릴까 싶기도 하고 코테공부도 빠르게빠르게 해볼까 싶어지는데 이럴때마다 속으로 급해지지 말자고 되새긴다. 아직 공부 시작한지 얼마 되지 않았고, 내 스타일대로 진득하게 공부해야 실력이 오르지, 급하게 쫓아가기만 해서는 안될 거 같다는 생각이다. 계속 꼼꼼히 하고, 공부시간을 최대한 더 늘려보자...!!
강의 내용
추상, 논리, 사고의 흐름
이름 짓기 : 내가 너무 긴 이름을 사용하는 걸 지양하고 있었구나를 느꼈다. 이름이 너무 길면 코드가 좀 지저분해 보이기도 하고 가독성이 떨어지는 거 같은 느낌도 들었는데 강의가 진행되면서 내 코드의 가독성 문제는 다른 데 있었음을 알 수 있었다.
메서드 추출, 추상화 레벨 : 내가 코드를 작성할 때의 가독성 문제가 바로 추상화 레벨에 대한 고려가 없었기 때문에 생겼다는 걸 알 수 있었다. 메서드 추출은 나름 가독성을 위해서 아니면 메서드 자체가 복잡해지지 않게 하고 나름 메서드를 봤을 때 어떤 역할을 하는지 알 수 있게 하기 위해 하긴 했는데 추상화 레벨을 고려하면서 한 메서드 안에서는 사용되는 로직, 메서드들의 추상화 레벨이 같아야 함을 알 수 있었다.
뇌 메모리 적게 쓰기라는 강의에서 사실은 사람이 모든 걸 기억할 때 추상화해서 기억하고 정보를 저장한다는 것을 알았다. 이전에 사람이 망각하는 이유에 대해선 단순히 나쁜 기억을 뭐 오래 기억하지 않기 위해서? 뭐 이런식으로 알고 있었는데 이런 것도 뇌가 효율적으로 정보를 처리하고 사고도 같은 추상화레벨에서 효율적으로 사고하기 위해서구나를 느꼈다. 그래서 코드를 읽을 때에도 같은 추상화레벨의 내용이 계속 읽힐 수 있도록 신경써줘야 한다는 점을 느낄 수 있었다.
예외처리 : 예외를 개발자가 애플리케이션 내에서 의도해서 사용하는 예외와 원하지 않는 예외를 구분해서 사용해야 한다는 것을 알았다. 의도해서 사용하는 예외는 자바에 원래 있던 예외와 구분하기 위해 새로 만들어서 사용하는 것이 좋다.
객체지향 패러다임, 적용
setter를 사용하지 않아야 한다는 것은 알고 있었지만, getter도 사용에 주의해야 한다는 점에서 객체지향에서 유의해야 하는 것이 뭔지, 객체지향에서 각 클래스가 맡아야 하는 책임에 대해서 생각해 볼 수 있었다. getter로 얻은 데이터와 관련된 어떤 정보나 동작을 원할 때 그 정보나 동작을 해당 객체가 맡아서 할지 그 객체를 호출하는 client쪽에서 맡아야 할지에 대한 고려가 중요하다.
SRP 책임에 대해서 잘 생각해 봐야 한다. 한 객체가 맡은 여러 행동(메서드)들이 과연 하나의 같은 책임에서 비롯된 것인지 분리될 수 있는 것인지 고려해봐야 한다.
OCP 나중에 바뀔 수 있는 부분에 대해서 유연하게 동작할 수 있도록 코드를 작성한다. 예를 들어 DIP를 적용해서 사용하는 기능,모듈을 추상화해서 사용하는 것도 OCP원칙을 지키는 것이다.
LSP 상속은 기능 확장이다. (자바의 예약어도 extends이다.) 기능 확장이라는 것은 원래의 기능을 바꾸는 것이 아니라 원래의 기능에 더해서 새로운 기능을 추가하는 것이다.
ISP SRP의 인터페이스 버전. 어떤 인터페이스를 구현하려는 클래스에서 인터페이스에 선언된 모든 메서드를 선언할 필요가 없다면 해당 인터페이스는 하나의 책임이 아니라 둘 이상의 책임을 맡고 있는 것이다. 인터페이스가 하나의 책임만 맡도록 분리해야 한다.
DIP 사용하는 기능과 모듈이 너무 저수준의 모듈이라서 변경가능성이 높다면 추상화해서 추후에 기능 확장 또는 변경에도 코드의 변경이 없도록 한다.
Value Object : 변수에 이름만 짓는다고 그 값에 의미가 생기는 것이 아니다. 제대로 의미를 부여하고 싶다면 그 값을 감싸는 클래스를 만들어 원하는 기능을 만들어주거나, 유효성 검증 등을 해줄 수 있다. 객체로 감쌌기 때문에 equals() & hashCode(), final 필드 선언을 통해 동등성과 불변성을 갖도록 해준다.
일급컬렉션 : 비즈니스 로직에서 어떤 컬렉션은 의미를 갖는다. 뭔소리냐면 전용 로직이 필요할 수 있단 소리. -> value object와 마찬가지로 감싸서 사용할 수 있다.
ENUM : 구현체들을 커스터마이징해서 사용할일이 없거나 변경할 일이 없고, 상수로서만 사용할 때는 enum 타입 활용
다형성 활용 : 강의 예제의 반복적인 if문 -> 추후에 추가적인 변경사항이 있을 때 많은 수정이 필요, 리팩토랭을 요함. 변하는 것과 변하지 않는 것을 확인. if문의 조건을 인터페이스화 시키고 각각의 조건을 구현체로 만든다. 조건에 해당하는 행위는 그 구현체의 메서드로 구현한다.
미션
DAY2 : 추상화에 대해서 깊이 고민해볼 수 있는 시간을 가질 수 있었다. 일상의 일을 나름의 추상화 레벨를 나누어 구체적으로 설명해 보았다.
DAY4 : 강의를 들으면서 노션에 적어놓은걸 정리해 미션을 완료했다. 다른 강의들을 때 지나가듯이 흘려 들었던 내용들이 촥 정리가 되었고, 그 이전 강의에서 어떤어떤 부분들이 SOLID의 어떤 원칙을 적용한거구나를 깨달을 수 있었다. 다음 미션이 그 다음 코드를 강의 듣기전에 미리 리팩토링 해보는 것 같던데 한번 기똥차게 리팩토링 해보고 싶다.
댓글을 작성해보세요.
