TIL/WID: What I Did
3월 4일 WID : Git Alias
Git alias 깃허브 명령어 커스터마이징이 가능하다는 것을 알고는 있었는데 오늘 생각이 나서 찾아보았다. 이것저것 등록하고 등록한 내역을 upNote에 정리해두었다. 익숙해질때까지는 이걸 보면서 하는 게 좋을 것이다. 기본적인 명령어 먼저 기본적인 명령어들을 커스텀했다. 자주 쓰는 것들이기도 하다. 비교적 간단한 명령어로 이루어져 있어 쉽게 설정할 수 있었다. git cm // commit -m git sw // switch git swc // switch -c git st // status git br // branch 조금 더 복잡한 명령어 아래 명령어들은 다른 사이트를 참고하여 커스텀한 명령어들이다. 복잡한 터미널 명령어를 처음 접해서 GPT에게 물어봐가면서 명령어를 파악하고 입력했다. git ..
2월 27일 WID : 레거시 코드에서 자유로워지기, 문서 작업의 범위
레거시 코드에서 자유로워지기 레거시 코드를 잘 파악해야 하지만, 레거시 코드에게 얽매일 필요는 없다. 어제 기존에 선언되어 있던 조건을 가져다 썼다가 오늘 수정했다. 기존에는 A && B 의 and 조건이었는데 생각해보니까 내가 쓴 로직에는 A || B 의 or조건이 더 알맞다고 생각했다. 문서 작업의 범위 문서 작업이라는 것은 닭이 먼저냐 달걀이 먼저냐 같은 논제와도 같다. 디테일하게 하는 만큼 업데이트해야 하는 영역이 많아지고, 큰 덩어리로 묶으면 정보의 전달이 불명확해질 수 있다. 매뉴얼 작업을 하면서 느끼는 거지만 얼마나 디테일하게 해야 할지, 어디까지 정보를 제공해야 할지 계속 고민이 된다. 내가 보기엔 필요해 보이는 정보가 누군가에게는 쓸모없는 정보일 수도 있고, 내가 간과한 부분이 매뉴얼을 ..
2월 26일 WID : PR 메시지 포맷, button 규칙 지키기
PR 메시지 포맷PR 메시지 포맷에 대해 생각했다. 커밋과 PR의 단위에 대해서도 좀 생각해볼만 할 것 같다. 요구사항이 큰 덩어리인 경우에는 PR과 커밋메시지가 확실하게 다른 계층으로 분리될 수 있을 거 같은데 작은 덩어리인 경우엔 PR과 커밋 메시지의 레벨이 동일할 수도 있겠다는 생각이 들었다. 이런 경우라면 차이점은 PR에는 상세한 내역을 기록하고, 커밋 메시지는 일종의 요약본으로 생각할 수도 있지 않을까? 커밋 메시지에 딸린 PR내역을 추적하긴 쉬우니까.. 오늘은 아래와 같은 포맷으로 작성했다. PR 제목 문제상황 어떠어떠한 상태인 경우, 이러저러한 문제가 발생한다. 해결방법 어떤 로직을 추가하여 해결하였다. 참고사항 같은 문제가 이전에 OO에서도 발생한 바 있으며, 당시 원인은 정확히 파악하지 ..
2월 22일, 23일 WID : 1px 잡기, 문서작업
느낀 점 일에 집중하고 일에 리듬을 타는 법이 다시 돌아온 것 같다. 자신감도 붙고, 집중도가 높아지니까 일이 재밌어지기 시작했다. 코딩에 재미가 붙기 시작한 타이밍에 매뉴얼을 작성하는게 너무 싫었는데 문서작업을 하면서 코드를 파악할 수 있었다. 계획보다 빨리 문서작업 후루룩 해버리고 얼른 하려던 거 하러 가야지~ 라고 생각했다. 이렇게 생각하니까 문서작업도 더 할 맛이 난다. 1px 잡기 탭 메뉴를 선택할 때마다 탭 목록 하단 border가 1px 두꺼워졌다가 메뉴에서 포커스아웃하면 다시 1px 얇아지는 현상이 있었다. 사실 기능상으로나 레이아웃상으로 크게 문제가 될 부분은 아니었지만 최근 업무 집중도가 높아지면서 기획할 때의 '검수 모드'가 장착되니까 너무 거슬려서 잡아내기로 마음을 먹었다. TabP..
2월 21일 WID : TabPanel 내용 보강, 업무적/개인적 todo list 작성
TabPanel의 itemRender와 itemComponent오늘은 데브익스트림의 TabPanel에서 사용할 수 있는 prop중 itemRender와 itemComponent의 작동방법을 비교했다. itemRender탭이 바뀔때마다 하나의 패널에 내용을 바꾸어 렌더링한다. 탭이 여러개여도 렌더링된 패널은 한개 뿐이다.tabPanel에 주입된 dataSource를 곧바로 받아오지 못한다. 메소드의 params로 넘겨준 값이나 렌더링할 컴포넌트에 주입한 props만 받아서 사용할 수 있다. itemComponent탭마다 패널을 렌더링해두고 탭을 선택할 때마다 디스플레이 속성을 통해 탭에 해당하는 패널을 노출해준다. 개발자도구에서 엘리먼트를 추적해보면 탭 개수대로 html요소가 준비되어있음을 알 수 있다.t..
2월 20일 WID : Devextreme의 TabPanel을 정복하다!
우리 회사에서는 UI 라이브러리로 devextreme이라는 라이브러리를 사용한다. 이번에는 팝업 안에서 Tab 메뉴를 이동하는 동시에, 각 개별 Tab메뉴 내에서 TreeView를 활용하여 selectedItems를 받아야 하는 업무가 주어졌다. 어려웠던 점 최초 팝업 오픈 시 NavButtons 미노출되는 현상 TabPanel에서는 showNavButtons라는 옵션으로 탭메뉴가 많아지고 길어졌을 때 좌우 이동 버튼을 제공하는데, 팝업에서 띄워서 그런지 최초 팝업 노출시 NavButtons의 노출 조건에 맞지 않아 최초 팝업 오픈 시 탭메뉴가 오른쪽으로 쭉 삐져나오는 현상을 겪었다. showNavButtons Specifies whether navigation buttons should be avail..
2월 16일 WID : 테스트, 테스트, 테스트, 그리고 Promise
오늘의 느낀 점 데이터의 흐름에 대해 항상 생각하면서 코드를 짜자. 지역변수와 전역변수로 쓸 것을 잘 구분하자. 오늘은 작업 목적에 따라 좀 더 세분화한 커밋을 등록했다. 어제보다 나아진 거 같음 테스트를 잘하자.... 테스트!!!!! 어떤 디테일하고 자그마한 현상이 나타날 때 그게 왜 나타나는지 원인을 짚고 넘어가는게 중요한 것 같다. 어제 좀 흔들렸다고 느꼈는데 바로 똥으로 돌아왔다. Promise 이해에 대한 필요성을 느낌. 기본적인 개념인데도 대충만 알고 있어서 한번 맞설 때가 온 것 같다. 디테일한 테스트 진행 어제 수정한 내용에 대해 추가 오류사항이 발생해서 수정을 진행했다. 그러면서 테스트를 한층 더 꼼꼼하게 진행했는데 처음부터 이럴 수는 없었던 걸까? 라는 생각이 들었다... 꼼꼼하게 테스..
2월 15일 WID : 원칙 적용
WIL을 따서 WID로 타이틀을 정했다. What I Did 라는 뜻이다. 이전 소스코드를 리팩토링하면서 새로 생긴 원칙들을 적용했다. 줄임말을 쓰지 않았다. 이전에 줄임말을 썼던 부분도 풀네임으로 바꾸었다. 타입 정의를 보다 명확하게 했다(일부 못한 부분도 있었음, 라이브러리가 제공하는 props의 경우). 클릭 시 데이터를 CRUD 하는 함수가 받는 파라미터를 아무 생각 없이 e 로 써두었었는데 이 함수가 받는 인수는 event나 element라기보다 target에 가깝다고 생각하여 target으로 명칭을 변경하였다. 보통은 event를 받아 event.target 또는 e.target으로 많이 썼는데 이 경우에는 인수에서 바로 data에 접근하기 때문에 target.data가 더 명확하게 의미가 전..