본격적으로 3주 차가 되면서 익숙해진 것 같지만서도 여전히 교통은 어렵다. 분명 10분 일찍 도착했는데도 엘리베이터 줄 때문에 계단을 타는 날이 있나 하면, 5분 남았을 때 운 좋게 바로 올라갈 수 있었던 적도 있다. 출석폼을 제출하는 것도 까먹을 뻔한 날이 종종 있었지만 이젠 엘리베이터 기다리면서 미리 열어두는 것도 생활에 적응한다는 것이겠지 🏄🏻♂️
월요일 1시 출근은 진짜 너무 좋다. 주말동안 어지럽혀진 생체 리듬을 돌리는 데 에어백이 되어 주는 듯. 월요일에는 오자마자 다들 출입증에 걸릴 사진 이야기로 시끄러웠다. 분명 따로 검수를 하지 않는다고 했던 것 같은데, 다들 너무 개성있게 사진을 올려둔 탓일까. 따로 몇 가지 가이드라인이 제공되어 다들 사진을 찾느라 바빴다. 일단 각양각색의 얼굴 다섯 개를 출입증에 담아 뒀다. 나중에 따로 불려서 얼굴은 하나만 바꿔달라고 통지받은 것은 비밀.. 👮🏻♂️
🪜 사다리 게임 피드백
화요일과 목요일에는 (빛)네오의 사다리 피드백이 있었다. TDD라는 건 참 어렵다. 어디부터 테스트해야 할까? 도메인에 대한 정확한 지식이 없다면 테스트 코드를 작성할 용기조차 나지 않는다. 내 머릿속에 떠오르는 객체들은 너무 많은 일을 하는 것 같다. 쪼개고 싶지만 어디서부터 해야할 지 선뜻 키보드에 손이 닿지 않는다. 사다리 게임에서도 구현하기 가장 편했던 것은 사람들의 이름, 결과들을 담당하는 것이었지만, 그 친구들은 결국 핵심 비즈니스 로직을 담당하는 것이 아니었으니 쉬운 것 부터 해두고 편하게 있어야지라는 생각이 조금 더 앞섰었다.
하지만, 결국 우선순위를 생각하면 사다리가 먼저다. 네오는 그렇게 사다리를 먼저 구현하기 시작했다. 시간제한이 있는 상황이라면 핵심 비즈니스 로직부터 구현하는 것이 당연하다. 내가 편하게 구현할 수 있는 것이 무엇인지 고를 시간이 없다.
비즈니스 로직을 찾았다면 이를 잘게 쪼개는 연습을 해야 한다. 처음에는 도메인 지식이 없으니 바깥에서 흐름을 파악하는 전체적인 TDD 틀을 잡고, 내부로 들어가면서 책임이 늘어갈 때마다 객체를 나누는 Out-In 방법을 많이 사용한다. 반대로 도메인에 대한 이해가 풍부하고, 미리 어떤 클래스가 어떤 책임을 가질 지 정확하게 알고 있다면 In-Out 방식으로 TDD 사이클을 돌 수도 있겠다.
결국 중요한 건 기존 테스트들을 유지하면서 점진적으로 개선해나가야 하는 것이다. 앞선 회고에서도 한 발자국씩 움직이는 것이 중요하다고 이야기했다. 이건 목요일에 진짜 감탄하면서 보게 되었는데, 일단 구현하고 리팩터링하자는 철학이 돋보였던 시간이었다. 생성자가 몇 개가 생기던 일단 테스트를 만들고, 테스트가 돌아가는 구현 코드를 작성하고, 리팩터링을 해나가면서 점차 요구사항에 맞는 코드가 완성되는 게…🙄
코드에는 의도를 담아야 한다는 말도 와닿았다. 우리가 무심코 작성한 public 제어자는 해당 클래스를 모르는 사람도 메서드와 파라미터의 이름을 보면서 흐름을 알 수 있도록 작성했어야 했다. 생성자를 열어두었다는 것은 외부에 생성 역할을 위임한다는 의미다. 외부에서 객체 생성에 필요한 내용을 알고 있어야 하고, 이 내용이 많아질수록 코드를 처음 보는 사람들이 이해하는 데에 시간을 더 쏟게 된다.
💫 Java는 무엇일까
수업을 마치고, 네오에게 설계 방식이 다른 건 왜 그럴까? 에 대한 이야기를 나눴다. 나는 사다리 미션에서 이름과 결과를 매핑하는 방식으로 구현했다. 가장 작은 비즈니스 로직을 담당하는 객체는 사다리의 한 줄(가로)이었다. 한 줄씩 타고 내려오면서 매핑한 인덱스를 서로 바꿔주는 식이다. 더 잘게 쪼개는 것은 어렵다고 판단했다.
나의 코드는 하나의 객체가 사다리의 모든 결과를 담는 일을 해내는 것 같았다. 객체 사이의 협업을 찾아보기 어려웠다. 지금 이 글을 읽고 있는 분들도 내가 어떻게 구현했는지 머리로 와닿지 않았을 것이다. 그게 내 설계의 문제였다.
코드에는 의도가 담겨야 한다는 말이 떠오른다. 도메인 지식이 없었던 사람도 코드를 읽어내려가면서 충분히 이해할 수 되어야 한다. 나는 아래에서 위로 사다리를 거꾸로 타고 올라갔다. 더 빠르게 계산하기 위해서였지만 이에 대한 적절한 설명이 코드에서는 찾아볼 수 없었다. 결국 나는 추가적인 문서를 작성하면서 왜 이게 요구사항대로 동작하는지를 풀어야 했다.
네오는 나의 고민을 들어주시곤 “Java는 blue collar 언어이다. 다른 언어에 비해서 느린 대신, 객체지향이나 코드에 문맥을 넣어 풍성하게 만드는 것을 챙겼다” 라고 귀띔해 주셨다. 점심을 먹고 돌아와서 이에 대해서 더 찾아 보았다. 자바의 아버지라고 불리는 James Gosling의 Feel of java 앞부분을 읽어 보고 완벽하게는 아니지만, 내 생각을 다듬을 수 있었다.
- Java는 프로그래밍 언어 연구에서 탄생한 게 아니다. 오히려 언어 연구를 한다는 것은 원하지 않는 방법이었을 것이다.
- Java는 Blue-collar 언어이다. 박사 논문을 위한 도구가 아니라, 직업을 위한 언어이다. Java는 듣기에 좋은 여러가지를 반영하는 방식이었고, 객체지향-대수 프로그래밍-시스템 프로그래밍-플랫폼 독립적이라는 네 가지 특징을 가지게 되었다.
나는 Java를 선택했고, 다른 사람과의 협업과 객체의 일에 더 주안을 뒀다. 방금처럼 생각을 건너뛰는 코드를 작성했기에 결국 추가적인 비용 소모가 필요했다. 정말 내가 이런 것을 원했을까? 도메인이나 설계와 관련된 리뷰를 받고 싶었지만, 코드는 이미 완성되었고 설명하는 시간이 더 오래 걸릴 것이었다.
결국 리뷰어분께 ‘이번 연휴동안 처음부터 다시 작성하고 올려도 되겠느냐’는 부탁을 드렸다. 브랜치는 원래 상태로 되돌아갔고, 한참이 지나서야 다시 2단계 리뷰를 올릴 수 있었다. 전체 연산에 집중하지 않고, 각 객체가 할 일을 찾도록 하니 매번 결정할 때마다 고민했던 것을 PR에 녹일 수 있었다.
그 밖의 일들
한 주간 짱수의 데일리로 마니또 활동을 했는데, 아토와 내가 서로 마니또였던 것이 밝혀졌다. 전혀 몰랐지만 노트북 파우치에도 기프티콘을 넣어 두었다고 이야기해주기도 하고… 브리조 최고 ✨
인생학교에서 배웠던 개-고양이-쥐, 개구리가 폴짝폴짝을 크루들과 나눴다. 끝까지 못 맞혔던 로키는 유튜브를 보려다가 다른 크루들의 만류로 하루동안 궁금한 나날을 보냈다 😜 내가 가고 나서도 알아챈 크루들끼리 재밌게 즐기는 걸 보니 뿌듯하기도 했다.
네오가 데일리 하는 장소가 너무 부럽다. 처음에 자리를 잘 잡아둘 걸 그랬다ㅋㅋㅋ 방 안이 조금 덥기도 하고, 트여있지 않다보니 답답해하는 크루들이 있었다. 자리를 매번 바꾸면 좋겠지만 너무 어수선할 것 같아 머리로만 생각하고 있다.
이번 주에는 유연성 강화하기, 웹 수업과 같은 줌 수업이 많아서 코드 작성할 시간이 조금 모자랐던 듯하다. 화요일부터는 다시 다음 미션이 기다리고 있을 텐데 잘 할 수 있을까 🙃 페어 화이팅!