흑백과 디지털

  파이썬에 정수 나눗셈 연산자가 있는지 있는지 오늘 처음 알았다. github 에서 다른 사람이 짠 코드를 보고 이건 뭔가 하는 코드를 발견했다. 혹시 정수 나눗셈인가 하는 의심이 들어 찾아 보니 파이썬에 정수 나눗셈 연산자가 있었다.

# 이건 결과가 float
a = 12 / 5

# 이게 결과가 integer
b = 12 // 5

print("a = ", a)
 # a =  2.4
 
 print("b = ", b)
 # b = 2

파이썬 버전 2에서는 C나 C++ 언어처럼 정수 나누기 정수의 결과도 정수였다. 그런데 파이썬 버전 3에서부터 비개발자도 이해하기 쉽게 하기 위해 정수 나누기 정수일지라도 비개발자도 이해할 수 있게 float 데이터 처럼 결과를 보여주기 시작했다. 분명 이 연산자는 파이썬 버전 3 처음부터 있었을 텐데, 오늘 처음 인식하게 되었다. 

아마 내가 파이썬 버전 2.7 대에서는 주로 Django 로 서버를 만드는 일을 했을 것이다. 그리고 그 Djanog 가 더 이상 파이썬 버전 2를 지원하지 않게 되자, 나도 파이썬 버전3로 전향을 하게 되었다.  파이썬 버전 2.7에서 버전 3로 넘어갈 때 걱정이 많았다. 그런데 생각외로 큰 변화가 없어서 쉽게 전향을 했던 것 같다. 파이썬 2에서 버전 업을 할 때 조금씩 파이썬 버전 3 기능을 지원했기 때문에 자연스럽게 전환을 했던 것 같다. 

역시 남의 코드를 자주 봐야 다양한 기능을 익히고 문법도 익히고 스타일도 익히게 되는 것 같다. 

이제 vuetify를 이용해서 vue 를 사용한지 1년은 된 것 같다. 그런데도 새로운 것을 배우게 된다. 그냥 무의식적으로 css 설정에서 deep (vue2 에서는 v-deep 로 알고 있다.) 를 사용했는데, 이것을 사용하는 이유를 인식하게 되었다. 난 이용도를 제대로 인식하지 못하다보니 deep 설정이 필요 없는 곳에도 난발하고 있었다.

vue에서 일반적으로 css 스타일을 지정할 때 <style scope> 처럼 scope 라는 구문으로 css 범위를 해당 파일로 제한하게 된다. vue3 를 기준으로 html 태그를 추가하면 자동으로 태그 옆에 data-v-f2c7905d 같은 랜덤함 attribute 가 동일한 파일범위에 같은 값으로 추가된다. 그래서 css 설정에 보면 자동으로 [data-v-f2c7905d] 같은 css selector 가 자동 추가된다. 이렇게 추가되다보면 현재 작업하는 파일과 다른 파일로 분리된 vue 컴포넌트는 다른 랜덤 data-v-XXXXXX 가 생성된다. 그러면 현재 범위를 기준으로 하위 컴포넌트의 스타일을 변경하지 못한다. 이러한 제한을 벗어나게 하기 위해 deep 구문을 이용해서  .test :deep([type="text"].v-field__input) 
으로 deep 를 설정하게 된다. deep 내에 둘러싸인 부분은 하위 컴포넌트를 접근하기 위한 css selector 조합인 것이다. 어째든 이렇게 deep 로 둘러싸인 부분은 자동으로 [data-v-XXXXXX] 같은 것이 추가되지 않는 것 같다.(정확한 동작 원리는 모르겠지만 내 테스트로는 이렇다.)
대충 내 느낌으로는 왼쪽 처럼 사용하면 오른쪽 처럼 자동으로 css selector 가 변화는 느낌이다. 
.test :deep([type="text"].v-field__input)   => .test  [data-v-f2c7905d]  [type="text"].v-field__input
.test ([type="text"].v-field__input)  => .test [type="text"].v-field__input[data-v-f2c7905d]

[type="text"].v-field__input 부분이 하위 컴포넌트 부분이라면  [data-v-f2c7905d] 가 아닌 다른 랜덤한 번호가 붙기 때문에 의도대로 css 셀레팅이 되지 않을 것이다. 이렇기 때문에 deep 를 사용해서 자동 추가를 막는 것 같다. 

어째든 하위 컴포넌트 속성을 selector 하는 부분이 없다면  이 구문이 필요 없는 것이었다. 내가 vuetify 를 이용하고, 이 컴포넌트들의 디자인을 더 작게 만들일이 많다보니 deep 를 많이 사용했던 것이다. 

이것을 오늘에서야 인식하게 되었다니, 나도 참 대충 프로그래밍 짜는 것 같아서 부끄럽다. 

* 퇴근시간 전에 확인 요청하는 경우
  - 내가 다니는 회사가 09:00 ~ 10:00 사이에 출근해서 근무시간 8시간만 채우고 퇴근하는 방식이다. 나는 아침 09:00부터 업무를 시작하는 편이다. 그러다 보니 17:30 분 이후에 업무 요청이 들어오는 경우도 꽤 많다. 이 시간 급하게 요청하면 내 퇴근 시간이 늦어지게 된다.

* 스크린샷만으로 버그 리포팅하는 경우
 - 어느 순간 사내 웹사이트 기능이 엄청 많다보니 화면 만으로는 어떤 URL 인지 알 수 없다. 그리고 특정 데이터를 가진 object 에서만 에러가 발생하는 경우가 많아서 전체 URL을 알아야 재현되는 버그도 많다. 그런데 꼭 스크린샷만으로 버그 리포팅 하는 사람이 많다. 이 때마다 버그 리포팅하는 크롬 확장을 만들어야 겠다는 생각을 하게 된다. 

* DM으로 버그 리포팅하는 경우
 - "스크린샷만으로 버그 리포팅하는 경우"가 발생하는 이유이기도 하다. 분명 버그 리포팅하는 양식을 만들어 두었는데, 그것을 무시하고 DM으로 버그리포팅 하는 경우가 많다. 이런 경우 재현이 싶지 않아서 다시 확인하게 된다.

오늘도 내 퇴근시간전에 DM으로 버그 리포팅이 발생해 이 글을 올린다. 너무 많은 기능, 1회성으로 요청하고 사용하지 않는 기능, 너무 다양한 입력 때문에 버그가 너무 많다. 물론 내가 게을러서 Testcase 환경을 구축하지 못했기 때문에 발생하는 문제도 있다. 이제는 뭔가 근본적인 해결책이 필요할 것 같다. 고민해봐야겠다.