Community

개발자 99% 커뮤니티에서 수다 떨어요!

← Go back
3장 기본 도구
#pragmatic
2년 전
437

오늘 TIL 3줄 요약

  • 지식을 표현할 최고의 포멧은 일반 텍스트는 사람이 이해할 수 있어야 한다.

  • 쉘 스크립트, 에디터 가지고 놀수 있을 정도가 되라

  • 버전 관리, 디버깅 도구를 활용하여 개발 생산성을 높이라

TIL (Today I Learned) 날짜

2022. 03. 23

오늘 읽은 범위

3장. 기본 도구

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

  • Topic 16 일반 텍스트의 힘

    • 우리가 수집하는 요구사항은 지식

    • 지식을 설계와 구현, 테스트, 문서로 표현

    • 최고의 포맷은 일반 텍스트

    • 일반 텍스트는 사람이 이해 할 수 있어야 한다.

      • 형식이 없는 텍스트를 의미하는 것이 아니다

      • HTML, JSON, YAML, 모두 일반 텍스트이다.

    • 일반 텍스트의 3가지 이유

      • 지원 중단에 대한 보험

      • 기존 도구의 활용

      • 더 쉬운 테스트

  • Topic 17 셀 가지고 놀기

    • 텍스트 파일을 다루는 프로그래머에겐 명령어 셸이 작업대다.

    • 셸이 실행 할 수 있는 목록

      • 응용 프로그램, 디버거, 브라우저, 에디터, 유틸리티

      • 파일을 검색 , 시스템의 상태를 조회, 출력을 필터링

      • 매크로 명령을 만들 수도 있다.

    • GUI의 장점은 WYSIWYG(What you see is what you get)
      단점은 WYSIAYG(What you see is all you get)

      • 설계자가 의도한 범위를 넘어설 수 없다.

  • Topic 18 파워 에디팅

    • 에디터를 유창하게 쓸 수 있게 하라

      • 유용한 기능을 새로 찾았다면 이 기능을 여러분의 몸이 기억하도록 만들어야 한다.

      • 사용 중인 에디터에서 명맥한 한계에 봉착한다면 필요한 기능을 추가하는 확장 기능을 찾아보라.

      • 여러분이 늘 하는 반복적인 일을 자동화할 방법을 연구해 보라.
        (한 두줄 만으로 가능한 경우가 많다.)

  • Topic 19 버전 관리

    • 버전 관리 시스템은 일종의 거대한`실행 취소`키와 같다.

    • 소스 코드나 문서의 모든 변경 사항을 기억한다.

  • Topic 20 디버깅

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

    • 디버깅을 시작하기에 앞서 올바를 마음가짐이 중요하다. "당황하지 말라"

    • 표면에 보이는 증상만을 고치려는 욕구를 이겨내라. 특정한 증상만 고치려 하지말고, 항상 문제의 근본 원인을 찾으려고 노력하라

    • 디버깅의 전략

      • 버그 재현하기 - 코드를 고치기 전 실패하는 테스트부터

      • 이상한 결과 - 옆에 종이와 펜을 가져다 두고 메모를 하면 도움이 될때가 많다.

      • 입력 값에 따라 바뀜 - 데이터 세트를 복사한 다음 이진분할을 활용하여 어떤 입력인 범인인지 찾기

      • 로깅과 트레이싱

      • 고무 오리 -그냥 누군가에게 문제를 설명하는 방법(들어줄 사람이 없다면 고무 오리나 곰 인형 화분도 괜찮다?!)

      • 소거법

  • Topic 21 텍스트 처리

    • 텍스트 처리 언어로 이를 처리한다면 엄청나게 많은 이점을 누릴 수 있다.

  • Topic 22 엔지니어링 일지

    • 그들은 엔지니어링 '일지'를 적도록 수련을 받았다

    • 무엇을 했고, 무엇을 배웠는지, 떠오르는 생각을 그려본 것, 업무에 관한 건 무엇이든지 적었다.

    • 수첩이 끝까지 가득 차면 책등에 수첩을 사용 기간을 적은 후 선반에 꽂아 넣었다.

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

  • Topic 16 일반 텍스트의 힘
    회사에서의 텍스트의 힘은 생각보다 어마어마하다. 새로운 기능을 추가가하거나 유틸을 추가하거나 배포를 하거나 모든 것들은 일반 텍스트로 전달하고 승인받는다. 지금도 나는 일반 텍스트를 이용하여 지식을 정리하고 있다. 하지만 이 일반 텍스트를 사람이 이해하지 못하게 쓰는 경우가 많다. 어떤 기능을 추가해야하는데 왜 추가해야하는지, 이해할수 있어야한다. 읽을 수 있다고 일반 텍스트가 아니다. 반드시 힘이 있는 일반 텍스트가 되려면 사람이 이해하기 쉬워야한다.
    지금 내글 읽기 쉬운 텍스트일까? 사람이 이해하기 쉬운 택스트일까?

  • Topic 17 셸 가지고 놀기
    따르릉. "이거 수정된거 맞아요?" QA담당자 분으로 부터 연락이 왔다. 어라라 나는 방금 수정해서 분명히 서버에 올렸다. 머지 서버에 제대로 올라가 있는지 확인부터 해보자.


    ssh dev1 ; sudo -uroot bash ; cd /static/ ; vi main.js
    빌드된 main.js 파일이 열린다. 내가 수정한 글자가 있는지 스크롤 하며 찾아본다. QA 담당자 분은 언제 확인 되냐고 전화가 계속온다. 아 X됬다. 내가 쉘 스크립트를 좀만이라도 잘 알았다면 grep을 활용해 내가 수정한 변수가 들어갔는지만 확인할수 있었어도 금방 해결되었을 텐데.
    나는 프론트엔드 개발자니까 서버는 잘 몰라도되 하며 매번 셸스크립트를 모른척하고 살았다. 하지만 셸 스크립트를 잘 다룰수 있다면 더 나은 개발자가 될수 있다는 것을 확신했다.

  • Topic 20 디버깅


    유저 게시판에 오류가 올라왔다. 특정 a기능이 간헐적으로 동작한다는 이슈였다. 열심히 디버깅을 하고 있었는데. 오류가 수정되었다고 연락왔다. 실장님이 수정해서 올렸다고 한다. 실장님이 가지고 있던 디버깅 비밀은 무엇이였을까? 어떻게 문제를 빨리 찾을수 있었을까? 실장님께 물어보니 대강 여기서 문제가 있을거 같아서 돌려보니까 안됬다고 했다.(생각보다 별거 없었다) 놀랍게도 실장님은 어느 부분에서 실패가 일어나는지 정확하게 알고 계셨다. 디버깅의 본질은 어디서 실패하는지를 누가 빨리 정확하게 찾아내는지가 매우 중요하다는 것을 다시금 느꼈다. 디버깅의 방법들에 대해서도 숙지해 놓는것도 필요하다고 생각되었다.

  • Topic 22 엔지니어링 일지


    엔지니어링 일지의 중요성은 말로 하지 않아도 안다. 책을 보고 다시한번 작성해야함을 느꼈다.
    이런 일이 있었다. 갑자기 특정 페이지에서 결재가 되지 않는 문제가 있었다. 문제의 원인으로 몇몇이 용의선상에 올랐다. 그중에 나도 있었다. 본부장님으로 부터 연락이 왔다. "let testest 이거 왜넣었어요?"라고 물어보셨는데. '머지??' 기억이 도저히 안난다. '내가 저걸 넣었었나?' 멘붕이 온다. 이것저것 물어보는데 정확하게 대답을 할수 없었다. 기억이 안났기 때문이다. 너무 비참했다. 그 이후부터 일지를 적고 있지만, 근래에 다시 안적고 있었다.ㅋㅋ 이러다 큰일나겠다. 내일부터 써야지 ㅋㅋ

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

오늘 읽은 다른사람의 TIL