과제물을 만드는 자세?

김민준·2023년 7월 3일
0
1. 더 나은 방식을 생각하자
2. 협력 방식의 조직화

저번 일주일동한 한 과제를 총 정리한 TIL
기술적인면보다는 조직/생활적인 면에 대해서 쓰고자한다.

1. 더 나은 방식을 생각하자.

뉴스피드를 만들면서 댓글 신고 시스템을 구현했다.
신고가 5회 누적되면 DB에서 댓글이 삭제되도록 만드는 기능이었는데, 이건 너무 만드는 입장에서만 생각한 것이었다. 서비스를 하는 입장까지 고려하면 단순히 신고 누적 외에도 신경쓸것이 있기 때문이다.

  1. 신고가 누적되었다고 삭제할만한 글은 아니다.
    단순한 불만표현 또는 괴롭힘으로 신고를 누르는 경우도 있기 때문이다.
  2. 삭제되면 댓글과 함께 신고내역도 같이 사라진다.
    즉, 원래 댓글의 주인이 항의를 하면 정말로 신고내역이 있었는지 그리고 그 댓글이 지워질만한 내용이었는지 아무도 알 수 없게 된다는 것이다.
  • 결론 : 신고와 같이 유저들의 판단에게 맡기는 시스템의 경우 삭제라는 되돌릴 수 없는 동작 대신 가리기 또는 get에서 불러오기 제외하는 등의 조치를 취하는 것이 더 좋다고 판단된다.

2. 협력 방식을 더 합리화/조직화해야한다고 생각했다.

과제물 제출은 오늘 오전 10시 발표는 오후 2시였다.
하지만, 오늘 새벽 3시에 발표를 맡은 팀원이 문제가 있는 것을 발견하였고, 새벽 5~6시까지 같이 오류를 수정했다.
과제를 위해 만든 레파지토리의 주인은 그 전에 자러 갔기 때문에 우리는 깃으로 파일을 공유할 수 없었고, 압축파일등으로 작업물을 주고 받게 되었다.
여기서도 세 가지 문제와 해결책을 찾았다.

  1. 찾거나 해결한 문제를 원격 저장소에 올리지 못했다.
    왜냐하면 새벽에 문제를 찾았고, 그때 공용 작업을 위한 레파지토리의 소유자가 없었기 때문에, 자료를 zip파일로 주고받으면서 작업했기 때문이다.

프로젝트를 할 때 공용 git hub 계정을 만들어야겠다. Id Password는 모두가 공유하지만, main branch는 팀장 또는 관리하기로 한 사람만이 맡는다. 관리자가 없을 때는 공용계정으로 로그인 한 다음 별도의 브랜치에 작업물을 올려서 작업을 행야할 것 같다. 왜냐하면, 충돌 해결을 한사람이 하면 일관성과 관리 책임의 소재가 확실해지지만, 반대로 그 사람이 없으면 긴급한 순간에 작업을 할 수 가 없게된다. 그에대한 대책으로 팀원들 끼리 정보가 공유되어도 상관 없는 새로운 계정을 만들고, 관리자가 없을 때는 별도의 branch에서 작업함으로써 긴급상황 대책과 일관성 유지를 동시에 챙기는 것이다.

  1. 피곤함
    위의 문제의 연장선이다. 오전 9시에 팀원들끼리 화상회의를 할때 새벽에 이미 해결했거나 찾은 문제들을 팀원들이 다시 찾고 고치기 시작했고, 잠을 제대로 자지 못해서 피곤한 상태였기 때문에 이미 찾거나 해결한 문제들을 제대로 설명하지 못했다. 심지어, 멀쩡한 정신으로 하는 팀원들은 새벽의 피곤한 사람들 보다 더 빠르고 효율적으로 문제를 처리했다. 즉, 새벽에 고생은 고생대로하고, 실질적으로 얻은 것은 매우 적었던 것이다.

정말로 급한것이 아니라면 일정 시간이 되면 작업을 그만두고 자고 일어나서 하는 습관(루틴)을 만들어야겠다. 예를 들어 아무리 늦어도 새벽1시에는 자야겠다고 정하기만 해서는 그럴 수 없을 것이다. 사람이 하던거 그만 두고 가기는 힘들기 때문이다. 오후 11시까지는 작업을 마무리하고, TIL이나 내일 할일 등을 정리하는 식의 계획을 세워야할것이다.

  1. 계속해서 발생하는 문제
    10시에 과제물을 제출한 이후에도 계속해서, 이 기능은 어떻게 고치는게 좋을까요? 같은 대화가 오고갔다. 개선책 자체는 나왔지만 시간내에 구현을 하지 못할 것같아서, 완성을 하지 못하고 원래 없던 기능 인것처럼 해야했다. 우리가 원하는 서로 자기 만들것만 만들고 레파지토리에 올릴때만 충돌을 해결하는 식으로 한것이 원인인것같다. 오늘의 일 뿐 아니라 얼마 전에도 내가 생각한 사용자 조회 정보와, 팀원들이 생각한 사용자 정보 조회의 세부적인 사항이 달랐고. 그래서 작업의 일부를 다시행하는 경우가 있었다.

해결책으로는 1주일 짜리 짧은 프로젝트이니 만큼 2~3일에 한번씩은 내가 어떤 기능을 어떻게 구현했는지. 그리고 왜 이런식으로 구현했는지. 그리고 궁극적으로 우리가 만들고 있는 작업물의 방향성이 서로 일치하는지를 봐야할 것 같다.
나의 짧은 경험으로 미뤄볼 때, 처음 몇 일간은 자기가 맡은 기능을 어떻게 구현할지 고민이 많기 때문에 수 / 금의 일정한 시간에 한번씩하고, 그 이후에는 어느정도 가닥은 다 잡히고, 기능의 자기 기능의 세세한 점을 파기전에 내가 하는 것이 전체 작업물에서 유의미한것인지 확인하는 간단한 확인 작업을 하루에 한 번은 하는게 좋을 것같다.

profile
node 개발자

0개의 댓글

관련 채용 정보