Community

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

← Go back
[TIL] Chapter 7. 코딩하는 동안
#pragmatic
2년 전
571

오늘 TIL 3줄 요약

  • 경험이 쌓이다 보면 본능적으로 코드에 이상함을 감지할 때가 있다. 이럴 때는 직감을 믿고 코드를 되돌아보자.

  • 우연에 맡기지 말고, "의도적으로" 코딩하라.

  • 기술이 발전할수록 보안에 신경 쓰자.

TIL (Today I Learned) 날짜

2022. 04. 02

오늘 읽은 범위

7장. 코딩하는 동안

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

  • 파충류와 이야기하는 법:

    • 뇌가 정리를 할 수 있도록 약간의 시간과 공간을 확보하라.

    • 문제를 표면으로 끄집어내라.

  • 위와 같은 방법을 시도해도 여전히 막혀있는 느낌이 든다면 프로토타이핑을 해보자.

  • 우리의 목소리에 귀를 기울여 주는 환경에 있다면 적극적으로 표현하라. 탐험하라. 어두운 출입구에 무언가가 숨어있을 것이다. 본능에 귀를 기울이고 문제가 여러분 앞에 튀어나오기 전에 미리 대처하라.

  • 가정하지 말라. 증명하라. 확고한 사실에 근거하지 않은 가정은 어떤 프로젝트에서든 재앙의 근원이 된다. (p286-287)

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

    1. 내가 지금 무엇을 하고 있는지 알자.

    2. 나보다 경험이 적은 프로그래머에게 코드를 상세히 설명할 수 없다면 우연에 기대고 있는 것이다. 내가 적은 코드라면 책임감을 갖고 완벽히 이해하도록 하라.

    3. 이것이 왜 동작하는지 잘 모른다면 왜 실패하는지도 알 리가 없다.

    4. 계획을 세우고 그것을 바탕으로 진행하자.

    5. 신뢰할 수 있는 것에만 기대라. 무언가를 신뢰할 수 있을지 판단하기 어렵다면 일단 최악의 상황을 가정하라.

    6. 가정을 기록으로 남겨라. 자신의 마음속에서 가정을 명확하게 하는 데 도움이 될 뿐더러, 다른 사람과 그에 대해 소통하는 데에도 도움이 된다.

    7. 노력을 기울일 대상의 우선순위를 정하라. 그리고 중요한 것에 먼저 시간을 투자해라.

    8. 기존 코드가 앞으로 짤 코드를 지배하도록 놓아두지 말라. 더는 적절한 코드가 아니다 싶으면 어떤 코드라도 교체할 수 있다. 한 프로그램 안에서도 예전에 한 일이 앞으로 할 일을 제약하지 못하도록 하라. 언제나 리팩터링할 자세가 되어 있어야 한다. 필요한 변경을 하지 않을 경우의 비용보다 일정이 늦어져서 발생하는 비용이 적어야 한다는 것을 염두에 두어라.

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

  • 이 때 밖으로 드러나는 동작이 바뀌지 않는다는 것을 보장하려면 코드의 동작을 검증하는 좋은 자동화된 단위 테스트가 필요하다. (p302)

  • 리팩터링을 하는 타이밍은 내가 무언가를 알게 되었을 때다. 무엇이든 '잘못'되었다는 생각이 들 때, 주저하지 말고 변경하라. (p302)

  • 일찍 리팩터링하고, 자주 리팩터링하라. 지금 리팩터링을 하지 않으면 일이 더 진척됐을 때 문제를 고쳐야 하고, 따라서 훨씬 더 많은 시간을 투자해야 한다. 일정에 리팩터링할 시간을 확실히 포함시켜 두도록 하라. (p304)

  • 손해보는 일 없도록 리팩터링 하는 법: (p305)

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

    2. 시작하기 전 든든한 테스트가 있는지 확인하라.

    3. 단계를 작게 나누어서 신중하게 작업하라.

  • 테스트의 주요한 이득은 테스트를 실행할 때가 아니라 테스트에 대해 생각하고, 테스트를 작성하는 과정에서 생긴다. (p308)

  • 상향식이나 하향식이 아니라 끝에서 끝까지 만들어라. 한쪽 끝과 다른 쪽 끝을 잇는 조그만 기능 조각들을 만들고, 그 과정에서 문제에 대하여 배워라. 코드를 채워나가면서 배운 것을 적용하고, 각 단계마다 고객을 참여시켜서 전체 과정을 안내하도록 하라. (p313)

  • 명백히 테스트는 개발을 이끌어 나가는 데 도움이 된다. 하지만 나아갈 때 마다 목적지를 떠올리지 않으면 계속 같은 자리만 빙빙 돌게 될 수도 있다. (p314)

  • 소프트웨어를 테스트하라. 그러지 않으면 사용자가 테스트하게 된다. 테스트는 프로그래밍의 일부이다. (p320)

  • 기본 보안 원칙: (p332~p338)

    1. 공격 표면을 최소화하라

    2. 최소 권한 원칙:
      최소한의 권한만을 꼭 필요한 시간만큼만 제일 짧게 부여하라.

    3. 안전한 기본값:
      사용자 기본 설정은 가장 안전한 값으로.

    4. 민감 정보를 암호화하라

    5. 보안 업데이트를 적용하라

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

  • '파충류와 이야기하는 법' 부분에서 '문제를 표면으로 끄집어내라' 라는 문장이 있었는데 이 부분에 깊은 공감을 했다. 누군가에게 문제를 설명을 하기 위해서는 현 상황을 논리정연하게 문장화하는 과정이 필요한데, 이 과정 안에서 원인 및 해결 방안을 깨닫게 되는 상황이 종종 있었다.

  • 테스트 주도 개발(TDD)이 중요하다는 것은 많이 듣는 얘기였지만 이 장을 읽고 왜 중요한지, TDD 맹신론자들이 빠지기 쉬운 함정은 어떤 것이 있는지까지 알게되어 새롭게 느껴졌다.

  • '의도적으로 프로그래밍하기'를 읽으면서 많이 공감되었고 반성도 하게 되었다. 잊어버리지 않게 매일 출근할 때 마다 읽으면 좋을 것 같다.