실패한 고통보다 최선을 다하지 못했음을 깨닫는 것이 몇배 더 고통스럽다.
- 앤드류 매튜스
HTML/CSS Front-end 프로젝트
작성중)JavaScript
완료)예정) - 집 가는 길에 하기예정)예정)
오늘의 일기는 우연히 보게 된 기술 블로그의 한 포스팅 글귀에 대한 내용으로 시작을 해보려고 한다.
수업과 자습이 끝나고 10시쯤 집에 가는 길에 지하철 안에서 어느 기업의 테크 블로그를 보았다. 해당 기업에 인턴으로 참여했던 학생들이 여러가지 개발 관련 질문을 한 내용에 대해서 Q&A 형태로 글을 포스팅을 했는데, 한 가지 인상깊었던 내용이 있었다.
Q(학생): “저는 Jenkins, AWS 등 Backend에 도움이 되는 도구를 배웠지만 도구를 배운다는 게 과연 실력을 키우는 것인지는 의문이다.”
A(실무자): “개발도구를 잘 활용하는 능력은 생산성과 직결되기에 중요합니다. 그런데 개발도구를 ‘배워야’하는 개발자보다는 스스로 익힐 수 있고, 적절한 도구를 선택할 수 있는 개발자가 현장에서는 필요합니다.
실패한 고통보다 최선을 다하지 못했음을 깨닫는 것이 몇배 더 고통스럽다.
- 앤드류 매튜스
rubber duck debugging 팀원들이랑 같이 하기(10:00 ~ 11:00)
HTML/CSS Front-end 프로젝트
일부 작성완료)JavaScript
예정)예정)예정)예정)
요 몇일동안 아니 저번달도 몇 일정도 이 TDD라는 녀석에 대해서 검색도 해보고, 영상도 보고 나름 이것저것 시행착오를 겪어가며 공부를 하였다.
처음에는 요즘 트렌드라고 하니깐, 그리고 완벽하게는 아니지만, 개발 도중에 발생하는 대다수의 버그를 잡아낼 수도 있다는 이야기를 듣고 무작정 해보려고 테스트 코드 작성법부터 찾아보았다. 하지만 왠지 제대로 작성하고 있는건지 의문이 들었었다.
그래서 그때부터 이론적인 부분부터 실무에서 직접 적용해 본 실무자들이 올린 블로그 글, 유뷰트 관련 영상 등등 이 곳 저 곳에 흩어져 있는 알짜배기 내용들을 읽고 정리하고 연습하기를 반복하였다.
가장 도움이 되었던 블로그 글은 네이버 기술 블로그에 프론트엔드 개발자 분이 올려주신 TDD관련 내용이었다. 그 분의 글을 보면서 실무에서는 어떤 방식으로 테스트 코드를 작성하고 어떤 테스트가 좋은 테스트인지에 대해서도 자세하게 알 수 있었다. 너무 내용이 좋아서 노트 필기를 하며 읽어 보았는데, 나중에 한 번 더 보고 싶을 때 참고할 수 있게 아래에 필기내용을 첨부하였다.
오늘은 본격적으로 Repository를 생성하고 header 부분의 레이아웃을 우선 설계해보았다. 확실히 HTML/CSS 수업을 듣고나서 진행하는 레이아웃 작성이라 그런지 레이아웃 구성시에 작성하는 코드에 대해서 설명이 가능한 것 같다.
header 레이아웃을 분석하던 도중에 반응형 레이아웃이라는 것을 고려한다면 어떻게 효율적으로 요소들을 배치해야 하는지 고민이 되었었다.
콘텐츠의 논리적 흐름을 최대한 유지한 상태에서 일부 요소의 배치를 이동하여 구성해야 된다는 것은 수업시간에 배워서 알고 있었는데, 막상 배치를 생각해보니 어려웠다. 더군다나 반응형 웹 페이지가 아닌 적응형 웹 디자인으로 작성된 페이지다보니 모바일과 데스크탑 웹 페이지의 헤더 부분이 많이 달라보였다.
그렇게 고민을 하던 중에 우연히 강의실을 지나가시던 데레사 강사님께 질문을 드렸다. 해답은 바로 콘텐츠의 논리적 흐름과 모바일 우선(mobile-first)방식에 있었다. 이미 개념적으로는 머리 속에 박혀있어서 레이아웃을 설계하면서 되뇌이던 개념이었는데, 역시 아직 많은 연습이 필요한 것 같다.
좋은 테스트란 무엇일까? 무작정 테스트 코드를 작성해보려고 했지만 막상 좋은 테스트란 무엇인지 알지 못했다.
우선 첫 번째, 테스트의 의도가 명확해야 한다. 코드의 가독성은 중요하다. 좋은 코드는 기계가 아닌 사람이 읽기 쉬워야 한다. 누군가 내가 작성한 테스트 코드를 보았을때 한 눈에 어떤 내용을 테스트하고 있는지 파악할 수 있어야 한다. 테스트 코드가 너무 장황해지거나 불필요하게 복잡해진다면 별도의 함수를 만들어 추상화시켜주는 것이 좋다.
두 번째, 좋은 테스트란 빠른 피드백을 받을 수 있으며, 개발 속도를 빠르게 할 수 있도록 해야 한다. 테스트 결과를 보기 위해 오랫동안 기다려야 하는 테스트는 개발 과정에서 좋지 않다.
