프로젝트 S 설명 및 회고
🗓️ 프로젝트 설명
기존에 작성된 사용자 사이트와 관리자 사이트의 전체 UI/UX를 개선하고, 버그 및 코드 관리
클라우드와 앱패키지를 통해 서비스 출시하였습니다.
한 개의 프로젝트에 두 가지 사이트를 동시에 개발해야 했습니다.
- 사용자 사이트
vanilla JS- MS Office 문서 내의 애드인 기능을 통해 문서의 정보를 저장/확인하고, 문서 원본을 서버에 등록하고 증명을 받을 수 있는 서비스
- 관리자 사이트
vue JS- 사용자가 저장한 문서의 정보의 현황을 관리하고, 서버에 저장된 문서 원본을 확인할 수 있는 서비스
🗄️ 프로젝트 시작
처음에는 프로젝트의 BUG들을 QA에게 전달받아 처리를 하는 일로 시작을 했습니다.
하지만 BUG가 너무 많았을 뿐더러, 사내의 다른 프로젝트들과 UI/UX가 차이가 많이 나서 먼저 전체의 UI/UX를 개선하면서 버그를 줄이는 프로젝트를 시작하게 되었습니다.
🗓️ 프로젝트 개발 및 배포 사이클 구체화
프로젝트의 기한 관리나 문서 관리가 되고 있지 않아, 사내에서 사용하고 있는 관리 시스템을 이용하여 기한 관리와 문서 관리를 시작했습니다.
업무 효율 향상
기한 관리를 통해 업무 처리 속도를 가늠할 수 있게 되고, 문서 관리를 통해 다른 팀들과 의사소통 리소스를 절약할 수 있게 되어 업무 효율이 향상되었습니다. 이에 대한 회고를 아래 페이지에 작성해두었습니다.
🎨 UI/UX 개선
공통컴포넌트 사용으로 개발 부담 감소
사내 서비스들의 UI/UX를 공통으로 맞추어, 서비스들끼리 공통 컴포넌트를 공유하여 사용하도록 수정했습니다. 사내에서 사용하는 컴포넌트들의 UI/UX를 맞추니 서로의 코드를 참고하여 개발 부담이 많이 줄어든 것을 느꼈습니다.
따로 함께 일하기
사내의 프론트엔드 개발자끼리 코드를 100% 오픈하여 서로 참고하고 잘 모르는 부분은 서로 질문하고 도와주는 환경이 가장 좋았습니다. 각자 다른 프로젝트를 하고 있지만 하나의 서비스처럼 개발을 해서 함께 일하는 느낌이 가장 많이 들었던 프로젝트입니다.
🐞 버그 개선
sonarQube 정적 분석을 통해 코드 품질 개선
배포 프로세스 중에 sonarQube 정적 분석을 통해 코드의 품질을 평가를 하는 단계가 있습니다. 이때 Critical로 분류된 이슈가 100개 가까이 되어 QA 팀에서 코드의 품질을 개선해달라는 요청이 있었습니다. Critical로 분류된 이슈는 장애를 발생시킬 가능성이 높기 때문에 우선순위를 높여 처리를 하되, 1주일 단위로 Critical의 개수를 10개씩 줄여나가 모든 Critical 이슈를 처리했습니다.
Clean Code의 중요성
이 과정에서 가장 많이 생겼던 이슈가 하나의 함수안에 15개 이상의 조건이 있는 경우에 대한 이슈였습니다. 이때 하나의 함수를 기능에 따라 여러개의 함수로 분류하고, 단순 if else 문 보다는 if return을 통해 조건문 부하를 줄이고, 삼항연산자를 이용해서 가독성을 높이는 방법으로 처리하니, 전보다 유지보수가 훨씬 쉬워진 것을 느끼고 가독성의 중요성을 깨달았습니다.
서비스 품질 개선
또한 QA 팀에서 수동 테스트 결과로 검출된 버그를 전달받아 2주에 한번 처리하여 기존 모든 페이지에서 발생하던 버그를 모두 처리하고 서비스의 품질을 높였습니다.
📝 E2E 테스트 도입
개발 단계에서 발견되지 못하고 배포 요청을 하게 되는 일이 반복되자, QA팀에서 TDD를 제안했습니다. 초기에는 단순히 유닛테스트를 넣으려고 했지만, 사용자의 입장에서 사용 흐름을 테스트할 수 있는 E2E 테스트를 최종 도입하게 되었습니다.
아래 페이지에 E2E 테스트를 도입하기 전의 생각과 회고를 작성해두었습니다.
🛫 배포 관리
개발환경
Jenkins를 이용하여 Git → E2E → SonarQube → Docker 순으로 배포 관리했습니다. 로컬 환경에서 기능을 추가하는 중 발생한 이슈를 E2E 테스트와 SonarQube를 이용해 테스트를 해볼 수 있어서 코드의 안정성을 보장받을 수 있어 좋았습니다.
SaaS 서비스
Azure Pipeline을 이QA에게 배포 요청하면 QA테스트 → 사내 사용 테스트 → 배포를 하는 과정을 거쳤습니다. 이때 QA 테스트에서 버그가 발견되면 수정하고 다시 배포하는 과정을 반복하여 서비스를 안정적으로 배포했습니다.
PaaS 서비스
내부 폐쇄망을 사용하는 고객에게 서비스를 제공하기 위해 실제 물리서버에 쿠버네티스 환경을 만들고 서비스 이미지를 배포한 뒤 폐쇄망을 만들어 운영을 해보는 테스트를 해보았습니다. 웹 개발을 시작하면서 물리환경이나 네트워크 환경에 대해 공부해 볼 기회가 많이 없었는데, 이 기회를 통해 공부를 하면서 스스로 만든 서비스를 제공할 수 있어서 값진 경험이 되었습니다.
🌈 느낀점
Liked
서비스를 배포하고 유지보수 관리를 하는 환경을 주도적으로 만들 수 있어 좋았습니다.
짧은 시간동안 모든 과정에 참여하여 서비스의 퀄리티를 손수 올릴 수 있어 좋았습니다.
Lacked
프로젝트를 이끌어 주시는 분이 있었지만, 함께 프로젝트를 만들어가는 팀원이 없어서 아쉬웠습니다. 주도적으로 일할 수 있어 좋았지만, 혼자 일하는 것 같은 느낌이 들 때가 있어 가끔 힘이 들 때가 있었습니다.
Learned
sonarQube, e2e테스트, docker, kubernetes 등 코드 및 형상 관리에 대해 많이 배웠습니다.
단순히 웹사이트를 만드는 것이 전부가 아니라 유지 보수를 하기 쉽고, 오류가 적고 성능이 좋은 코드를 만드는 것이 중요하다는 것을 많이 배울 수 있어 좋았습니다.
Leave a comment