6.5주차 정리
피드백 정리
Optional에 대해
문제가 된 코드는 다음과 같다.
1
2
3
4
5
6
7
8
private static Optional<Players> validatedInputPlayers() {
try {
return Optional.of(Players.fromStringList(INPUT_VIEW.inputPlayers()));
} catch (IllegalArgumentException e) {
System.out.println(e.getMessage() + TRY_INPUT_AGAIN);
}
return Optional.empty();
}
INPUT_VIEW를 통해 사용자의 입력을 받아올 때, IllegalArgumentException 예외가 발생하여도 일단은 정상적인 흐름으로 가져가기 위해 Optional을 도입했다. 코드 자체에는 문제가 없다. Optional의 사용방법이 문제이다.
Optional은 데이터가 있을 수도 있고, 없을 수도 있을 때를 가정하여 만들어진 문법이다. 하지만 나는 데이터의 유무와 관계없이 예외가 발생했을 때 정상적인 흐름을 위해 사용했다. 스트림, 람다, Optional 등 나름의 최신 문법을 오남용하기보다는 이 문법이 어떤 의도로 만들어졌는지, 왜 사용해야하는 지를 인지하고 개발하도록 하자.
커밋은 언제해야할까?
TDD로 수강신청 미션을 진행할 때, 커밋의 크기에 대해 고민했다. 처음에 개발할 때에는 TODO에 따라 커밋을 하곤했는데, 나중에 요구사항 변경 단계에서는 어떤 타이밍에 커밋을 해야할 지 어려웠다.
내가 미리 작성해놓은 테스트가 정상적으로 통과할 때까지 수정을 한 다음 커밋을 했는데, 이 크기가 너무 컸다는 것이다.
리뷰어님은 커밋 단위의 기준을 문제가 발생했을 시 롤백 후 바로 배포가 가능한 수준이라고 하셨다. 롤백 후 바로 배포가 가능하다는 게 뭘까? 곰곰이 생각해봤는데 사실 ‘어떻게 코드를 작성하더라도 롤백 후 바로 배포가 가능하지 않나?’ 라는 생각이 들었다. 물론 컴파일 에러는 안 된다. 컴파일 에러가 발생하지 않는 수준에서는 언제든 커밋을 해도 된다는 의미로 받아들여졌다. 가령, 테스트가 성공하지 않더라도 TDD사이클(실패 - 성공 - 리팩터링) 각각에서도 커밋을 해도 된다는 뜻이다. 커밋 단위는 잘게 쪼개야 한다. 테스트가 성공하지 않아도 된다.
객체의 의인화
내가 작성한 정적 팩터리 메서드 중엔 이런 코드가 있었다.
1
2
3
public static CoverImageInfo createFromData(Long id, Long size, String imageTypeStr, Long width, Long height) {
return new CoverImageInfo(id, size, imageTypeStr, width, height);
}
DB 등에서 가져온 데이터를 통해 객체를 만드는 메서드이다. 그래서 메서드 이름을 createFromData로 지어줬다.
리뷰어님이 이 이름에 대해 피드백을 해주셨다.
도메인 객체 본인이 어떤 방향, 계층에 의해 사용되는 지 굳이 알 필요가 없을 것으로 보인다.
이 멘트에 정말 깊은 감명을 받았다. 나름 객체지향에 대한 책도 읽고 생각도 많이 했었지만, 이렇게 자연스럽게 의인화를 해본 적은 없었다. 개인적으로는 저 문장 한 줄이 객체지향 전체를 아우르는 문장이라고 느꼈다. 객체를 자율적이기 때문에 어디서 어떻게 쓰이는 지 알 필요가 없다. 내 메서드 이름은 createFromData이기 때문에 해당 객체는 Data에 의해 생성된다는 것을 굳이 알게되었다. createWithId등과 같이 바꾸는 것이 좀 더 객체지향적일 것이다.
마지막 라이브 강의
마지막 라이브 강의에서 포비는 개발문화를 만드는 것에 대해 다양한 얘기를 전해줬다.
어떻게 개발문화를 만들 수 있나?
- 레거시 코드 리팩터링
- 개발 툴 도입
- 문화만들기
개발 문화… 어떻게 만들 것인가?
개발문화를 바꾸거나 만들기 위해서는 먼저 내 역량을 쌓는 것이 우선이다. 그래야 남들이 나를 따라올 이유라도 생기는 것이다.
내 개인 역량을 쌓은 후 팀과 동료에 영향력을 전파하는 과정이 필요하다. 이 과정에서 많은 감정노동이 생기는데, 이는 결국 리더십 역량이 된다. AI 시대에서 리더십 역량과 감정 노동은 가장 필요한 역량이라고 한다.
사람들은 기본적으로 변화를 거부한다. 당연히 더 큰 단위인 팀은 거부하는 성향이 더 강할 것이다. 그럼 이들을 이끌고 어떻게 개발문화를 만들어가야할까?
그냥 묵묵하게 혼자 하는 것이다. 회사에서 내가 담당하는 부분만 TDD를 적용하고, 리팩터링을 적용한다. 그러다가 관심이 있는 생기면 전파하면 된다.
6.5주차 정리
이제 모든 과정이 종료되었다. 과정을 진행하면서 느꼈던 것들은 추후에 따로 회고하려고 한다. 회고를 작성할 예정이라 이번 포스트는 간단하게 마무리하려고 한다.