주 52시간 근무가 시작되고 야근이 사라졌다.

또한 공짜로 먹던 저녁 식사도 함께 사라졌다.


슬프다.


이젠 저녁 식비로

올해 올랐던 연봉만큼 빠져나갈 것 같다.


하지만 시간이 많이 생겼다.

그리고

이렇게 공부를 하러왔다.


AI 공부인데

여전히 이해가 하나도 안되지만

정말 만들어보고 싶은걸 만들 수 있는 그날까지 계속 하고싶다.


노트북으로 학습을 시켜두고

그동안 이렇게 글을 쓴다.



신입 사원 교육을 들을 때다.

객체지향적 사고를 위한 교육을 듣던 중이다.


객체지향의 주요한 특징들

추상화

상속

다형성

(캡슐화는 제외)


이 3가지 속성에 대해서 열띤 교육을 들을 때다.


각각의 개념을 들을 때마다

절로

고개가 끄덕여지는 강의들이었다.


팀장님, 이사님, 선배님들의

각자의 경험들을 살린 교육을 듣고있으면

마치 내가 객체지향의 프로가 된 기분이었다.


그러다 나온 질문이 하나있다.

'너는 객체지향에서 가장 중요하다고 생각하는게 뭐야?'


정답이 없는 질문


더 중요하고 덜 중요하고 이런건 없다.

다 중요하다.


그래도 신입인 입장에서 질문을 받았으면 답변하는게 도리이니

곰곰히 생각하다가

나는 추상화라고 말했다.


왜냐하면

상속이나 다형성은

뭔가 어렴풋이 이런 개념이 나온 이유도 이해가 되고

어떻게 하는지도 머리속에 명확하고

코드로도 조금은 그려져서

그래서 가장 이해가 안되는 추상화라고 답했다.


함께였던 다른 동기들의 답변들은 다양했다.

가장 많은 답변은 다형성이었던 것 같다.


추상화

아니 추상이란 단어의 의미


설계학적으로는 인터페이스와 구현을 분리한다고 하지만

난 이 말이 너무 어려웠다.


진짜 그냥 생각해보면 아무것도 아닌데

막상 추상화시켜서 클래스를 작성한다고 해보면

뭘 어떻게 하라는건지 감이 안왔다.


또 일상 생활에서 많이 쓰던 인터페이스란 뜻조차

어느 순간부터는 헷갈리기 시작했다.

내가 인지하고 있던게 맞는건지, 헤매던 시간


나에게 이 말을 철학과 같았다.

그 때 속마음이


'뭐 느낌은 알겠는데

근데 어떻게 하는걸까?'


'그렇게해서 진짜 도움되는건 뭐고

실제로 코드로는 어떻게 표현하는데?'


인터페이스와 구현을 나누었을 때

명확한 이점이 나한테는 보이지 않아서 더욱 이해가 안갔다.


그리고

이제는 조금은 추상화라는게 이해가 간다.

선배들이 짰던 코드들과 이후에 디자인패턴 쪽을 공부하면서 야금야금 정립이 되던 시간들

그리고 코드로도 어떻게 표현하는지.


이에 관련된 건 제대로 포스팅하고 싶어서 다음으로 미루고


이번 포스트의 핵심 주제인 이름 잘 짓기.


그래 이거였지.


위에서 주저리 주저리 객체지향개념을 꺼낸 이유가 바로 이걸 쓰기 위해서다.


객체지향에서 가장 중요한건 3대 개념이고 뭐고

캡슐화고 뭐고

은닉화고 뭐고

추상화고 뭐고

상속이고 뭐고

다형성이고 뭐고


제일 중요한 것은 함수 및 변수 이름을 잘 짓는게 가장 중요하든 것이다.


객체지향을 떠나서 그 어떤 코드를 짤 때

이름 짓는 일에 시간을 소홀히 하면 안된다.


급해서 넘어갔다고 해도 다시 돌아와서 마음에 드는 이름으로 바꿔야한다.


이름 짓기의 가장 중요한 것

!! 명확함 !!


찾아보면 Microsoft가 지정한 학습 도서인  'Code Complete'을 보면

이름 짓는 몇몇 규칙을 알려준다.


나보다 훨씬 뛰어난 프로그래머 분들의 말씀이니 정말 새겨들어야 한다.

가장 이상적인 이름의 길이

변수 및 함수에서 자주 쓰이는 단어들


막 엄청 많다.


근데 내가 느낀건

길이는 중요하지 않다.


각 회사나 팀의 이름 짓기 Convention(규칙)이 있다면

그 Convention을 아주 충실히 따르는 전제하에

이름은

언제나

한 눈에

알아보기

쉬워야한다.


궁극적으로는

주석없이도

이게

어떻게

돌아가는 코드인지

그 코드의

변수 이름과

함수 이름과

클래스 이름을

통해서


그런 코드를 짜야한다.


일전에 교수님의 말씀 중에 남는 말이 있다.

교수님은 빅데이터 교수님이셨고 남편 분은 현업 프로그래머셨는데

집에서 언제나

변수 이름 하나를 짓는데

30분 이상을 고민한다고 하신다.


그리고 코드 짤 때 가장 어려운게

이름 짓는 일이라고 한다.


공감이 매우 간다.


이름 잘 지어야 한다.

특히

오래된 프로그램일수록

오래갈 프로그램일수록


후에 어떤 사람이 내가 짠 코드를 볼 지 모르는데

개인만의 이름이나 규칙은

가져다버린후

훗날

스스로가 세계에서 인정받는 개발자가 되면

그 때 상징적 의미로 가져오도록 하자


가장 최악의 이름 3개


1번

for문에서 index의 이름 i, j, k로 짓는 것

나중에 변수 잘못 써서 논리적으로 문제되면 찾기도 어려울 뿐더러

검색도 하기 어려움

위치 찾기도 어려움


2번

연결되는 변수와 함수의 이름을 구분지을 때

뒤에 1, 2로 숫자로 네이밍하는 것

이름은 언제나 무엇을 하는지 명확해야 함


이상적인 것은 주석없이 읽을 수 있는 코드가 이상적인데

이상적인 것은 이상적인 것이고

쪼렙땐 최대한 주석 상세하게 적기


더 좋은것은

코드 짜기전에 먼저 주석으로 동작해야 할 일을 써놓고

코드를 작성하면 좋다.

습관적으로 잘 안되서 문제지만.


3번

짧은 이름

책들을 보면

이상적인 이름 글자 수를 정해놓거나

단어 수를 정해놓거나 그렇다.

그런데 막상 짓다보면 이상적인 이름을 짓는건 정말 어렵다.

뭔가

머릿속에

딱~!

이거닷~!

하고 떠올라도

오래되고 규모가 큰 프로그램이면 비슷한 느낌의 이름일 가능성이 매우 매우 높다.


아무리 좋은 이름이어도 다른 변수나 함수와 의미가 혼동되게 되면

그것은 안좋은 이름이다.


그렇다고 귀찮다고 완전 의미가 없는 이름을 지으면

그건 진짜 최악.


짧게 짓느니 엄청 엄청나게 길어도 의미가 명확한 이름이 낫다.

짧게 짓느니 엄청 엄청나게 길어도 의미가 명확한 이름이 낫다.

짧게 짓느니 엄청 엄청나게 길어도 의미가 명확한 이름이 낫다.



-끝-


-------------------------------------------2019.09.07-------------------------------------------

변수 함수 이름에 대해서 추가.


위 내용에 대한 결론은 이름을 잘 짓자.

그리고 짧은 이름보다 길어도 명확한 이름이 낫다.

라는 결론이었다.


이 포스트를 쓰고 1년쯤 지났다.

그동안 위에 적은대로 명확한 이름을 짓기위해 노력했다.

그러면서 겪은 시행 착오들을 추가한다.


1. 이미 선배들이 지은 이름이 굉장히 축약된 이름일 경우

...

솔직히 굉장히 난감하다.

아무리 수평적인 개발자 문화라지만 눈치가 보인다.

바꾸고 싶은 마음은 굴뚝같은데 여기서 문제.


내가 지은 이름이 상대방에게도 좋은 이름이라고 단언할 수 없다.


왜냐하면 그 분은 이미 이 이름에 익숙해져있기 때문에 오히려 새로 바꿀 내 이름이 정말 좋은가?

생각하게 된다.

나에게는 좋다. 그러나 상대방에게는 새로 적응해야한다.


두 번째.

열정에 불타서 이름을 열심히 바꿨다.

내심 만족했다.

이름은 대규모 프로젝트의 경우 한 번 잘못바꾸면 엄청난 규모의 코드를 바꿔야한다.

스마트하게 VisualStudio의 전체 바꾸기를 하면 좋은데

물론 내가 Side-Effect를 커버할 수 있는 범위라면 그렇게 해도 좋긴한데

10년 이상 유지보수해온 코드이므로 당연히 자동으로 테스트하는 기법이 적용되어 있지 않다. 우리 프로젝트는.

테스트케이스도 없으므로 Side-Effect 검출은 순전 고치는 사람의 능력과 책임이다.

또한 한 소리 들었다.

마일스톤이 다가오는데 왜 시간을 이슈 해결이 아닌 다른쪽에 쏟느냐.

이렇게 고쳤을 때 Side-Effect는 예상이 가느냐.


최고의 해결법.

VisualStudio의 정규식을 활용해서 모두 바꾸기하자. (그럼에도 놓치는 부분들이 있다.)

정규식을 사용하지 않으면 무서워서 바꿀 수 있음에도 Side-Effect가 무서워 안하게되거나

순수 노가다를 해야하므로 굉장히 바보스런 일이다.

그렇다고 정규식을 생활화하자.

내 실력에도 도움이 된다.


요즘들어 항상 인정도 못받는거 굳이 이렇게 이름을 고쳐야하나?

라는 생각이 들었다.

가졌던 강박들이 좀 깨지는 느낌도 들고.


그러던 와중에 하나의 기능이 내 담당이 되었다.

이 기능또한 약 10년동안 유지보수해온 기능이며

여러 담당자의 손길이 거쳐갔다.

처음 이 기능의 담당자가 되었을 때 완전 멘붕이었다.


왜냐하면 이 기능의 이름이 3가지 정도로 흩어져서 구현되어있었는데

코드 이해하기가 정말 dirty하게 어려웠다.

kinsoku, forbiddenCharacter, turnoverWord

이렇게 3개인데 뜻은 '금지문자'라는 의미이다.

그래서 팀장님과 합의하고 차후 담당자를 위해서 이 이름을 통일해야한다고 설득해서 고칠 시간을 벌었다.


그리고 한 6개월 후에 다시 관련 이슈가 생겨서 버그 트래킹을 하는데

정말

편했다.


그러니 이름을 바꿔야할 때는 반드시 바꾸자.

그리고 가장 중요한 것.

반드시 팀장님과 합의하에 바꾸자.

그냥하면 인정도 못받고 일하는 시간에 딴짓하는걸로 보인다.

끝.

+ Recent posts