1분기가 지난지 한달이 되어 가지만 4달간의 회고를 해보려고 한다.
[4월까지 느낀점]
만 2년이 넘어서 다시 front개발을 본격적으로 해보았다. html, js, css를 잊어버려서 신입된 기분이었다.
생각해보면 과거에 'A사 얼굴인식 프로젝트' 개발할 때는, css나 어느정도 구조가 많이 잡혀있는 상태였고
나는 얼굴파트였기때문에, V3 출입조건 전송 병렬처리 배치나 온라인서비스, 포조쪽을 많이 작업하였고
화면도 얼굴frame을 잡거나, 사진 관리하는 로직 등 front 업무에서도 js로직적인 부분에 처리할 것이 훨씬많았다.
html, css보단 js를 주로 수정했었다. 그래서 html이나 css는 정말 필요한 아주 적은 부분만 아는 상태였다.
이번에는 거의 바닥에서 부터 시작한 프로젝트였기 때문에 html과 css에 대해서 더 깊게 배울 수 있었다.
과거에 'A사 얼굴인식 프로젝트'에서 대기업의 부품같이 틀에 정해진 일을 집중적으로 하는 경험에 비해
지금 하는 일은 스타트업 창업과 비슷하다, 비교적 바닥부터 만든것이 많기 때문에 재미있는 부분도 많았다.
신입이 4명이나 있어서 신입들 교육하는데 오전, 오후를 다 쓰고, 내 작업은 저녁먹고 시작한 적이 많았다.
안그래도 복잡한 공통화면은 다 내 화면이고, GNB, LNB, Main 등 나의 분량이 압도적인데
신입들과 사람들 질문도 받아주느라 3,4월은 거의 매일 12시에 퇴근을 했다.
두달쯤 지나고 보니, 신입들이 모두가 1인분을 할 수있는 상태까지 발전한 것 같아서 뿌듯하기도 하다.
나랑 커넥션이 있어서 제일 열심히 알려준얘가 아직 제일 못하는 부분은 조금 아쉽긴 하지만.. 잘 따라오고 있다.
이상한 얘들이면 그냥 내가 다해버리려고 했는데 사람들이 착해서 많이 가르쳐주고, 도와줬다.
우리팀 사람들하고 앞으로도 잘 지냈으면 좋겠다.
[개발하면서 신경썼던 부분]
· ES6를 적용하여 트랜디한 개발
- var제거하고 const, let사용
- arrow function 최대한 활용(this 바인딩 불가, this 사용 필요한 event fucntion 등에서는 제외),
- proxy로 observing을 위한 필터 사용 : 화면간의 로직 의존성을 줄이기 위해 활용
º 모바일 TOP 버튼은 Navigation bar가 존재하는 main화면에서만 나타나야 한다.
main이 아닌 상세화면이나 팝업화면에서는 TOP 버튼을 hidden처리해야하는데
proxy 필터링을 통해 다른 사람들로직에서도 자체동작하도록 구현
- temlplate literal로 js에서 직접 html 렌더링하는 로직을 최대한 직관적으로 파악 할 수 있도록 구현
º template literal의 최대 강점은 indent와 line feed가 모두 유지되는 것에 있다!
→ 개발자도구에서도 수정 편함, 대만족!!
· 퍼포먼스를 항상 생각 (렌더링 퍼포먼스, js 퍼포먼스)
- 성능이 느린 jquery를 99%이상 native js로 대체해 사용
º 애니메이션 부분은 jquery가 편해서 사용하였다. js로 대체가 가능하긴하지만... 편함이 이김..
- 데이터를 한번에 불러오지 않고, 스크롤바가 내려감에따라 데이터를 추가 로딩하여 append하는 로직 구현
º 사진 등 용량이 큰 데이터의 경우 꼼꼼히 확인한다.
- dom을 수정할 일이 많아 dom에 대한 수정을 최소화하는 로직을 구현
º dom을 최대한 적게 rendering을 해야한다는 생각을 가질 것
- 데이터 수정시 페이지 전체 불러오지 말고 innerHtml로 부분만 변경
- html에 append할시 htmlFragment에 append를 한뒤 dom에는 한번만 append한다.
- 라우팅 최대한 줄여 성능 개선 도모하기
º 라우팅을 최소화하기 위해 전체화면 팝업으로 사용할 수 있는 부분을 최대한 많이 뺐다.
- 쓸데없이 메모리를 많이 사용하는지 확인한다.
º 전역변수 확인
º 무분별한 클로저변수 확인
º 변수에 필요한 것 이상의 데이터가 담겨져있는지, 변수 초기화는 제때 잘 하는지 확인
- 중복되는 서비스콜, ajax 최대한 삭제
º 남이 구현한 로직에서 중복으로 서비스 호출하는 경우가 의외로 많다.
- local storage, session storage, cache 등을 항상 고려하고 필요한 경우 사용한다.
º 사실 공통팀이 아닌이상,, 거의 사용할 일이 없는듯 하다..
- 크롬 개발자도구 적극 이용한다.
º network 습관적으로 확인
º performance 확인 : 아직 모르는 부분이 많다.
- error, warning은 내것이 아니더라도 무조건 먼저 해결하는 방향으로 작업함
º 안좋은 프레임웍의 경우 에러가 프레임웍 전체 퍼포먼스를 심각하게 저하시키는 버그가 있는 경우가 많다.
· 개발 효율성 관리
- 개발 우선순위 설정 중요!
1) 재사용 가능한 부분을 최대한 가져온다.
★ 다른 프로젝트에 재사용 가능한 부분을 최대한 캡쳐하여 가져온다.
개발에 빠르게 착수 할 수 있도록 라우팅을 먼저 연결하여 인프라 구성하는 센스가 젤 중요
일을 착수 할 때 남이 개발한 코드가 남아있으면 처음부터 새로할지 분석하여 사용할지 고민하게된다.
내 경험상 원래하던 사람이 아무리 못해도 90%는 있던 로직 분석해서 재사용하는게 퍼포먼스가 더 낫다!
∵ 나에게 인수인계는 되지 않았지만 꼭 해야하는 업무나 요구사항이 있는 경우가 엄청 많다. - 이게 너무 큼..
처음부터 끝까지 다 뜯어고치더라도 그 사람 코드 위에서 뜯어고치자!
처음부터 새로 만드는게 기분은 좋지만 참아야함...
2) 내가 먼저 구현하고 싶은 것보다 다른사람이 사용하는 것을 먼저 구현한다.
3) 큰것부터 구현하고 세부적인것은 천천히 한다.
→ 눈에 잘 보이는것 부터 먼저 하자!
- 공통 함수 구현
º 사용성 개선 : 로직을 전혀 볼 필요없이 최대한 활용하기 쉽게 구현
ex)공통 토스트 팝업 : RegulationToast.open('필터가 설정되었습니다.'); //렌더링되는 높이설정도 자체구현
- PC버전과 모바일 버전에서 충돌나는 전역 클로저 및 전역변수 관리
º 클로저, 전역변수를 const MobileAPI = { }로 싸서 모듈화 하였다.
- element ID, css class 등을 PC버전과 mob버전으로 확실하게 구분지어 전체변경함 → 개발 및 디버깅 편의성 도모
- ID 충돌문제 혹은 예상치 못한 버그 등을 고려하여 ID는 최대한 유니크하게 설정하려고 노력했지만
ex)ID = 업무분류+기기종류+화면ID+elem desc
디자인 및 기능이 너무나 비슷한 화면은 로직의 간편함을 위해 ID를 고의적으로 일치시킨 부분이 있다.
→ 내부함수가 아닌 공통함수로 구현하기 위함
- 재사용성 개선 : 가능한 공통 모듈로 만들어내서 구현하고 각 화면은 최대한 모듈화한다.
º 공통으로 사용할 수 있는 함수는 최대한 추려낸다.
º 화면 의존성 제거 : 내 화면의 위젯은 다른 화면 로직에서 어쩔수 없는 상황이 아닌한 제어하지 않도록 구현
º CSS 클래스 구조, 속성선택자 등을 활용하기 용이하도록 최대한 효율적이고 섬세하게 설계해야함
→ js 로직으로 이벤트 제어가 심플해지고 재사용 가능 하도록 구현
→ 속성선택자도 굉장히 편리한데 간과하는 경우가 많다.
- Element inline style 최대한 제거
º inline style은 우선순위가 !important 다음이기 때문에 css에서 제어시 !important가 강제된다.
정말 바뀌지 않는다는 확신이 있을때만 사용하도록 하자!!
- 개발할 때 콜백함수는 최대한 depth를 줄일 수 있는 방향으로 설계한다.
º 콜백지옥이 되면 유지보수 개빡세다.
- 마스터에 error가 발생하는 로직을 푸시하는지 항상 체크한다. ※ 이런 분들 의외로 엄청 많다...
º 데스크톱과 노트북 두개의 기기를 이용하면 체크가 용이하다.
→ 리소스를 안넣었거나, tracking 안되는 파일때문에 에러가 안나는 경우 등의 모든 경우의 수 체크 가능
· 다양한 기기에 범용적으로 사용하기 위한 개발 단위 관리
- rem으로 단위 관리 (Task Mobile Project : 640X360에서, 1rem = 16px) 기준으로 작업
º pixel은 기기가 변경할때 유연하게 변경되지 못한다. → 화면 깨짐
º 이벤트를 걸어 window-size가 변경될때마다 자동으로 font-size변경하도록 구현하여 개발 편의성 도모함
※ 이유는 모르겠지만, image는 rem으로 크기를 설정해도 빌드할때만 사이즈 변경이 적용되는 것 같다.
- block구조를 기기의 변화에 범용적으로 대응하기 쉽도록 구현해야한다. - 신중하고 섬세한 block 구조 설계가 필요
º 요소의 width, height를 직접적으로 명시하는것을 최대한 자제하고, 부모의 속성을 이용한다.
ex)width = 10rem, height = 2rem X
º calc(100% - 4rem) 등 이러한 부모 기준로직을 최대한 활용한다.
º 비율(%)를 최대한 활용한다.
1) row의 맨처음과 끝에 있에 두개의 요소만 있는경우 부모 속성으로 제어한다.
ex)부모 속성display:flex, justify-contents
※ rem이 화면너비에 따라 font-size가 조정되어도 가로 혹은 세로만 크게 늘어나는 경우 제어가 잘안된다.
- font-size로 width, height가 제어되는 요소들 관리 - align시 flex, line-height등으로 추가적인 제어가 필요
º font-matrix는 복잡하다, 어떤 family냐에 따라서 width, height가 달라지는 경우도 있고,
크로스브라우징이 안되는 속성으로 align을 제어하는 경우도 많으니 잘 찾아봐서 대응해야한다.
º font-size는 inline style에 주는 개발자가 많았는데 별도로 클래스를 정의하고 css파일로 빼는것이 좋다.
- 모바일인 경우 키보드 올라올때 window-size가 변경되는데 이것으로 키보드 이벤트 감지하는 게 좋다.
º 텍스트 field나 area에서 focus 감지로 키보드 제어를 처리하는 경우 예외처리가 매우 복잡해진다.
· 정렬처리 (vertical-align, horizontal-align)
★ 가장 많이 하는 노가다기도하고, 해도해도 오랜만에 하면 자꾸 까먹는 노가다이다.
- display가 flex인 경우
º flex가 구현과 정렬이 제일 편하다, align-item, align-contents 속성주면 다해결된다.
※ ie 낮은 버전에서 지원안되는 단점이 있다...
- display가 inline 또는 block 계열인 경우
º 정렬을 할때 부모가 block 속성인지, inline 속성인지 확인해야한다.
ex)block은 width, height 제어가능, inline은 vertical-align, horizontal-align 제어 가능
º 이미지와 같이 사용할때 이미지는 부모속성이 아니라 이미지 자체에 주어야한다.
º horizontal은 거의 99% text-align:center 먹이면 왠만하면 다된다.
º vertical이 까다로운데 특히 inline인 요소인 경우가 font, baseline 등을 고려해야 해서 까다롭다.
→ 정 못하겠으면 div로 정렬하려는 element를 싸면 비교적 쉽게 해결된다.
º inline-block은 가로로 쌓이는 블럭이다.
→ 별거 아닌 사실인데 의외로 인지 못하는 개발자가 많아서 썼다.
- display가 table-cell인 경우
º 부모에 속성을 dispaly, text-align, vertical-align 속성을 잘주면 해결된다. 중요한건 display 속성이다.
- 스크롤바가 생기는 경우 스크롤바는 너비에 영향을 준다.
º overflow:overlay 속성을 주거나, 숨김처리하면 해결된다.
→ 숨김처리하면 모바일의 경우 터치스와이프 가능
· 생략 처리(ellipsis)
- width 사이즈 설정하고 overflow속성 주면 된다.
ex) overflow:hidden; text-overflow:ellipsis; width:200px;
- display가 table-cell인 경우
º min-width를 사용해야 ellipsis가 적용된다.
ex) overflow:hidden; text-overflow:ellipsis; min-width:200px;
- flex 인 경우
º 가로로 연결되어 있는 요소에 flex:1, flex:2 등 속성으로 확대, 축소 비율을 조정 할 수 있다.
→ max-width를 주어야 깔끔하게 생략처리가 제어가능한 것 같다.
- 노트리스트에서 노트내용을 두번째까지 보여주면서 ellipsis처리하는 경우 웹킷 속성을 사용하면 편하다.
· 예외 처리
- 이벤트 버블링과 캡처링에 유의하면서 개발한다.
º 의도치 않게 다른 개발자의 화면 이벤트에 영향을 주는 경우가 많이 발생한다.
→ event.stopPropagation()
- 렌더링 타이밍에 의한 element npe 버그
º front 개발하면서 가장 많이 보는 에러라고 확신한다!
º 서비스콜인 경우는 callback함수에 로직 처리한다.
- 개발할 때 콜스택과 이벤트스택이 동작하는 자바스크립트 엔진 동작방식을 항상 고려해서 개발해야한다.
º setTimeOut 함수 사용 등
· 라이브러리 사용
- jquery
º 특징 : 속도가 느리지만 크로스 브라우징에 특화되어있고 전반적으로 native js보다 코딩은 더 쉽다.
º 애니메니션 제어($.animate 등)는 확실히 압도적으로 편하다.
º $(document).ready() == $(function(){}) → native js는 이상하게 잘 안먹는거 같다..
※ native js 보다 10배 이상 느리지만 확실히 편하긴 하다.
느린만큼 최대한 재정의를 줄여야한다. const $a = $('~');
정말 별거아닌 쉬운 일인데 신경쓰는 사람이 드물다.
- hammer
º 모바일 더블탭, 스와이프 기능 구현시 사용함
º 타임라인을 구현하면서 펼쳐보기, 더블탭시 접기 기능을 구현하였다.
그런데 두번째 터치하는 곳의 위치가 타임라인이 접히면서 버튼이 위치하게 되는 부분이 되면
의도치 않게 버튼에 이벤트가 들어가는 경우가 생긴다.
마지막 터지를 무효하는 방법을 찾지못해 setTimeout(1ms)를 사용했다.
- mobx
º 채팅 구현때 사용 -> 내가 구현한 게 아니기 때문에 파악해보려고 한다.
※ 라이브러리를 사용하는게 성능에 얼마나 영향을 끼치는지 잘 판단이 안선다...
개발자도구로 퍼포먼스체크를 할 수 있는지 확인해봐야 겠다.
코드나 블로그 보고 정리한것도 아니고 그냥 백지상태에서 써봤는데 이정도로까지 쓴것을 보면...
내가 정말 일을 엄청나게 열심히 했구나.. 하는 생각이 든다...
개발은 항상 최대한 섹시하게 개발을 해야하는데, 시간상의 이유나 의지상의 이유 등 여러 다양한 이유로
당연히 해야하는 일을 하는게 쉽지는 않은 것 같다.
하지만 지금실력으론 야근을 하더라도 더 나은 코드로 바꾸려는 노력을 최소 5월까지는 해야할 것 같다.
내가 최적화한 부분이나 철학이 디자인패턴에 이미 있는 것이라면 정말 뿌듯한 기분이 든다. 이게 아무도 안알아주고, 모르지만 나름 내가 생각하는 코딩하는 재미인 것 같다.
먼저 생각해서 개발해보고 디자인패턴들과 대조해서 더 좋은 코드로 변경하고 블로그에 정리하여 최대한 디테일한 부분까지 신경쓰는 개발자가 되도록 노력할 것이다.
나의 작업과 생각을 시간나는대로 블로그에 적어서 나중에 쉽게 재활용 할 수 있도록 관리할 것이다.
'회고' 카테고리의 다른 글
| A사 v3 프로젝트 (0) | 2021.11.14 |
|---|---|
| 협업툴 프로젝트 (0) | 2021.11.14 |
| 2020년 7월까지의 회고 (0) | 2020.08.20 |
| TOP 모바일... (0) | 2020.05.11 |
| 2019년 회고 (0) | 2020.01.02 |
