Last Mission 💻
우아한 테크코스가 주고 싶었던 진정한 즐거움이 무엇이었을까?
개인의 성장, 지속적인 몰입, 피드백, 하나의 프로그램을 완성하는 과정?
다 정답이 될 수 있지만 스스로 돌아보며 내가 즐거웠던 이야기를 풀어보고자 한다.
온보딩과 초반 미션들...👨💻
Java 너무 오랜만에 다루어서 진짜 부담된다 못 따라가면 어떻게 하지?
컴퓨터공학과를 전공하면서 기본적으로 여러 프로그래밍 언어를 사용하는 데 익숙하기 때문에
내가 생각한 논리적인 구현은 할 수 있었다.
하지만!
1. 늘어나는 코드 줄
2. 내가 작성해도 의도가 뭐였지? 하고 걸리는 시간
3. 다른 언어에서는 구현 과정 메서드로 존재하는데 Java는 없나?
4. 객체로 사용하면 뭐가 좋은데?
초기에 내 생각이 이러했다.
프로그램이 정상적으로 돌아가는 데는 문제가 없었지만 유지 보수에는 문제가 발생하는 것이다.
피드백이 주는 즐거움👨💻
- 나랑 비슷한 생각을 하신 분들도 있을 것이다.
조금 깔끔하게 코드를 작성하고 싶으면 블로그를 참고하기도 하고 Java 문법을 위한 Document, Slack에서 커뮤니케이션 하시는 많은 분의 내용…. 정보들은 수없이 넘쳐나지만, 본질을 깨닫는 건 스스로 해야 한다.
내가 궁금했던 사항들,
왜?에 대한 이유를 공통 피드백을 통해서 스스로 알아가기를 알려주신다. 미션을 수행하는 모든 분은 예를 들어메서드는 최대한 하나의 기능을 수행하도록 해야 한다.가 주어졌다면 이를 수행하면서 테스트 코드를 수행하면서 얻는 이유, 나중에 리팩토링을 진행할 때 메서드 단위로 수정해 나아가는 것이 편리하기 때문이다.
피어 리뷰가 주는 즐거움👨💻
-
피어 리뷰를 통해서 코드를 작성하는데 편리한 문법을 이해할 수도 있고 클래스의 관계, 프로그램 구조도 이해할 수 있다.
-
더 중요한 것은 피어분들의 설계를 이해하고 요구사항과 목적에 맞게 설계했는지를 알아볼 수 있다는 것이다.
내가 프로그램 동작을 위해 설계한 방식이 과연 옳은 방식일까? 놓치고 있던 부분은 없었을까? 를 배울 수 있었고 문법보다는 객체를 조금 더 객체답게, 다른 사람들이 봤을 때 이해하기 쉬운 코드를 작성하는 법을 배우게 되었다.
나랑 다른 생각을 가지신 분도 있겠지만 놀라웠던 점이 있다.
피어 리뷰를 통해 얻는 피드백이 다음 미션을 진행하는 데 있어서 주어지는 공통 피드백과 비슷하다는 것이었다.
4주차 미션을 통해서 얻었던 점👨💻
객체 간의 설계를 잘해보자❗️
Dependency? 의존성에 대해 많이 들어봤을 것이다.
변경으로 영향을 받을 가능성 이라고 하면 조금 더 와닿을까 싶다.
따라서 우리는 객체 간 설계를 할 때 의존성을 줄여 나아가는 것이 차후, 리팩토링 과정을 위해서도 좋을 것이다. 이번 미션이 어렵다고 느낀 점은 주어진 클래스가 존재했고, 이를 기반으로 제한 사항과 요구사항들이 있었기 때문이라고 생각한다.
피드백을 통해 설계 할 때 고려했던 사항❗️
A -> B
B가 변경될 때, A도 함께 영향을 받는 것을 의미한다.
// 영구적인 관계
class A {
private B b;
}
class B {
public B() {}
}
// 일시적인 관계 즉, 의존 관계 협력을 위해 일시적으로 필요한 의존성
class A {
public B method(B b) {
return;
}
}
위에서 언급했듯이, 의존성을 줄이기 위해서 양방향 의존성을 줄이기 위해서 설계에 공을 들였다.
양방향 의존성(사이클)이 존재한다면, 리팩토링할 때 두 객체를 뜯어고쳐야 하는 일이 생길 것이다.
관계에는 방향성이 필요하므로 이러한 의미가 곧 의존성의 방향을 의미한다. 객체는 객체답게 방향을 고려해보고 메시지를 던지기 위한 객체를 고려해보고 이를 구현하고자 했다.
비즈니스 로직에 집중하자❗️
InputView, OutputView, BridgeGame, BridgeMaker…. 각 객체의 존재 이유는 분명하다.
하지만 비즈니스 로직에 View가 개입하거나 getter와 setter가 난무하게 된다면 비즈니스 로직에 집중할 수 없다. View와 Business의 의존성이 존재하는 것은 Controller에서 해결하고 Business Logic은 오직 Domain에서 해결하고 다리 건너기 게임을 위해 어쩔 수 없이 Domain에 대해 의존성을 가지는 BridgeGame은 도메인간 메시지를 주고받을 수 있도록 설계하였다.
정답은 없다 🧑💻
많은 피어분의 코드를 보진 못했지만, 설계의 비슷함은 느꼈으나 각자마다 생각이 다른 부분들도 있었다.
하지만 클린한 코드를 위해 작성한 노력, 유지 보수를 위한 설계 등등…. 보고 배울 점도 많고 고정 관념을 벗어나 생각의 범위를 키울 수 있다는 점에서 함께 성장하는 것을 배우는 것은 변함이 없다.
이번 미션을 끝으로 프리 코스는 끝이 났지만, 컴퓨터공학과를 전공한 사람으로서 코스를 통해 더 깊은 부분을 배우게 됐고 내가 놓치고 있던 부분들이 너무 많았다고 생각했다.
취업을 위해 프로젝트를 하고, 코딩 테스트를 준비하고, 포트폴리오를 준비하면서
결국 내가 실무에 투입되어서 협업할 때 필요한 기본 역량마저 놓치고 있던 건 아닐까?
(포트폴리오에 쓴 프로젝트들, 작성했던 코드들, 생각하면 내가 인사 담당관이어도 안 뽑을 것 같다는 생각이 들었다 ㅋㅋㅋ)
운이 좋아서 최종 시험을 보게 될 기회를 받을 수도 있지만 공부의 끝은 없다는 사실을 얻게 되었다.
