서버에서 등록한 단어들을 가져와 랜덤 순서로 테스트하고 자신의 결과 점수와 틀린 단어를 확인할 수 있다.
목표
마크업과 레이아웃, 이벤트와 비동기처리 등 HTML, CSS, JavaScript를 다양하게 활용할 수 있다.
클라이언트-서버 간 데이터 요청과 응답을 javascript로 구현한다.
Sass를 활용하여 CSS styling을 하며, 특히 디바이스에 따른 반응형 웹화면을 구현한다.
내가 맡은 부분에 대한 설명
HTML 마크업
header-main-footer의 3단 구조이지만 화면에는 main만 보이게 처리
각 섹션에 heading을 달아 호환이 되지 않는 브라우저나 접근성 측면 고려
semantic mark-up을 지향하며 단어장에 걸맞는 dl-dt-dd 태그나 form태그를 사용
논리적 구조와 접근성 향상을 위한 노력
CSS Styling
모던 레이아웃 기법의 활용 (Flex, Grid 등)
반응형 화면과 애니메이션
mixin, variables, partials, calculation 등 Sass의 편리한 기능 활용
결과물 시연
선생님 피드백
발표태도
자신의 코드에 자신을 가지고 발표할 것
목소리를 크게 할 것
실무에서는 잘 쓰지 않는 스타일링과 레이아웃
flex 사용 시 row, column reverse는 잘 쓰지 않는다는 점 기억할 것
nth-child 요소선택자는 다른 요소가 언제 추가될지 모르니 사용하는 것을 지양할 것
Sass를 활용해본 것, 특히 nesting을 활용한 것은 구체성 점수를 투머치로 주지 않는 좋은 방법이다.
기타 실수 및 디테일
버튼은 버튼태그로 해야지 dd로 넣으면 안좋다.
role 어트리뷰트 이름은 aria-role이 아니라 role
disabled 된 요소들이 시각적으로도 disabled 알 수 있게 처리
팝업창이 뜨더라도 그 배경에 있는 요소들을 스크린리더가 읽을 수 있으니, 팝업창의 마크업에 role="dialog"를 넣어주어 팝업창만 읽을 수 있도록 처리
컨벤션을 잘 지키고 잘 알아볼 수 있는 변수이름을 쓰도록
마크업 잘 했고, 레이아웃도 성의있게 잘 한 것이 보인다고 칭찬받았다 헤헤
셀프 피드백
mark-up 설계의 중요성
처음에 DOM 트리와 아웃라인 알고리즘도 그려가면서 마크업을 했는데도 결국엔 불가피하게 수정할 것이 생겼다.
input, button 있다고 그냥 무조건 form 태그로 마크업했다가 레이아웃 시 다시 고치는 참사 발생
클래스이름 중 하나가 혼란을 주어서 javascript로 취득하는 과정에서 다른 팀원을 헷갈리게 했다.
마크업 수정 과정에서 이벤트가 이미 걸려있는 태그인지 하나하나 확인하는 것이 전자폭탄 해체하면서 이 전선을 자르면 폭발할지 조마조마한 마음이었다.
충분한 시간을 들여 소통하면서 설계 및 네이밍을 해야 뒤탈이 없다는 것을 깨달았다.
웹표준과 웹접근성 지키기의 어려움
열심히 지킨다고 했는데도 사소한 실수(role을 aria-role로 쓴다거나)도 있었고, 팝업창 role 주는 것 등도 미스가 있어서 아쉬웠다. 그래도 계속 공부해나가면서 접근성이 무엇인지 잘 알아야겠다.
완벽히 지키는 것이 분명 이상적이지만, 타협해야 하는 부분들이 생긴다는 것을 깨달았다.
Sass의 파워와 CSS의 애환
여러 파일로 나누어 나중에 import를 하는 partials 기능이나, nesting 등은 혁신이다.
폰트나 컬러를 변수로 넣어서 스타일링하면 나중에 아주 적은 시간을 들여서도 페이지 자체의 분위기를 바꿀 수 있어서 CSS 하는 맛이 났다.
마크업과 같이, 스타일링도 처음에 제대로 설계하지 않으면 너무 많은 시간을 들여서 이것저것 수정하게 된다.
반응형을 구현하다보면 뜻밖의 포인트에서 무너지는 배치에 분노가 일어나는 경험을 할 수 있는데, 그래도 처음에 너비와 높이를 설계할때부터 반응형을 고려해야한다는 교훈을 얻었다.
내 화면에서는 괜찮았는데 다른 화면으로 보니까 못생겨진다. 여러 환경에서 보면서 작업을 해야하는 것 같다.
애니메이션 구현 실패
display 값이 none에서 block으로 되는 팝업창 요소에 애니메이션을 주려고 했는데, 실패하면서 왜 안되는지 리서치를 했는데 실패가 가치있을 만큼 좋은 지식을 얻었다.
display가 none 인 요소는 DOM 트리에 존재하지 않는 상태이기 때문에 transition을 줄 수 있는 요소가 아니다. transition은 DOM 트리에 존재하는 요소가 변화하는 시점의 0%에서 100% 까지의 변화과정을 조작하는 것인데, display가 none이면 0%가 없으므로, 먹히지 않는 것. ( 참고: dev-tinkerbell님의 블로그 )
setTimeout 등으로 display 값이 변경된 후에 애니메이션을 넣는 방법으로 해결할 수 있다고 한다. ( 참고: 심형섭님 블로그 )
GIT 및 기타
git으로 매 변경사항마다 끊어서 커밋을 하고, feature과 develop branch를 따로 파서 해보고 싶었는데 마음이 조급해서 그렇게 하지 못한 게 아쉽다.
npm으로 명령 입력 시 javascript의 express와 sass의 명령어가 충돌해서 결국 폴더 안에서만 sass를 구동했는데 이걸 어떻게 해결하는지 이제 잘 알고싶다.
스타일링 작업하느라 markup 잠깐 바꿔둔 index 파일 등을 따로 stage에 올리지 않고 css파일만 올려서 서로 충돌없이 작업하는 혁신적인 방법을 뒤늦게 알게 되었다.
시간이 없는데 발표자료 만드는 에디터가 없어서 너무 성의없어보이는 발표자료에 아쉽다. 잘 만들었으면 그만큼 잘 포장하는 것도 중요한데, 앞으론 신경써야지.
처음에 시작할 때 비슷한 기능의 웹앱을 참고했더라면 레이아웃이나 디자인, 기능구현 시 시간을 절약할 수 있었을 것 같다는 아쉬움.
조급해하지 않는 것, 처음에 시간을 들여 설계하는 것이 얼마나 중요한지 뼈저리게 느꼈다.
느낀 점
수업은 끝나는 시간이라도 있지만 프로젝트는 내가 더 하는 만큼 더 진행할 수 있는데, 문제는 현재의 내 실력으로는 더 한다고 더 좋은 결과가 보장되지는 않는다. 오히려 피곤한 상태에서 더 뭔가 했다간 꼬이는 경우도 있었다. 그냥 적당한 선에서 끊고 마감치는 기술도 멘탈엔 매우 필요한 능력.
겉모습은 조금은 투박해도 반응형이나 비동기처리 등이 잘 구현되어 있어 내실있는 어플리케이션을 만들어냈다는 뿌듯함이 있다. 그리고 그걸 선생님이 알아봐주셔서 정말 기뻤다.
우리팀이 정말 신기하게도 모두 말이 없어서 성향은 서로 잘 맞았는데, 서로 프로젝트 중반까지도 데면데면해서 애먹은 것 같다. 발표에 있어서는 서로 가혹할 정도로 피드백을 줬어야 한다는 뒤늦은 후회. 그래도 좋은 팀원들 만나서 행운이었다.
프로젝트 마치니까 정말 희열이 느껴질 정도로 보람이 있었다. 이런 맛에 프로젝트 하는구나.
