4Week Fs
1) Facts: 일주일 동안 있었던 일, 내가 한 일
팀 과제를 완료했다.
주말동안 내용을 나름대로 정리해서, 계획을 세워서 노션 파일로 정리해둔 다음 팀원분들께 공유했다.
마감날보다 빠르게 과제를 완성하고, 부족한 부분을 다듬으면서 실행에 문제가 없도록 코드를 수정했다.
깃 허브로 협업하면서 README 파일도 작성해봤다.
2) Feelings: 나의 감정적인 반응, 느낌
깃 허브로 협업 해본 적이 없었는데, 이번 팀 과제에서 팀장을 맡았다. 팀장을 맡는 것 자체는 사실 괜찮았다. 계획 세우는 것도 좋아하고, 내용 정리하는 것도 좋아하기 때문이다.
다만 실력이 모자랏 탓에 팀원들을 잘 이끌 수 없을 것 같은 것이 가장 걱정이었다. 깃 허브로 팀장으로써 협업을 해본 경험이 없었기 때문이다.
하지만 팀원분들이 정말 잘하시는 분들이었고, 모르는 부분을 여쭤봤을 때 다 알려주셔서 큰 문제가 없이 잘 해결되어서 참 다행이라고 생각한다.
3) Findings: 그 상황으로부터 내가 배운 것, 얻은 것
(1) 깃 허브 조직으로 협업하기: 깃허브에서 조직을 만들어서 그 안에서 진행할 수 있었다. 처음 접해본 기능이었는데, 처음에 조직을 만들 때 팀원분들을 추가할 수 있다. 그 다음에 레퍼지토리를 만드는데, 레퍼지토리마다 팀원분들을 추가해주어야 한다. 그리고 팀원에게 역할을 부여해줄 수 있는데, 4 종류의 역할 내용을 잘 읽어보고 부여해 주어야 한다. 그렇지 않으면 팀원분들이 브랜치도 생성하지 못하는 문제가 생길 수 있다 ..^^ 번거롭긴 하지만 제3자가 와서 코드를 수정할 수 없는 것 같아서 괜찮은 기능이라고 생각한다.
(2) 깃허브 내용 pull: $git pull origin <브랜치이름> .. 이제는 외웠다 .. 내용을 pull 해올 때 충돌이 일어날 수 있는데, 내용을 잘 읽어보고 필요한 내용만 잘 남겨두면 코드를 잘 받아올 수 있다. 하지만 충돌이 .. 없이 가져오는 게 제일 좋을 것 같다..
(3) 무한 루프 상태의 메소드를 불러오기: 메소드 안에 무한 루프를 돌려놓고, 조건에 맞으면 다른 메소드를 호출했다가 다시 무한 루프가 있는 메소드를 불러오는 형태를 사용했었다. 하지만 이렇게 되는 경우, 처음에 무한 루프에 따로 break를 걸지 않았기 때문에 종료가 되지 않은 상태이다. 다시 돌아오면 무한 루프가 두 개가 도는 격이라 종료조건에 걸려도 제대로 종료가 되지 않는다. 무한 루프에 다른 메소드로 넘어가면서 break를 걸지 않을 것이라면 다른 메소드에서 다시 무한루프를 포함한 메소드를 호출하지 않으면 된다. 혹은 break를 걸 것이라면 다른 메소드에서 다시 무한루프가 있는 메소드를 호출하면 된다.
4) Future: 배운 것을 미래에는 어떻게 적용할 지
깃허브 협업이 처음이었는데, 조직도 사용해봤고 pull request 내용을 보고 merge도 직접 해보니 조금 익숙해진 듯 하다. 충돌이 일어나도 어디서 충돌이 생겼는지 친절하게 알려주기 때문에 내용을 잘 읽어보고 변경하면 충돌 해결도 충분히 잘 할 수 있을 것 같다.
0개의 댓글
