두 번째 미션인 출석은 총 2주를 진행했다.
앞서 회고를 작성한 페어프로그래밍 1주와 페어 프로그래밍한 코드를 모두 삭제하고 혼자서 다시 구현하는 1주의 시간을 가졌다.
이번에 작성할 이야기 2주간 있었던 일들을 간단히 이야기하고 출석 미션을 홀로 구현하기 전 목표로 세웠던 점, 구현하면서 고민했던 점, 알게 된 점, 느낀 점을 이야기하려고 한다
우테코 Level1 - 2,3주차
내 2주간 기억은 노트북밖에 없다
왜냐하면 2주간 열심히 코딩만 하고 자고 등교하고 했던 것 같기 때문이다.
초반 1주일의 우테코는 적응도 안되고 긴장되는 탓인지 캠퍼스 내에 있으면 힘들어서 빠르게 집을 갔지만, 이제는 종종 캠퍼스 문을 닫는 11시까지 공부하곤 하였다.
나보다 정말 열심히 하는 크루들이 많다. 조금은 자극되기도 해서 늦게까지 남았던 것 같다 ㅎㅎ
지금까지 느낀 우아한 테크코스
나는 우아한 테크코스가 크루들에게 성장하는 길을 안내해 주는 역할을 하지 않는다는 것을 알았다. 우아한 테크코스는 자신의 길, 나만의 길을 걷길 원한다. 남이 이야기하는 것보다 자신이 생각하는 것을 직접 경험해 보고 깨닫고 나아가며 성장하길 바란다. 정말 어려운 것 같다. 정말 어렵기에 자신만의 길을 나아갈 수 있는 환경을 제공해준다고 한다.
그래서인지 절대로 정답을 말하지 않는 것 같다. 항상 크루들이 질문을 하면 다시 크루들에게 되묻는다. 혹은 정답이 아닌 먼저 경험한 선배로서 자신의 경험을 말해준다. 크루들이 궁금해하고 있는 것에 대해 해결이 될 수 있을 만한 질문을 하여 스스로 깨닫도록 한다.
또한, 하드 스킬 이외에 소프트 스킬을 굉장히 중요시 여긴다. 모두 개발자라는 목표를 가지고 있고 직장에 들어가길 원한다면 협업은 필수이다. 혼자서 일하지 못하고 항상 팀 단위로 일을 한다. 그렇기에 소프트 스킬이 필요하다고 하였다. 또한, 스스로가 성장하기 위함도 있다.
출석 미션
목표와 후기
내가 홀로 출석 미션을 하며 가져가고자 했던 목표는 TDD 경험과 비즈니스 로직 위치에 대한 이해 두 가지였다.
TDD
첫 번째는 이번 미션의 주 목표인 TDD의 사이클을 경험하고 장점을 느끼는 것이다.
나는 기존에 TDD에 대한 인식이 좋지 않았다. 그저 실용 가능성이 없어 보였기 때문이다. 간단한 요구사항에는 적용할 수 있겠지만, 복잡한 요구사항 혹은 어려운 기술이 들어간 코드는 힘들어 보였었다.
하지만 나는 제대로 TDD를 경험해 본 적이 없다. 몇 번 조금 하고 위와 같은 생각을 한 것이다. 이건 그 누구라도 비웃을 수밖에 없기 때문에 내가 정말 TDD에 대해 논하고 싶다면, 직접 경험해 보는 것이 좋다고 생각하였고 정말 열심히 미션에 적용하였다.
* 요구사항 분석 *
먼저 TDD를 하기 전, 요구사항을 분석하고 구현할 기능을 README에 작성했다.
사실 요구사항을 정의하는 방법, 설계하는 방법을 따로 공부해보지 않은 탓인지 요구사항을 분석하고 이해하여 설계하는 데 어려움이 있었다. 그래서 내가 해결한 방법은 잘은 모르더라도 내가 맞다고 생각한 방법대로 일단 실행했다.
먼저, 요구사항을 읽고 요구사항에서 필요한 역할을 가진 객체들을 정의한 뒤 해당 객체에게 책임을 부여했다. 이 책임의 단위가 TDD의 단위가 되었다. 이것이 정답인지 모르겠지만, 일단 진행했다.
하지만 모든 구현을 완성하고, 설계 시 객체를 정의하고 해당 객체에 책임을 부여하는 것에 대한 불편한 점을 알게 되었다. 해당 객체에 필요할 것 같아 책임을 부여하고 구현하였지만, 필요 없어 다시 삭제하게 되는 것이다.
그래서 다음에는 방법을 바꿔 (1) 큰 기능을 정의하고 (2) 기능에 필요한 객체를 정의하고 (3) 객체에 필요한 책임을 부여하는 방법을 해보고 싶다.
이렇게 일단 경험해 보고 부족한 점을 채워나가는 것이 좋은 것 같다.
* TDD의 장단점 *
내가 이번 미션에서 느낀 TDD의 장단점은 명확하다.
먼저 장점으로는 내가 실제 서비스에서 사용될 프로덕션 코드를 작성할 때, 해당 코드에 신뢰를 먼저 쌓을 수 있다는 것이다. 내가 구현할 프로덕션 코드에 대해 근거를 만들어놓고 해당 근거를 기반으로 코드를 작성할 수 있다. 근거에 맞지 않는 코드를 작성하면 테스트는 실패할 것이고, 근거에 맞는 코드를 작성하면 테스트를 통과할 것이다. 그래서 최종 결과에는 신뢰도가 높은 결과물이 나올 수밖에 없었다.
다음으로는 내가 구현할 요구사항에 대해 코드로 작성할 수 있다는 것이다. 내가 프로덕션 코드를 작성하기 전에, 어떤 요구사항에 대해 작성할지 테스트로 먼저 명확하게 정의하고 가는 것이다. 모든 개발자들은 요구사항을 구현하다가 “이것도 필요하고, 저것도 필요해”와 같은 마음으로 한 번에 모든 것을 하려 한 경험이 있을 것이다. 그러다 자신이 무엇을 목표로 구현하고 있는지 잠깐 헷갈릴 때도 있다. TDD는 이것을 방지해 주는 역할을 해주는 것 같다.
그리고 단점은 내가 처음 TDD를 경험해 본 입장으로써 말한다면, 너무 시간이 오래 걸린다는 단점이 있다. 사이클에 대한 경험이 부족해서 인 것도 있고 테스트 코드 작성 경험이 많이 없어서 그런 것도 있는 것 같다.
하지만, TDD 사이클을 지킨다는 것이 나는 너무 억지스럽다 생각한다. 왜 빨간 불을 봐야 하고, 그린을 봐야 하는지.. 아직도 잘 이해하지 못하고 있다. 관련 서적을 보면 나와있겠지만 아직 게을러서 안 봤다. 더 궁금해지고 불편해지면 볼 예정이다.
그래도 느낀 단점보다 느낀 장점이 더 컸다. 계속해서 TDD를 해볼 생각이다.
* TDD에서 중요하다고 생각한 점 *
내가 TDD에서 가장 중요하게 생각하는 점은 요구사항 분석 및 설계 능력이다. TDD 하면서 가장 어려운 부분이었던 것 같다. 요구사항을 분석해서 TDD를 할 만큼 작은 단위로 나누어야 하는데, 이것을 어떤 기준으로 나누는지 아직 정확하게 감이 오지 않는다. 자신만의 기준대로 하라는데, 많이 경험해봐야 할 부분 같다.
비즈니스 로직의 위치
이번 출석 미션을 하면서 비즈니스 로직의 위치는 어디에 있어야 하는 걸까?를 정말 많이 고민했던 것 같다.
기존에 나는 무조건 서비스에 위치해야 한다고 생각했다. 하나 그것은 잘못된 것임을 step1 페어프로그래밍 때 알고, 기존의 틀에서 벗어나려는 노력을 하였다. 조금은 낯설고 어려웠지만, 금방 익숙해져 갔고 객체지향 프로그래밍에 다가가게 된 계기가 된 것 같다.
기존에는 비즈니스 로직을 서비스에만, 페어 프로그래밍에서는 도메인에만 구현을 했다. 각각 장단점을 많이 느꼈고, 이번 다른 방법으로는 각자 자신의 도메인에서만 포함하는 비즈니스 로직은 도메인 내에서 구현하고, 여러 가지 도메인이 섞여야 하는 비즈니스 로직은 새로운 협력 객체를 만들었다. 하지만, 완벽한 분리는 어려웠다.
그에 대해 라라에게 피드백을 받았다.
일단 도메인 객체들이 상호작용해야 하는 경우가 많기 때문에 일정 수준의 결합도를 완전히 없앨 수는 없지만 최소화할 수는 있을 것 같아요.
결합도를 최소화하려면 책임을 잘 분리하고, 필요 이상으로 객체들이 서로 의존하지 않도록 설계하는 것이 중요할 것 같아요.
개발은 모든지 유연하고, 적당하게 하는 것이 좋은 것 같다.
고민했던 점
고민했던 점은 3가지였다.
첫 번째는 public 메서드 간 의존되는 것이 괜찮을지 고민해 봤는데, 라라의 피드백으로 고민을 조금은 덜게 되었다.
두 번째는 TDD를 진행하고 리팩토링 하게 되면서 다른 객체의 메서드를 구현하게 되었는데, 이것을 TDD로 하기 힘들다고 생각했다. 그래서 어쩔 수 없이 TLD를 해야 하는 걸까?라고 고민했었고, 이것도 라라의 피드백으로 조금의 고민은 해결되었다.
세 번째는 객체를 생성할 때 생성 후 객체의 정보들을 출력해야 했을 때 했던 고민이다.
생성이 완료된 후, 생성할 때 사용했던 데이터를 사용해 출력을 해야 할 것인가? 아니면, 생성 완료 후 생성된 것을 다시 조회해서 출력에 사용할 것인가?
나는 내 나름대로의 이유를 가지고 후자를 선택했지만, 전자의 이점도 분명했기에 고민했던 것 같다.
라라의 피드백을 받았지만, 아직 내가 경험해보지 못한 이야기라 확 와닿지는 않았던 것 같지만 말을 기억해 놓고 다음에 어떤 말이었는지 확인해 봐야겠다.
회고 끝 느낀 점
주변에 열심히 하는 크루들과 함께 공부하며 새로운 것을 많이 알게 되는 것 같다.
기존에 내가 알고 있던 것이라 하더라도 잘 설명하지 못하는 경우가 많았는데 이것은 알지 못하는 것이라고 인지하고 설명할 수 있을 때까지 공부해야 한다는 것을 알았다.
더 깊게 공부해서 좋고, 더 넓게 공부해서 좋고, 더 정확하게 공부할 수 있어서 좋은 것 같다.
앞으로 조금은 천천히 운동도 하면서 체력을 길러서 열심히 공부해 봐야겠다
'우아한 테크코스' 카테고리의 다른 글
[LEVEL 1] 블랙잭 미션 회고 (0) | 2025.03.26 |
---|---|
[LEVEL 1] 출석 미션 회고 - (1) (2) | 2025.02.25 |
[LEVEL 1] 로또 미션 회고 (0) | 2025.02.19 |
도메인과 서비스 그리고 개발자 마음가짐 (0) | 2025.02.16 |
테스트하기 쉬운 코드 만들기(+ 테스트 작성범위) (0) | 2025.02.15 |