개발자 99% 커뮤니티에서 수다 떨어요!
오늘 TIL 3줄 요약
도구를 잘 활용하기 위해 노력하자. 그리고 기존 도구로 해결할 수 없는 문제를 발견했을 때 고집피우지 말자.
셸과 VCS를 적극 활용하자.
버그를 발견하면, 당황하기 보다는 문제와 해결책에 집중하자.
TIL (Today I Learned) 날짜
2022.03.23
오늘 읽은 범위
3장. 기본 도구
책에서 기억하고 싶은 내용을 써보세요.
도구는 여러분의 재능을 증폭한다. 도구가 더 훌륭하고 여러분이 더 사용법에 능숙해질수록 여러분의 생산성은 더 높아질 것이다. ...(중략)... 사용하는 도구로 다룰 수 없는 문제를 마주쳤다는 생각이 들면, 도움이 될 만한 뭔가 다른 것이나 더 강력한 것을 찾아보아야 한다는 것을 명심하라. - 104p
사람이 읽을 수 있는 형태의 데이터와 그 자체만으로 의미가 드러나는 데이터는 다른 어떤 형태의 데이터보다, 심지어 그 데이터를 생성한 애플리케이션보다 더 오래 살아남을 것이다. - 107p
다양한 시스템이 섞인 환경에서는 일반 텍스트의 장점이 다른 모든 단점을 보상하고도 남는다. 여러분은 모든 참가자가 하나의 공통 표준을 사용해서 소통하도록 해야 한다. 일반 텍스트가 바로 그 표준이다. -110p
텍스트 파일을 다루는 프로그래머에겐 명령어 셸이 작업대다. 셸 프롬프
트에서 모든 종류의 도구를 불러다 쓸 수 있다. - 111p
에디터를 몇 개 사용하든 상관없다. 다만 각각의 에디터에 유창해지도록 노력해야 한다. ...(중략)... 유창해지는 것의 가장 큰 이점은 더는 에디터 사용법을 생각하지 않아도 된다는 것이다. 뭔가를 생각하는 것에서 에디터 화면에 그게 뜰 때까지의 거리가 확 줄어든다. - 115p
무언가 같은 일을 반복하는 것을 발견할 때마다 이렇게 생각하는 습관을 들여라. ‘분명 더 나은 방법이 있을 텐데.’ 그리고 더 나은 방법이 있는지 찾아보라.
유용한 기능을 새로 찾았다면 이 기능을 여러분의 몸이 기억하도록 만들어야 한다. 그래야 반사적으로 사용할 수 있다. 우리가 아는 유일한 방법은 반복이다. - 116p
버전 관리 시스템은 일종의 거대한 ‘실행 취소’ 키와 같다. 프로젝트 전체에 걸쳐서 코드가 실제로 컴파일되고 실행되던 지난주의 평화로운 시절로 돌려줄 수 있는 타임머신이다. - 119p
혼자서 한 주짜리 프로젝트를 진행하는 경우일지라도, 나중에 ‘버리기로 한’ 프로토타입일지라도, 심지어 여러분이 작업하는 것이 소스 코드가 아닐지라도, 모든 것을 버전 관리 아래에 둬라. - 121p
디버깅은 단지 문제 풀이일 뿐이라는 사실을 받아들이고, 그런 마음으로 공략하라. - 126p
겉으로 드러난 특정한 증상만 고치려고 하지 말고, 항상 문제의 근본 원인을 찾으려고 노력 하라. - 128p
인공적인 테스트는 애플리케이션을 충분히 테스트하지 못한다. 경계 조건과 실제 최종 사용자의 사용 패턴 모두를 철저히 테스트해야 한다. 그것도 체계적으로 할 필요가 있다. - 129p
문제의 원인을 찾는 매우 단순하지만 꽤 유용한 기법으로 그냥 누군가에게 문제를 설명하는 방법이 있다. ...(중략)... 코드가 무엇을 해야 하는지 차근차근 설명해 나가는 단순한 행위 그 자체로 충분할 때가 많다. 그것만으로도 여러분이 찾고 있던 문제가 화면 밖으로 뛰쳐나와 모습을 드러낸다. -134p
예상치 못한 ‘놀라운’ 실패를 대면했을 때 자신이 세운 가정이 적어도 하나는 잘못되었다는 것을 받아들여야 한다. 버그와 관련된 루틴이나 코드가 제대로 작동하는 걸 ‘안다’고 해서 대충 얼버무리고 지나치지 말라. 그것을 증명하라. - 136p
무언가를 쓰기 위해 하던 일을 멈추면 여러분의 뇌도 기어를 바꾼다. 누군가에게 이야기를 하는 것과 비슷하다. 하던 일을 돌아보기에 알맞은 기회가 생기는 것이다. 메모를 시작하자마자 메모의 주제인 여러분이 방금 전까지 하던 일이 실은 말도 안 된다는 것을 깨닫게 될 수도 있다. - 143p
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
도구가 내 손의 연장선으로 여겨질 수 있을 만큼, 도구를 손에 익혀야 한다는 말이 인상적이었다. 책을 읽는 동안 내가 사용하고 있는 도구들을 100% 활용하고 있는가에 대해 끊임없이 스스로에게 되물었다. 극단적이기는 하지만 책에서 제시한 일주일 간 마우스, 트랙패드 없이 에디터를 써보라는 방법을 제시했는데, 이 방법이 도움이 될 수 있을 것 같다는 생각을 했다.
예전에 칼 세이건의 코스모스를 읽다가 인상 깊었던 구절을 마주했었는데, 정확한 문장이 기억나지는 않지만 책을 통해 지금 세상의 기반이 되었던 예전의 지식들을 들여다볼 수 있다는 식의 이야기였던 것 같다. 이번 챕터에서 계속해서 텍스트의 중요성이 강조되었는데, 그 중요성을 잘 설명해줄 수 있는 말인 것 같다. 마지막에 일지를 쓰는 것에 관한 이야기도 나왔는데, 다른 사람 혹은 미래의 나에게 도움이 될 수 있을지 모르니, 기록하는 습관을 가지기 위해 노력해야겠다는 생각이 들었다. 또한, 이해할 수 있는 텍스트의 중요성에 관한 이야기는 코드를 semantic하게 작성하는 것의 중요성을 다시금 상기시켜주었다.
예전부터 프로젝트를 하면서 깃의 가치를 몸소 느꼈기 때문에 VCS의 중요성에 관해 이야기하는 부분은 많이 공감이 되었으나, 셸에 관한 이야기는 크게 와닿는 부분이 많이 없었던 것 같다. 예전에는 그래도 터미널을 많이 활용했었는데, 다시 관심을 갖고 써보도록 노력해야겠다.
이번 챕터에서 디버깅과 관련된 이야기가 가장 크게 도움이 되었던 것 같다. 침착하게 대응하고, 핑계나 비난보다는 문제를 꿰뚫는데 집중하고, 자신을 너무 믿지 말라는 것. 알고는 있지만, 막상 버그를 마주하게 되면, 마음처럼 되지 않는 것 같다. 책에서 언급한 이야기들을 항상 명심해야겠다. 디버깅 기술에 관한 팁들도 인상적이었는데, binary search를 이용하는 방법이 특히 더 인상적이었다. 예전에 수업 들으면서 개념도 배우고, 연습문제도 풀어봤던 기억이 있는데, 그 뒤로 오랜만에 들은 것 같다. 배운 내용을 문제 해결에 접목하려 하는 시도는 항상 창의적인 생각으로 귀결되는 것 같다. 어떤 것을 배우면, 응용할 수 있는 다른 경로에 관해 생각하는 습관을 가지자.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
레거시 시스템 (Legacy System) : 낡은 기술이나 방법론, 소프트웨어 등을 이르는 말로, 현대까지도 남아 쓰이는 기술뿐만 아니라 더 이상 쓰지 않더라도 현대의 기술에 영향을 주는 경우도 포함한다. (참고 : https://limkydev.tistory.com/217)
회귀 테스트 (Regression Test) : 수정 혹은 기능 추가에 의해 기존 소프트웨어에 새로 유입된 오류가 있는지 확인하는 테스트 (참고 : https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=anto949&logNo=221536117653)
오늘 읽은 다른사람의 TIL
shuttle님의 TIL (https://nomadcoders.co/community/thread/3868)