3 주차
금, 토 | Assignment #12
7장. 코딩하는 동안
📘 책에서 기억하고 싶은 내용
- 개요 (p.273)
- 프로젝트가 실패하는 가장 큰 원인은 설계 내용을 컴퓨터가 실행할 수 있는 문장으로 바꾸는 일만 하면 된다는 생각이다.
- 적극적으로 자기 코드에 대해 생각하지 않는 프로그래머는 우연에 맡기는 프로그래밍을 하는 것이다.
- 파충류의 뇌에 귀 기울이기 (p.275)
- 파충류의 뇌 = 동물적인 본능
- 코딩이 평소와 다르게 오르막길과도 같다면 지금 하는 작업이 필요 이상으로 어떤 원인으로 인하여 힘들어지고 있는 것일수도 있다.
- 휴식 및 동료에게 설명하는 방법으로 해결되지 않는다면 프로토타이핑을 시도해봐라.
- 이때, 꺼림칙했던 느낌이 코딩 도중에 갑자기 명확한 문제로 구체화되면 즉각 해결하라.
- 우연에 맡기는 프로그래밍 (p.282)
- 우리는 행운과 우연한 성공에 의존하는 프로그래밍이 아닌
의도적으로 하는 프로그래밍 을 해야 한다.
- 왜 코드가 망가졌는지 모르는 까닭은 애초에 코드가 왜 잘 돌아갔는지도 몰랐기 때문이다.
- 문서화된 동작에만 의존하라, 그럴 수 없다면 추측을 문서로 상세히 남겨라.
- 가정하지 말라. 증명하라.
- 인터넷 검색으로 찾은 첫 번째 답에서 코드를 복사해 올 때 여러분과 동일한 상황이라고 확신하는가?
아니면 의미는 신경쓰지 않고 그냥 따라 하는 "화물 숭배" 코드를 만들고 있나?
- 잘 되는 듯한 답을 찾는 것과 올바른 답을 찾는 것은 다르다.
- 확고한 사실에 근거하지 않은 가정은 어떤 프로젝트에서든 재앙의 근원이 된다.
- 코드뿐 아니라 내가 세운 가정도 테스트해 보아야 한다. 어떤 일이든 추측만 하지 말고 실제로 시험해 보라.
- 기존 코드가 앞으로 짤 코드를 지배하도록 놓아두지 말라.
더는 적절한 코드가 아니다 싶으면 어떤 코드라도 교체할 수 있다.
언제나 리팩토링할 자세가 되어 있어야 한다.
- 알고리즘의 속도 (p.291)
- 코드의 실행 시간이 얼마나 될지 또는 메모리를 얼마나 사용할지 확실하지 않다면 직접 실행해보라.
- 정확하게 시간을 재는 일이 어렵다면
코드 프로파일러 를 사용하여 알고리즘이 돌아갈 때 각 단계의 실행 횟수를 센 다음 입력값 크기별 실행 횟수를 그래프로 그려 보라.
- 가장 빠른 알고리즘이 언제나 가장 좋은 알고리즘은 아니다.
- "성급한 최적화"를 조심하라.
시간 투자 전 그 알고리즘이 정말로 병목인지 먼저 확인하는 것이 좋다.
- 리팩토링 (p.300)
- 소프트웨어 개발은 "건축"보다 "정원 가꾸기"에 가깝다. (유기적인 활동)
- 리팩토링은 잡초 제거나 갈퀴질처럼 위험하지 않은 작은 단계들을 밟는 일상 활동이다.
- 소스 코드를 이곳저곳 변경하는 것은 굉장히 고통스러운 작업일 수도 있다.
많은 개발자들이 코드에 조금 개선할 부분이 있다는 이유만으로는 다시 돌아가서 코드 열기를 주저한다.
- 일정의 압박은 리팩토링을 하지 않는 단골 핑계다.
- 일찍 리팩토링하고, 자주 리팩토링하라. (단, 리팩토링할 시간을 일정에 확실히 포함해야 한다.)
- 리팩토링의 본질은 재설계다.
- 리팩토링과 기능 추가를 동시에 하지 말라.
- 리팩토링을 시작하기 전 테스트가 있는지 먼저 확인하라.
- 단계를 작게 나누어서 신중하게 작업하라.
- 기대하는 수준에 못 미치는 코드를 발견하면, 고쳐라. 고통을 관리하라.
지금은 고통스러울지라도 앞으로 더욱 고통스러워질 것 같으면 지금 고치는 편이 낫다.
- 테스트로 코딩하기 (p.307)
- 테스트는 버그를 찾기 위한 것이 아니다.
- 테스트가 코드의 첫 번째 사용자다.
- 명백한 테스트는 개발을 이끌어 나가는 데 도움이 된다.
하지만 나아갈 때마다 목적지를 떠올리지 않으면 계속 같은 자리만 빙빙 돌게 될 수도 있다.
- 단위 테스트를 계약을 잘 지키는지 보는 테스트로 생각해야 한다.
- 코드가 계약을 지키는지 확인
- 코드로 표현된 계약의 의미가 우리가 생각한 것과 일치하는지 여부 확인
- 테스트할 수 있도록 설계하라.
- 로그 메시지는 반드시 규칙적이고 일고나된 형식이어야 한다.
프로그램의 처리 시간이나 프로그램이 택한 논리 경로를 추론하기 위해 로그를 자동으로 파싱하고 싶을 때가 있기 때문이다.
- 테스트 코드를 다른 제품 코드와 마찬가지로 다뤄라. 결합도를 낮추고, 깨끗하고 견고하게 유지하라.
- 테스트, 설계, 코딩, 이 모든 것이 프로그래밍이다.
- 속성 기반 테스트 (p.321)
- 속성 : 코드에 존재하는 계약과 불변식
- 속성 기반 테스트 : 코드에서 속성을 찾아내 자동화한 테스트
- 역할
- 문제가 발생하는 상황에 집중할 수 있게 해줌
- 회귀 테스트
- 속성 기반 테스트가 실패했다면 테스트 함수가 어떤 매개 변수를 사용했는지 알아낸 다음 그 값을 이용하여 별도의 단위 테스트를 정식으로 추가하는 것이 좋다.
- 코드를 불변식과 계약이라는 관점으로 보면 데이터의 일관성을 해치는 함수를 찾기 수월해진다.
- 바깥에서는 안전에 주의하라 (p.331)
- 해킹은 공격자의 지능이 높아서 일어나기보다 개발자의 부주의로 벌어진다.
- 보안 원칙
- 공격 표면을 최소화하라. (공격 표면 = 사용자와 서비스의 모든 접근 지점)
- 최소 권한 원칙 (최소한의 권한만을 꼭 필요한 시간만큼만 제일 짧게 부여)
- 안전한 기본값
- 민감 정보를 암호화하라
- 보안 업데이트를 적용하라
- 이름 짓기 (p.341)
- 언어 자체의 문법에선 어느 쪽이든 상관없다고 하더라도 아무 것이나 쓰면 안 된다.
- 프로그래밍 언어별 문화를 존중하라. (변수명, 표기법 등)
- 반드시 팀의 모든 살마이 각 단어의 뜻을 알고 일관성 있게 사용해야 한다.
- 짝 프로그래밍, 용어 사전 등의 방법을 통해 의사소통을 장려할 수 있다.
- 잘못된 이름은 바로 고쳐라, 고칠 수 없다면 ETC 위반이다.
🤔 소감 및 생각
- 이 챕터의 내용처럼 '잘 되는 코드를 괜히 내가 리팩토링 하려고 했다가 더 오류가 나진 않을까?' 라는 생각때문에 더 나은 코드로 교체하기를 두려워했던 적이 많았고, 지금도 그렇다. 새로운 시스템을 개발할 때 TDD 기반으로 진행하여야 회귀테스트 등 리팩토링 후에도 동일하게 정상 동작함을 증명 가능하기 때문에 테스트 코드 작성이 더욱 더 중요함을 다시 느끼게 되었다.
🔍 새롭게 또는 다시 알게 된 내용
- 스트루프 효과 : 과제에 대한 반응 시간이 주의에 따라 달라지는 효과 또는 이러한 현상을 이용하는 검사
