[워밍업클럽 3기] - BE클린코드/테스트코드 1주차 발자국

일주일 학습 내용 요약 추상잘못된 추상화가 야기하는 사이드 이펙트는 생각보다 크다. 그렇기 때문에 추상화를 잘 해야 한다.'적절한 추상화'는 해당 도메인 안에서 정말 중요한 핵심 개념만 남겨서 표현하는 것이다.추상화를 잘 하기 위해서는 적절한 '이름 짓기'를 잘 해야한다.관용어 처럼 사용하는 이름이 아니면 줄여 쓰는 것은 좋지 않다.잘 쓰여진 글은 하나의 문단에 하나의 주제가 들어가 있다. 생략할 정보와 의미를 드러낼 정보가 무엇인지를 잘 생각해보자.메서드 명에는 그 안에 담긴 코드를 유추할 수 있는 적절한 의미가 담긴 이름을 지어줘야 한다.반환 타입, 메서드 명, 파라미터에 담긴 이름을 읽을 때 의미를 파악하기 위해 고민이 길어진다면 이름을 다시 생각해 볼 필요가 있다.한 줄의 코드라도 추상화가 필요하다면 하는게 좋다. 코드의 양 보다 코드의 의미가 중요하다.상위 추상화 레벨로 추상화가 가능한지를 고민해 보자.추상화를 한 후에도 추상화가 잘 됐는지 계속 고민해야 한다.논리, 사고의 흐름최소한의 인지로 최대의 효율을 내보자.early return으로 else의 사용을 줄여보자.사고의 depth를 줄이자.부정어구를 쓰지 않아도 되는 상황인지 고민해보자.예외 상황을 꼼꼼히 체크하여 처리하는 것이 개발자의 역량이다.객체 지향관심사에 따라 기능과 책임을 나누자 -> 유지보수성이 높아진다.각 관심사 끼리는 결합도가 낮아야 한다.setter의 사용은 자제하자. getter도 꼭 필요할 때 만들어 사용하자.SOLIDSRP(Single Responsibility Principle)하나의 클래스는 하나의 책임만 갖도록 설계해야 한다.OCP(Open-Closed Principle)확장에는 열려있고 수정에는 닫혀있게 설계해야 한다.LSP(Liskov Substitution Principle)부모 클래스의 인스턴스를 자식 크래스의 인스턴스로 치환할 수 있어야 한다.ISP(Interface Segregation Principle)사용하지 않는 인터페이스에 의존하지 않게 인터페이스를 작게 쪼개 사용하자.DIP(Dependency Inversion Principle)상위 수준의 모듈은 하위 수준의 모듈에 의존해서는 안되고 둘 다 추상화에 의존해야 한다.일주일 간의 학습 내용에 대한 회고 강의의 첫 시작은 가볍게, 재미있게 들었던 것 같다. 그렇지만 내용은 정말 묵직하고 단단했다.추상, 메서드 이름 짓기, 상수, 등이중요하다는 것은 이미 많이 듣고, 읽고, 사용해 보았다. 그러나 강의를 들으며 '지금까지 내가 알고 있던 것들이 제대로 알고 있던 거였을까?' 하는 생각이 들었다.강의를 들을 수록 이미 알고 있었다 생각했던 것들이 머리 속에서 새롭게 정리가 되는 것 같았다.많이 듣고 알고 있다고 했던 개념들이 눈에 보이는 자료와 적절한 비유를 통해 더 또렷해졌다.그만큼 각 개념에 따라 적절한 비유를 재미있게 잘 설명해 주셨다. 개인적으로 추상에서 노래방을 아주 구체적으로 풀어쓴 예시가 너무 재미있었고 이 때부터 강의에 더 빠져들었던 것 같다. 초반부를 지나 점점 내용이 깊어지고 코드를 따라 변경해보며 각 개념을 어떻게 적용 시켜야 하는지도 알 수 있었고이름 짓기의 중요성을 특히 더 느끼게 되었다. 그러나 과제를 진행해 보면서 듣는것과 직접 해보는건 또 다르다는걸 다시 한번 느꼈다. 강의를 들으면서는 정말 잘 이해됐고 앞으로 이름 지을 때 조금 더 잘 생각해낼 수 있을 것 같았는데,생각보다 바로 바로 떠오르지 않았다. 강사님이 말한 것 처럼 많은 고민히 필요한 부분임을 느꼈다. 강의가 진행되면서 개념을 새롭게 정리하고 그 개념을 도입하며 코드가 변화되어 가고 읽기 쉬운 코드로, 유지 보수 하기좋은 코드로 변해갔다. 코드를 따라 변경해 보면서 '어떻게 이렇게 구상하셨을까?' 하는 생각이 들었다.한 번의 리팩토링에서 끝나는게 아니라 또 다시 더 좋은 코드로, 더 더 좋은 코드로 변경되어 갔다. 그만큼 엄청난 고민이 있었으리라 생각이 든다. '이 스터디를 마치고 나면 나도 조금은 더 좋은 코드를 작성할 수 있게 될까?'싶은 생각과 언젠간 강사님 처럼 강의 내용과 같은 생각의 흐름이 자연스러운 개발자가 되도록 해야겠다는 생각이 들었다.한 번의 완강이 끝이 아니라 때때로 한 번씩 보면서 내가 현재 놓치고 있는게 무엇인지도 되돌아 보면 좋을 것 같다.칭찬하고 싶은점아직까지는 요일별 강의 분량을 잘 듣고 따라가고 있다. 아쉬웠던점현재 중요한 일정을 앞두고 있어 후반부로 갈수록 강의를 쫓아가기 바빠졌고 그러다보니 미션에 대해 깊은 고민을 하지 못한 것 같다.보완하고 싶은 점뒷부분 강의는 다시 들어보며 조금 더 이해를 도와야 할 것 같다.다음 주 목표시간 분배를 잘 해서 미션의 의미를 잘 생각해보고 제출하기 바쁘기 보단 정말 고민하고 내것으로 만들도록 해야겠다.미션 요약어떤 관점에서 접근했는지, 문제를 해결하는 과정은 무엇이었는지, 왜 그런 식으로 해결했는지 day2 미션은 그렇게 어려운 미션은 아니었기 때문에 그냥 가장 먼저 떠오르는 것을 생각해보고 그게 추상적인 것인지,구체적인 것인지를 생각해 추상과 구체를 나누어 보았다. day4미션은 내가 생각한 것보다 시간이 더 오래 걸리는 문제였다. 그래서 너무 늦게 시작해 충분한 고민과 더 좋은 코드로 리팩토링을 하진 못했다. 처음에는 그 코드를 바꾸기 위한 세팅과 나머지 필요한 부분까지 잘 구현하고 싶었는데, 일단 다 구현할 필요는 없다고 하여 중요 포인트를 먼저 리팩토링 하기로 했다.일단 강의를 들으며 짚어 주셨던 빠른 리턴과 뎁스의 깊이, 부정 연산자가 눈에 띄었다.그리고 꼭 필요한 것 같지 않은 getter가 많이 보였다. 그래서 getter 대신 객체에 물어보는 형식으로 이름을 지어주었고,else로 복잡하게 작성된 코드들도 early return을 사용하여 정리해 주었다. 그리고 부정 연산자를 사용할 필요가 없을 것 같아 부정연산자 없이 사용할 수 있도록 메서드 이름에 부정의 의미를 담아 주었다.이름을 조금 더 잘 지어줄 수 있는지에 대한 고민을 충분히 하진 못했던 것 같아 추후에 다시 한번 리팩토링을 해보고 다른 분들의 코드도 참고해 보면서 더 좋은 코드를 작성할 수 있도록 해야겠다.좋은 코드를 많이 보는 것도 좋은 거라 하셨다:)