예외처리 메커니즘 예외 메커니즘은 예외 상황의 문맥을 전달하기 위해 사용합니다. 커스텀 예외란, 개발자가 직접 정의한 예외입니다. 예외는 예외 상황에서만 사용해야 합니다. 예외처리를 클라이언트에게 강제하고 싶은 경우, Checked Exception을 사용합니다. 디미터 법칙 디미터 법칙이란 의존성을 관리하기 위한 한 가지 법칙입니다. 디미터 법칙은 TDA(Tell, Don’t Ask)원칙을 준수하게 만듭니다. 디미터 법칙은 대상이 자료구조라면 위반될 가능성이 없습니다. 추상 클래스, 인터페이스 추상 클래스 상속(구현 상속)은 개념 면에서 밀접한 연관이 있는 객체들에게 사용합니다. 인터페이스 상속은 개념적으로 관련이 없더라도 공통 행위를 정의하고 싶다면 사용합니다. 인터페이스는 다중 상속이 가능합니다. ..
레벨1의 마지막 미션인 체스 미션이 종료되었습니다. 레벨1이 이대로 끝난다니 섭섭하기도 하네요.. 마음같아서는 한 달 정도 더 하고 싶은 생각입니다. 아무튼 체스 미션 과정에서 제가 느낀 점들을 잊기 전에 적어보려 합니다. 기술 회고는 내용이 많아질 것 같아서 따로 작성해야겠습니다 😀 새로운 페어와의 만남 새로운 페어인 제이미를 만났습니다. 제이미는 보통 페어의 개발 스타일에 맞춰주면서, 그 속에서 흡수해 나가는 것 같았습니다. 이 부분은 배워야 할 점이라고 생각했습니다. 저는 제 생각에 대한 은근한 고집..? 이 있어서 페어에게 많이 맞춰주는 것이 아직까지는 어려운 것 같습니다. 따라서 제이미를 통해 상대를 존중하는 방법, 상대의 사고과정을 지켜보는 방식을 배우게 된 것 같습니다. 그리고 개발 과정에 ..
들어가면서 얼마 전, 이펙티브 자바 스터디를 하면서 불변 객체에 대한 토론을 하게 되었습니다. 그리고 준팍, 아벨 등을 비롯한 크루분들도 불변 객체에 관한 고민을 많이 하고 있는 것 같았습니다. 그 과정에서 '불변 객체의 본질은 무엇인가?'에 대한 아이디어를 얻어 글을 작성해보려고 합니다. 불변객체를 구글에 검색해보면, 비용을 제외한 단점이 없는 것 같아 보입니다. 하지만 불변객체의 장/단점만으로는 적용 시점을 결정할 수 없는 것 같습니다. 불변 객체에 대해 검색하다보면, 아래와 같은 고민들이 당연히 피어날 수 밖에 없습니다. 무엇을 불변객체로 결정해야 할까? 언제가 비용을 지불하면서도 불변객체를 사용할 때일까? 하지만 불변객체 사용 시점은 단편적으로 결정할 수 있는 부분이 아니라고 생각합니다. 예를 들..
getter 사용은 과연 금기인가 우아한테크코스에 합류하고 객체지향과 클린코드라는 개념을 차차 알아가는 중이다. 좋은 코드를 만들기 위해서는 getter / setter 사용을 자제하라고 한다. 따라서 나는 코드를 짜면서 getter / setter 사용을 모든 상황에서 제거하려고 노력했다. 하지만 얼마 전 체스 미션을 진행하면서 이에 관한 내 생각이 흔들린 것 같다. View를 위해서가 아니더라도 getter를 사용해도 되는 상황이 있다는 것을 깨달았기 때문이다. 과연 getter 사용은 금기일까? 나는 아니라고 생각하게 되었고, 그 이유를 아래에서 풀어보고자 한다. 주관적인 내용이 많이 담겨있습니다. "getter를 사용하지 마라" 왜 위와 같은 말이 나왔을까? 시스템은 객체들이 메세지를 보냄으로써 ..
사실 회고는 따끈따끈하게 적어야 의미가 있는 것이라 생각하지만, 요 며칠 스터디와 체스 미션으로 인해 바빠 블랙잭 게임 미션에 대한 회고를 작성하지 못했다 😅 (회고를 제때제때 적는 것도 의식적으로 연습해야겠다..) 기술적인 부분에 대한 회고는 나중에 따로 다루기로 하고, 감정 회고를 먼저 작성해보려고 한다. 마코와의 페어 프로그래밍 블랙잭 게임을 통해 세 번째 페어인 마코를 만났다. 상당히 사고도 깊은 크루이고, 주관도 뚜렷하기에 페어 프로그래밍을 하는 내내 즐거웠던 것 같다. 나는 내 말에 정면으로 반박하는 페어가 참 좋은 것 같다. 기본적으로 내가 토론을 좋아하는 성격이기 때문이다. 마코는 의견 차이가 생기더라도 나를 설득하려고 애쓰는 모습이 좋았다. 반면 나는 페어 프로그래밍을 하기에 부족한 점이..
사다리 타기 미션이 종료되었다..! 물론 끝난지 10일 정도 되가지만.. 미루고 미루다가 정리한다 ㅎ 나는 내가 학습한 것들을 나만의 언어로 작성하면 못배기는 성격이기에, 사다리 타기를 통해 배운 것들을 정리하고자 한다. 기능목록도 도메인 영역별로 이전까지는 요구사항을 조금 불친절하게 작성했던 것 같다. 문서는 나를 위해서만 존재하는 것이 아니다. 기능 목록을 도메인 영역별로, 상세히 작성하는 경우 다른 개발자가 시스템을 이해하기가 쉬워지며, 더불어 커밋 로그에 대한 가이드라인이 되기도 한다. 따라서 이 이후로는, 기능목록에 도메인 로직을 상세히 작성하기 시작했다. 현재는 다음과 같이 도메인 모델에 따라 기능을 분류하고 있다. 내려가기 규칙 내려가기 규칙에 대해서는 내가 프롤로그에 따로 작성해 둔 것이 ..
가독성 높은 코드 API를 적절히 사용하라 class Menus { public Menus(final List menus) { for (int i = 0; i < menus.size(); i++) { for (int j = 0; j < i; j++) { if (menus.get(i).equals(menus.get(j))) { throw new IllegalArgumentException("메뉴는 중복될 수 없습니다."); } } } } } class Menus { public Menus(final List menus) { if (menus.size() != menus.stream().distinct().count()) { throw new IllegalArgumentException("메뉴는 중복될 수 ..
첫번째 미션이었던 자동차 경주 미션이 종료되었으므로 회고를 해보자 !! 회고 템플릿은 어떻게 할까 하다가, 유명한 KPT(Keep, Problem, Try) 로 해보기로 함. 🥸 Keep 빠른 시간 안에 구현을 완료했던 것! 코드 작성 중 문제가 생기더라도 페어(하디)와 의견을 많이 나눴던 것. MVC 모델에 맞춰서 구현을 마친 것. Problem 잡담은 경쟁력인데, 첫 미션이라 그런지 긴장을 많이 해서 하디와 잡담을 많이 하지 못했다.. ㅎ 조금은 쉬어가면서 해도 좋았을 걸, 급하게 달린 것 같기도 하다. 리팩토링 기간 후반부에는 마땅히 문제점이 보이지 않아 리팩토링을 거의 못했는데, 내가 알던 지식들이 맞나 다시 검증하는 시간을 가졌으면 어땠을까 싶다! Try 예외처리에 대한 나만의 방식 만들어보기...
컨트롤러가 필요할까 무의식적으로 MVC 구조를 계속 사용하고 있었고, 당연히 Controller 클래스를 항상 정의해왔다. 리뷰어 분이 main에서 정의하지 않고 컨트롤러를 쓰는 이유를 여쭤보셨는데, 나는 다음과 같이 생각했다. 'main은 시스템의 엔트리포인트 역할을 한다. 그렇기에 단순히 컨트롤러 등의 호출 순서를 조정해주는 역할이라고 생각한다' 그렇기 때문에 컨트롤러를 사용한 것인데, 계속 생각해 본 결과 컨트롤러가 MVC 패턴이 아니라면 굳이 필요할까? 싶기도 한다. 도메인 영역이 구성이 잘 되어있다면 컨트롤러는 존재하지 않아도 된다. 도메인이 해결할 수 없는 부분을 해결하기 위해 컨트롤러가 존재하는 것이기 때문이다. 이는 Service Layer의 존재 의의와도 비슷하다. 결국 핵심은 도메인인데..
TDD(Test Driven Development) 코드는 두 가지로 나뉠 수 있다. 1. 프로덕션 코드, 2. 테스트 코드. 프로덕션 코드란, 사용자가 실제로 사용하게 될 코드를 의미한다. (우리가 코드를 생각하면 떠올리는 것들!) 테스트 코드란, 프로덕션 코드를 테스트하기 위한 코드이다. TDD는 뭘까? TDD = TFD(Test First Development) + Refactoring 이라고 한다. 유추할 수 있듯이, 테스트를 먼저 작성하면서, 리팩토링으로 보강하는 개발 방법이다! TDD란 프로그래밍 의사결정과 피드백 사이의 간극을 의식하고 이를 제어하는 기술이다. - 켄트벡, Test Driven Development by Example 중 TDD의 아이러니 중 하나는 테스트 기술이 아니라는 점..
