2장 의미 있는 이름 #66
Comments
|
안녕하세요, 오랜만이네요! 이번에는 조금 여러 포인트들에 대해서 제 의견을 내 보았는데요, 반대 의견도 언제나 환영이고 좋아합니다!
동의합니다. C#에는 존재하지 않지만, 가장 큰 범위인 전역 변수/함수들은 함수 이름과 각 파라미터의 이름은 가능한 descriptive 해야 한다고 생각합니다. 클래스 안의 멤버 변수/함수(필드와 메서드)는, 클래스 이름이 그 맥락을 파악하는데 도움을 주므로 조금 클래스 이름이 주는 맥락을 이용해 덜 descriptive해도 괜찮다고 생각합니다. 로컬 변수의 경우에는 이건 진짜 스타일의 차이라서... 개인적으로 어떻게 생각하는지만 적어 보았습니다!
이것도 C#에서 주로 I를 붙이고, 마이크로소프트가 I를 붙이기를 권장합니다. 저는 I를 붙히지 않고 작업도 해 보았는데, 딱히 불편함을 느껴보진 않았습니다.
유니티 프로젝트는
static 팩토리 메서드 사용에 어떤 비용이 발생하는지 그 의견을 듣고 싶습니다!
저는 고정된 네이밍 룰같은건 딱히 없는 것 같아요. 저는 여러가지 실험해 보는 걸 좋아해서 그때그때 바뀌는데요, 요즘 해보고 있는 것을 공유드립니다. 저는 사실 private 멤버 변수(필드)에 대해서는 언더스코어(_)로 시작하는 편입니다. 헝가리안 인코딩은 현대에 필요없다고 생각은 합니다만, 언더스코어로 시작하는 것은 개인적으로는 같은 이름을 초기화할때 this키워드를 안쓰거나, 색깔만 바뀌는것보다 조금 더 지역 변수와 구별하기 쉽다고 생각은 합니다만, 이 부분은 그냥 취향의 영역이라 생각합니다. 저도 팀 코드베이스에서는 언더스코어로 시작하지 않는데요, 둘이 왔다갔다 해도 별로 불편한 점은 모르겠습니다. 그 외에도 private static 멤버 변수에 저같은 경우에는 이름을 최대한 짧고 간단하고 명료하게 하려 합니다. 어려운 단어보다는 우리에게 친숙한 단어로 하는게 더 좋은 것 같습니다. 유니티의 SerializeField의 경우에는, 특히 그게 prefab일 경우에는 저는 **Prefab이렇게 인코딩을 하는 편입니다. 이게 타입이 아니다 보니까 저같은 경우에는 헷갈리더라고요! SerializeField 버튼같은 경우에 closeButton의 이름을 close로도 바꾸어 보았는데요, 생각보다 헷갈리지는 안더라고요. 이게 좋은건지는 계속 해봐야 알 것 같습니다. 글을 쓰다 보니까 굉장히 길어졌네요..!! 이만 말 줄이겠습니다! |
|
@rpopic2 현중님은 왜 그런지, 진짜 목적이 뭔지 판단하시는 걸 좋아하시는 것 같습니다. 여러 시도도 직접 해보시고 결과를 보고 직접 판단하시는 부분과 쉽게 확신하지 않는 모습 또한 많이 배워갑니다. 항상 이런 글 올려주시는 것에 대해 감사하게 생각하고 있습니다. 4월달에 읽고 정리한 내용이라 지금 다시 읽어보면 달라진 내용도 있어서 의견을 나누기 적합해 보입니다.
이 부분에 대해서 BookClud에서 토론하며 나름 생각하게된 방향이 있었는데, 책에서 말하는 그렇게 작성하는 것이 코드작성레벨에서 궁극적으로 가져야 한다는 부분은 아직까지 동일합니다. 메서드 자체도 서술적인 명칭으로 뒤에 오는 매개변수와 이어질 수 있도록(없는게 좋지만) 하지만 시간이 지나면서 기본적인 그라운드에 대한 현실적인 문제?에 대해서 조금은 깨닫게 된 것 같습니다. 위에서 말한 궁극적인 레벨이 되려면 두 가지 조건이 선행되어야 한다는 부분입니다.
저는 두 가지다 아직은 가질 수 없고 개발하고 있는 현 주소가 한국이기 때문에 어렵다는 결론이 나왔던 것 같습니다. 지금도 가까워지려고 하지만 어려운 영단어, 서술적인 표현보다 협업 시 다른 사람들이 익숙하게 받아드릴 수 있는, 많이 사용하는 단어를 사용하려고 합니다.. 협업에 대한 가장 중요한 부분이 이런 이해관계라고 생각합니다. 말씀해주신대로 클래스이름의 힌트를 얻어 내부 멤버는 좀 더 즉각적인 유추가 가능한 너무 세부적이지 않은 이름의 부분도 매우 동의합니다. 로컬변수도 개수가 1~2개 이하라면 말씀 해주신대로 오히려 익숙한 변수명이 도움이 될 수 있다고 봅니다. 개수에 제한이 있는 이유는 프로그래머의 뇌라는 책에서 STM, LTM, 작업기억공간에 대한 개념이 나오는데 로컬의 경우 개수가 많아진다면 descriptive해야 한다고 생각이 들긴 합니다.
이 부분도 시간이 지나면서 많이 바뀌게 된 내용인데 실제로 궁극적인 인터페이스의 형태는 I를 붙이지 않는다고 하네요 실제로 스택오버플로우에 왜 붙이지 않는지에 대한 설명 질문에 대한 답변이 신입에게 왜 붙이지 설명하지 않는 비용이 붙여서 오는 비용보다 더 커서 말을 안 한다고 하네요 저는 첫 번째 의견과 같이 협업이기 때문에 정해진 컨벤션에 맞춰서 작업하는 편입니다.
처음 유니티로 게임을 개발하는 사람들 대부분이 단순 게임 제작에 강한 성격을 가지지, 코드 레벨까지 교정하지 않으니 위에서 다룬 모든 내용을 설명하기엔 성격이 달라서 단순 구현을 보여주기 편한 형태로 발전해온 것 같습니다. 물론 저도 아직도 Mananger, Controller를 사용중입니다. (나름 피해자..?) 하지만 협업 시초에 두개의 형태를 온전하게 분리한다면 나름 유용할 수 있다고 봅니다. 회사를 제외하고 3~4명이서 작업하기에 위 내용이 온전하게 분리가 된다면 좀 더 유연한 사용이 되겠지요.. 남의 코드를 쉽게 욕하지 말라고 하는 것이 그 당시에 최선의 선택을 했기 때문에 그런 결과가 나왔다고 생각이 이어지긴 합니다 그래서 인지 저는 항상 클래스를 만드는 것을 두려워 하지 말고 이름을 우아하게 작성하는 것을 목표로 두고 있습니다.
전역관련은 오로지 순수함수만 존재해야 한다고 많이 말을 들었습니다. 팩토리 메서드도 그중에 포함이 될 것 같습니다. 게임(유니티) 특성 상 데이터를 매우 매우 많이 다루게 되는데 이를 불변을 보장한다고 사용, 접근할 때 마다 팩토리 메서드로 할당 받아야 한다는 부분에 대한 비용적인 생각이였던 것 같습니다. lock문제도 같이 생각했었는지 잘 모르겠네요
1번 의견으로 대체합니다. 현중님! 너무 좋은 내용이 많아서 제 개인 REPO에서 다루기 보다 BRIDGE-DEV에서 기록되어 나름 문서화가 되면 좋을 것 같은데 혹시 내용을 옮겨도 될까요? 불편하지 않으시다면 해당 레포 PR부분에 코드 리뷰 형식이나 Disscussion 형태로 기록해도 좋을 것 같습니다. |
저야말로 같이 이야기할 수 있어서 매우 영광이고 감사합니다!! 항상 열심히 공부하시는 모습 보면 자극이 많이 됩니다.
동감합니다. 어려운 단어 써봤자 읽는 사람이 모르는 단어라면 인상을 찌뿌리거나 한 번 더 무슨 뜻인지 물어보게 되더라고요.
개수가 많아디면 descriptive 해야함에 동감합니다. 다만 저의 개인적인 생각으로는 로컬 변수의 개수가 5~10개를 넘어가면 함수를 이해하기가 힘들어지고, 너무 하는 일이 많다고 생각합니다. 또한 '클린 코드'가 좋아하는 짧은 함수와 한 가지만 하는 함수에서 멀어진다 생각합니다. 물론 불가피하게 로컬이 많아지는 경우에는 저도 descriptive한 이름이 필요하다고 동감합니다.
흥미롭네요.
정안님은 어떻게 실제 프로젝트에서 어떻게 그 둘을 구분하셨는지 궁금합니다!
저도 이 태도가 좋은 것 같아요. 항상 그게 최선의 선택이었을것이라 생각합니다.
흥미로운 주장이네요. 순수함수만 존재해야 하는 이유도 궁금하네요,
불변을 이야기하신다면 struct에 대해 이야기하고 계신 것 같네요. 저는 Complex 예시를 보고 간단한 팩토리를 생각했습니다: struct Complex {
Complex(float f) {
// 어떤 초기화
}
public static Complex From(float f) {
return new Complex(f);
}
}저도 이런 간단한 타입에서 굳이 팩토리를 써야하는지 잘 모르겠다는 생각입니다. 적어도 C#에서는 말이죠. 해당 팩토리가 객체이며 abstract라면 성능상의 비용이 분명히 발생하겠네요. virtual 함수는 inline되지 않으며 vtable때문에 오버헤드가 발생하므로 그런 방식의 팩토리는 말씀하신 tight한 루프에서 성능 문제가 발생하겠네요.
Unity 스크립트는 single-thread인데 lock과 같은 동기화 수단이 필요한 순간이 오는지 궁금합니다.
너무 좋습니다!! 거기로 옮겨주셔도 무관합니다! |
https://github.com/fkdl0048/BookReview/blob/main/CleanCode/Chapter02.md
The text was updated successfully, but these errors were encountered: