[우아한테크캠프 3기] 2번째 페어프로그래밍 종료 및 회고 👀

728x90
반응형

 

# 프로그램 진행 방식

 

우아한테크캠프의 진행 방식은 매 프로젝트 (현재까지는 1주 ~ 2주 단위)로 2명 단위로 조를 짜서 프로젝트를 진행합니다 (랜덤 방식)

프로젝트는 제공받은 기획서 양식대로 프로젝트를 개발해야하며 이에 따라서 새로운 조원과 코딩 방식, 목표 등 과 같은

그라운드 룰을 정하게 됩니다

 

 

 

위와 같이 대부분 wiki를 통해서 정리를 하는데요,

양식은 자유롭지만 매 아침 스크럼, 오늘 할 일에 대한 목표, 개발할 api 형식 등을 정해서 wiki에 작성해 놓습니다.

이렇게 정리해놓으면 좋은 점은 개발하다가 이 부분 어떻게 하기로 했었지?? 하는 순간이 꼭 오게 되는데 그럴 때 확인하면서

정해된 양식대로 개발하거나 수정하기가 아주 용이한 점이 있어요

 

 

 

 

 api 양식을 정해두면 파트를 나눠서 개발하거나 혹은 헷갈릴 때 매번 다른 팀원에게 물어보지 않고도 확인하고

아~ 이렇게 하면 어떤 데이터를 받게 되는 군하고 확인할 수 있습니다

 

 

 

이렇게 데이터베이스 형식을 정의해두었기 때문에 새로 heroku mysql과 연동하면서 다시 테이블을 만들어야 했을 때 기존의 구조를 참고로 쉽게 데이터베이스를 만들 수 있었습니다. 꼭 정의해두시는 것이 중요해요 👍

 

 

# 팀원과의 협의 

개발자의 역량에 있어서 중요한 점은 무엇이라고 생각하시나요?? 

항상 언급되는 말이 있죠. 바로  '의사소통 능력' 과 '협동' 입니다.

 

개발하기도 바쁜데 다른 역량도 요구하니 힘들죠, 하지만 이것은 스스로를 보호하기 위해 길러야할 능력이기도 해요. 

우테캠에서 교육으로 길러주고자 하는 것이 이러한 역량이라고 생각하기도 합니다. 조원과 "같이" 한다라는 게 중점이 되어야해요

 

이번에 두 프로젝트를 하면서 다른 분들과 같이 개발을 했었는데요, 저를 비롯해서 모두 코딩방식과 지향점이 조금씩 다르더라구요 💦

정말 사람들마다 코딩 방식과 중요하다고 생각하는 점이 정말 다르다고 생각하게 되었습니다.

서로 원하는 것을 말하는 데 그 의견들이 상충한다면? 스트레스가 쌓일 수 밖에 없겠죠. 하지만 자신의 의견이나 다른 팀원이 원하는 대로만

진행한다고 괜찮아질까요?? 하기 싫은 것을 코딩할 때는 각자의 본 실력 그대로 코딩할 수 없다고 생각합니다. 

 

천성이 의사소통 잘하고 협조적인 사람이라면 정말 좋겠지만 그렇지 않은 사람이라면 연습이 필요합니다. 저도 그런 사람이구요 ㅠ_ㅠ

그렇기에 본인의 의견을 말하고 또 타당한 의견이라면 다른 의견을 받아들이는 연습을 해야되는데 그 중 하나가 페어 프로그래밍이고

우테캠이라고 생각해요 

 

이번 경험을 토대로 저희 조 뿐만 아니라 다른 팀들은 어떻게 개발을 진행하고 있는지를 보다보면 크게 의견이 갈리는 부분들이 있는 것 같습니다.

 

프로젝트 완성도를 높일 것이냐 vs 새로운 기술 개발 공부 및 활용에 중점을 둘 것이냐 

이번 프로젝트를 진행하면서 저도 많이 고민을 했습니다. 저희 조는 기본 바닐라 자바스크립트에 scss를 쓴게 다였거든요 .

하지만 TDD도 도입한 조도 있고 typescript를 도입한 조도 있는 것을 보고 저희도 그래야하지 않을까하고 계속 고민하게 되었습니다.

 

하지만 저의 의견은? 결론적으로 하지 말자였습니다. 저는 기술 공부도 중요하지만 이 기술이 과연 이 프로젝트에 필요할까? 를 중심으로 생각하게 되었던 거 같아요. TDD와 Typescript를 공부하는 것은 저에게 있어서 앞으로의 개발자 진로에 아주 좋은 경험이 될 것이라고 생각합니다. 하지만 이번 프로젝트에서 이것을 썼을 때 플러스적인 요소인가 마이너스적인 요소인가를 봤을 때는 좋지 않다고 봤습니다.

 

일단 둘 다 이러한 기술에 대한 경험이 없었고 현재로서의 제 역량을 살펴봤을 때에는 주어진 기간 내에 활용해서 좋은 프로젝트를 만들 수 있을 것 같지 않았거든요. 기술만 사용해보고 쓰지 못한다면 일단 제가 행복하지 못할 것 같다는 생각을 했어요. 

 

이렇게 보면 저는 프로젝트 완성도를 높이는 쪽에 가깝다고 볼 수 있는데 어떻게 보면 "삽질하면서 경험하고 깨달아라" 라는 이번 프로그램의 취지와는 상충할 수 도 있겠다고 생각합니다. 하지만 어느 쪽도 정답이라고는 생각하지 않고 타당한 이유만 있다면 새로운 기술을 충분히 도입할 수 있다고 생각합니다. 그렇기에 더욱 자신이 원하는 방향에 따라 프로젝트를 진행하고 싶을 때 타당한 이유로 설득할 수 있는 의사소통 능력을 더 길러야 된다고 생각합니다. 

 

# 새로 해본 것은 없어?

 

이번에 새로 써본 것이 아예 없느냐하면 그것도 아닙니다. webpack외에 이번에 SCSS를 처음으로 도입했어요. 기존의 css문법을 알면 해보기 쉽다는 점을 고려해 써보기로 했고 만약 잘 되지 않는다면 css를 쓰자라고 조원과 협의한 후에 도입했습니다. 결과적으로는 아주 좋았습니다. 

 

자식 요소의 css를 부모 요소 안에 적어주면서 관계도 명확하게 보이고 코드양을 상당 수 줄여 가독성이 좋아졌습니다.

@include extends 문법을 사용하면 재사용성도 훨씬 높아지기 때문에 이전보다 css개발 속도를 훨씬 더 높일 수 있었습니다.

부모와 자식 관례가 명확하게 한 블럭안에 보임

 

 

# 팀원에게 배울 점 

저는 기능을 빨리 개발해보고 코드를 정리하자!! 라는 편이었습니다. 하지만 이번에 같이 한 팀원이 미리 코드 구조를 구상하거나 기존 코드 를 리팩토링하는데 열심이었고 이에 대한 덕을 저도 톡톡히 보았어요. 그 중 하나가 크롱님이 말씀하셨던 fetchManager.js 입니다

 

fetchManager.js 

const options = {
  headers: {
    Origin: origin,
    'Content-Type': 'application/json',
  },
};
const getOptions = { ...options, method: 'GET' };
const postOptions = { ...options, method: 'POST' };
const deleteOptions = {
  ...options,
  method: 'DELETE',
  'Access-Control-Allow-Origin': '*',
};
const patchOptions = { ...options, method: 'PATCH' };

function getFetchManger(url) {
  return fetch(url, getOptions).then((res) => res.json());
}

function postFetchManger(url, body) {
  postOptions['body'] = JSON.stringify(body);
  return fetch(url, postOptions);
}

 

저희는 api를 fetch를 통해서 프론트 단에서 받았는데 이렇게 옵션들과 url을 하나로 정리하니 불필요한 코드를 줄이고 새로운 기능을 개발할 때 빠르게 도입을 할 수가 있었어요 😃이건 모두가 써줘야합니다.. 신세계예요

 

 //컬럼 생성
    const columns = await getFetchManger(todoListApi);

 

그러면 이렇게 간단한 코드로 쉽게 api를 사용할 수 있습니다.

이런 식으로 코드를 정의해서 사용해볼 생각을 안하고 매번 전체 코드를 쓰다가 반성하게 되었습니다. 

앞으로는 이렇게 재사용할 수 있는 코드를 작성하는 방법을 생각해야겠다고 깨닫고 많이 배웠습니다.

 

 

# 워라벨

지금까지 프로젝트를 진행하면서 항상 시간이 부족했고 쉽게 피로했습니다.

 

처음에는 욕심나서 자기 전에 더 개발하려고 했었는데요, 결과적으로는 피곤해서 하나도 못하고 다음 날에도 체력에 지장이 가고 결국은 안하느니만 못하더라구요. 

 

그래서 이전도 그렇고 이번에도 그렇고 개발은 정해진 시간에 열심히하고 남은 시간은 자율적으로 활용하면서 터치하지 않는 것을 지향하도록 했습니다. 6시 퇴근 시간이 되면 딱 퇴근을 준비하고 요가도 하고 강아지랑 산책도 하면서 일상적인 휴식도 충분히 취해야 지치지 않을거라고 생각했거든요. 

 

아무래도 모르는 부분이 많아서 공부할 시간이 부족했는데 회사에서는 개발에 집중하고 공부는 출퇴근 시간에 왔다갔다하면서 새로 개발할 기능에 필요한 기술에 대한 영상이나 자료를 찾고 추가 공부를 해서 회사에서 적용하는 방식으로 시간을 관리했습니다. 

 

기술이 다양하고 유동적으로 변하는 직종이다보니 평생 공부해야 한다는 직종이지만 워라밸의 균형을 맞추는 데도 다같이 관심을 갖고 협력하면 좋을 것 같아요 

 

 

여기까지 저의 우테캠 회고였습니다. 

프로젝트 동안 많은 것을 배웠고 또 더 많은 것을 배울 것이라고 생각합니다. 

다른 기술블로그 처럼 저도 많은 것을 공유할 수 있는 개발자가 되기를 희망하며 마칩니다.

 

 

 

 

 

 

 

 

 

 

 

 

728x90
반응형
TAGS.

Comments 0