TIL

3줄 요약

• 도구는 재능을 증폭한다. 일을 하는 데 더 나은 방법이 없는가 늘 주변을 살펴라.

• 명령어 셸의 힘을 사용하라. 하나의 에디터를 잘 사용하라.

• 다른 누가 만든 게 아니고 바로 자신이 문제를 만들었다는 것.

14. 일반 텍스트의 힘

• 우리의 기본 재료는 지식. 요구사항을 지식으로 수집하고 설계, 구현, 테스트 그리고 문서에 표현. 이 때 일반 텍스트가 최고의 포맷!

• 일반 텍스트: 사람이 직접 읽고 이해할 수 있는 형태의 인쇄 가능한 문자로 이루어진 텍스트. 자명한 데이터 흐름을 얻을 수 있다.

• 단점

  • 압축된 이진 포맷을 사용하는 것보다 더 많은 공간 차지

  • 일반 텍스트 파일을 해석하고 처리하는 데에 더 많은 계산 필요

• 텍스트의 힘

  • 구식이 되는 것에 대한 보험: 사람이 읽을 수 있는 형태의 데이터와 자명한 데이터는 오래 살아남는다. 살아있으면 사용할 수 있는 기회가 찾아온다. 사람이 읽을 수 있는 것과 이해할 수 있는 것에는 차이가 있다.

  • 호환성: 컴퓨팅 세계의 거의 모든 도구들은 일반 텍스트를 다룰 수 있다.

  • 더 쉬운 테스트

• 최소 공통분모

• 모든 참가자가 공통의 표준을 사용해서 소통하도록 할 필요가 있다면 일반 텍스트가 표준

15. 조개 놀이

• 프로그래머에겐 명령어 셸이 작업대. GUI환경의 기능은 일반적으로 설계자의 의도에 따른 제약을 받음.

• 명령줄은 쿼리나 기타 다른 작업을 수행하기 위해 몇 개의 명령어를 재빨리 결합하려 할 때 사용하기 좋다.

• 명령어 셸의 힘을 사용하라

16. 파워 에디팅

• 하나의 에디터에 대해 매우 잘 알, 코드, 문서화, 메모, 시스템 관리등 모든 편집 작업에 그것을 사용하는 것이 더 낫다.

• 하나의 에디터를 잘 사용하라.

• 에디터는 우리 손의 연장이 된다.

• 에디터의 기능

  • 설정 변경 가능: 기호에 맞게 설정 변경 가능

  • 확장 가능: 새로운 언어나 텍스트 포맷을 추가할 수 있어야 한다.

  • 프로그램 가능: 복잡하고 다단계의 작업을 수행할 수 있도록 에디터를 프로그램 하자.

• 생산성. 작업을 능률적으로 하는데 도움을 준다.

17. 소스코드 관리

• 진보라는 것은 변화와는 거리가 멀고 오히려 기억에 의존한다.

• 소스코드 관리 시스템은 프로젝트 전체를 커버하는 타임머신이다.

• 형상 관리 시스템은 소스코드나 문서 관련의 모든 변화를 기억한다. 컴파일러나 os버전까지도 기억 가능. 소프트웨어의 이전 버전으로 언제든 되돌아갈 수 있다.

• 릴리즈들을 구분하게 해준다.

• 언제나 소스코드 관리 시스템을 사용하라. 소스코드가 아닐지라도..!

• 소스코드 관리와 빌드: 제품 빌드가 자동화되고 그것을 반복할 수 있게 된다.

  • 빌드를 자동화 하는 것은 일관성을 보장한다. 수작업이 없고 특정 빌드 영역으로 코드를 복사해야 한다는 걸 기억해줄 개발자가 필요없다.

  • 특정일에 존재했던 빌드를 언제건 반복 할 수 있따.

18. 디버깅

• 다른 누가 만든 게 아니고 바로 자신이 문제를 만들었다는 것.

• 디버깅은 단지 문제 해결이라는 사실을 포용하고, 그 방식으로 공략하라.

• 비난 대신 문제를 해결하라

• 디버깅 사고방식

  • 디버깅을 할 때 당황하지 마라

  • 무엇이 자신으로 하여금 버그가 있을 거라고 생각하게 하는지, 그 증후의 원인이 무엇인지 실제로 생각해보는 것이 정말 중요.

  • 디버깅을 할 때 근시를 조심. 실제 문제는 몇 단계 떨어져 있고 여러 가지와 연관되어있을 확률이 다분하다.

• 관찰을 정확히 해야한다.

  • 처음에 받은 자료 이상을 얻기 위해서 버그를 보고한 사용자를 인터뷰하자.

  • 인공테스트는 앱을 충분히 테스트하지 못함. 경계 조건과 실제 최종사용자 사용 패턴 모두를 철저히 테스트하자. 이것을 체계적으로 하자.

• 디버깅 전략

  • 데이터를 가시화해라. 프로그램이 뭘 하는지, 뭘 할 것인지 알아내는 가장 쉬운 방법은 프로그램이 다루는 데이터를 살펴보는 것. ex)출력 텍스트, gui대화상자의 필드등

  • 데이터와 데이터들 사이에 존재하는 모든 상호관계를 시각화할 수 있는 디버거 사용하자. 안되면 종이와 연필로라도 하자.

  • 트레이싱: 시간에 따라 프로그램이나 데이터 구조의 상태가 변화하는 것을 볼 필요가 생긴다. 트레이싱 구문은 ‘여기까지 도달'이나 ‘x 값 = 2’ 등의 화면 혹은 파일에 출력하는 작은 진단용 메세지. 시간 자체가 중요한 요소가 되는 시스템에서 굉장히 귀중하다. 콜트리에서 내려가기 위해 (파고 들어가기) 트레이싱 구문을 추가할 수 있다.

  • 고무 오리: 누군가에게 문제를 설명하면 통찰이 생긴다.

  • 제거 과정: ‘select’는 망가지지 않았다. 즉 다른 라이브러리 보다 내 코드를 먼저 의심해라. 라이브러리나 프레임워크, 도구가 업데이트가 됐다면 업그레이드를 고려할 떄는 일정을 살펴라.

• 놀람의 요소

  • 버그에 관련한 루틴이나 코드가 제대로 작동한다고 ‘안다'고 해서 대충 얼버무리지 마라. 그것을 증명해라.

  • 가정하지 마라. 증명해라

  • 놀라운 버그를 마주치면 단순히 고치는 걸 넘어서 외 이 실패가 더 일찍 발견되지 않았을까 생각해 볼 필요가 있다.

  • 만약 다른 사람이 내린 잘못된 가정의 결과라면 전체 팀과 토론하라.

19. 텍스트 처리

• 텍스트 처리 언어 하나를 익혀라.

  • 이를 사용해서 유틸리티를 빠르게 만들 수 있고 아이디어를 프로토타입해 볼 수 있다.

20. 코드 생성기

• 코드를 작성하는 코드를 작성해라.

• 수동적 코드 생성기

  • 결과를 내기 위해 한 번만 실행. 결과물은 독립적이 된다.

  • 타이핑을 줄여준다. 몇 개의 입력에서 주어진 출력을 생성하는 매개 변수화된 템플릿.

  • 새 소스 파일 생성: 수동적 코드 생성기는 새로운 파일을 만들 때마다 템플릿, 소스코드 제어 지시자, 지적재산권 문구, 기본적으로 들어가는 주석을 만들기 위해 사용할 수 있다.

  • 코드 생성기는 꼭 정확할 필요 없다. 코드 생성기를 만드는 노력과 부정확한 부분을 수정하는 시간을 고려해서 만들어라.

• 능동적 코드 생성기

  • 코드 생성이 필요할 때마다 작동.

  • 어떤 지식을 하나의 형태로만 만들어 놓고 앱이 필요로 하는 온갖 형식으로 변환할 수 있다. 이렇게 만들어진 형식은 언제라도 버릴 수 있고 필요할 때마다 코드 생성기가 만들어내기 떄문에 중복이 아니다.

  • 데이터 베이스와 해당 db에 접근해야 하는 프로그래밍 언어가 있다. 이 떄 스키마가 바뀌면 프로그래밍 언어의 구조체도 변경해야 한다. 이 때 능동적 코드 생성기를 사용해서 db스키마로 구조체들의 소스 코드를 만드는데 사용한다. 이러면 스키마가 변경될 때 코드 또한 자동으로 변경된다.

    • 이런 방식은 코드 생성을 빌드 과정 자체의 일부로 만들어 두었을 때 효과적.

  • 공통 정보를 더 단순하고 언어에 중립적인 형태로 표현해 놓은 다음 각 언어의 코드를 생성하는 편이 더 간단한 경우가 많다. 그 외에 한 언어를 파싱해서 다른 언어 코드를 생성할 수 있다.

• 코드 생성기가 꼭 복잡할 필요는 없다.

  • 가장 복잡한 부분은 입력을 분석하는 파서. 입력을 단순하게 하면 코드 생성기도 단순해진다.

• 코드 생성기가 꼭 코드를 생성해야할 필요는 없.

  • HTML, XML 일반 텍스트 등 원하는 결과물을 원할 때 코드생성기를 쓸 수 있다.

소감

• 지식을 기록할 떄는 일반적인 텍스트로 저장해두는 게 나중에 파악할 때도 좋을 것같다.

• 셀 스크립트를 공부해야지 하고 거의 5년동안 미뤄온 것 같은데 당장 오늘부터 하나씩 공부를 해야할 것 같다. 이와 비슷하게 vim도 공부해서 써봐야지 했는데 이것도 조금씩 써봐야겠다. 그런데 생각해보니 에디터 중 주로 사용하는건 vscode니 좀 더 스마트하게 vscode를 사용하는 법을 알아보는게 우선이겠다.. vim은 조금만 더 뒤로 미루는 것으로..

• 소스코드 관리는 여기는 너무 오래된 것만 추천하는데 뭐 다들 당연하게 git을 사용하겠지..? git에 대해선 공부하고 있는데 정말 지원하는 기능이 많다는 걸 느낀다. 자유자재로 사용하면서 내 코드를 좀 더 체계적으로 관리해보자.

• 디버깅은 그래도 나름 책에 나온대로 잘 하고 있다고 생각은 하는데, 시각화 디버거들은 사용해본적인 거의 없는 것 같다. 도구는 시간을 줄여주고 생산성을 높여주니 디버거에 대해서 좀 찾아봐야겠다.

• 텍스트 처리에 대해서는 이 책에서 나온것처럼 깊게 생각해본 적이 없다. 오히려 텍스트 처리에 대해서 좀 거부감, 공포감, 두려움을 갖고 있었다. 그런데 실제로는 엄청나게 복잡한 것만 있는 것도 아니고 (정규식이 떡칠되어 있는,,) 잘만 사용하면 많은 반복 작업을 줄일 수 있을 것 같다는 생각이 들었다. 여기서 예시에 나온 db스키마를 보고 코드가 생성된다는지 하는 그런 것들 말이다. 자바스크립트를 자주 사용하니까 노드로 저런 코드 생성기 프로그램 만드는 프로젝트도 재밌을 것 같다. 만약 다른 언어를 배우라는 이 책의 가르침을 따르려면 조금은 할 줄 아는 파이썬이나 다른 스크립트 언어를 배우면서 도전해봐도 좋을 것 같다. 좀 깊게 생각해보면 코드 생성기를 만들 분야가 많을 것 같은데 바로 생각은 안나네,,,