TIL (Today I Learned)
2022.03.23
오늘 읽은 범위
3장. 기본 도구
🎨 책에서 기억하고 싶은 내용을 써보세요.
- 104p
많은 신참 프로그래머가 예컨대 특정 통합 개발 환경IDE 같은 강력한 도구
하나만 고집하는 실수를 저지르고, 그 익숙한 인터페이스에서 떠날 생각을 하지 않는다. 정말로 안타깝다. 여러분은 IDE가 갖는 한계를 넘어설 수 있어 야 한다. 유일한 방법은 기본 도구들을 언제나 곧바로 사용할 수 있도록 예리 하게 유지하는 것이다.
내가 지금까지 공부하면서 pycharm과 vscode밖에 써본적이 없어서 그런지 엄청 와닿았던 것 같다.
- 105p
우리는 지식을 저장하는 최고의 포맷이 일 반 텍스트plain text라고 믿는다.
일반 텍스트는 사람이 이해할 수 있어야 한다.
- 111p
GUI의 장점은 WYSIWYGWhat You See Is What You Get, 즉 여러분이 보는 것이 여러분이 얻는 것이라는 점이지만, 단점은 WYSIAYG What You See Is All You Get, 즉 여러분이 보는 것이 여러분이 얻는 전부라는 것이다.
GUI 환경의 기능은 일반적으로 설계자가 의도한 범위를 넘어설 수 없다.
내가 배울게 많아서 그런지 더 이상 필요한게 무엇인지 생각할 틈 조차 없다고 생각하기도 했고 최근에 git len같은 extension을 봐서 그런지 공감이 가진 않았지만 머리로는 이해가 갔다.
- 113p
여러분은 셸 안에서 많은 시간을 보내게 될 것이다. 소라게처럼 조개 껍데기 shell 그러니까 셸을 여러분의 집으로 만들어라.
확실히 맥을 처음 사고나서 zsh를 이용해 터미널을 꾸미고 기능들을 추가하니까 윈도우를 사용할때보다 엄청 편해지고 내가 지금 뭘 하고 있는지도 직관적이게 된것같다.
- 121p
언제나 버전 관리 시스템을 사용하라.
git이 얼마나 강력하고 좋은 기능을 가지고 있는지 다시 알게되었다.
- 127p
당황하지 말라.
한 발짝 뒤로 물러나서 여러분이 버그라고 생각하는 증상의 원인이 무엇일지 진짜로 생각해 보는 것이 정말 중요하다.
요즘에 느꼈다. 한숨돌리고 다시 코드를 본다면 내가 어디서 잘못하고 있었는지 훨씬 더 잘보인다.
-
129p
버그를 고치는 첫걸음으로 가장 좋은 것은 그 버그를 재현할 수 있게 만드는 것이다. 무엇보다, 재현할 수 없다면 어떻게 그 버그를 고쳤다는 것을 확인할 수 있겠는가?
코드를 고치기 전 실패하는 테스트부터. -
131p
우리 경험상 가끔 실마리를 발견하고 쫓아 들어갔지만 결국 허탕을 쳤을 때 메모가 특히 도움이 되었다. 추적을 시작할 때 우리가 어디에 있었는지 메모를 남겨 두지 않았다면 원래 자리로 돌아오느라 시간을 많이 소모했을 것이다.
1. 입력값에 따라 바뀜
데이터 세트를 복사한 다음, 개발 환 경에서 실행시킨 애플리케이션에 입력해서 여전히 프로그램이 죽는지 확인 하라. 프로그램이 죽는다면 이진 분할을 활용해서 정확히 어떤 입력값이 범 인인지 찾아내라.
2. 릴리스 사이에서 발생한 문제regression
정확하게 어떤 변경 사항 때문에 버그가 발생했는지 알아낼 수 있다 면 좋지 않을까? 그렇다. 이진 분할이 등장할 시간이다.
현재 릴리스에서 실패하는 테스트를 만들 어라.
문제가 없었던 버전 중 가장 최근 버전과 현재 버전 사이에서 중간 정 도에 위치한 릴리스를 골라라.
테스트를 수행한 후, 결과에 따라 어느 쪽을 탐색할지 골라라.
git commit 뿐이 아니라 진짜 실물의 포스트잇이나 아이패드를 이용해 손으로 메모를 남겨두며 추적한다면 도움이 크게 될것같다.
- 134p
누군가에게 문제를 설명하게 되면 혼자 코드를 살 펴볼 때는 당연히 여기고 지나갈 것을 명시적으로 이야기해야 한다. 이런 가 정 몇 가지를 입 밖에 내면, 문제에 대한 새로운 통찰을 불현듯이 얻을 수도 있다. 만약 들어 줄 사람이 없다면 고무 오리나 곰 인형, 화분도 괜찮다.
이 방법은 내게 남에게 설명을 하는 능력도 올려주고 내가 몰랐던 지식들도 얻게 해줄 좋은 공부방법이라 생각한다.
- 135p
설사 외부 제품에 문제가 있더라도 버그 리포트를 제출하기 전에 여러분의 코드에 문제가 없다는 것을 확인해야 하는 것은 마찬가지다.
우리가 맡았던 프로젝트에서 한 고참 엔지니어는 select 시스템 콜11이 특 정 유닉스 시스템에서 제대로 작동하지 않는다고 확신했었다. 어떤 설득이 나 논리도 그의 생각을 바꿀 수 없었다. 같은 컴퓨터에서 다른 네트워킹 애플 리케이션이 모두 잘 작동한다는 사실도 신경 쓰지 않았다. 그는 수 주에 걸쳐 우회하는 코드를 작성했지만 뭔가 이상한 이유로 문제를 해결하지 못한 듯 보였다. 결국 자리에 앉아서 select에 관한 문서를 읽을 수밖에 없게 되자 그 는 원인을 발견해 냈고, 몇 분 만에 문제를 해결했다. 우리 둘 중 하나가 자신 의 실수일 수 있는 일을 시스템의 문제라고 탓하기 시작하면 우리는 그 사건 을 떠올리도록 ‘select가 망가졌어’라는 표현을 사용한다.
아직 내 실력에 자신이 없어 이런 경우가 없었지만 내가 앞으로 가져야할 마인드라 생각하고 책에 있는 일화와 함께 기억해야한다고 생각한다.
-
136p
예상치 못한 ‘놀라운’ 실패를 대면했을 때 자신이 세운 가정이 적어도 하나는 잘못되었다는 것을 받아들여야 한다. 버그와 관련된 루틴이나 코드가 제대로 작동하는 걸 ‘안다’ 고 해서 대충 얼버무리고 지나치지 말라. 그것을 증명하라. 이 맥락 안에서, 이 데이터로, 이 경계 조건하에서 증명하라.
-
142p
그들은 엔지니어링 ‘일지’를 적도록 수련을 받았었다. 무엇을 했고 무엇을 배웠는지, 떠오르는 생각을 그 려본 것, 방금 읽은 계기판의 눈금 등 기본적으로 업무에 관한 건 무엇이든지 적었다. 수첩이 끝까지 가득 차면 책등에 수첩을 사용한 기간을 적은 후 선반 의 예전 수첩들 옆에 꽂아 놓았다
- 143p
기억보다 더 믿을 만하다
진행 중인 작업과 직접적인 관계가 없는 발상을 일단 쌓아 놓을 수 있는 곳이 생긴다
누군가에게 이야기를 하는 것과 비슷하다. 하던 일을 돌아보기에 알맞은 기회가 생기는 것이다. 메모를 시작하자마자 메모의 주제인 여러분이 방금 전까지 하던 일이 실 은 말도 안 된다는 것을 깨닫게 될 수도 있다.
수첩에다 뭘 적는다는 행위가 많은 이득을 가져다 준다.
처음 읽었을때는 내가 TIL을 작성하는 것과 완전히 같은게 아닌가라고 생각했지만 다시 이 문단을 읽어보면 다른 유형이라 생각하고 다른 이점이 있다.
🍋 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
확실히 앞 장들을 읽었을때는 클린코드와 겹치는 내용이 많아서 책에 대해 실망을 했지만 뒤로 갈수록 다르고 이 책이 주는것은 다른 내가 어디에서 주워들은적도 없는 개발자로서의 나를 만들어주는 역할, 나에게 더 자극을 주는 책이라 마음에 든다.
🧐 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
계약에 의한 설계 design-by-contract:
정확한 프로그램이란 스스로 자신이 하는 일이라고 주장하는 것보다 많거나 적지도 않게 딱 그만큼만 하는 프로그램을 말한다.
이러한 개념을 문서화하고 검증하는 것이 바로 DBC의 핵심
다중 처리 프라그마 multi-processing pragma : ?
이진 분할(이진 검색) binary chop : 정렬된 배열 내에서 대상 값의 위치를 찾는 검색 알고리즘 입니다.
이진 검색은 대상 값을 배열의 중간 요소와 비교합니다.
동일하지 않은 경우 목표가 놓일 수 없는 절반이 제거되고 나머지 절반에 대해 검색이 계속되며, 다시 중간 요소를 사용하여 목표 값과 비교하고 목표 값을 찾을 때까지 이를 반복합니다. 나머지 절반이 비어 있는 상태에서 검색이 끝나면 대상이 어레이에 없습니다.
분할 정복divide and conquer : 그대로 해결할 수 없는 문제를 작은 문제로 분할하여 문제를 해결하는 방법이다.
경계 조건 : 에러냐 아니냐의 경계가 되는 조건
경계 검사 : 주로 컴퓨터 보안과 관련하여 메모리 취약점 발생을 근본적으로 방지하는 목적으로 사용
