5. TIL (2022.03.23) – 노마드 코더 Nomad Coders

일반 텍스트
- 우리의 기본 재료는 지식, 지식을 일반 텍스트로 저장하라.
- 왜? → 구식이 되는 것에 대한 보험, 호환성, 더 쉬운 테스트를 위해.
- 텍스트는 어디에나 존재하며, 소통에 있어서 공통의 표준이다.
- 📌 XML, SGML, HTML
셸
- GUI의 장점은 WYSIWYG, 단점은 WYSIAYG
- GUI의 기능은 일반적으로 설계자의 의도에 따라 제약을 받는다.
- 셸은 쿼리나 기타 다른 작업을 수행하기 위해 몇 개의 명령어를 재빨리 결합하려 할 때 사용하기 좋다. → 생산성과 직결
- 단지 코드를 자르거나, 객체 모델을 개발하거나, 문서를 작성하거나, 빌드 과정을 자동화하거나 하지만은 않는다. 이 모든 일을 다 한다. 어떤 도구든지 사용 범위는 보통 그 도구가 사용되리라고 예상되는 작업에 한정된다.
하나의 에디터를 잘 활용할 것
- 완전히 마스터하고 모든 편집 작업에 그 에디터를 사용해 볼 것.
- 에디터의 기능을 기호에 맞게 다시 설정할 수 있어야 하며, 에디터가 나를 ‘학습하도록' 해야.
소스코드 관리
- 일종의 거대한 UNDO 키와 같다.
- 코드가 실제로 컴파일되고 실행되던 지난 주의 평화로운 시절로 되돌려 줄 수 있는, 프로젝트 전체를 커버하는 타임머신이다.
- 넓은 의미의 형상 관리 시스템은 소스코드나 문서 관련의 모든 변화를 기억한다.
- 소스코드 관리 시스템은 관리하는 파일들을 중앙 저장소에 유지할 수 있는데 이는 아카이브를 위한 훌륭한 선택이다.
디버깅
- 기술의 전당에서는 남을 비난하기보다 문제를 고치는데에 집중하고 싶어 한다. → 비난 대신 문제를 해결하라.
- 디버깅을 할 때 당황하지 마라.
- 한발짝 뒤로 물러나서 무엇이 자신으로 하여금 버그가 있을 거라고 생각하게 하는지, 그 증후의 원인이 무엇일지 실제로 생각해보는 것이 정말 중요하다.
- 깨끗이 컴파일된 (경고문 없는) 코드로 작업하고 있는지 확인하라.
- 데이터 시각화, 데이터를 가시화하라. ex) DDD 디버거
- 트레이싱 활용하기, 화면 혹은 파일에 출력하는 작은 진단용 메시지.
- 고무오리🐤, (내 경우엔 윌슨🏐, 캐스트 어웨이)로 발화하기.
- 제거 과정, 써드파티 제품에 문제가 있다고 해도 여전히 자신의 코드를 제거해야 한다.
- 가정하지 마라, 증명하라.
디버깅 체크리스트

✔ 보고된 문제가 내재하는 버그의 직접적 결과인가 아니면 단순히 증상일뿐인가?
✔ 버그가 정말로 컴파일러에 있나? OS에? 혹은 여러분 코드에 있나?
✔ 이 문제를 동료에게 상세히 설명한다면 어떻게 말하겠는가?
✔ 의심가는 코드가 단위 테스트를 통과한다면, 테스트는 충분히 완전한 것인가? 이 데이터로 단위 테스트를 돌린다면 무슨 일이 생기는가?
✔ 이 버그를 야기한 조건이 시스템의 다른 곳에도 존재하는가?
텍스트 처리
- 텍스트 처리 언어를 하나 익혀라.
코드 생성기
- 코드를 작성하는 코드를 작성하라.

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

소스코드 관리와 디버깅 챕터가 가장 의미있게 다가왔던 것 같다. 무엇보다 버그를 대처하는 자세, 기술의 전당에서는 비난하기보다 문제를 해결하는데 집중한다. 크으, 너무 멋진 말인 것 같다. 비난의 카타르시스보다는 이런 자세를 가져야지. 이전 회사에서는 버전관리의 중요성을 잘 몰랐었다. 하자고 독려하는 분위기도 아니었고, 독려가 아니라 기본이어야 하지만. 이번 공부 범위에서는 도구도 도구지만, ‘분명 좀 더 나은 방법이 있을 텐데'라는 마음가짐이 너무 중요했던 것 같다.

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

일반 텍스트의 힘에서 체크섬

오늘 읽은 다른사람의 TIL

https://flynndev.notion.site/2022-03-23-DAY-05-5e2efb73d6f444edaf365e02c30980d6
→ 체크섬에 관한 관련 링크를 올려두셔서 이해하는데 도움을 많이 받았다. 😎

글쓰기

노마드코더 이벤트노마드 코더, 강의 1:1 상담 해드려요~️⭐️📚 노마드코더 신간 안내 📚 IT 5분 잡학사전

# interview