코드스테이츠 3주 차, 3번째 스프린트를 마쳤다. 스프린트명은 Twittler다. HTML, CSS, 그리고 JS를 활용한 DOM control로 기초적인 트위터 프론트엔드 화면을 구현하는 것에 목적이 있다. 페어와 함께 간단한 ui를 그리고, 실제로 구현하고, 그리고 작성한 정적 페이지에 동적인 컨트롤을 추가하는 과정이 꽤나 벅차지만 결과물이 눈에 보여서인지, 보람 있는 스프린트였다.
스프린트는 다음과 같이 진행ehl었다.
HTML, CSS에 대한 수업을 듣고, 작성할 Twittler의 Wireframe을 만들어본다.
figma를 통해 페어와 그려본 Twittler 와이어프레임
와이어 프레임을 만들고 HTML, CSS를 통해 목업을 구현하는 과정은 꽤나 도움이 된다. 특히 코드스테이츠에서 설명하는 실무 workflow 작업 안내에 따라 페어와 함께 구조마다 ID나 CLASS명을 작성했다. 특히 CLASS명을 통해서 같은 CSS를 적용할 수 있는 뭉치(?)들을 묶었다.
동영상을 보고 클론코딩을 해본 것이 전부이다 보니, HTML 구조를 작성할 때도, 내가 어떤 형태의 뼈대를 그릴 지에 대해 생각하지 않고 주먹구구식으로 형태를 잡는 일이 많았다. 물론, 어떻게든 구현을 하긴 하지만 중간 클래스명이 중복되어 변경하거나 추가, 형태를 처음부터 다시 잡는 일이 빈번했다.
대략적인 완성본을 머릿속에 그리고 일을 한다는 것은 꽤나 강력한 무기가 된다. 구조가 그려지고 그림에 대해 서로 공유를 하고 있다 보니, 업무가 철저하게 분업이 가능하다. 서로 상황에 따라 더 좋은 방법을 선택하고 공유할 때도 있지만, 기본적으로 공동의 그림을 만들어간다는 것이 함께하는 프로그래밍의 장점이라는 것을 사알짝 경험할 수 있었다.
위 Wire Frame에 대한 목업.
목업을 구현하던 중 와이어프레임과 변동사항이 있었다. 하나는 아이콘 이미지를 추가한 것이고(추후에 다시 지웠다..), 다른 하나는 트윗 출력 창을div에서 li로 변경했다. 동일한 형태를 반복해서 작성하는 데는 list 형태가 보다 적합하다는 것이 결론이었다.
- DOM을 사용해 몇 가지 트윗의 기능을 구현한다.
과제에서 요구한 구현 과제는 크게 다섯 가지다.
1.화면이 켜지면 DATA obj에 저장된 다섯 개의 트윗이 나열된다.
2.트윗 내용을 작성하고 'Tweet'을 누르면 아래 트윗 리스트에 트윗이 업데이트된다. 단, 작성 시간도 작성한 시각이 그대로 표현되어야 한다.
3.'Refresh'를 누르면 랜덤 트윗이 리스트에 업데이트된다
4. 트윗 리스트에서 유저명을 누르면 동일인이 작성한 트윗만 표시된다.
5. 'Before'를 누르면 다시 트윗리스트가 다시 나열된다.
먼저, 구현 결과는 다음과 같다.
구현 화면,
footer는 아래 트윗을 가려서 hover시 나타나게 조정했다.
html과 css 구현은 목업에서 했던 내용인지라 크게 어려움은 없었다. 다만 DOM 제어를 통해 li를 생성할 때, 이미지를 넣는 과정을 하나 생략했더니, 오히려 구현된 모습은, 처음 와이어 프레임을 작성할 때와 같아졌다(…)
작성한 JS 파일은 다음과 같다.
미천한 나의 코드…
자바스크립트를 먼저 경험한 페어분의 도움을 받았다. 시간을 가장 많이 할애한 것은 다름 아니라 수도코드를 작성하는 일이었다. 아직 프로그래밍적 사고가 익숙하지 않다.
구현해야 하는 결과에 대해서 최소단위로 나눌 줄 아는 것이 프로그래밍적 사고다.
컴퓨터는 뭐랄까, 아주 똑똑한 멍청이다. 주어진 명령에 대해서 충실히 이행하지만 그건 어디까지나 명령이 최소단위로 명확하게 주어졌을 때다.
트윗을 작성하고 트윗 버튼을 누르면 내용이 바로 아래로 들어가는 것이 아니라, 작성한 트윗이 DATA obj에 저장이 되는 과정이 선행되어야 하고, 그 이후에 DATA obj에 있는 해당 트윗 element를 불러와 아래 트윗에 구현시켜야 한다.
마찬가지로 누군가의 트윗을 sorting 한다면, 가장 선행되어야 하는 과제는 기존에 있는 ‘모든 트윗'을 삭제하는 것이다. 그 이후에 선택한 대상의 이름이 DATA의 obj[key]와 같은지 확인하고, 같은 내용에 대해서만 아래 트윗에 구현시켜야 한다.
새로운 트윗을 작성하는 단계
- 트윗 버튼을 누르면 작성한 트윗을 DATA OBJ에 저장한다.
- 새로운 li을 만들어 UL 안에 추가한다.
- 만들어진 li에 DATA OBJ에 저장된 방금 작성한 트윗 내용을 textContent 한다.
이 세 단계를 거치게 된다. 누군가를 Sorting한 후에, 다시 이전으로 return하는 일도 마찬가지다.
트윗 목록으로 return하는 과정.
1. before 버튼을 누르면 기존에 있는 모든 li들을 삭제한다.
2. DATA obj에 있는 element를 불러온다.
3. 새로운 li를 만들어 UL 안에 추가한다.
4. 만들어진 li에 element의 내용을 추가한다.
5. DATA obj의 모든 element에 대해 2~4를 반복한다.
확실히 DOM을 통해 눈으로 보이는 결과물을 보다보니 재미있다. 다만 그 재미있는 것을 능수능란하게 사용하지 못하다보니 괴로울 뿐이다.
아쉬운점, 생각해볼 부분
template()의 작성
다음은 리스트 안에 추가할 li를 생성하는 template 함수다. 함수는 차례대로
<li class="tweet_item>
<div class="info_div">
<div class="name_div"></div>
<div class="time_div"></div>
</div>
<div class="text_div"></div>
</li>를 구성하고 마지막에 ul에 들어간다. 이 과정에서 반복되는 작업이 너무많다. 의도대로 작동은 했지만, 코드 한 줄이 아쉬운 상황에서 막연하게 길어지는 코드를 어떻게 하면 로직화 할 수 있을까? li를 만들어내는 보다 간결한 형식화가 필요하다.
- 작동 상황의 확인
함수 중간에 console.log(“함수명 Start”), console.log(“함수명 Done”)과 같은 내용을 추가해 어느 부분까지 작동이 되었는가를 시각적으로 확인할 수 있도록 했다. 그러나 문제는…
시작하자마자 등장하는 콘솔의 향연
화면이 리프레시 되면 DATA obj에 기본 저장되어있는 다섯개의 elements에 트윗을 올려주는 함수가 작동한다. 그 결과 콘솔창이 시작부터 아주 길게 늘어진다.
obj의 el이 15개가 되면 콘솔창에 파티가 열린다.
랜덤 트윗을 만들어 elements가 15개가 되면….중간 ‘debugger;’를 삽입해줄 수도 있지만 내 생각으로는 debugger는 ‘왜' 해당 부분이 오류가 나는가? 를 확인해줄수있는 방법인것같다. 다시 말해 어디가 오류가 나는지 알고 있을때 그 이유를 확인해주는것이 아닐까 싶다. 코드가 제대로 작동하는지, 어디까지 작동하고 어느 부분에서 오류가 나는지에 대해 조금 더 간단 명료하게 찾을 수 있는 방법을 생각해내자. - 그 외
그 외로는 함수 내용에 대한 아쉬움이다. template() 외 작성한 함수에도 중복되는 내용이나, 더 로직화 시키면 줄일 수 있는 부분이 있었다. if문이 이중으로 반복되는 경우도 있었다. 모든 기능이 구현하는 상황에서, 최대한 간결하게 코드를 작성하는 것이 좋다. 아는 내용 안에서 몸부림을 쳐 봤지만, 함께 진행한 페어분의 코드를 보면 forEach, 화살표 함수 등 같은 내용을 보다 간단 명확하게 실행할 수 있는 방법이 있었다.
순서대로 Wireframe, mockup, final. 붙여놓으니 나름 뿌듯하다..
3주차도 하루가 남았다. 이번 한 주는 참 즐겁고 괴로웠다. 앞으로 더 즐겁고 고통받는 일들이 얼마나 많이 남았을까? 이 똑똑한 멍청이를 다루는 일에 재미를 붙이고 있다.
