갑자기 너무 추워지더니 금새 또 포근해지는 한 주...
1주차 전반기까지는 손을 꺼내서 다니는 것조차 힘들정도로 한파가 밀려오더니, 후반기부터는 또 포근해진 가을날씨로 당장 뛰쳐나가 돌아다니고 싶어지는 날들이였다.
제 버릇 남 못준다고 잘 참아왔던 책쇼핑... 다시 시작한 것 같다.
이번 주 즐겨들었던 집중용 음악
요즘 유튜버 우든체어의 노래를 즐겨듣는 것 같다. 하이퍼포커스 책에서 말하는 배경노래는 가사가 있어서는 안되고, 리듬이 너무 복잡해서는 안된다고한다. 가사가 있거나 리듬이 복잡할수록 거기에 집중하기 때문이라고 한다.
거기에 적극 동감하는게 원래 나는 즐겨듣는 노래방 노래를 유튜브 뮤직에 재생목록으로 저장 해 놓는데, 그 노래들만 틀면 따라부르기 바쁘기에 오히려 집중을 깨는 경우가 많았기 때문이다.. 하하..
codepen.io
나는 종종 codepen.io를 가서 재밌는 pen이 없나 보곤한다. 그래서 유쾌하거나 유용해보이는 pen들은 fork해놓고 참고하고는 하는데 이번에 임포스터를 구현한 pen이 있어서 바로 사용해본다 ㅎㅎ
1. TDD, Clean Code with Java - 첫 번째 미션 종료
1단계 자동차경주 미션의 5스텝이 모두 merged되며 1단계 미션 종료가 되었다.
자동차 경주 자체는 기능만보면 크게 어려울 게 없는 미션이다. 하지만 여기에 Clean Code의 원칙들이 들어간다면?
기존에 객체지향 설계에 대해 심도있게 고민해보지 않았거나 디자인패턴을 따로 공부하지 않았다면 많은 멘탈붕괴를 겪을만한 첫 미션이다. 이 미션을 수행하며 사용한 디자인 패턴만 다시 삭제한것 까지 합쳐보면
•
옵저버 패턴
•
팩토리 패턴
•
전략 패턴
•
정적 팩토리 메소드 패턴
정도로 내가 이 강의를 듣기 약 2개월전 디자인패턴 책 1회차 정리를 끝내지 않았었더라면 미션 진행이 가능했을까? 싶다. 그리고 강의를 시작하기 일주일전부터 들었던 백기선님의 더 자바, Java 8 강의 역시 도움이 많이 되었다.
•
Lambda
•
Stream
•
FunctionalInterface
◦
IntBinaryOperatior
◦
...
등 ... 물론 이 부분에 대해서는 포비가 언급하길 객체 지향을 연습하기 위해선 이런 API를 안쓰고 해보는 것도 도움이 될 것이라고 해서 고민을 하긴 했지만, 신규 API에 대한 숙달도 할 겸사 나는 우선 Java 8의 API를 없이 구현해보고 그 다음 다시 Java 8의 문법으로 구현을 해서 푸시를 하곤 했다.
리뷰어분은 회사일이 바쁘셔서 리뷰가 빠르게 오지는 않았지만 그 대신 매번 리뷰의 디테일이 살아있고 내가 놓치고 있던 부분들까지 짚어줌으로써 극단적으로 말해 1주전과 지금의 내 코드만해도 정말 비교가 안될정도로 퀄리티가 높아진게 눈에 보이고 단점으로 회사에서내가 기존에 짠 코드들이 꼴뵈기 싫어지고 있다.. 젠장
이제 2주차를 들어가는 시점에서 1주차에서 중요하다고 생각했던 개념들과 내 문제점을 짚어보자면
미션1 자동차경주의 주관적 중요 포인트
여기서 소트웍스 앤솔러지의 9가지 원칙은 언급하지 않는다. 왜냐하면 이는 미션1이 아닌 모든 미션을 관통하는 주제이기 때문이다.
•
실패하는 테스트 케이스를 만들어라.
: 내가 매 번 TDD를 실패하는 이유기도 했다. 아직 구현도 안한 테스트케이스를 어떻게 만들라는거지? 하면서 기능을 구현하다 보면 기능이 돌아가는 걸 눈으로 확인을 하고 잘 돌아가니 굳이 시간을 더 써서 이미 확인한 기능을 테스트 코드로 구현하는 것에 무슨 의미가 있는가 싶었다.
하지만, 이는 분명 의미가 있다. 테스트를 주도적으로 먼저 작성을 한다면 테스트가 가능한 코드를 짜야하고 이는 곧 테스트가 필요한 메소드는 언제든 외부에서 테스트가 가능하게 모듈화 되어 독립적으로 돌아갈 수 있게된다. 이것은 곧 순수함수가 된다는 의미가 되고 이런 순수함수들이 모여 로직이 구현된다면 테스트에 자유롭고 유연한 코드가 될 수 있다는 의미가 된다.
•
내가 작성하는 코드 라인하나, 단어하나, 심지어 스페이스바 하나도 의미를 생각하면서 작성 하라.
: 코드의 묶음은 결국 하나의 기능을 말하며 이는 소설속의 이야기와 비슷하다. 그럼 다시 소설에 비유해 말해보자. 소설의 내용들이 기승전결이 모두 개행없이 띄어쓰기 없이 작성되어 있다고 하면, 읽기 쉬울까?
어려울 뿐 아니라 애초에 보는순간 숨이 턱 막히며 책을 덮을 것이다.
코드도 동일하다. 코드는 독자(개발자)에게 변수명, 메소드명, 클래스명은 이 게 무엇을 의미하고 어떤 동작을 암시 하는지 추측할 수 있어야 하고 개행과 띄어쓰기를 통해 로직&키워드 에 쉽게 집중할 수 있도록 해야 한다.
가령 예를 들어 사칙연산 키워드(+,-,*,/)에는 계산 우선 순위가 있다. 근데 이를 그냥 띄어쓰기 없이 작성을 한다면 3+2*4/2-1 이라고 작성을 하게 되는데 이 중 무엇부터 계산을 해야 할 지 한눈에 들어올까?
그래서 책'클린코드' 에서도 연산자 우선순위에 따라 띄어쓰기를 해서 가독성을 높히기를 권장한다. 그렇다면 띄어쓰기를 하면 어떻게 될까? 3 + 2*4/2 - 1 이제 무엇부터 연산을 해야할 지 좀 더 쉽게 알아볼 수 있지 않은가?
•
전략 패턴을 사용한 비즈니스 로직의 유연성 증가
: 자동차의 전진 조건을 전략 패턴을 사용해 그때그때 주입해서 사용한다. 기존에는 그냥 해당 객체 안에서 로직을 작성했는데, 이렇게 로직을 주입함으로써 전진 조건이 변경되었을 때 쉽게 변경이 가능해진다.
•
값을 꺼내쓰지말고 객체간의 메세지 전달
: 기존에는 하나하나의 필드(Ex: 자동차 이름(name), 현재 위치(position)...)들을 Primitive Type으로 가지고 있으며 setter, getter를 가지고 해당 값을 꺼내 로직을 수행했습니다.
하지만 소트웍스 앤솔러지의 규칙 중 9번째인 getter/setter/property를 쓰지 않는다는 규칙을 지키는게 쉽지가 않다. 이를 어떻게 해결하면 좋을지에 대한 답은 값을 주고 받는게 아닌 메세지를 주고받는다는 것입니다.
예를 들어, Car라는 객체에 name이라는 값이 있으면 이를 원시 값으로 놓고 쓰는 게 아닌 CarName이라는 객체를 만들어 name만 가지고 있으며 이 이름에 대한 유효성검증로직정도가 추가 되 있는 것이다.
그렇기에 Car에서는 직접 name의 유효성을 검증하고 Primitive value를 주고받을 필요없이 유효성은CarName객체에서 수행하고 데이터를 주고받는다 하더라도 CarName 객체 자체를 주고받는 것.
내부 값은 직접 핸들링 하는게 아니라 객체로 메세지를 보내 객체에서 자체적으로 수행하는 것이다.
그럼 객체가 너무 많아지는 것 아닐까? 객체 지향적 으로는 이게 더 올바른 설계다.
그럼 클래스에 필드가 너무 많을 경우 그걸 하나하나 다 객체로 만들어야 하는가?? 클래스에 인스턴스 변수가 너무 많다면 클래스가 더 분리될 수 없는지 보도록 해야 합니다.
사실 이 밖에도 많은 팁들과 규칙들 그리고 포인트들이 있다. 하지만 제가 제일 인상 깊었던 포인트 위주로 작성해보았다.
내 문제점
•
지적 허영심
: 굳이 새로 배운 지식, API, 디자인패턴 등 아는게 생기면 어떻게든 쓰려고 한다. 장점으로 보일수도 있으나 과하다. 그렇기에 오히려 복잡도가 높아지고 코드의 가독성이 낮아지는 경우가 생긴다.
그래서 step3 첫 자동차 경주에서 너무 과도한 인터페이스 분리로 지적을 받았다. 그리고 for-loop을 사용하면 더 간단하게 끝날 것 같은 문제도 굳이 Stream으로 메서드 체이닝을 하거나 한다.
시급히 고쳐야할 습관이다.
•
리뷰어에 대한 맹신
: 내가 짠 코드에 대해 지적이 들어오거나 의문을 받게되면 내가 이 코드를 얼마나 자신있게 작성 했는지와 상관없이 나보다 잘하는 사람이 저렇게 말하면 다 이유가 있겠지 하면서 의문조차 가지지 않고 고치거나 변경하거나 삭제한다.
하지만, 다른 분들의 PR 공간을 보면 댓글을 통해 서로의 의견을 나누고 변경을 할지 말지에 대한 생각도 자신의 줏대로 결정한다. 물론 잘 못된 코드이기에 변경하는 것은 맞다. 하지만, 이게 잘못되었는지 아닌지에 대한 확신도 없이 그냥 잘하는 사람이 하는 말이니 맞겠거니 하는 내 태도는 분명 시급히 고쳐야 할 문제다.
정리
이제 2번째 미션 로또 만들기를 수행할 예정이다. 내가 과연 수료를 할 수 있을까? 하는 걱정이 매번 반복된다.
1주차 미션 코드리뷰정리
: 시간이 날때마다 다른 사람들의 PR에등록된 코드리뷰 역시 모아놓고 있는데, 일이 바빠져서 그런지 시간내기가 쉽지가 않다.
2. Clean Code
나는 사실 TDD, Clean Code with Java 과정명의 이름중 Clean Code가 정말 책 Clean Code를 의미하는지 몰랐다. (왜지... 바본가?)
그냥, PR을 보내고 남는 다음 미션을 진행할까도 했지만, 과정 시작 초반과 직전에 했던 디자인패턴, 자바 8 공부의 효용성을 보고 이번에는 Clean Code라는 책을 보기로 했다.
근데, 보면 볼수록 내가 받는 코드리뷰의 내용들과 소트웍스 앤솔러지의 원칙들과 일치하는 규칙들과 주의사항들이 있다. 그제서야 나는 아 이 강의명의 Clean Code 가 책의 Clean Code구나 라는걸 깨달았다.
현재 5장 형식 맞추기 까지 읽었으며 내가 의도치 않게 야생형 학습법으로 Clean Code를 학습하게 되었네 라는 생각을 하게 되었다.
아직 이 책을 전부 읽어 본 것은 아니지만, 지금까지 읽으며 내가 느낀 이 책에서 추구하는 개발 방법론은 '읽기 쉬운 글 작성하기' 가 아닐까 싶다. 코드는 결국 특정 목적을 수행하기 위한 객체와 메소드의 집합이다. 그리고 이 목적을 수행하기 위한 이야기(함수,메소드,변수)를 잘 풀어내어 독자가 읽기 쉽고 수정하기도 쉽게 만드는 것이다.
그리고 파트별로 더 상세히 각각이 주제에 대하여 어째서 그래야 하는지 독자를 설득한다.
그리고, 새삼스럽게 느끼지만 영어 공부를 해야겠다. 책에서 훨씬 나아진 네이밍과 주석없이도 이해할수있다며 보여주는 함수및 변수명들이 영어에 약한 내게는 단어 뜻을 모르니 여전히 뭘 말하려는지 알 수가 없었다..
총 17장으로 이뤄진 이 책의 남은 12장을 언제까지 읽을 수 있을지는 잘 모르겠다. 하지만 책이 쌓여가는 속도보다는 빠르게 읽고싶은게 개인적인 바램이다....
야생형 학습법
이론부터 차근차근 공부한 뒤 실습을 하는게 아닌 반대로 정말 기초적이거나 대주제만 익힌 뒤 바로 실습을 해본 뒤 응용&심화 분야 공부를 하는 것.
클린 코드 챕터별 정리 포스팅
3. 책 구매
부족함은 조급함을 부르고 조급함은 충동구매를 부른다.
한동안 잘 참아왔던 책 충동구매... 공부를 열심히 할수록 다른 개발자들과 이야기를 나눌수록 내 부족함은 점점 더 부각되고 나라는 길의 이곳 저곳 뚫려있는 지식의 구멍은 내 가 계속 길을 걸으며 발이 걸려 넘어지게 한다.
그래서 이 길을 메울 재료로 책을 사지만, 언제 채울 수 있을지는 잘 모르겠다 하하...
첫 번째. IT 개발자의 영어 필살기
클린코드를 읽다가 부족한 영어실력에 참담함을 느끼던 찰나에 뜬 책...사실 그냥 눈팅만 하려고 했는데, 추천사에
토비의 스프링저자인 이일민님의 추천글이 있는것을 보고 나도모르게 충동구매를 해버렸다.
내가 과연 이번엔 다 볼수 있을까... 개발책은 느리더라도 완독을 했는데, 영어책은 지금까지 생전 완독해본적이 없다 ... 하하
수능때도 다 1~3등급 사이였지만, 영어만큼은 6등급을 받아 친구들에게 흥선대원군이라는 별명까지 얻었는데..
더는 미룰 수 없다!(아마도)
두 번째. IT 엔지니어를 위한 네트워크 입문
사실 지금 회사생활을 하면서 내게 가장 필요한 책이다.
깔끔하고 아름다운 리팩토링된 코드? 없어도 기능은 돌아간다.
백엔드? 퀄리티만 보장하지 않는다면 왠만한 요구사항은 다 만들 수 있다.
프론트엔드? 디자인만 빼면 왠만한 요구사항은 다 만들 수 있다.
하지만 이 이야기가 매번 네트워크로 흘러가면 한없이 약해진다.
배포관련한 내용과 서버와 네트워크 관련 키워드만 나오면 고개만 끄덕이기 일수이며 바보가 된다...
이번 주말 수원의 북 리브로에서 자바 책이나 보러갔다가 충동 구매해버린 네트워크 입문 책.. 클린코드과정을 끝낸 내년 상반기에 시작할 예정이며 부디 이 책 완독이 끝난 뒤에는 네트워크 바보에서 네트워크 평민까지는 갈 수 있기를 바란다.
4. 광교 앨리웨이
2주만에 아내와 만나 다녀온 광교앨리웨이의 도쿄등심. 사진을 많이 찍지는 않아 음식 사진만 두 장 딸랑 있다.
보통 수원에서 많이 있는데, 요즘 코로나 1단계로 내려간 뒤 너무 사람이 많아져 걱정도 되고 밥조차 먹기 힘든 상황이기에 광교에 놀러갔다.
광교는 올 때마다 좀 신기한데, 쇼핑 및 음식점들이 번화가처럼 상가거리가 따로 있는게 아니라 아파트 앞이 상권이라는 것이 너무 신기하다. 광교의 많은 아파트 단지들이 아파트 단지 내에 대형마트, 스타벅스부터(일명 스세권!) 각종 프랜차이즈나 쇼핑몰까지 있는데, 내게는 좀 충격이였다.
요즘에는 오이도역쪽 역시 이런식으로 상가단지를 구성하려고 하던데, 확실히 집앞에 이런 상권들이 안정적으로 조성되면 거주민 입장에서는 정말 편하겠다는 생각과 건축가들이 정말 대단하다는 생각도 든다.
좋은 설계는 삶의 질을 이렇게 높혀주는구나!
