참고: 4F 회고
Fact : 무슨 일이 있었는지, 어떤 일을 했는지
Feeling : 어떤 감정을 느꼈는지
Finding : 어떤 지식과 인사이트를 얻게 됐는지
Future Action : 앞으로 무엇을 할 계획인지
Fact
: 무슨 일이 있었는지, 어떤 일을 했는지
역대급 시간에 쫓기는 페어 1단계 제출이었다.
그러면서 가장 마음에 걸렸던 점은 이번주 학습목표가 OOP임에 불구하고 기능 구현에 급급해 객체 고민을 못했다는 것이었다. 그래서 제출하고 다음날 페어와 계속 이어서 분리를 고민하고 구조를 바꿔봤던 것 같다.
하지만 리팩토링 과정에서도 다른 페어들은 좌표 dx, dy를 이용해서 알고리즘적으로 해결하는데 우리도 그렇게 해야하나..?하는 생각들도 들면서 주관을 갖고 코드를 짜는 것이 가장 어려웠던 미션이었다.
블랙잭 미션의 리뷰어였던 제이미와 커피챗을 했다!
미션 때 제이미의 리뷰를 통해서 정말 많이 성장했다고 느꼈기에 기대되었던 커피챗이었는데 아니나 다를까 정말 많은 생각 정리가 되었다.
하지만 목표가 잘하는 것이 아니라 ‘선을 잡아가는 것’으로 두면 오히려 과정이고 좋은 일 아닐까요?
생각의 전환이었다.
맞네. 이렇게 했더니 이상하게 짜져봤기에 선을 더 잡을 수 있는 계기가 되었던 것이니까!
선을 잡아가는 것
이라는 목표, 바로 이거다!
Feeling
: 어떤 감정을 느꼈는지
내 구조에 대해 확신이 없는 상태에서 다른 크루들의 코드를 리뷰하면서 보고 리뷰어의 리뷰를 반영하다보니,
저게 더 좋아보이고, 내건 복잡해보이고, 리뷰어의 리뷰를 반영하려면 뭔가 싹 고쳐야할 것 같고,
그렇게 손을 대다보니 내코드도 니코드도 아닌 점점 손을 대기 어려운, 즉 내 코드의 방향을 잃는 상황이 발생했다.
이런 무력감은 처음이었다.
코드를 처음 배울 때로 돌아가서 아무것도 못치겠는 기분.
더불어 나만 뒤쳐진 기분.
이 문제를, 체스 미션을 영영 해결하지 못하고 끝날 것 같다는 불안감에 휩싸였다.
누군가에게 얘기하는 수밖에 없다는 생각이 들었다.
그래서 화장실에서 양치하던 크루에게도, 집에 같이 가던 크루에게도, 내 닉네임을 익히려 가볍게 말을 걸었던 포비에게도 물었다. 그리고 이런 이야기들을 들었다.
커비, 저 사람들은 커비보다 몇 년을 더 코드를 쳤던 사람들이야, 커비가 못하는 건 당연한 거 아냐?
커비는 더 많이 넘어져 봐야 할 것 같아요. 아니, 더 많이 넘어져 보면 좋겠어요. 그게 커비의 인생에 훨씬 좋을 거에요.
이런 얘기들을 들으며 '그래 어떻게든 해보자'라는 생각으로 이리 저리 고쳐보다가, 마침 네오의 3차 강의를 듣고 해당 방식을 참고하는 것이 현재 내가 갖고있는 문제를 해결할 수 있는 가장 단순한 방법이라는 생각이 들었다.
물론 다들 어떻게든 자기 방식으로 하는데 나는 다른 사람 걸 따라하는 기분때문에 계속 찝찝했다.
하지만 이것도 또한 방법이라고 생각한다.
이유가 어찌됐든 이런 상황에 처했고, 난 이 방법을 선택했고, 후회하진 않는다!
이번 미션은 DB까지 연결하는 것이 과제였다.
난 DB, Dao를 제대로 공부해본 적이 거의 없는 탓에 이게 제대로 짠 게 맞나? 정석적인 방법이 맞나?
확신이 없었다.
근데 그냥 했다. 일단 지금까지 배운 것을 바탕으로, 맞다고 생각하는 대로, 내맘대로 구조로 짜면서 말이다!
처음에는 Dao라는 용어 하나만 알고, DB와 바로 연결해봤다가,
Entity가 뭐지?하고 적용해봤다가 '아 여기서 사용하면 안되는구나'를 직접 깨닫고 빼봤다가,
다른 중간 매개체가 필요한 것 같아서 그제서야 DTO를 연결해봤다가,
주위에서는 서비스 계층을 만들어서 한다는 얘기를 듣지만 '난 지금 시점에서 필요성이 느껴지지 않아'라고 생각하면서 끝까지 컨트롤러로만 연결을 해보기도 하면서,
이전에 1,2단계를 하면서 다른 코드를 보면서 내 코드가 이리저리 휘둘렸던 것이 경험이 되어서 그런지,
내맘대로 한바탕 짜놓고, 크루들이나 리뷰어에게 물어보고 하는 방식으로 진행한 3,4단계는 훨씬 수월했다.
결과물이 물론 매우 완성도가 높다고는 못한다. 내 생각대로, 정석이 아닌 방식으로 짠 코드라서.
하지만 그 과정에서 내가 직접 이런 저런 방식으로 적용해보면서 학습을 했던 것이 더 가치있다고 느낀다!
저번주부터 학습할 게 감당을 넘어가 버린 것 같다
라는 생각이 들었고 마침 네오 강의에서 이런 Q&A가 있었다. 네오의 대답은 이랬다.
모든 걸 학습할 필요없음
지금 내 단계에서 학습해야할 걸 한개 한개 학습하기
지금 학습하고 끝낼 것 아니고, 우테코 나머지, 회사가서도 계속 학습할 것이기 때문에
맞다. 항상 되뇌이지만 항상 까먹는 자세이다.
학습은 평생 이어진다. 모두 학습해낼 수 없음에 조급해하지 말고, 지금 하나 하나 얻게되는 학습을 즐기자!
난 state 패턴이 안떠올랐는데… 어떻게 네오는, 또 다른 크루들은 생각해냈을까?
이런 질문도 나 역시 들었는데 여기에 대해서는 이런 답변을 들었다.
괜찮다. 경험의 차이다. 많은 반복을 통해 학습하면 될 것이다.
경험의 차이, 또 여러 차이 인정하기!
Finding
: 어떤 지식과 인사이트를 얻게 됐는지
블랙pawn이 화이트pawn을 잡았는데 블랙pawn이 잡히지 않고 계속 남아있는 오류가 발생했었다.
public class ChessBoard {
private void catchPiece(final Piece currentPiece, final Position targetPosition) {
Piece targetPiece = findPieceBy(targetPosition);
pieces.remove(targetPiece);
// 이동전 현재 피스의 해시값: -1582489239
currentPiece.move(targetPosition);
// 이동후 현재 피스의 해시값: -821358821
}
}
public abstract class Piece {
protected final Color color;
protected Position position;
@Override
public boolean equals(final Object o) {
if (this == o) {
return true;
}
if (o == null || getClass() != o.getClass()) {
return false;
}
final Piece piece = (Piece) o;
return color == piece.color && Objects.equals(position, piece.position);
}
@Override
public int hashCode() {
return Objects.hash(color, position);
}
}
몇 시간의 디버깅을 통해 알아낸 이유는 바로, Piece의 color필드를 바꾸니 Piece의 해시값이 달라졌기때문이었다.
대상 객체의 필드가 final이 아니라 변경되면 객체의 해시값도 변경되어서 정상적으로 set.remove가 안되었던 것이다.
final이 아닌 필드가 있다는 것이 찝찝했지만 기능상 어쩔 수 없지하고 넘어갔는데 이렇게 문제점이 드러났달까?
결국 Piece에서 position 필드를 빼내 Board에 Map<position, piece>를 필드로 갖게하는 방식으로 수정했는데, 이로써 final이 붙지 않는 요소들이 발생시킬 수 있는 문제점 하나를 알아간 기분이다!
Future Action
: 앞으로 무엇을 할 계획인지
이번 미션에서 좌절해보면서, 또 제이미와의 커피챗을 통해서 조금 더 구체적인 목표가 생겼다.
- 잘하는 것이 아닌 ‘선을 잡아가는 것’
극단적인 것 같은 방법으로도 해보고 그랬기에 결과물이 완성도 있지 않더라도
이상하게 짜봤기에 선을 더 잡을 수 있는 계기가 되었다고 생각하기!
이 우테코 내에서 여러 방향으로 튀어보면서 나만의 선을 만들어보기!
- 미션 미션마다 내가 챙겨갈 것을 챙겼는지를 체크하기!
정리할 시간이 너무 없다하면 rc 반영 몇 개 넘기더라도 짧게 정리해보기.
챙길 것 이외의 것이라면 버리거나 다른 크루의 코드를 따라치기만 하더라도!