안녕하세요, 오늘은 Asset(이하 에셋)의 Naming(명명)에 대해 필자의 견해를 적어보겠습니다.
왜 글을 쓰게 되었나요?
기존의 서비스를 개편하면서 파일, 클래스, 함수, 변수 명에 대한 Naming에 대한 고민을 하게 되었습니다.
고민을 하던 중, 우연히 에셋 폴더를 열어본 순간 에셋 명 또한 고민이 필요하단 사실을 깨달았습니다.
일반적인 프로젝트의 에셋 상태.png
기존 서비스의 에셋 중 일부입니다. 정리가 잘 되어있는것 같지만, 애매합니다.
어느 에셋은 소문자 카멜케이스를 준수하는데, 어느 에셋은 _를 포함하며, (←) 모양의 에셋과 (<) 에셋의 이름이 'arrow'로 동일하게 이루어져있습니다. 또한 "bin_deleted"는 에셋을 보기 전까지는 어떤 에셋인지 짐작이 가지 않습니다.
신입 개발자 홍길동 씨는 새로운 페이지를 개발할때
← 에셋을 사용하려면 에셋 폴더를 뒤져서 비슷한 모양을 찾아 에셋의 이름을 확인해야 하며,
"bin_deleted" 에셋을 사용하려면 기존 코드를 통해 어떤 경우에 사용되는지 알아보거나, 유추해야 합니다.
이처럼 정리/관리 되어있지 않은 에셋은 재사용성이 현저히 떨어지며, 똑같은 에셋을 프로젝트에 또 삽입하게되는 불상사까지 벌어질 수 있습니다.
이러한 현상을 조금이라도 타개 하기 위해 네이밍을 고민 해보았고, 자료를 찾아보았으나, 고민을 확실하게 덜어주던 자료가 없어 글을 작성해보게 되었습니다.
그렇다면 어떻게 해야 하나요?
언제나 그렇듯이 파일, 변수, 함수 클래스의 모든 이름은 지나가던 (영어 할 줄 아는) 사람도 읽고 이해 할 수 있어야 합니다.
이것을 인지하고 네이밍을 고민해 보신다면 수월 할 것이라고 생각합니다.
필자는 에셋이 사용되는 기능 별로 구분하여 명명 했으며,
직접 고민했던 내용과 해결 방법들을 적어보겠습니다.
- 이것이 정답이라는 것은 아닙니다! 지극히 개인적인 견해입니다!!
1. 네이밍의 표기법을 정합니다.
기존 서비스에서는 소문자 카멜케이스, 스네이크 케이스 표기법이 혼용 되었기 때문에, 명명에 있어 기준이 필요했습니다.
필자는 소문자 카멜케이스를 채택했으며, 공백을 사용할 수 없기 때문에 (_)를 사용하였습니다.
2. 에셋의 기능이 아닌 에셋 자체를 표현하도록 합니다.
일반적으로 🔍 아이콘은 검색 기능에 사용됩니다. 따라서 xxxSearch, 혹은 searchIcon로 명명하실 것 이라고 예상합니다.
하지만 searchIcon로 명명하게 되면 검색에 사용되는 에셋인지, 검색 페이지에 진입하는 에셋인지 구분하기 어려울 것이라고 생각됩니다.
이를 해결하기 위해 에셋 자체를 표현합니다.
돋보기(magnifier) 모양이 필요한 곳에 maginifier를 삽입한다고 생각하니 편리합니다.
3. 비슷한 모양이라도 각각의 이름이 존재합니다.
위 상황에서 보셨듯이, → 아이콘과 > 아이콘은 비슷하지만 각각의 이름이 존재합니다.
→ : rightArrow
〉 : rightAngleBraket
▲ : filledTriangle
△ : emptyTriangle
최대한 에셋의 원래의 이름을 찾아 주세요.
대표하는 이름이 없다면 특징 묘사나 메타포(Metaphor)로 명명해 줍니다.
eg) checkBox, star, radioButton 등
4. 비슷한 에셋인데 색깔이나 상태, 방향등 일부만 다릅니다.
색이나 방향을 바꿔서 에셋을 사용하는 경우가 정말 많기 때문에 이러한 케이스는 빈번하게 일어납니다.
따라서 미리 규칙을 만들어 구분하게 되면 편리합니다.
저는 다음과 같은 방법을 사용하였습니다.
-
Color의 구분
questionMarkRed, questionMarkBlack 등
-
Button(controlState)의 구분
categorySearch_filter, categorySearch_filterActivated 등
-
Direction의 구분
arrowRight, arrowLeft, arrowUp, arrowDown
매우 상세한 구분법은 아닙니다만 위와 같은 방법으로 꽤 많은 에셋을 분류해 냈습니다.
5. Asset의 이름이 같은데 사이즈가 다르다면 이미지의 사이즈를 명시합니다.
angleBraketRightGray라는 동일한 Asset의 사이즈가 다른 경우가 존재합니다.
단순하게 small, big 등으로 구분 할 수 도 있지만, 비슷한 사이즈가 생겨난다면 애매해지기 때문에, 사이즈를 직접 명시하는 방법이 있습니다.
아래와 같은 경우를 참조해보시면 좋을 것 같습니다!
- angleBraketRightGray24 : (24x24) 사이즈 이미지
- angleBraketRightGray28 : (28x28) 사이즈 이미지
- angleBraketRightGray10x11 : (10x11) 사이즈 이미지
6. Folder를 통한 구분도 중요합니다.
특수한 상황/페이지/기능 에서만 단일적으로 사용되는 에셋의 경우, 쉽게 찾을 수 있도록 에셋 모음에서 폴더를 추가하여 폴더를 통해 관리합니다.
또한 에셋의 이름에 폴더 이름을 명시해줍니다.
이 때, iOS의 경우 공백을 허용하지 않으므로 일반적으로 대쉬(-) 혹은 언더바(_)를 많이 사용합니다.
- FAQ
- faq_questionMarkBlack
- faq_questionMarkRed
7. 텍스트 에셋의 경우
문자 그대로를 에셋으로 사용하는 경우도 빈번합니다. 이때도 마찬가지로 해당 에셋의 기능/사용처를 명시하는것 보다는 에셋 자체의 내용인 텍스트로 명명하면 편리합니다.
-
주의사항 텍스트 에셋 (색과 사이즈 다른경우)
text_caution
text_cautionWhtie
text_cautionWhtieLarge
-
카테고리 텍스트 에셋 (비슷한 텍스트)
카테고리 : text_category
상품카테고리 : text_productCategory
이벤트카테고리 : text_eventCategory
8. 마지막으로 에셋이름은 축약하지 않습니다.
에셋의 이름을 축약하게 되면 에셋을 한번에 파악하기 어렵게 됩니다. 따라서 최대한 축약은 기피해야하되, 축약어가 보편적으로 사용된다면 에셋의 이름이 너무 길어지는 것을 방지 하기 위해 예외적으로 허용하도록 합니다.
예를들어, '자주하는 질문' 의 경우 풀 네임은 Frequency Asked Question입니다.
하지만 통용적으로 FAQ로 축약하여 사용하기도 합니다.
따라서 풀 네임을 에셋 이름으로 할 경우 너무 길어지므로, 축약하여 사용했습니다.
- faq_questionMark
이러한 제약을 만들어 두어야 축약을 남발하지 않으며 통일성이 유지됩니다.
마무리하며...
이상으로 필자가 고민해보고, 적용했던 에셋 네이밍 규칙 입니다. 다시 한번 말씀드리지만 위 규칙이 정답이 아닙니다.😅
그렇지만 시작도 하지 못해 고민하고 있던 저에게 무척이나 필요했던 내용이였기 때문에, 이렇게 글로 남깁니다!
같은 고민을 하고있는, 하실 분들에게 조금이나마 도움이 되었다면 좋겠습니다.
끝으로 도움이 되었던 내용들을 첨부합니다.
읽어주셔서 감사합니다.
업데이트 이력
- 동일한 Asset의 사이즈가 다른 경우 (2021.06.21 추가)
https://brunch.co.kr/@pizzakim/26 : PizzaKim님의 블로그
https://github.com/dkhamsing/ios-asset-names : dkhamsing님의 github
