세번째, 네번째 스터디 활동
3, 4주차 활동을 통해 '내 코드가 그렇게 이상한가요?' 책의 9장부터 끝까지의 내용을 다루었습니다.
3주차 활동의 내용은 클린 코드와 관련된 내용을 주로 다루었지만,
4주차 활동의 내용은 개발 문화와 협업에 대한 내용이 주로 구성되어 있었습니다.
지금부터 스터디 내용을 회고하는 시간을 가져보도록 하겠습니다😊
(책의 순서보다 스터디 진행 순서에 우선순위를 두도록 하겠습니다.)
1. 로직 구조를 나타내는 이름 (10.4장)
class Magic {
boolean isMemberHpMoreThanZeroAndIsMemberCanActAndIsMemberMpMoreThanMagicCostMp(Member member) {
if (0 < member.hitPoint) {
if (member.canAct()) {
if (costMagicPoint <= member.magicPoint) {
return true;
}
}
}
return false;
}해당 코드는 게임에서 멤버가 마법을 사용할 수 있는지 판정하는 코드입니다.
메서드의 이름이 로직 구조를 그대로 드러내고 있지만, 불필요하게 길어 의도와 목적을 파악하기 힘듭니다.
따라서 아래와 같이 의도와 목적을 알기 쉽게 이름을 개선해야 합니다.
class Magic {
boolean canEnchant(final Member member) {
if(member.hitPoint <= 0) return false;
if(!member.canAct()) return false;
if(member.magicPoint < costMagicPoint) return false;
return true;
}
}이에 대해 멤버분께서 질문을 남겨주셨습니다!
질문을 살펴보면 다음과 같습니다.
로직 구조를 나타내는 이름을 봤을 때, Spring Data JPA의 쿼리 메소드가 제일 먼저 떠올랐어요.
쿼리메소드가 딱 책에서 설명한 로직 구조를 그대로 나타내는 구조라고 느꼈습니다.
동시에, 쿼리가 바뀌면 메소드 명도 전부 수정해주어야 하기에 좋지 않은 구조라고 생각했어요.
ex. 나이가 30살 이상인 멤버를 나이순으로 정렬하여 조회 : findAllByAgeGreaterThanOrderByAgeAsc(int age)
-> 만약 정렬 조건을 바꾸고 싶으면 메소드 명을 수정해야 함
저는 쿼리가 길어지면 사용을 지양하고, JPQL이나 QueryDSL 등 다른 ORM으로 구현하고 있습니다.
다른 Spring 개발자 분들은 쿼리메소드를 어떻게 사용하시는지 궁금합니다!
해당 주제에 대한 토론의 결과는 다음과 같았습니다.
JPQL 또는 QueryDSL을 사용하더라도 Repository의 메소드는 해당 메소드가 어떤 기능을 하는지 이름에 직접적으로 드러나야 할 것 같다.
만약 메소드 이름의 길이 조절을 위해 이름을 수정하고 JPQL이나 QueryDSL을 사용하게된다면,
비즈니스 로직이 모두 SQL로 구현이 되게 됩니다.
따라서 비즈니스 요구사항이 바뀌게 된다면,
이에 발맞춰 SQL이 수정되어야 하고, 어플리케이션의 메소드 이름은 변경할 이유가 없겠죠.
이러한 상황일 때, 요구사항에 맞게 수정되었는지 수정자 본인을 제외한 다른 사람들은 모르게 될 가능성이 높아지고,
어플리케이션과 SQL이 하는 일이 노출이 되지 않아 혼란을 줄 수 있다는 의견이었습니다.
(메소드 이름을 통해 내부 로직이 눈에 띄어야 한다.)
2. 데이터 클래스처럼 보이는 이름 (10.5장)
책에서는 DTO와 같은 데이터 전송 용도 객체는 참조 용도로서의 역할만을 담당해야 한다고 주장합니다.
예시는 다음과 같습니다.
public class StartDateTime {
private String startYear;
private String startMon; // Jan, Feb...
private String startHour;
private String startMin;
}해당 주장과 관련해서 멤버 한 분이 질문을 남기셨습니다.
DTO에 검증로직을 넣거나 DTO 필드의 값을 변환해서 반환하는 메서드는 어떨까요?
예를 들어, 날짜 데이터를 따로 받아서,LocalDateTime으로 변환하고 싶을 수 있습니다.
다음과 같이of메서드 로직을 DTO에 포함하는 것에 대해 어떻게 생각하시나요?
public class StartDateTime {
private String startYear;
private String startMon; // Jan, Feb...
private String startHour;
private String startMin;
public LocalDateTime convertedStartDate() {
//변환 작업들
return LocalDateTime.of(startYear, startMon, startHour, startMin);
}
}
public class StartDateTimeConverter {
return static LocalDateTime of();
}해당 주제에 관한 결론은 다음과 같았습니다.
실제로 DTO를 DTO 자체의 의미로만 사용하는 경우는 잘 없습니다.
만약 위와 같이 타입 변경이 필요하다면, DTO안에 구현하는 것이 올바르다고 생각합니다.
실제로 저 또한 프로젝트에서 개발을 진행할 때, of와 같이 DTO안에 필드 값 또는 타입을 변경하여 리턴하는 메서드를 자주 구현합니다.
이는 가독성에 긍정적인 영향을 미칠 뿐만 아니라, 해당 DTO가 어떤 목적을 가지고 활용되는지를 보다 쉽게 코드로 이해를 할 수 있다고 생각하였습니다.
평소엔 깊게 생각하지 않고 접근했던 부분이지만, 다시 한 번 내가 왜 of, from메서드를 활용했는가에 대해 짚어보는 시간이 되었습니다.
3. 이상과 현실의 차이
스터디 멤버분께서 현업에서 경험하신 부분들을 바탕으로 한 가지 토론 주제를 남기셨습니다.
책에서는 팀의 설계 능력을 높이기 위해 동료들과 함께 학습하는 것을 권장합니다. 하지만 저의 경험상, 실제 업무 환경에서는 이상과 현실 사이에 큰 차이가 있음을 느꼈습니다.
제가 이전에 근무했던 회사에서는 기능 개발이 가장 우선시 되었습니다.
바쁜 업무 속에서 코드개선의 필요성은 언급되었지만 실제로 적용하기는 어려운 상황이 많았습니다.
예를 들어, 테스트 코드의 중요성은 인식되었으나, 실행 속도와 안정성 간의 균형을 맞추는 것이 쉽지 않았거든요..
이러한 환경에서 이직&퇴사가 올바른 해결책이였을까요?
해당 주제에 대해 멤버분들께서 나누셨던 의견들은 다음과 같습니다.
-
이직&퇴사가 올바른 방법이었을까요?
채용 시장이 호황일 때는 가능하지만... 현실은...🥹
만약 이직을 한다고 했을 때 왜 이직을 하는지, 어떤 부분이 힘들었고 어떤 과정 또는 시도를 통해 이를 극복했는지에 대해 제시할 수 있는 경험을 쌓아보는 것도 좋지 않을까? -
테스트 코드의 중요성은 인식되었으나, 실행 속도와 안정성 간의 균형을 맞추는 것이 쉽지 않습니다.
이것은 어떠한 회사든 모두가 쉽지 않습니다!
하지만 이는 회사의 개발 문화와 연관이 많으므로 회사 개발 문화를 발전시키고자 하는 방향이 좋지 않을까 싶어요!테스트 코드가 없으면 테스트는 운영배포 또는 개발배포해서 테스트를 해야할 수 밖에 없습니다.
테스트 코드 빌드하고 실행되는데 걸리는 시간, 로컬 서버가 뜨는 시간, 개발 배포 시간, 운영 배포 시간 등 많은 자원이 들게 됩니다.
하지만 테스트 환경이 있다고 해서 모든 케이스를 커버를 할수도 있고 못할수도 있어요.
따라서 테스트 코드의 필요성을 인식했다면, 어려운 상황속에서도 추진할만한 가치가 있습니다.
위와 같이 다양한 이야기가 오고갔었지만,
아쉽게도 저는 아직 현업 경험이 없어 의견을 제시하기보단 멤버분들의 의견을 듣고 생각해보는 시간을 가졌습니다.
생각 이상으로 보다 현실적인 내용이 오고가서 놀랐는데요,
아직 경험하지 못한 영역이지만 이후 현업에 참여하게 된다면 가져야 될 마음가짐에 대해 한 번 생각해볼 수 있는 기회가 되었다고 생각합니다😃
'내 코드가 그렇게 이상한가요?' 책 스터디를 마치며...
4주차를 끝으로 책 내용을 기반으로 한 스터디는 마무리 짓게 되었습니다.
회고록에서 다루지 않은 다양한 내용들도 있었지만, 제가 인상깊게 듣고 참여했던 주제들을 골라 다시 한 번 다뤄보는 시간을 갖고자 회고록을 작성한 만큼 뜻깊은 시간이었다고 생각합니다.
또한 추후 제가 프로젝트에 참여하게 된다면 지향해야할 코드 작성 방향성, 나아가 개발자로서의 마음가짐에 대해 많이 느끼고 배워가는 시간이었다고 생각합니다.
이제 5주차부터는 지금까지 읽었던 책 내용을 바탕으로 git에 기록되어있는 코드를 리팩토링하며 토론하는 시간을 가질 예정입니다.
(가장 기대하던 부분이라 너무 설레요🫣)
그럼 다음 회고 시간에 돌아오겠습니다!
PS. 요즘 건강문제로 한의원에 다니고 있습니다... 지금은 거의 다 나아졌지만 정말 건강이 최고인 것 같다고 되새겼습니다...
다른 개발자 동료분들께서도 건강관리 모쪼록 신경쓰시고 화이팅하시면 좋겠습니다! 🫡
