[포스코x코딩온] 웹 풀스택 과정 7기 7주차 금요일 회고
포스코 코딩온 웹 풀스택 과정 7기 7주차 금요일 회고
포맷터 통일
팀 프로젝트를 진행하는데, 팀원들끼리 포맷터 설정이 제각각이라 커밋마다 필요치 않은 변경사항이 계속 생겨났다.
- import { Request, Response } from 'express';
+ import { Request, Response } from "express";
- import { Controller } from '@/types';
+ import { Controller } from "@/types";
- import login from './login';
- import signup from './signup';
- import todo from './todo';
+ import login from "./login";
+ import signup from "./signup";
+ import todo from "./todo";
-declare module 'express-session' {
- interface SessionData {
- user: number;
- }
+ declare module "express-session" {
+ interface SessionData {
+ user: number;
+ }
}
팀원들이 모두 VSCode를 사용했기 때문에, .vscode/settings.json 파일을 통해 포맷터 설정을 통일했다.
테스트 생성
Jest를 사용해 테스트를 생성했다.
간단히 API를 통해 데이터를 보내고 DB에 저장되는지 확인하는 테스트를 작성했다.
예를 들어 DIARY 객체를 생성하는 API 테스트 코드는 다음과 같이 작성하였다.
test("create diary", async () => {
const [id, pw] = genIdPw();
await signup(id, pw, app);
const loginRes = await login(id, pw, app);
const cookie = loginRes.header["set-cookie"];
const [year, month, date] = dateSeparate(new Date());
const [title, content] = genIdPw();
const res = await request(app)
.post(`/diary/${year}/${month}/${date}`)
.set("Cookie", cookie)
.send({
title,
content,
emotion: "1",
});
const result = res.body as Diary;
expect(result?.title).toBe(title);
const userResult = await db.user.findOne({
where: {
username: id,
},
});
const user = userResult?.toJSON<User>();
const diaryResult = await db.diary.findOne({
where: {
user_id: user?.id,
year,
month,
date,
},
});
const diary = diaryResult?.toJSON<Diary>();
expect(diary?.title).toBe(title);
});
테스트 코드를 작성하니 예상도 못하고 있던 오류들이 온갖 곳에서 튀어나왔다.
물론 테스트 코드 자체가 잘못된 경우도 종종 있었지만, 대부분은 프로덕트 코드에 오류가 있었다.
테스트 코드를 작성하면서 오류를 수정하고, 오류를 수정하면서 테스트 코드를 작성하는 과정을 반복하며 코드를 수정했다.
덕분에 코드의 품질이 훨씬 개선됐다.
왜 다들 TDD(Test Driven Development)를 추천하는지 알 것 같다.
PR 리뷰
프로젝트가 서서히 완성되어 가면서, 프로젝트를 직접 만들기 보다는 팀원들의 PR을 review하는 시간이 더 많아졌다.
코드를 읽고 이해하고 피드백을 주는 과정이 생각보다 어렵고 오래 걸리는 작업이었다.
비록 많은 코드를 작성하지는 못했지만, 다른 사람의 코드를 이해하는 능력과 피드백을 주고 새로운 작업 사항을 지시하는 능력이 많이 향상된 것 같다.
Git에 대한 고찰
팀원들과 함께 작업을 하면서 여러 난관을 겪었다.
- Conflict
프로젝트 내내 컨플릭트가 발생해서 매번 해결하느라 고생했다. 팀원끼리 동시에 한 파일을 수정하는 경우가 종종 있었다. push 전에 pull을 꼭 하고, 그보다 중요한 것은 팀원 간의 소통이 중요하다는 것을 느꼈다. - PR 혹은 커밋 메세지에 본인 이름 적기 커밋이랑 PR에 변경점이 아니라 이름만 적고 올리는 경우가 많았다. 이런 경우 리뷰를 할 때, 변경점을 찾기가 힘들었다. PR 이나 커밋 메세지에는 변경점을 명확하게 적어주는 것이 다른 사람을 위한 배려라는 점을 확실히 느꼈다.
- 하루 치 변경 사항 커밋 하나에 넣기 커밋 하나에 하루 동안 변경한 수백 수십 줄을 한 번에 올리는 경우가 많았다. 이런 경우 리뷰를 할 때, 무엇을 했는지 알기 힘들었다. 아무리 애매해도 최대한 작은 단위로 커밋하는 것이 좋다는 것을 느꼈다.
- 스스로 본인 PR 승인하기
집에 가기 10분 전이었는데 팀원이 자기가 PR을 올리고 스스로 승인하고 merge했다. 다행히 GitHub에서 직전의 PR을 바로 revert 할 수 있는 기능이 있어 merge 를 되돌렸다.
그리고 바로 모든 팀원들을 Contributor에서 제외시켰다.
그 다음날 해당 PR 브랜치를 가져와 수정하고 다시 PR을 올리고 merge했다.
repository에 대한 권한 관리의 중요성을 뼈저리게 느꼈고, 불가능하다면 각자 repository를 fork해서 작업하도록 지시하는 것이 더 안전하다고 생각했다.
Git이 단순히 코드 백업용이 아니라, 협업툴 이라는 것을 다들 인지하고 팀과의 협업을 위해 사용해주셨으면 좋겠다.