[새싹 x 코딩온] 웹 개발자 과정_ 1차 프로젝트 회고(1)
HTML, CSS, JS에 이어 Node.js, ejs, MySQL 까지 배우고 드디어 첫 프로젝트를 마치게 되었습니다. 1.목표와 계획 평가: 프로젝트를 시작할 때 설정한 목표와 계획을 다시 살펴보고, 이를 얼마나 달성했는
lemon4974.tistory.com
위의 글에서 이어집니다!
4.협업과 커뮤니케이션 평가:
- 팀 내 협업 및 커뮤니케이션을 평가합니다. 팀원들과의 협업에서 장점과 개선점을 언급하고, 프로젝트 관리 도구나 회의, 의사소통 도구 사용에 대한 피드백을 제공합니다.
잘한 점
1. 웹디자인 시안
프론트로서 사이트가 어떤 기능을 하고 있는지 정리해주어야 백이 작업을 할 수 있기 때문에 빠르게 메인페이지를 결정하고 싶었습니다. 이에 저는 AI로 메인페이지를 만들었습니다. 아래의 사이에서 가능합니다.
https://www.framer.com/templates/
Framer — Success starts with a site
Design and publish your dream site. Add animations, interactions, and optimize for every breakpoint. Then scale your site with an advanced CMS and Localization — no code needed and publish for free.
www.framer.com
위의 사이트를 이용해 아래의 사이트를 만들었습니다.
https://cheerful-apartment-423645.framer.app/
My Framer Site
Made with Framer
cheerful-apartment-423645.framer.app
구체적인 예시를 보여주면서 어떤 기능이 있어야하고 어떤 페이지로 연결되어야 할지 얘기를 해보니, 저나 다른 팀원이 이해가 잘 되는 느낌이었습니다.
2. 피드백
깃에서 하나의 develop 브랜치에 계속 merge 하고 같이 사용했습니다. 이 때문에 실행이 안 되는 부분은 모두의 문제(?)였기 때문에 하나의 에러라도 발생하면 같이 논의하여 조금 더 빠르게 문제를 해결할 수 있었던 것 같습니다. 처음에 분리해서 작업하지 않고 합쳐서 작업했기에 프로젝트 중간에 프론트와 백을 합치는 과정의 시간을 아낄 수 있었습니다. 하지만 실제로는 프론트와 백을 분리해서 작업한 후 합치는 것이 실무적으로 일반적이라는 말을 들어서 다음 프로젝트에서는 다른 방식으로 하게 될 것 같습니다.
개선해야할 사항
1. 초반엔 프론트랑 백이 분리된 느낌이었습니다. 하지만 pr로 각자 어떤 기능을 구현했는지 commit message로 남겼기 때문에 pr(pull request)로 진행 상황을 알 수 있었습니다. (수업 시간의 commit message 습관이 들었기 때문에 가능했다고 생각합니다.) 또한 한 사람의 pr을 다른 사람이 approve를 해줘야 merge를 할 수 있었기에, 카톡으로 어떤 기능을 만들었고 머지를 부탁한다는 연락을 주고 받아야 했습니다.
느낀 점
1. 파레토의 법칙
파레토의 법칙은 흔히 20 : 80의 법칙으로 알려져 있습니다. (20%의 사람이 80%의 일을 한다는 법칙입니다. )프로젝트를 하면서 잘하는 사람이 결국 일을 많이 할 수 밖에 없다는 사실을 절실히 알게되었습니다.... 제가 5시간 고민해봐야 어떤 사람은 10분 만에 해결하는 경우가 있기에, 후에 신입으로 지원하게 될 제 입장에서는 개발자로서 나를 뽑아야 할 이유가 있을까? 라는 의문이 들어서 그 이유를 분명히 찾아야겠다는 생각이 들었습니다.
2. 안 되는 것은 바로바로 요청하기
전의 글에서도 말했듯이 백엔드 팀원으로부터 도움을 너무 많이 받아서 혼자 해결해 보려고 했지만, 시간을 오래 끌게 되어서 왜 이런 것도 혼자 해결 못하지... 자괴감이 들었던 적이 있는데, 알고보니 컨트롤러 쪽의 코드 에러였어서 제가 해결할 수 없는 문제였습니다. 그 코드를 고친 후 바로 해결되었기 때문에, 문제 상황은 바로바로 팀원에게 물어보는 것이 좋다는 중요한 교훈(?)을 얻을 수 있었습니다.
부족했던 점
1. 사실 특별한 규칙이 없었음에도 결과가 좋았던 것은...
- 데이터를 뽑아오면서 카멜케이스와 스네이크케이스가 섞여있기도 하고, 브랜치명도 통일되지 않았지만, 프로젝트가 무사히 완수된 것은 팀원들이 적극적으로 소통하려고 했기 때문이었습니다. 프로젝트 관련이라면 뭐든 서로 돕고 얘기하려고 했었습니다. 하지만 현업에서는 프로젝트만 하는 것이 아니기에 이정도의 협력적인 모습은 어려울 수 있다고 생각합니다. 다음 프로젝트에서는 규칙을 잘 숙지하고 지키는 과정을 해봤으면 좋겠다고 생각이 들었습니다.
2. 주석 설명
- 분명 처음에 서로 주석으로 (특히, 백과 프론트에서) 기능 설명이나 코드 위치를 알려주려 했는데, 시간이 쫓기다 보니 자연스럽게 잊혀졌습니다.
3. 주체가 되지 못함?
- 시간에 쫓기면서 하는 동안, 아는 것이 없으니 이런 기능이 필요하겠다도 제안하지 못하고, 공부해서 어떤 기능을 자신있게 도입하지 못 했습니다. 지난번에 구글링에 대한 감이 살짝 생긴 것 같아, 다음 프로젝트에서는 빠르게 공부하고 기능을 도입할 수 있었으면 좋겠습니다. (제발...)
사용 도구
: git, slack, 카톡, 디코, 노션
의외로 발견한 강점이 이런 도구에 대한 사용법을 그래도 잘 익히는 편인 것 같다는... 생각이 들었습니다. 디코도 사용해봤기에 다른 분들에게 회의하는 용도의 도구로서 안내를 해줄 수 있었던 것 같습니다.
깃에 대해서 확실히 알게 되면 강점으로 작용할 수 있을 것 같아... 깃을 파보는 것도 나쁘지 않을 것 같습니다.
5. 사용자 피드백과 사용성 평가:
- 프로젝트를 사용한 사용자들로부터 받은 피드백을 정리하고, 이를 바탕으로 사용성을 개선한 내용을 기록합니다. 사용자들이 프로젝트를 어떻게 활용하고 있는지에 대한 인사이트를 공유합니다.
리더님들 피드백 중 프론트 쪽으로는 디자인적인 통일성이 아쉽다는 평을 받았습니다. 제가 봐도 여러 사이트의 소스나 부트스트랩을 얼기 설기 붙여 놓아 통일성이 아쉽다고 생각했습니다. 프론트도 어느 정도의 UI/UX 공부도 해야하는 걸까라는 생각이 들었습니다. 오늘 커리어 코칭에서 사이트를 보여주었을 때 몇 개의 클론 코딩을 해보는 게 좋을 것 같다고 하셔서 앞으로 두 세개 정도의 클론 코딩을 진행할 예정입니다.