우테코 프리코스를 시작하며 다짐했다. "모든 것을 받아들일 수 있는 백지가 되자"  이미 익숙한 지식과 기술을 새롭게 배우는 자세로 임하고 싶었다. 그렇기에 프리코스에서 강조된 리뷰 문화와 프로그래밍 제약 사항을 최대한 지키려 노력했다. 익숙하지 않아 까다롭게 느껴지는 부분도 있었지만, 이런 과정을 통해 개발자로서의 나를 다시 돌아볼 수 있었다. 프리코스에서 익힌 습관은 함께 진행 중이던 데브코스의 협업 문화와 문제 해결 과정에도 자연스럽게 녹아들었고, 결과적으로 성장의 선순환을 만들어냈다. 마지막으로, 회고의 중요성을 강조하고 싶다. 단순히 지나간 일을 돌아보는 데 그치지 않고, 개선 방향을 모색하고 더 나은 미래로 나아가기 위한 중요한 도구임을 배웠다.   데브코스에 몰입하느라 잠시 내려뒀던 우테코가..

반 년간의 데브코스를 마쳤다데브코스를 시작할 때, 나는 내가 경험해보지 못한 것이 나의 부족함이라고 정의했고, 그것을 채우는 것을 목표로 삼았다. 그러나 내가 이해했다고 여겼던 것들을 다시 되짚는 과정에서 오히려 더 깊은 통찰을 얻었다. 단순히 유행하는 기술을 익히는 데 그치지 않고, 스스로를 객관적으로 바라보며 부족한 점을 채워나가는 과정에서 진정한 성장이 이루어진다는 것을.특히 가장 큰 변화는 단순히 구현하는 것에 머물지 않고, '왜 이렇게 해야 하는가'라는 질문을 끊임없이 던지게 되었다는 점이다. 이 관점은 코드 레벨에 그치지 않고, 비즈니스와 도메인 관련 기획까지 확장되었다. 기술적 결정이 비즈니스 요구사항과 도메인의 특성을 어떻게 반영해야 하는지 고민하게 되었다는 점에서, 단순히 개발을 넘어 더..

GitHub - m-a-king/java-convenience-store-7-m-a-kingContribute to m-a-king/java-convenience-store-7-m-a-king development by creating an account on GitHub.github.com  5F 회고  사실 (Facts) 마지막 주차의 미션은 그동안 배운 모든 개념을 종합적으로 적용해보는 자리였다. 하지만 개인적인 사정으로 충분한 시간을 투자하지 못해 동작하는 코드를 만드는 데 집중할 수밖에 없었다. 다소 복잡한 비즈니스 요구사항은 모두 해결했지만, 설계 측면에서 한계를 느꼈다. 도메인이 데이터 클래스처럼 사용되며 대부분의 로직이 서비스 클래스에 집중되는 점이 대표적인 문제였다. 또, 재고 관리 기..

코드에 대한 기준이 점점 높아지면서 고민거리가 늘고, 예상치 못한 문제들이 발생하기도 했다. 하지만 돌아보면 이 과정이 프리코스에서 가장 값진 경험이 아니었나 싶다.   Console.close() 호출 문제  class InputHandlerTest {    ...        @BeforeEach    void setUp() {        ...    }    @AfterEach    void tearDown() {        Console.close();        ...    }    @ParameterizedTest    @ValueSource(...)    @DisplayName(...)    void validLottoPurchaseAmount_isStoredCorrectly(Strin..

상수 관리? 그게 꼭 필요해? 물론 자주 쓰게 되는 값을 저장해 두면 편리하다는 것은 알고 있었지만, 한 번 쓸 값까지도 다 정리해둬야 하나? 오히려 코드가 더 지저분해지고 불필요한 선언이 늘어나는 것 같았다.  좀 더 찾아보니, 개발을 진행하면서 매직 넘버(Magic Number)의 문제를 실감하게될 수도 있겠다는 생각이 들었다. 코드 중간중간에 의미를 알 수 없는 숫자나 문자열이 나타나면, 그 값이 무엇을 의미하는지 파악하기 어렵고, 협업 시 다른 사람이 코드를 읽을 때 이해하기 힘들 것 같았다. 또한, 나중에 요구사항이 변경되어 그 값을 수정해야 할 때 여러 곳을 일일이 찾아서 수정해야 하는 번거로움도 예상되었다.   파일 최상단에 상수 선언하기   그래서 처음에는 파일 최상단에 final 상수로..

프리코스 3주 차, 잘못된 입력에 예외가 발생하면 다시 올바른 입력을 요청해야 한다는 요구 사항이 나를 막아세웠다. 무엇이 잘못된 입력인가?이 경우 예외는 어떤 타입으로 던질 것인가?잘못된 입력을 검증하는 책임은 어디에 있는가?입력을 다시 요청하는 로직은 어디에 배치해야 하는가?한 문제를 넘으면 또 다른 난관이 기다리고 있었다. 지금은 문제를 파악하고 해결했기에 넓은 시각으로 볼 수 있지만, 그 당시에는 올바르게 처리하고 있는지 끊임없이 확인하며 버거움을 느꼈다. 완벽함을 추구하는 욕심을 내려놓았다면 빠르게 구현할 수 있었겠지만, 포기할 리 있나.  MVC  소프트웨어 설계의 복잡성을 관리하는 방법 중 하나가 바로 MVC(Model-View-Controller) 패턴이다. 애플리케이션의 구조를 세 가지 ..