오늘 TIL 3줄 요약

• 도구에 유창해져라(일반 텍스트, 셸, 에디터, VCS 등)

• GUI 환경에서 벗어나 CLI 환경, 셸에 익숙해져라.

• 디버깅은 문제 풀이라고 받아들이고 해결할 땐 근본 원인을 찾아라.

TIL (Today I Learned) 날짜

2022.03.23

오늘 읽은 범위

3장. 기본 도구

책에서 기억하고 싶은 내용을 써보세요.

• 일반 텍스트

  • 일반 텍스트라면 데이터 그 자체만으로 의미가 드러나는 데이터를 만들 수 있음. 즉, 데이터가 데이터를 만드는 애플리케이션에 독립적인 것.

  • 일반 텍스트가 형식이 없는 텍스트를 의미하는 것 X. HTML, JSON, YAML 등은 모두 일반 텍스트. HTTP, SMTP, IMAP 등 인터넷에서 사용되는 핵심 프로토콜도 대부분 일반 텍스트.

  • 유닉스에서는 사용자, 비밀번호, 네트워크 설정 등 시스템 관리용 데이터베이스를 모두 일반 텍스트 파일로 저장.

• 회귀 테스트(regression test) - 동일한 테스트를 반복적으로 수행함으로써 새로운 기능이 애플리케이션에 추가되었을 때 기존 기능이 여전히 제대로 작동하는지 검사하는 테스트. 회귀 테스트에서 찾아낸 문제를 리그레션(regression)이라 부르기도 함.

• 모든 작업을 GUI로만 하면 여러분이 가진 환경의 능력을 전부 이용할 수 없다. GUI의 장점은 WYSIWYG(What You See Is What You Get), 즉 여러분이 보는 것이 여러분이 얻는 것이라는 점이지만, 단점은 WYSIAYG(What You See Is All You Get), 즉 여러분이 보는 것이 여러분이 얻는 전부라는 것이다. GUI 환경의 기능은 일반적으로 설계자가 의도한 범위를 넘어설 수 없다.

• 여러분은 셸 안에서 많은 시간을 보내게 될 것이다. 소라게처럼 조개 껍데기(shell), 그러니까 셸을 여러분의 집으로 만들어라.

• 디버깅을 풀어야 할 퍼즐로 공략하는 대신 현실 부정이나 손가락질, 어설픈 변명, 무관심으로 대하는 사람과 마주치기도 한다. 디버깅은 단지 문제 풀이일 뿐이라는 사실을 받아들이고, 그런 마음으로 공략하라.

• 겉으로 드러난 특정한 증상만 고치려고 하지 말고, 항상 문제의 근본 원인을 찾으려고 노력하라.

• "코드를 고치기 전 실패하는 테스트부터."

• 이진 분할 - 프로그램이 죽는다면 이진 분할을 활용해서 정확히 어떤 입력값이 범인인지 찾아내라. (131p)

• 버그와 관련된 루틴이나 코드가 제대로 작동하는 걸 '안다'고 해서 대충 얼버무리고 지나치지 말라. 그것을 증명하라. 이 맥락 안에서, 이 데이터로, 이 경계 조건하에서 증명하라.

• 버그를 수정하는 김에, 혹시 이것과 동일한 버그가 있을 법한 다른 코드가 있는지 살펴보자. 바로 지금 그것들을 찾아서 고쳐야 한다. 어떤 일이 일어났든지 간에 똑같은 일이 다시 발생하면 그 사실을 알 수 있도록 하라.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

• GUI 환경에 익숙해져있는 와중에도 항상 한계가 있는 것 같다는 생각을 해왔는데 이렇게 책에서도 그 부분을 적어두니 확실히 셸에 익숙해져야겠다는 생각을 했다. 내가 필요한게 만들어져있지 않다면 만들어도 봐야겠다.

• 팀 프로젝트에서 버그가 나타나면 책임을 묻는 경우가 종종 있었는데, 앞으로는 나 스스로에게나 팀원에게도 귀책을 묻기보다는 그저 '문제 풀이'라고 생각하고 해결해야겠다. 그리고 딱 드러난 버그만을 고치기보다는 불안했거나 이와 비슷한 코드들을 다시 살펴보는 습관도 길러야겠다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• 칸반 보드(kanban board) - https://en.wikipedia.org/wiki/Kanban_board

• 분할 정복(divide and conquer) - 이진 탐색, 퀵 정렬 알고리즘

• 트레이싱 구문 - '여기까지 도달'이나 'x값 = 2'같이 화면 혹은 파일에 출력하는 작은 진단용diagnostic 메시지