실용주의 프로그래머 TIL 10일차

최정환·2022년 4월 2일
북클럽
0

pragmatic-programmer

목록 보기
10/13

TIL (Today I Learned)

2022.04.01 ~ 04.02

오늘 읽은 범위

7장.코딩하는 동안

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

  • 274p

    적극적으로 자기 코드에 대해 생각하지 않는 프로그래머는 우연에 맡기는 프로그래밍을 하는 것이다

    최근 프로젝트를 하면서 내가 짜는 코드가 제대로 된 코드가 맞나 생각하는지보다 '일단 구현해보자'가 더 큰 영향을 주면서 작성하고 있는 것같다

    물론 지금은 기능을 어떻게 만들지 프로토타입을 만드는 중이라 이런생각이 좀 더 강하게 드는건지 모르겠지만 전부터 약간 이런생각이 드는 중이라 공감이 되었다.

  • p275

    오직 인간만이 무언가를 직접 보고, 정확한 예측에 필요한 모든 정보를 획득하고, 심지어 순간적으로는 정확한 예측을 한 후에도, 그런데 그것이 아니라고 말할 수 있다.

    개빈 드 베커(Gavin de Becker),《서늘한 신호(The Gift of Fear)》

  • 277p

    어떤 작업을 앞두고 마음 속에 의심이 계속 남아 있거나 왠지 꺼림칙하다면, 여러분의 경험이 여러분 에게 말을 거는 중일지도 모른다.
    그 느낌을 따라라. 어떤 것이 문제라고 정 확하게 짚지는 못하더라도, 시간을 좀 주면 여러분의 의심은 아마도 좀 더 실체가 있고 대응책을 생각할 수 있는 무엇으로 구체화될 것이다.
    직감이 여러분의 역량에 일조하도록 하라.

    내가 배우는 것들은 지식이 되어 쌓일거라고 생각했고 항상 어떤것을 설명하려고 할때는 생각이 잘 나지 않고 설명을 할 방법을 찾지 못해서 불안했다.
    하지만 이 글을 보고 나서 내가 지식을 꼼꼼하게 쌓진 않았어도 직감은 제대로 기르고 있구나 하고 약간은 안심을 하게 되었다.

  • 278p

    하지만 전문가라면 여러분은 계속해 나가야 하지 않을까? 진흙 묻은 발을 끌고 또 한 발을 내디뎌서 여러분에게 맡겨진 일을 해야 마땅하지 않을까? 안타깝지만 진짜로 여러분이 해야 하는 일은 정반대다.

    만약 내가 잘못됐다고 생각해도 계속 나아가기 보다 이 방법이 진짜로 맞나 다시 한번 생각해보고 길을 다시 찾는다는게 중요하다는 것을 배우게 되었다.

    나도 코드가 작동하지 않을때 계속 한방향으로 생각하며 앓고 있으면 끝까지 되지 않고 한숨 돌리고 나중에 다시 보면 다른 방법으로 풀 수 있었던 경험이 있어 바로 말의 뜻을 이해하게 되었다.

  • 280p

    1. 포스트잇에 “프로토타이핑중” 이라고 써서 모니터 옆에 붙여라.
    2. 프로토타이핑은 원래 실패한다고 자신에게 상기시켜라.실패하지않더라도 프로토타입은 버리는 것이라는 점도 함께 상기시켜야 한다. 프로토타
      이핑으로 손해 볼 일은 없다.
    3. 텅빈 에디터화면에 여러분이 배우고 싶은것 혹은 하고 싶은것을 한 문
      장의 주석으로 표현해 보라.
    4. 코딩을 시작하라.

    프로토타입을 작성할때 자기 자신을 상기시키고 마인드 컨트롤을 하는게 좋겠다고 생각했다. 부담이 없다면 두려운것은 없다.

  • 288p 의도적으로 프로그래밍 하기

    • 언제나 여러분이 지금 무엇을 하고 있는지 알아야 한다.
    • 더 경험이 적은 프로그래머에게 코드를 상세히 설명할 수 있는가?
    • 자신도 잘 모르는 코드를 만들지 말라.
    • 계획을 세우고 그것을 바탕으로 진행하라
    • 신뢰할 수 있는 것에만 기대라. 가정에 의존하지 말라. 무언가를 신뢰할 수 있을지 판단하기 어렵다면 일단 최악의 상황을 가정하라. 그리고 가정을 기록으로 남겨라
    • 코드뿐 아니라 여러분이 세운 가정도 테스트해 보아야 한다. 어떤 일이든 추측만 하지 말고 실제로 시험해 보라.
      단정문을 작성하라
    • 노력을 기울일 대상의 우선순위를 정하라. 중요한 것에 먼저 시간을 투자 하라.
    • 더는 적절한 코드가 아니다 싶으면 어떤 코드라도 교체할 수 있다

  • 292p

    O() 표기법은 우리가 측정하는 값―시간, 메모리 등―의 상한을 기술하는 표기법이다.
    예를 들어 어떤 함수가 O(n2) 시간이 걸린다고 하면, 이 말은 이 함수가 실행되는 데 걸리는 시간의 최댓값이 n2보다 더 빨리 늘어나지 않는 다는 뜻이다.

    • 단순 반복문 하나가 1부터 n까지 돌아간다면 이 알고리즘은 O(n)일 가능성이 크다. 즉, 수행 시간은 n에 비례해서 증가한다

    • 반복문 안에 또 반복문이 들어 있다면, 알고리즘은 O(m×n)이 되며, 여 기서 m과 n은 두 반복문의 반복 횟수다

    • 반복문을 돌 때마다 작업 대상의 수를 반으로 줄여 나가는 알고리즘이라 면 로그적 알고리즘, 즉 O(lgn)이 될 가능성이 크다 (이진 탐색)

    • 입력 데이터를 둘로 나눠서 각각 독립적으로 작업한 다음, 결과를 합치는 알고리즘은 O(nlgn)일 수 있다

    • 알고리즘이 항목의 순열permutation을 다루기 시작하면 대부분의 경우 수행 시간은 걷잡을 수 없이 늘어난다.
      순열에는 계승factorial이 따라오기 때문이다.

숫자가 외부 요인에 따라 달라진다면(어젯밤 일괄 작업에서 처리된 레코드의 수나, 명단 에 있는 이름 개수 등) 잠시 작업을 멈추고 커다란 수가 들어왔을 경우 수행 시간이나 메모리 소모에 어떤 영향을 미칠지 생각해 보는 것이 좋다.

알고리즘에 대해 다시 얕게 상기시켜줄 페이지들이었다.
시간에 대해서 생각하는 것은 비동기처리를 해줄때만 생각했었는데 ux를 위한다면 확실히 메모리 소모와 수행시간이 중요한점이 될것같다.

  • 301p

    리팩토링이란 밖으로 드러나는 동작은 그대로 유지한 채 내부 구조를 변경함으로써 이미 존재하는 코드를 재구성하는 체계적 기법


    1. 이 활동은 체계적이다.아무렇게나 하는 것이 아니다.
    2. 밖으로 드러나는 동작은 바뀌지않는다. 기능을 추가하는 작업이 아니다.

    리팩토링을 해야하는 시기는 따로 정해져있지 않다.

    코드가 더는 잘 맞지 않아서 장애물에 부딪혔을 때, 두 가지가 사실 은 하나로 합쳐져 있어야 한다는 것을 발견했을 때, 무엇이든 ‘잘못’되었다는 생각이 들 때가 있을 것이다. 주저하지 말고 변경하라. 언제나 바로 지금이 최적기다. 코드를 리팩터링할 이유는 아주 많다.

  • 305p 리팩터링의 본질은 재설계다.

    1. 리팩터링과 기능추가를 동시에 하지말라.

    2. 리팩터링을 시작하기 전 든든한 테스트가 있는지 먼저 확인하라. 할 수
      있는 한 자주 테스트를 돌려 보라.
      이렇게 하면 여러분이 바꾼 것 때문에 무언가 망가졌을 경우 그 사실을 재빨리 알 수 있다.

    3. 단계를 작게 나누어서 신중하게 작업하라.
      클래스의 필드하나를 다른클래스로 옮기기, 메서드 하나 쪼개기, 변수명 하나 바꾸기 같이 작은 단위로 작업해야 한다.
      리팩터링에서는 국지적인 변경들이 많이 모여서 커다 란 규모의 변화를 낳는 일이 자주 발생한다.
      단계를 작게 나누고, 한 단계 가 끝날 때마다 테스트를 돌린다면 기나긴 디버깅 작업을 피할 수 있다.

  • 309p

    테스트가 코드의 첫 번째 사용자다.

    코딩을 시작하기 전에 경계 조건의 테스트와 경계 조건에서 어떻게 동작해야 하는지를 먼저 생각해 본다면, 아마 함수를 단순하게 만드는 코드 패턴을 찾을 수 있을 것이다.

    아직 테스트를 어떻게 작성해야할지 모르지만 이 문장이 엄청 마음에 들었다. '테스트가 코드의 첫 번째 사용자다.'

  • 310p TDD(테스트가 주도가 되어 개발)

    1. 추가하고싶은작은기능하나를결정한다.
      1. 그 기능이 구현되었을때 통과하게 될 테스트를 하나 작성한다.
      2. 테스트를 실행한다. 다른테스트는 통과하고 방금 추가한 테스트 딱 하나
        만 실패해야 한다.
      3. 실패하는 테스트를 통과시킬 수 있는 최소한의 코드만 작성한다. 그리고
        이제는 모든 테스트가 통과하는지 확인한다.
      4. 코드를 리팩터링한다. 방금 작성한 테스트나 함수를 개선할 수 있는 부분
        이 없는지 살펴본다. 개선한 후에도 테스트가 계속 통과하는지 확인한다.

    이 발상의 핵심은 이 반복 주기가 몇 분정도로 매우 짧아야한다. 따라서 끊임없이 테스트 작성과 테스트를 통과하게 만들기를 반복하게 된다.
    그리고 중요한 점은 항상 테스트에 너무 깊게 빠지지 말고 코드를 작성하는 진짜 이유 즉, 큰 그림을 항상 신경을 써야한다.

  • 320p

    테스트, 설계, 코딩, 이 모든 것이 프로그래밍이다.

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

마음에 드는 글귀가 많았던거 같다.
지금 하고 있는 프로젝트를 할때에도 적용하면 좋을거 같은것들을 많이 배웠고 리팩토링과 테스트에선 양심이 찔릴때도 있었다.

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

제약 조건 전파constraint pro- pagation : 알아낸 답의 일부와 문제의 조건을 바탕으로 가능한 답의 범위를 점점 좁혀 나가는 방식이다

profile
최정환
이전 포스트

실용주의 프로그래머 TIL 9일차

다음 포스트

실용주의 프로그래머 12일차

0개의 댓글