입사 후 첫 프로젝트를 하며 느낀 점 (개발 방법론, 생산성, 협업)
어느덧 개발자로 입사하여 회사의 프로젝트에 참여하게 되었다.
몇 달 간 실무를 하며 느낀 점들을 정리해보았다.
소프트웨어 개발방법론의 필요성
입사 1달 만에 팀장이 교체되었고, 새로운 팀장님마저 퇴사하셨다.
이후 팀장 없이 부서가 운영되었다.
처음에는 어떻게 업무를 진행해야 할지 몰랐지만, 대표님과 연구소의 도움으로 개발 진행 방식을 배웠다.
덕분에 '소프트웨어 개발방법론'의 개념을 알게 되었다.
먼저 제품에 대한 영업/컨설팅 문서를 바탕으로 고객 요구사항과 개발 Scope을 정리해야 했다.
이후 화면 디자인, 아키텍처, DB 설계를 진행하게 되었다.
폭포수 방식으로 진행하기에는 설계에 사용할 시간이 부족할 때, 프로토타입 개발방법론을 자주 사용한다고 한다.
프로토타입을 먼저 개발해보며 추후 미비된 설계를 보완하는 방식이다.
고객의 요구가 불분명한 경우에는 애자일 방법론을 사용하려 하지만, 현재 매끄럽게 진행된다는 생각은 들지 않았다.
프로젝트를 성공적으로 진행하려면 소프트웨어 개발방법론에 대한 이해와 경험을 바탕으로
프로젝트의 성격, 고객의 특징, 가용 시간에 맞게 적절한 방법을 사용할 수 있어야겠다.
스스로의 개발 생산성 높이기
취업 개인 프로젝트를 진행할 때에는 시간에 쫓기지는 않았다.
그러나 회사 실무에서는 마감으로 인해 시간이 부족한 상황이 발생한다.
그래서 시간 관리가 중요하며 개발 생산성을 높이기 위한 방법을 찾는 것이 중요하다고 느꼈다.
1. 최소 기능별 데드라인을 스스로 설정하기
개발 업무는 작은 기능 단위로 쪼갤 수 있다.
예를 들면 '사용자 등록 테이블 CRUD 구현'과 같은 식이다.
이에 대한 데드라인을 스스로 설정하는 것이 생산성을 높이는 방법이라고 느꼈다.
개인적으로 3~4시간 단위가 적절한 것 같다.
2. 에러 핸들링은 할당된 시간에만 진행하기
에러 핸들링을 하다 보면 시간만 무한정으로 투입하고, 정작 에러를 해결하지 못하는 경우가 종종 있었다.
이 경우 시간이 길어질수록 집중력이 흐트러지고 늘어져 오히려 업무의 효율성이 떨어졌다.
그래서 에러핸들링에 투입할 시간을 미리 정해놓고, 그 시간 내에 해결하지 못하면 휴식을 취하거나 다른 업무를 진행했다.
시간이 지난 뒤에 다시 그 에러를 핸들링하면 금방 해내는 경우가 많았다.
결론적으로 해결되지 않는 에러를 놓고 무작정 시간만 투입하는 것은 비효율적이라고 느꼈다.
에러핸들링에는 정해진 시간만큼만 사용하고, 만약 시간 내 해결하지 못하면 다음 날로 미루는 것이 더 낫다고 생각했다.
3. 코딩하기 전에 먼저 코드 구조를 종이에 그려보기
처음에는 구현해야 할 기능이 있으면 무작정 코딩을 시작했다.
그러나 이는 코드 구조를 복잡하게 만들었고 투입한 노력에 비해 완성된 코드의 품질이 좋지 않았다.
그래서 코드 구조를 A4 용지에 미리 그려본 뒤에 코딩하는 것이 더 유용하다고 느꼈다.
최근 프로그래머스 Dev 매칭에서도 이와 같은 방법을 사용했고, 덕분에 제한 시간 내에서 넉넉하게 과제를 마칠 수 있었다.
협업을 위한 매너
1. 최소 기능 단위로 자주 commit 하기
혼자서 프로젝트를 할 때에는 1건의 commit에 다양한 기능을 변경 내용을 포함시켰다.
그러나 협업 시에는 1건의 커밋에 1개의 기능 또는 컴포넌트만 포함되어야 하며, 커밋은 최대한 자주 하는 게 좋다고 한다.
그래야 동료들이 1건의 커밋 메시지를 통해 어떤 기능이 바뀌었는지 직관적으로 이해하기 쉽다.
2. commit 하기 전에 반드시 기능 테스트 진행하기
코드 수정 후 기능테스트를 하지 않고 commit 및 push를 한 적이 있다.
그래서 동료들이 pull을 받고 에러가 발생하여 고충을 겪었다.
이런 민폐가 또 있을까?
코드를 수정했으면 반드시 기능 테스트를 하고, 완성된 코드만 push 하자.
3. 한글 경로 사용 지양하기
개인 PC에서 서버 Repository 경로에 한글이 포함되어, 로컬에서 Spring 서버가 실행되지 않는 에러가 발생한 적이 있다.
한글 경로 사용은 지양해야겠다고 느꼈다.