[WIL] 바닐라코딩 부트캠프 14주차 후기 - 이제부터 실전이다!

백엔드 마지막 테스트 주가 끝났다. 테스트 과제도 성공적으로 잘 마무리 했던 것 같다. 이제 다음주부터는 팀 프로젝트를 시작으로 개인 프로젝트까지하면 여기서의 부트캠프도 끝이 난다.

 

2월에 시작하여 지금까지 4달이 흘렀다. 그동안 나에게는 어떤 변화가 생겼을까?

 

가장 큰 변화는 기초과정 → 프론트 → 백엔드 과정을 거치면서 코드를 바라보는 관점에 변화가 생겼다.

여기서 말하는 관점이란 나의 시선이 아닌 다른 사람의 시선을 생각하게 됐다고 말해도 좋을 것 같다.

예전에는 나를 중심으로 코드를 작성했다면, 지금은 함수명 하나에도 많은 고민을 하게 된다. 왜냐하면 내가 아닌 다른 사람이 이 코드를 바라봤을 때 좀 더 쉽게 이해하기 위해서는 어떻게 해야할지를 고민하기 때문이다.

 

좋은 코드란 무엇일까?

 

여기에 더불어 좋은 코드가 무엇인지를 끊임없이 고민하게 된다. 좋은 코드라는 것이 추상적일 수 있지만, 주니어가 봐도 시니어가 봐도 좋은 코드는 읽기 쉬운 코드일 것 같다.

 

읽기 쉬운 코드를 보통 가독성이라고 표현을 많이 한다. 가독성을 어떻게 하면 높일 수가 있을까?

예를 들어 다음과 같은 코드가 있다고 생각해 보자.

function signup(signupData) {
	{ username, phone } = signupData;
	
	const filter = { phone };
	const foundUser = UserModel.findOne(filter);
	
	const userDao = {
		username,
		phone
	};
	const returnUser = foundUser || UserModel.create(userDao);

	return returnUser;
}

 

여기서 { username, phone } = signupData; 이 부분에서는 JS의 객체 구조 분해 할당이라는 개념이 들어갔고, const returnUser = foundUser || UserModel.create(userDao); JS의 or 연산자 개념이 들어간다.

 

만약 JS의 문법에 대해서 잘 모르는 개발자가 이 코드를 본다면 바로 이해할 수 있을까?

만약 이렇게 바꿔본다면

function signup(signupData) {
	const username = signupData.username;
	const phone = signupData.phone;
	
	const filter = { phone };
	const foundUser = UserModel.findOne(filter);
	
	if (foundUser === null) {
		const userDao = {
			username,
			phone
		};
		const createdUser = UserModel.create(userDao);
		
		return createdUser;
	}
	
	return foundUser;
}

라인 수는 많아졌지만, 가독성 측면에서 생각해보면 좀 더 읽기 쉬운 코드가 된다.

 

우리의 코드를 누가 유지보수 할지는 아무도 장담하지 못한다. 다만, 코드를 작성한 후 한번은 좀 더 쉽게 표현할 수 없는지를 고민하는 것부터가 좋은 엔지니어가 될 수 있는 성장의 발걸음이지 않을까?

 

오버 엔지니어링일까?

 

이번 테스트 과제를 끝내고, 모의 면접도 진행하였다. 모의 면접은 현업에서 지금 일하고 계신 바코 선배님들이 해주셨다. 이번 과제에서 ‘관심사의 분리'에 신경 써보라는 요구사항이 있었다.

 

그래서 나는 관심사의 분리를 잘하기 위해서 계층별로 역할을 나누었고, 더불어 한 로직 안에서 핵심 로직과 부가 로직을 나누어서 내부적으로 이벤트 드리븐을 적용하여 로직을 작성하였다.

 

그런데 모의면접에서 면접관 역할을 해주셨던 분이 ‘오버 엔지니어링일 수도 있지 않을까요?’라는 질문을 하였다. 시스템의 요구사항을 구현하는데 필요 이상의 복잡성을 가지게 설계하는 것을 보통 오버 엔지니어링이라고 한다.

 

이벤트 기반 아키텍처를 통해 시스템을 구축하면 다음과 같이 여러 장점들이 많다.

• 확정성과 재사용성
• 비동기를 통한 시스템 최적화
• 유지보수성
• 장애전파 방지
• 관심사의 분리

하지만 또 이런점들도 고려해봐야 한다.

• 시스템의 복잡도가 증가
• 이벤트 처리 순서 보장 어려움
• 분산 트랜잭션
• 디버깅과 테스트가 어려움

 

모든 것은 다 트레이드 오프가 있다. 그래서 이를 잘 생각하여 로직을 작성해야 한다. 만약 ‘관심사의 분리에 신경써봐라’ 라는 요구사항이 없었다면 나도 이벤트 기반 로직을 도입을 안 했을 것이다.

 

또한 실제로 이벤트 기반 아키텍처를 도입해야 한다면 다음과 같은 고려사항을 생각해 볼 것 같다.

• 프로젝트의 확장 여부
• 외부 시스템과의 통신 여부

 

정말 프로젝트의 단위가 작고, 확장 가능성이 거의 안보인다면 도입을 하지 않을 것 같다.

 

항상 트레이드 오프를 생각하고, 이를 잘 설명할 수 있도록 연습하자!

한줄 후기

 

트렌드 보다는 상황에 맞게!

 

 

바닐라코딩: https://www.vanillacoding.co/