나는 자바 백앤드를 주로 하던 만 3년차 개발자로, 이직을 하게 되면서 CSS를 다룰 일이 많아졌다. 나에게 CSS는 항상 궁금하던 영역이었지만 이러 저런 핑계로 지식과 경험이 거의 없는 상태였다. 그때 bsidesoft의 맹기완님이 HTML/CSS 관련한 스터디를 하신다는 소식을 듣게 되었다. 종로에서 한다고 해서 잠깐 고민했지만 좋은 경험이 될 것 같아서 바로 신청했다!(https://www.facebook.com/groups/dgding/)
스터디 교재
스터디 교재는 모던 웹사이트 디자인의 정석이라는 책이다. 레이아웃을 반응형으로 작성하는 것부터 시작해서 웹사이트를 반응형으로 만드는 법을 자세하게 설명해주는 책이다. 이 스터디는 맹기완님이 책을 가지고 HTML/CSS 특히 CSS의 기본과 실전을 설명해주신다. 바닥(graphic systems)에서부터 실전까지 CSS의 규칙들을 쳬계적으로 정리해볼 수 있다.
나의 정리
- 저장소 : https://github.com/voyagerwoo/S68-modern-web-design
- 강의 정리 : https://github.com/voyagerwoo/S68-modern-web-design/tree/master/lecture
동영상
이번 스터디는 스터디 운영진분들께서 모두 동영상을 남겨두셨다. 그래서 나는 3회차부터는 종로까지 가지 않고 집에서 동영상으로 강의를 시청했다. 혹시 아쉽게 해당 스터디에 참여하지 못하신 분들도 위 링크를 통해서 강의를 시청할 수 있다.
인상 깊었던 내용
맹기완님이 강의 중에 들었던 인상 깊었던 내용들을 정리 했다. 글에 오류나 더 이야기해보고 싶은 내용이 있다면 댓글을 달아주시길.
Graphic Systems & Rendering systems
컴퓨터에서 보통 출력을 담당하는 모니터는 수많은 점으로 이루어져 있다. 글자, 이미지, 동영상은 모두 그 점들을 조작해서 표현한 것이다.
rendering이라는 것은 코드나 설계도 같은 눈에 보이지 않는 것들을 시각화 하는 것이다. HTML 코드를 브라우저에서 시각화하는 것을 예로 들 수 있다. (브라우저)렌더링은 두가지 단계로 나눠지는데, 공간을 계산해서 나누는 것과(Geometric Calculator), 나눈 공간의 점들을 색으로 채우는 것(Fragment Fill)로 나눌 수 있다.
더 자세한 내용은 강의를 참고 하시길.
Reflow & Repaint(Redraw)
이 내용은 스터디 중에 자세히 다룬 내용은 아니지만 개인적으로 좀 정리해 두고 싶어서 적게 되었다.
참고 : http://webclub.tistory.com/346
Reflow는 생성된 DOM 노드의 레이아웃 수치(너비, 높이, 위치 등) 변경시 영향 받은 모든 노드(자신, 자식, 부모, 조상-결국 모든 노드)의 수치를 다시 계산(recalculate)하여, 렌더 트리를 재생성 하는 과정이다.
또한, Reflow 과정이 끝난 후 재 생성된 렌더 트리를 다시 그리게 되는데 이 과정을 Repaint라 한다.
크롬 브라우저 타임라인 탭에서 확인 가능하다.
(컴퓨터 과학에서) 공부는 단어(어휘)를 이해하는 것이다
당연한 말처럼 들리는 사람도 있겠지만, 나는 뒷통수를 맞은 느낌이었다. 새로운 것을 공부할 때에 그냥 대충 문장을 훑어보고 코드를 훑어 보고 넘어가고 대충 이해했다고 느끼는 경우가 많았다. 그러나 막상 설명하라고 하면 못했다. 결국은 모르는 것이다.
메타 인지(내가 아는지 모르는지 아는 것)의 측면에서 내가 이 문장과 이 문맥에서 모르는 단어가 얼마나 있는지 확인함으로써 이 개념을 아는 지 모르는 지 확인하면 좋을 것 같다. 많은 단어를 모른다면 단어들을 각개 격파하고 문장을 완성해보자.
영어 단어는 특정 상황에서 고유명사로서 의미를 갖는다
위 내용과 이어져서 컴퓨터 과학에서는 많은 단어들이 중복 사용된다. 예를 들어 도메인이라는 단어가 있을 때, 네트워크에서 도메인을 이야기하는 것과 도메인 주도 설계(DDD Domain Driven Design)에서 도메인은 완전히 다른 의미이다.
같은 단어이기 때문에 비슷한 의미일 수 있겠지만 문맥에 따라서 완전히 다른 경우가 대부분이다. 괜히 비슷하게 생각했다가 더 이해하기 어려운 경우가 많다. 그래서 공부를 할 때, 문맥과 문맥 속의 그 단어의 의미를 그냥 외우는 것이 좋다.
pseudo의 의미
pseudo code라는 단어를 알고리즘이나 자료구조 시간에 많이 들었다. 보통 번역하면 의사 코드라고 하는데 그 의미가 와닿지 않는다.맹기완님이 pseudo의 의미에 대해서 간단하게 정리해 주셨다. pseudo란 가짜이지만 진짜인 것, 가짜이지만 의미를 담고 있으며 언제든 진짜로 대체 가능한 것이다.
이제 pseudo code를 다시 보자. 이것은 실제 코드는 아니지만 실제 코드로 대체 가능하며 대체되면 의도한 대로 실행되는 코드이다.
CSS 에서 pseudo element를 보자. 의미를 담는 것이 아닌 그림그리기 위한 element로 메타 정보가 전혀 없다. 가짜이지만 진짜처럼 표현 되며, 진짜 element로 대체 가능하다.
아직도 이해가 안가는 BFC
BFC는 Block Formatting Context라는 visual formatting model 중의 하나이다.
사실 지금도 이해 못한 부분인데, 스스로에게 숙제처럼 남겨두었다. 언젠가는 잘 이해해서 블로그로 포스팅도 하고 그래야지.
관련링크 : https://developer.mozilla.org/ko/docs/Web/Guide/CSS/Block_formatting_context
프로그램은 무조건 변경된다. 그래서 격리한다.
나의 작은 경험에 의한 일반화이지만 프로그래머는 대부분의 시간을 기존의 코드를 수정하며 보낸다.
계속 서비스가 되고 누군가의 요구사항이 들어온다면 코드는 변경된다. 이게 아니더라도 코드 퀄리티를 높이기 위해서, 개발자의 개인적인 기호 등등 많은 이유에서 코드는 변경된다. 여기서 중요한 점은 코드가 변경되어도 기존의 영역에는 문제가 없어야 하는 것이다. 가장 쉬운 해결책은 코드를 격리시키는 것이다.
클래스 명으로 selector를 격리시키고 즉시실행함수로 변수들을 격리시킨다.
변화율과 대칭성
위의 내용과 계속 이어가보면 어떻게 그루핑 해서 격리를 시킬까? 맹기완님은 변화율이라는 단어로 설명해주셨다. 비슷하게 변할 것 같은-변화율이 비슷한 놈들끼리 묶어야한다. 다른 말로 하면 변화했을 때 같이 변할 것 같은 코드들을 묶어 놓는 것이다.
예를 들어, 아래의 코드가 있다.
/* 사이트 이름 */
.site h1 a{
/*생략*/
}
.site h1{
/*생략*/
}
/* 네비게이션 */
.menu ul{
/*생략*/
}
.menu li a{
/*생략*/
}아마 사이트 이름 관련한 style이 변경된다면 site h1 a와 .site h1이 같이 변경될 가능성이 높다. 또한 아래 네비게이션도 동일하게 같이 변경될 가능성이 높다. 그래서 그런 녀석들 끼리 같이 묶어 놓는 것이 중요하다. (그리고 묶은 대로 격리한다.)
CSS 뿐만 아니라 js, java 등 모든 언어들도 이렇게 변화율이 비슷한 부분을 옆에 두어서 변경에 용이하게 한다. 예를 들어 변화율이 비슷한 function 또는 method 끼리 묶고 (그게 클래스가 될 가능성이 높다) 변화율이 비슷한 class들 끼리 package로 묶는다.
대칭성이라는 것은 바로 예를 들면 get과 set이 한꺼번에 있는 것을 의미한다. 상식적으로 대칭적인 기능이 제공되어야 하는 것을 말하는 것 같다. 이부분은 확실하지 않다...
이 부분에 대해서는 클린 코드란 책의 일독을 권한다.
(도서 리뷰 : http://reimaginer.tistory.com/entry/clean-code-book-review)
텐션 관리
모든 일은 반복적으로 변하게 되면 지루해진다. 일을 진행하면서 눈에 보이거나 느낄만한 성과가 없으면 지치게 된다. 그래서 개발을 오래 잘하고 싶다면 텐션관리를 잘해야한다.
스터디 중에 든 예는 퍼블리싱(CSS) 작업을 하면서 완료되지 않은 레이아웃들에는 백그라운드 색을 주고 완료가 되면 백그라운드를 해제하는 것이다. 그렇게 하면 작업의 성과가 눈에 보이게 된다.
어떤 측면에서는 테스트 주도 개발도 좋은 텐션을 유지하는데 도움이 되는 방법인 것 같다. 내가 지금 다니고 있는 매쓰홀릭의 서비스에서도 학생이 성과를 바로 확인할 수 있는 green challenge라는 것이 있다. 결국 중요한 것은 재미있게 하는 것이다.
프로그래밍은 이름짓기다
프로그래머들이 이름 짓기가 제일 어렵다고 하는데, 이것은 우스갯 소리가 아니다. 진짜 너무 어렵고 너무 고민된다. 동료들 뿐아니라 작성한 본인을 위해서라도 의미있게 이름이 지어야한다. 현재 담아내고자 하는 도메인(비즈니스 로직)을 반영해야 하고 이미 이름 지어진 녀석들과 관계까지 생각해야한다. 너무 머리가 아프다.
그래서 맹기완님은 아예 이름 짓는 행위 자체를 안할 수 있도록 해야한다고 했다. (나는 바로 Functional Programming 이 떠올랐다.) 그런데 나의 작은 경험으로는 이름이 많지 않은 코드가 어떻게 읽기가 좋을지 이해가 되지 않아서 이 부분은 좀더 고민하고 공부를 해야할 것 같다.
여튼, 결론은 이름 짓기가 프로그래밍이라고 해도 될 만큼 이름 짓기는 중요하다.
원칙 혹은 convention의 의미
원칙 내용의 옳고 그름을 떠나 원칙은 장점이 있다. 그것은 모두 원칙을 지켰을 때, 원칙을 지키지 않는 것을 쉽게 찾을 수 있다는 것이다. 또한 쉽게 규칙대로 원하는 것을 찾을 수 있다는 것이다.
예를 들어, 교장선생님 훈화말씀에 학생들이 반별, 번호순서대로 오와 열을 맞추어 서있다. 이것이 옳고 그름을 떠나서 장점은 몇 반이 어디에 있는지 잘 보이고 몇번이 어디있는지 찾기 쉽고 누가 빠져있으면 쉽게 찾을 수 있는 것이다.
내가 생각할 때 코드 원칙 즉 컨벤션은 팀이 인지 부하를 줄이고 버그를 줄이기 위한 노력이다. 팀의 생산성을 위해서라면 굉장히 중요한 부분이다.
간단한 4L 후기
Liked
- 많은 경험이 있는 분의 강의를 듣는 다는 것 자체자 좋은 경험이었다.
- 학습 방법에 대해서 고민해보게 되는 시간이었다.
- 동영상 강의를 제공해주어서 집에서 편하게 공부할 수 있었다.
Learned
- 내가 잘 모르던 CSS 부분을 차근차근 잘 설명해 주셨고 어떻게 공부해야 할지도 알게 되었다.
- 내가 이쪽 영역을 정말 모른다는 것을 알게 되었다.
- 프로그래머로서 노하우를 많이 알려주셨다.
Lacked
- 딱히 없는 거 같다.
Longed for
- 스터디 교재였던 책의 코드를 모두 작성해보고 싶다.
