컨벤션과 패턴이 뭐야? WHAT
개발 전에 정해야 할 것들이 있다.
컨벤션은 개발자들 사이에 일종의 약속된 규칙 또는 관례를 뜻하고 코드를 작성하고 구성하면서 일관성을 유지하고 가독성을 향상하는 데 도움을 준다. 소프트웨어 디자인 패턴은 특정 문제를 해결하기 위한 반복적이고 일반화된 해결책이다. 잘 적용된 패턴은 시스템의 구조를 조직화하고 코드의 재사용성, 유지보수성, 확장성을 향상한다. 둘 다 개발 효율을 올려주는 것들이지만, 컨벤션과 패턴을 유지하기 위해 드는 비용이 개발에 드는 비용을 잡아먹는다면 의미가 없다. 언제나처럼 상황에 맞게 적용하도록 하자.
꼭 정해야 되나? WHY
많은 시행착오를 겪고 싶다면 안 정해도 될지도?
이번 프로젝트는 1인 개발이기 때문에 많은 규칙은 필요 없다. 막말로 문서화를 아예 하지 않고 Build and fix 일명 주먹구구식으로 개발해도 괜찮을까 싶지만 프로젝트 중간에 개발 외적인 부분에 힘을 빼고 싶지 않았다. 실제로 이전 프로젝트에서 팀원들의 코딩 실력은 준수했는데 규칙이 없다 보니까 Git 브랜치 관리, PR 규칙, 코드 리뷰 등 상당히 어지러웠던 기억이 있다. 혼자 하는 개발이라도 조금만 지나면 내 코드도 읽기 힘들어지기 때문에 간단한 컨벤션은 정해두는 게 좋다.
어떻게 정했어? HOW
문서화 비용이 프로젝트를 잡아먹지 않도록 해라.
아래는 이번 프로젝트를 위해 정한 컨벤션, 패턴 등의 리스트이다. 참고로 말하자면 아키텍처 디자인 패턴과 프로젝트 패키지 구조는 서로 다르지만 연관되어 있다. 소프트웨어 디자인 패턴은 소프트웨어 시스템의 구조와 흐름을 조직화하는 방법을 설명하는 패턴이며, 프로젝트 디렉터리 구조는 소프트웨어 프로젝트의 파일과 디렉터리를 조직화하는 방법이다. 이번 같은 경우는 디자인 패턴을 정하고 나니 디렉터리 구조가 대강 잡혀서 아래와 같이 묶어뒀다. 이 외에도 Git branch protection rule, 개발에 사용할 resources (icon, vector asset), color (프로그램 전역에서 사용될 테마 색상), dimen 등도 미리 설정해두면 좋다.
SQLI 프로젝트 컨벤션 및 패턴
- 아키텍처 디자인 패턴: MVP (Model View Presenter)
- 프로젝트 패키지 구조
- Git and GitHub
- Git commit message convention
- GitHub Issue / PR templates
- Git Branch 전략: Git-flow
- Code convention
- 명명 규칙 (Naming Convention)
- 들여쓰기, 주석 규칙
이 외에도 다양한 컨벤션 등이 있다. 규모가 큰 프로젝트를 진행하는 회사에서는 정말 세세한 것까지 통일하는 컨벤션이 존재하는 거 같다. 자세한 컨벤션과 시행착오에 대한 경험담을 읽고 싶다면 아래 참고 문서의 글을 보면 도움이 될 것이다. 이제부터는 본격적인 개발을 시작하게 되는데, 프로젝트 중반에 일어날 수 있는 트러블 슈팅, CI/CD, 개발, 테스트, 리펙터링 등 다양한 글로 다시 찾아오도록 하겠다! 그때까지 다들 화이팅
SQLI 프로젝트의 GitHub Repository가 궁금하다면? 클릭
참고 문서
- 우아한 기술 블로그 표준 개발 환경 개선 되돌아보기
- 우아한 기술 블로그 우린 Git-flow를 사용하고 있어요
- Android Developers Kotlin 스타일 가이드
- Android Developers 앱 아키텍처 가이드
- 인텔리전스랩스 이야기 우당탕탕 프론트웹개발팀의 개발 문화 정착기
