실용주의 프로그래머 7장 < 코딩하는 동안 >
Today reading range
- 오늘 읽은 범위
실용주의 프로그래머 7장 < 코딩하는 동안 >
Impressive content
- 인상 깊었던 내용
***적극적으로 자기 코드에 대해 생각하지 않는 프로그래머는 우연에 맡기는 프로그래밍을 하는 것이다.*** - 274p.
실용주의 프로그래머는 모든 코드를 비판적인 시각으로 바라본다. 자신의 코드도 예외가 아니다.
테스트는 버그를 찾는 작업이 아니다. 여러분의 코드에 대한 피드백을 받는 작업이다. ... 이 말인즉슨 테스트의 긍정적인 효과는 대부분 테스트를 수행할 때 나타나는 것이 아니라, 테스트에 대하여 생각할때 나타난다는 것이다.
우리가 고른 이름이 여러모로 우리가 만드는 현실을 정의한다. 코딩하는 동안 이름의 의미가 변하지 않는 지 늘 경계해야한다.
Topic37. 파충류의 뇌에 귀 기울이기
우리 인간은 더 동물적인 부분인 본능, 즉 파충류의 뇌lizard brain를 무시하라고 배워 왔다고 한다. -275p.
하지만 전문가라면 여러분은 계속해 나가야 하지 않을까..? ... 안타깝지만 진짜로 여러분이 해야 하는 일은 정반대다. -278p.
여러분의 코드가 무언가 말하려는 것이다. 지금하는 작업이 필요 이상으로 힘들다고 말이다.
...바로 프로토타이핑을 하면 된다. -279p.
- 포스트잇에 "프로토타이핑 중"이라고 써서 모니터 앞에 붙여라.
- 프로토타이핑은 원래 실패한다고 자신에게 상기켜라. 실패하지 않더라도 프로토타입은 버리는것이라는 점도 함께 상기시켜야 한다. 프로토타이핑으로 손해 볼 일은 없다.
- 텅 빈 에디터 화면에 여러분이 배우고 싶은 것 혹은 하고 싶은 것을 한 문장의 주석으로 표현해 보라.
- 코딩을 시작하라.
첫 단계는 산책과 수다, 그리고 휴식이다.
하던 일을 멈추고 그 느낌을 분석하라. 여러분의 목소리를 귀 기울여 주는 환경에 있다면 적극적으로 표현하라. -281p.
Topic38. 우연에 맡기는 프로그래밍
우리는 우연에 맡기는 프로그래밍, 곧 행운과 우연한 성공에 의존하는 프로그래밍을 하지 않아야 한다. 대신 '의도적으로 프로그래밍'해야 한다.
왜 코드가 망가졌는지 프레드가 모르는 까닭은 애초에 코드가 왜 잘 돌아가는지도 몰랐기 때문이다.
가정하지마라, 증명하라. -286p.
언제나 사용자가 글을 읽을 수 있다고 생각하는가? 확실한 것이 아닌데도 의존하고 있는 것은 또 무엇이 있을까? -287p.
잘되는 듯한 답을 찾는 것과 올바른 답을 찾는 것은 다르다.
Tip 62 우연에 맡기는 프로그래밍을 하지 말라.
### Topic39. 알고리즘 속도
어떤 정렬 루틴이 원소 𝑛개를 정렬하는데 𝑂(𝑛2) 시간이 걸린다고 말할 때, 이는 그저 최악의 경우에 걸리는 시간이 𝑛의 제곱에 비례하여 늘어난다고 애기하는 것이다. -292p.
𝑂() 표기법은 우리가 측정하는 값-시간,메모리 등-의 상한을 기술하는 표기법이다.
대문자 𝑂 표기법은 수행 시간이든 메모리든, 아니면 다른 무엇을 나타내든 실제 숫자를 알려주지 않는다. 값이 어떻게 바뀔지를 알려줄 뿐이다. -293p.
단순반복문 => 𝑂(𝑛)
중첩반복문 => 𝑂(𝑚 ☓ 𝑛) or 𝑂(𝑛2)
반씩 자르기 => 𝑂(lg𝑛)
분할 정복 => 𝑂(𝑛lg𝑛)
조합적 => 외판원 문제...등
이론적인 요인과 실무적인 요인을 모두 고려하려고 노력하라.
Tip 64 여러분의 추정을 테스트하라.
그리고 성급한 최적화를 조심하라.
Topic40. 리펙토링
코드는 정적인 존재가 아니다. 코드는 발전해야한다. -300p.
소프트웨어 개발은 건축보다 정원가꾸기에 가깝다.
<<리팩터링>> 에서 마틴 파울러는 '리팩터링'을 다음과 같이 정의한다.
" 밖으로 들어나느 동작은 그대로 유지한 채 내부 구조를 변경함으로써 이미 존재하는 코드를 재구성하는 체계적 기법 "
- 이 활동은 체계적이다. 아무렇게나 하는 것이 아니다.
- 밖으로 들어나는 동작은 바뀌지 않는다. 기능을 추가하는 작업이 아니다
리팩터링은 그런게 아니라 잡초 제거나 갈퀴질처럼 위험하지않은 작은 단계들을 밟는 일상 활동이다.
리팩터링은 어려분이 무언가 알게 되었을 때한다.
코드를 리팩토링할 이유는 아주 많다.
- 중복
- 직교적이지 않은 설계
- 더 이상 유효하지 않은 지식
- 사용 사례
- 성능
- 테스트 통과
일정의 압박은 리팩터링을 하지 않는 단골 핑계이다. 하지만 이는 설득력이 떨어진다. 지금 리팩터링을 하지 않으면 일이 더 진척되었을 때, 즉 신경 써야 할 의존성이 더 많아졌을 때 문제를 고쳐야 하고 따라서 훨씬 많은 시간을 투자해야 한다. 그때가 되면 일정에 더 여유가 생길까? 그럴리가. -304p.
Tip 65 일찍 리팩터링하고, 자주 리팩터링하라.
### Topic41. 테스트로 코딩하기
Tip 66 테스트는 버그를 찾기 위한 것이 아니다.
우리는 테스트의 주요한 이득이 테스트를 실행할 때가 아니라 테스트에 대해 생각하고, 테스트를 작성할 때 생긴다고 믿는다. -308p.
테스트 작성에 대해 생각함으로써 코드의 작성자가 아니라 사용자인 것처럼 메서드를 외부의 시선으로 보게 되었다.
즉, 무언가 테스트하기 좋게 만들면 결합도가 낮아진다.
- 추가하고 싶은 작은 기능 하나를 결정한다.
- 그 기능이 구현되었을 때 통과하게 될 테스트를 하나 작성한다.
- 테스트를 수행한다. 다른 테스트는 통과하고 방금 추가한 테스트 딱 하나만 실패해야한다.
- 실패하는 테스트를 통과시킬 수 있는 최소한의 코드만 작성한다. 그리고 이제는 모든 테스트가 통과하는지 확인한다.
- 코드를 리팩터링한다. ....
TDD 발상의 핵심은 이 반복 주기가 기껏해야 몇 분 정도로 매우 짧아야 한다는 것이다.
Tip 66 상향식이나 하향식이 아니라 끝에서 끝까지 만들어라.
동일한 테스트를 코드 수정 후 다시 돌려보는 것을 회귀 테스트라고 한다. -315p.
우리는 단위 테스트를 계약을 잘 지키는지 보는 테스트라고 여긴다. => 계약을 테스트 하자!
여러분이 만든 테스트를 그냥 버리지 말고 기존의 단위 테스트 군단에 합류시켜라.
로그 메세지는 반드시 뀨칙적이고 일관된 형식이여야 한다. -318p.
"나중에 테스트"는 사실 "테스트하지 않음" 이라는 뜻이다.
명심하라. 테스트는 프로그래밍의 일부이다. 테스트, 설계, 코딩, 이 모든 것이 프로그래밍이다.
Topic42. 속성 기반 테스트
우리는 여러분이 함수를 작성할 때 단위 테스트도 작성하기를 추천한다. - 321p.
우리가 선호하는 대안은 컴퓨터에게 테스트를 맡기는 것이다. 컴퓨터는 여러분과 달리 선입견이 없으니 말이다.
이렇게 코드에 존재하는 계약과 불변식을 뭉뚱그려서 '속성property'이라고 부른다. 코드의 속성을 찾아내서 테스트 자동화에 사용할 수 있는데, 이것을 '속성 기반 테스트property-based testing'라 한다.
Topic43. 바깥에서는 안전에 주의하라.
좋은 울타리가 좋은 이웃을 만든다.
- 로버트 프로스트(Robert Frost), < 담장고치기 >
우리는 지나칠 정도로 의심을 해야한다. 매일. - 331p.
-
공격표면을 최소화하라.
"공격표면" 이란 공격자가 데이터를 입력하거나, 데이터를 추출하거나 서비스를 실행시킬 수 있는 모든 접근 지점을 합한 것이다.
코드의 복잡성은 공격 매개체attack vector를 유발한다.
입력 데이터는 공격 매개체다.
인증없는 서비스는 공격 매개체다.
Tip 72단순함을 유지하고 공격 표면을 최소화하라. -
최소 권한 원칙
최소한 의 권한만을 꼭 필요한 시간만큼만 제일 짧게 부여하라는 게 또다른 핵심 원칙이다.
여러분의 애플리케이션이 여러 단계의 접근 권한을 구현하는가? 아니면 '관리자' 외에는 모두 그냥 '시용자'인 초보적인 도구인가? 그렇다면 더 상세하게 제어하는 시스템을 고민해보라. -
민감 정보를 암호화 하라.
우리는 프로젝트에 필요한 모든 것을 버전 고나리 시스템에 넣으라고 강력히 추천했다. ...이 규칙에 중요한 예외가 하나있다. 암호나 API키, SSH키, 암호화 비밀번호, 그 밖의 다른 인증 정보를 소스코드용 버전 관리 시스템에 넣지 말라. -
보안 업데이트를 적용하라.
지금까지 발생한 데이터 유출 사고 중 가장 큰 사고는 업데이트를 하지 않은 시스템때문에 발생했다는 사실만 기억하기 바란다.
까다로운 비밀번호 정책은 실제로는 보안 수준을 낮춘다 - 338p. => 비밀번호가 까다로울수록 사용자는 더 보안이 안좋은 곳에 비밀번호를 메모할지도 모른다.
### Topic44. 이름 짓기
이름이란게 무슨 의미가 있나? 프로그래밍에서는 이름이 "모든 것!" 이다.
그리고 이름은 아주아주 중요하다, 이름은 여러분의 의도와 믿음을 잔뜩 드러내기 때문이다. 우리는 코드에서 하는 역활에 따라 이름을 지어야한다고 믿는다.
두 가지가 눈에 띈다. 먼저, deductPercent는 '이 함수가 하는 일'이지 '왜 이 일을 하는지'가 아니다. -343p
이름을 지을 때는 여러분이 표현하고 싶은 것을 더 명확하게 다듬기 위해 끊임없이 노력해야 한다.
"어리석은 일관성은 소인배의 말썽꾸러기 도깨비다." -345p.
부지런히 이름을 바꾸지 않으면 악몽과 같은 상황에 빠지게 된다. 무의미한 이름보다 더 고약한 잘못된 이름을 사용하는 코드가 되는 것이다. -346p.
Thoughts I had while reading the book
- 오늘 책을 읽으면서...
인상 깊었던 내용 첫줄에 적은 문장 그 다음에 쓰고싶었던 문장하나가 더 있었다.
너무 찔려서 차마 쓰지 못하다가 소감문에 적어본다.
이 책을 읽으면서 항상 성경책같다는 생각을 한다. 마치 그날 읽은 성경책 내용이 오늘 힘들었던 무언가에 대한 대답같이 느껴질때처럼...< Topic 38 우연에 맡기는 프로그래밍 > 이 오늘있었던 내 상황을 반성하라는 듯한 내용이여서 더욱 그랬다. 코드가 작동하는데 왜 저렇게 작동하는지 해답을 못찾아서 한동안 찾았는데 결국 못찾았다. 그러다가 에러처리를 하려는 도중에 뭐가 잘못됬는지 알았는데 항상하던 작업이라 아무생각없이 하다가 중요한 코드 하나를 놓쳤던 거였다🤣 정말 어이가 없었다. 근데 하필 오늘 읽은 내용이 우연에 맡기는 프로그래밍이라니 읽으면서 엄청 반성하게됬다..잘하자..발자야
리눅스 수업때 꼭 Root로 접속하지말고 일시적인 권한을 얻는 subo를 이용해서 사용하라는 말을 들었는데 이런 이유에서 였구나
프로젝트 중에 로그인페이지에 저 기능을 넣을까 말까 고민을 많이 했다. 보안도 중요하지만 서비스 이용방식에 대한 선택권을 넓히면 더 사용자가 안전하다고 느끼려나?
도전해볼것
- 로버트 세지윅의 알고리즘 혹은 알고리즘 분석 입문 읽기
- 더 자세히 알고싶다면 도널드 커누스의 << The Art of Computer Programming >> 읽기
- 현재 작업 중인 코드에 대하여 생각해 보자. 어떤 속성, 즉 계약과 불변식이 있는가? 속성을 자동으로 검증하기 위해 속성 기반 테스트 프레임워크를 사용할 수 있는가?
