개발자 99% 커뮤니티에서 수다 떨어요!
코로나에 걸렸어서 제출을 못했었는데 늦게라도 작성해봅니다!
오늘 TIL 3줄 요약
프로그래머가 코딩하는 동안 더 적극적으로 행동하는 방법
여러분의 본능과 무의식적인 생각을 더 잘 활용해라
테스트를 수행함에 있어서 나타나는 긍정적인 효과
TIL (Today I Learned) 날짜
2022. 04. 06
오늘 읽은 범위
7장. 코딩하는 동안
책에서 기억하고 싶은 내용을 써보세요.
여러분의 본능과 무의식적인 생각을 더 잘 활용해라
직감이 여러분의 역략에 일조하도록 하라.
여러분 내면의 파충류에게 귀 기울여라.
일단, 하고 있는 일을 멈춰라. 여러분의 뇌가 정리를 좀 할 수 있도록 약간의 시간과 공간을 확보해라. 코드에 대해 생각하지 말고 키보드에서 떨어져서 잠깐 머리를 비운 채로 할 수 있는 일을 하라. 산책을 하고 점심을 먹고 다른 사람과 수다를 떨어라. 아예 하룻밤 자면서 생각을 해봐도 된다. 생각이 저절로 여러분의 뇌 층층이 스며들도록 놔둬라.
여러분이 이런 방법들을 시도해 보았는데도 여전히 막혀 있을 수도 있다. 여러분의 뇌에게 여러분이 하려는 일은 별 문제가 없다고 알려줘야한다. 바로 프로토타이핑을 하면 된다.
프로토 타이핑 하는 방법
1. 포스트잇에 "프로토타이핑 중"이라고 써서 모니터 옆에 붙여라.
2.프로토타이핑은 원래 실패한다고 자신에게 상기시켜라. 실패하지 않더라도 프로토타입은 버리는 것이라는 점도 함께 상기 시켜야한다. 프로토 타이핑으로 손해 볼 일은 없다.
3. 텅 빈 에디터 화면에 여러분이 배우고 싶은 것 혹은 하고 싶은 것을 한 문장의 주석으로 표현해 보라.
4. 코딩을 시작하라.
의심이 들기 시작하면 포스트잇을 보라
직감에 귀 기울이는 방법은 계속 갈고닦아야 할 중요한 기술이다. 가끔은 설계가 왠지 이상하게 느껴질 수 있고, 어떤 요구 사항이 마음을 불편하게 할 수도 있다. 하던 일을 멈추고 그 느낌을 분석하라.
프로그래머가 코딩하는 동안 더 적극적으로 행동하는 방법
우리는 우연에 맡기는 프로그래밍, 곧 행운과 우연한 성공에 의존하는 프로그래밍을 하지 않아야 한다. 대신 '의도적으로 프로그래밍 해야 한다.'
다른 사람이 호출할 코드를 작성하고 있다면 모듈화를 잘하는 것, 그리고 잘 문서화한 적은 수의 인터페이스 아래에 구현을 숨기는 것 같은 기본 원칙들이 모두 도움이 된다.
잘 되는 듯한 답을 찾는 것과 올바른 답을 찾는 것은 다르다.
우연에 맡기는 프로그래밍을 하지 말라.
우리는 코드를 마구 찍어 내는 데에 드는 시간을 줄이고 싶고, 또 가능한 한 개발 주기 초기에 오류를 잡아서 고치고 싶고, 애초부터 오류를 더 적게 만들고 싶어 한다. 그러려면 의도적으로 프로그래밍해야 한다.
필요한 변경을 하지 않을 경우의 비용보다 일정이 늦어져서 발생하는 비용이 적어야 한다는 것을 염두에 두어라.
앞으로는 어떤 것이 잘 돌아가는 듯이 보이기는 하는데 여러분이 그 이유를 모를 경우, 그것이 우연은 아닌지 반드시 확인하라.
성능 문제가 발생하기 전 미리 잠재적인 문제점을 찾아내는 방법
사용하는 알고리즘의 차수를 추정하라.
O(n2)알고리즘이 있다면 분할 정복을 사용하여 O(n log n)으로 줄일 수 없는지 시도해 보라.
코드의 실행 시간이 얼마나 될지 또는 메모리를 얼마나 사용할지 확실하지 않다면 직접 실행해 보라.
성급한 최적화를 조심하라. 언제나 어떤 알고리즘을 개선하느라 여러분의 귀중한 시간을 투자하기 전에 그 알고리즘이 정말로 병목인지 먼저 확인하는 것이 좋다.
프로젝트를 진행하면서도 끊임없이 기존 코드를 개선할 수 있는 방법
코드는 정적인 존재가 아니다. 코드는 발전해야 한다.
코드 고쳐쓰기, 다시 작업하기, 다시 아키텍쳐 만들기는 모두 아울러서 '재구성(리팩토링)'이라고 부른다.
이 정의에서 핵심적인 부분은 다음 두 가지다.
1. 이 활동은 체계적이다. 아무렇게나 하는 것이 아니다.
2. 밖으로 드러나는 동작은 바뀌지 않는다. 기능을 추가하는 작업이 아니다.
정리하자면 정확한 목적을 가지고 정밀하게 접근하는 활동이다. 그래서 코드를 바꾸기 쉽게 유지하는 것이다.
리팩터링은 언제 하는가 ? 여러분이 작년이나 어제, 심지어 10분 전과 비교해서 더 많이 알게 되었다면, 리팩터링을 한다. 주저하지 말고 변경하라. 언제나 바로 지금이 최적기다. 리팩터링을 할 이유는 아주 많다.
언제해야할까?
중복 - DRY 원칙 위반을 발견했다.
직교적이지 않은 설계 - 더 직교적으로 바꿀 수 있는 무언가를 발견했다.
더 이상 유효하지 않은 지식 등이 있겠다.
일찍 리팩터링하고, 자주 리팩터링하라.
코드 한 부분 때문에 '리팩터링만 하는 일주일'이 필요해서는 안 된다. 그건 완전 재작성이다. 만약 이 정도로 시간이 많이 필요하다면 즉시 해치울 수 없는 것도 당연하다. 그 대신 일정에 리팩터링할 시간을 확실히 포함시켜 두도록 하라. 그 코드를 사용하는 사람들이 코드가 조만간 재작성 될 것이라는 사실과 재작성이 그들의 코드에 미칠 영향을 인지하도록 해야 한다.
리팩터링은 천천히, 신중하게, 조심스럽게 진행해야 하는 작업이다.
1. 리팩터링과 기능 추가를 동시에 하지 말라.
2. 리팩터링을 시작하기 전 든든한 테스트가 있는지 먼저 확인하라.
3. 단계를 작게 나누어서 신중하게 작업하라.
테스트를 수행함에 있어서 나타나는 긍정적인 효과
테스트는 버그를 찾기 위한 것이 아니다. 우리는 테스트의 주요한 이득이 테스트를 실행할 때가 아니라 테스트에 대해 생각하고, 테스트를 작성할 때 생긴다고 믿는다.
테스트가 코드의 첫 번째 사용자다. 이것이 테스트가 주는 가장 큰 이득일지 모른다. 테스트는 우리의 코딩을 인도하는 필수 피드백이다.
테스트 주도 개발(test driven development,TDD) 의 기본 주기는 다음과 같다.
1. 추가하고 싶은 작은 기능 하나를 결정한다.
2. 그 기능이 구현되었을 때 통과하게 될 테스트를 하나 작성한다.
3. 테스트를 실행한다. 다른 테스트는 통과하고 방금 추가한 테스트 딱 하나만 실패해야 한다.
4. 실패하는 테스트를 통과시킬 수 있는 최소한의 코드만 작성한다.
5. 코드를 리팩터링한다.
어떻게는 TDD를 실천하라. 하지만 도중에 이따금 멈추어 큰 그림을 살피는 것을 잊지 말라.
소프트웨어 단위 테스트란 어떤 모듈에게 이것저것을 시켜보는 코드를 가르킨다. 일반적으로 단위 테스는 일종의 인위적인 환경을 구축한 다음, 테스트할 모듈의 루틴들을 호출한다.
우리는 단위 테스트를 계약을 잘 지키는지 보는 테스트라고 여긴다.
테스트할 수 있도록 설계하라.
여러분의 소프트웨어를 테스트하라. 그러지 않으면 사용자가 테스트하게 된다.
테스트, 설계, 코딩, 이 모든 것이 프로그래밍이다.
버그가 일어났을 때 어떻게 대처해야 하는 지
코드에 존재하는 계약과 불변식을 뭉뚱그려서 '속성'이라고 부른다. 코드에서 속성을 찾아내서 테스트 자동화에 사용할 수 있는데, 이것을 '속성 기반 테스트'라 한다.
속성 기반 테스트로 가정을 검증하라.
우리는 속성 기반 테스트가 단위 테스트를 보완한다고 믿는다. 둘은 서로 다른 문제를 해결하고 각각의 장점이 있다.
읽고 분석하기 쉬운 코드를 쓰는 방법 , 보안에 관하여
코드 복잡성은 공격 매개채를 유발한다.
입력 데이터는 공격 매개체다.
단순함을 유지하고 공격 표면을 최소화하라.
최소환의 권한만을 꼭 필요한 시간만큼만 제일 짧게 부여하라는 게 또 다른 핵심 원칙이다.
보안 패치를 신속히 적용하라.
특별한 조합 규칙을 도입하지 말라. 예를 들어 대문자와 소문자 , 숫자와 특수문자를 반드시 섞어서 써야 한다거나 반복되는 문자는 쓰면 안된다거나 하는 식으로 강제하지 말라. (조합을 강제하는 경우 사람들은 맨 끝에 특수문자를 붙이는 등("1!@") 예측이 쉬운 형태로 비밀번호를 만들거나, 아니면 외우기 힘든 복잡한 비밀번호를 만든 후 종이 등에 적어서 보관함으로써 오히려 보안에 취약해지는 경우가 더 많다고 한다.
우리는 많은 것들의 이름을 지어야 하는데 코딩하는 동안 이름의 의미가 변하지 않는 지 감시해야 한다.
이름을 명확하게 짓는 작업이 여러분의 코드를 작성할 때 코드를 더 잘 이해할 수 있도록 도울 것이다.
잘못된 이름을 바꿔라. 이름을 바꾸기 쉽게 만들고, 자주 이름을 바꿔라.
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
7장의 분량이 되게 많았는데 그 이유는 책의 제목처럼 실용주의 프로그래머가 되는 방법을 많이 소개했기 때문인 것 같습니다. 각 파트별로 배운 점이 많았고 코드를 작성할 때나 문제 해결을 할 때 책에서 소개해준 방법을 사용해보고자 합니다.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
속성 기반 테스트가 아직 테스트가 익숙하지 않다 보니 어려웠습니다.
오늘 읽은 다른 사람의 TIL