[우테코/BE/7기] Weekly Rewind - 1주차

0. 시작하기 앞서

 

A) 주차별 풀이목표

이번 주차는 생각보다 문제에서 요구하는 바가 적었습니다.

이를 반영해 프리코스에서 얻고자 했던 점들 중 하나인 '클린코드 작성'을 연습할 수 있도록 목표를 설정했습니다.

 

주어진 문제를 간단하고 정확하게 해결할 수 있는 코드 작성하기

 

1. 프로젝트 정리

 

🔎 문제분석

 

문제에서는 특별히 어렵거나 복잡한 요구사항을 요청하지 않았습니다.
크게 입출력 조건과 주요 문제해결 조건 1개가 주어져 총 2개의 문제해결조건이 주어졌고, 이를 정리하여 구현기능 정리 전 README에 정리하였습니다.

 

 

 

 

오히려 문제에서 요구조건을 상세히 주지 않아, 추가적인 요구조건을 하단에 설정하여 문제를 풀이했습니다:

 

이를 통해 문제해결을 위한 구현기능 목록을 다음과 같이 정리하였으며, 각 단계에 따라 commit을 적절히 정리하며 문제를 풀이하였습니다.

 

 

⚙️ 구현기능목록

 

분석된 요구사항에 따라, 다음과 같이 구현할 기능목록을 정의하고 계획을 수립했습니다:

 

입출력 형식대응

1. 입출력 기본형식 대응
2. 입력조건 판별대응

요구사항 구현

1. 피연산자 추출
2. 구분자 인식대응

---

 

🚪 문제접근 & 풀이

프로젝트의 요구사항이 간단하고, 반영도메인의 크기가 작아 문제풀이에 큰 어려움은 없을 것으로 생각했습니다. 이를 위해 관련 도메인에서 최대한 간략하고 빠르게 동작할 수 있는 문제해결방법 적용을 위해 정규식을 활용한 문제풀이방법을 설계/적용 하였습니다.

 

🏗️ 문제구현

문제구현은 대부분 사전에 계획된 각 단계에 맞춰 진행되었으나, 일부 개발 상의 편의를 위해 입출력 형식대응과 요구사항 구현 일부가 동시에 진행되기도 하였습니다.

 

프로젝트 구조

프로젝트는 표준 MVC패턴을 사용하지 않고 일부 변형된 형태의 디렉터리 아키텍처를 차용했습니다.
각 디렉터리 별 역할은 다음과 같습니다:

 

• calculator.dto: 입출력 및 각 메서드 간 데이터 이동을 위해 사용되는 Class 패키지
• calculator.io: 콘솔을 통한 입출력 제어를 전담하는 Class 패키지
• calculator.logic: 프로젝트 내에서 사용된 메인 비즈니스 로직 관리 Class 패키지
• calculator.validation: 입출력 및 메서드 내 로직처리 간 필요한 형식 준수여부를 확인하는 Class 패키지

 

 

 

 

Q. MVC 패턴을 적용하지 않은 이유

 

프로젝트를 진행함에 있어 저 또한 MVC패턴의 도입여부를 고민했으나 저는 최종적으로 적용하지 않았습니다.

 

제가 프리코스에 참여하여 얻고자 했던 목표들 중 하나는 ‘유지보수 하기 좋은 코드’를 작성해보는 연습을 하는 것이었습니다.

이를 위해서는 유지보수에 방해가될 수 있는 불필요한 보일러플레이트 코드는 지양해야 했습니다.

 

하지만 MVC 패턴을 적용하기 위해서는 다양한 패키지를 이동하며 명확하게 구분되는 윈칙준수를 위해 기능구현을 위해 거치는 다양한 인자/메서드 대응코드가 필요합니다. 저는 간단한 명세를 복잡한 형식에 맞추어 구현할 필요성은 없다고 판단, 이를 대체하기위한 수단으로 MVC 패턴을 일부 변경한 방식의 디렉터리 아키텍처를 선정했습니다.

 

문제해결방식

문제의 요구사항은 정규식을 활용해 해결하는 형식으로 구성하였습니다.
크게 다음과 같은 과정을 통해 문제를 해결하였습니다:

 

1. 문자열 입력
2. 커스텀 구분자 인식 및 구분정규식 등록
3. 정규식 기반 피연산자 인식 & 연산

이중 1, 3에서 정규식을 사용해 문제를 해결하였으며, 각 상황에 알맞는 정규식을 작성/적용하여 최소코드로 문제를 해결할 수 있도록 구성하였습니다.
구현코드는 여기에서 확인하실 수 있습니다.

---

 

2. 프로젝트 회고

🙋🏻 구현코드의 이해난이도

구현된 코드는 일반적인 유지보수 및 확장 등을 고려했을 때 쉽게 조치할 수 있도록 구성했다고 생각합니다.

다만 정규식을 작성해 판단하는 부분의 코드는 정규식 패턴 하나에 모든 경우의 수에 대한 유효문자열 형식이 담기게 되어 길이가 길어졌고, 이로 인해 코드파악이 어려워졌다고 생각합니다. 향후 정규식을 사용하게 될 경우 이점을 고려하여 최대한 간단하게, 패턴을 나눠 설계하는 방법을 고려해야할 것 같습니다.

 

😅 아쉬웠던 점

 

A) 정규식으로 인해 어려워진 구현코드의 이해난이도

해당 내용은 위에서 언급했으므로 생략하겠습니다.

 

B) 객체지향적이지 않은 코드설계

Validator, CalcLogic 등 프로젝트 내에 포함된 각 class파일 내에는 static method가 다수 포함되어있습니다. 이는 각 코드가 class명이 나타내는 대상을 '표현'하도록 설계된 것이 아닌 기능구현에만 집중해 풀이되어 발생한 문제라고 생각합니다. 다음부터는 문제풀이에 주요대상이 되는 객체개념을 명확히 식별하고, 그 대상을 표현하는 형식으로 문제풀이할 수 있도록 노력해야할 것 같습니다.

 

C) 신중하지 못했던 git commit

 

git commit을 올린 직후 아차!하여 git을 덮어씌운 횟수가 이전에 비해 많았습니다. 물론 신중을 기하다보니 각 commit에 남는 아쉬움을 일일히 수정하여 그런 것도 있지만, commit을 남기는 코드에 신중을 기하지 못한 점도 있다고 생각합니다. 다음 프로젝트부터는 각 commit에 신중을 기하는 코드를 작성할 수 있도록 노력해야겠습니다.

 

D) 명확하지 못했던 요구사항 분석

본래 풀이조건에는 '음수'에 대한 언급이 없어 초기 풀이방향성 설정 시 풀이에 음수가 대응될 수 있도록 노력하고자 했습니다. 하지만 제공된 기본 테스트케이스를 확인하는 과정에서 음수가 입력되는 경우는 고려하지 않는다는 것을 확인, 관련된 명세설명을 삭제하고 관련 대응코드를 수정하는 등의 추가작업을 진행했습니다. 이를 통해 초기에 제공된 테스트케이스와 문제요구사항을 꼼꼼히, 명확하게 이해/정리하고 풀이해야하는 것의 필요성을 느꼈습니다.

 

🤔 오랫동안 고민했던 부분

A) 풀이 요구조건 구체화

보다 명확한 문제풀이를 위해 요구조건을 추가하는 과정에 생각보다 오랜 시간이 소요되었습니다. '숫자를 입력'한다는 단어에서 숫자의 입력형태부터 범위를 주로 고려했으며, 모든 숫자의 합값의 범위와 커스텀구분자의 입력범위 및 개수 또한 고려하였습니다. 따라서 설정하는 전제조건이 비교적 많아졌으나, 덕분에 명확한 코드의 지원범위를 확정할 수 있었으며 기능구현에 큰 도움이 되었습니다.

 

B) 정규식 구성

 

정규식을 사용함으로서 적은코드로 빠른판단을 할 수 있는 코드를 작성했으나, 그만큼 대응되는 코드를 작성하기 위해 오랜시간이 걸렸습니다. 본래 정규식은 기본적인 입력형태를 확인하기위한 용도로만 사용했었기 때문에, 그룹을 기준으로 확인하는 방식에서의 개념을 이해하고 적용하는데 시간이 소요되었습니다. 하지만 이번 기회를 통해 정규식 그룹을 사용하는 법을 명확히 이해하였으며, 이해하기 쉬운 정규식을 작성하는 방법을 고민해보는 기회가 되었습니다.

 

💡 새롭게 배운 점

 

A) 정규식 패턴 활용법

위에서 언급한 내용이므로 생략합니다.

 

B) JavaDoc

프로젝트를 진행하며 나중에 활용될 수 있는 코드들에 주석을 추가하고자 하였습니다. 이전에 FE파트 개발을 통해 경험했든 JSDoc을 그대로 Java에서 적용해보았고, 적절히 JavaDoc을 사용하는 방법에 대해 고민해볼 수 있었습니다.

 

---

3. 1주차 총평

 

개인총평

 

아쉬움도, 배움도 많았던 풀이

풀이 다음주가 시험이라 과제에 완전히 집중하지 못했습니다. 다른 시험공부와 병행하며 과제를 하다보니 구현을 위해 작성한 코드에도, 함께 참여하며 성장하고자 했던 커뮤니티에도 참여하지 못해 아쉬움이 남았습니다. 2주차 기간도 완전힌 시험기간과 겹쳐있어 3주차가 되어야 완전할 몰입을 할 수 있을 것으로 생각되는데, 이를 위해 1, 2주차를 거치며 적어도 준비를 할 수 있는 시간이 되도록 노력해야겠습니다.

 

공통풀이 분석

이번주차 과제는 개발환경에 익숙해지고, git convention을 작성연습을 목표로 출제된 과제였습니다.

그중 의미있는 배움들을 추려 정리해보았습니다. 다음 주차에서 반영할 수 있도록 노력하고자 합니다.

 

오류를 찾을 때 출력함수 대신 디버거 사용하기

 

디버거를 사용하면 다음과 같은 장점이 있다고 합니다:

1. 불필요한 코드가 남을 여지를 제거할 수 있음

2. 코드 내부의 상태값 변화를 실시간으로 확인 가능

3. 코드 흐름을 파악하며 프로그램의 실행순서 확인 가능

 

 이름을 통해 의도 드러내기 & 축약하지 않기

 

변수명, 메서드명, 클래스명을 짓는데 시간을 투자함으로서 각 코드의 역할과 의도를 표현할 수 있음을 느꼈습니다.

과거 프로젝트 등을 진행하며 새삼 느꼈던 부분이지만, 그 중요성을 한번 더 느끼게 되어 정리에 포함했습니다.

추가로 지양해야하는 습관이 정리되어있어 함께 정리해봅니다:

 

• 연속된 숫자를 덧붙여 정리하는 방식 (a1, a2, an, ...)
• 불용어를 사용하는 방식 (Info, Data, a, an, the, ...)

 

변수명에 축약 또한 지양해야 혼란을 방지하고, 더 큰 문제가 숨는 문제를 방지할 수 있음을 배웠습니다.

"의도를 드러낼 수 있다면 이름이 길어져도 괜찮다"라는 문장이 크게 와닿았습니다.

 

공백도 Coding Convention이다

 

공백또한 코드의 결과물 인식에 큰 영향을 주기 때문에, 변수사이의 공백사용 등을 고려하여 코딩하는 것의 중요성을 배웠습니다.

• 공백라인을 의미있게 사용하기 (문맥분리 등에 사용 but 남용 X)
• 스페이스와 탭 혼용하지 않기