오늘 TIL 3줄 요약

• 작업 중 느낌이 이상하다면 현재 작업 절차를 점검하자.

• 우연은 없다. 항상 모든 상황을 생각하고 계산하고 증명하자.

• 테스트는 단순히 버그를 찾는 일이 아닌다.

TIL (Today I Learned) 날짜

2022. 04. 01~02

오늘 읽은 범위

7장. 코딩하는 동안

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

코딩도 대부분은 반복적인 일이지만 정신을 늘 기민하게 유지하면 재앙을 막을 수 있다.

• Topic 37. 파충류의 뇌에 귀 기울이기 (p.275)

프로그래머로서 경험이 늘어 갈수록 여러분의 뇌에는 암묵적인 지식이 켜켜이 쌓인다.

여러분은 자신의 뇌가 하는 일을 자각하지 못하더라도 뇌는 계속 저장을 하고 있는 것이다.

어떤 작업을 앞두고 마음속에 의심이 계속 남아 있거나 왠지 꺼림칙하다면,

여러분의 경험치 여러분에게 말을 거는 중일지도 모른다.

직감이 여러분의 역량에 일조하도록 하라.

이미 존재하는 코드 위에서 작업하고 있어서 기존 코드 때문에 문제 해결이 여의치 않다면,

기존 코드를 잠시 다른 곳으로 밀어 두고 비슷한 것을 대신 프로토타이핑으로 만들어라.

명확한 문제로 구체화되면 즉각 해결하라.

마친 후 여전히 불안한 마음이 들면 다시 처음부터 시작하라.

• Topic 38. 우연에 맡기는 프로그래밍 (p.282)

우리는 우연에 맡기는 프로그래밍, 곧 행운과 우연한 성공에 의존하는 프로그래밍을 하지 않아야 한다.

대신 '의도적으로 프로그래밍'해야 한다.

애초에 코드가 왜 잘 돌아가는지도 모른다면,

왜 코드가 망가졌는지도 모를 것이다.

단순히 코드가 지금 작성된 방식이 그렇기 때문에 생기는 우연한 일들이 있다.

이런 우연에 기대다 보면 결국 문서화되지 않은 에러나 예외적인 경우의 동작에 의존하게 되고 만다.

특정한 경우에만 '딱' 특정한 현상이 발생하는 것은 그저 우연이다.

사실은 더 깊고 근본적인 문제가 있었을 것이다.

테스트가 여러분의 장비에서는 통과했던 것 같은데 서버에서는 통과하지 못하는 이유는

두 환경의 차이 때문일 수도 있지만 어쩌면 그저 우연일 수도 있다.

가정하지 말라. 증명하라.

그러므로 앞으로 어떤 것이 잘 돌아가는 듯이 보이기는 하는데

여러분이 그 이유를 모를 경우

그것이 우연은 아닌지 반드시 확인하라.

• Topic 39. 알고리즘의 속도 (p.291)

실용주의 프로그래머가 거의 날마다 하는 또 다른 종류의 추정이 있다.

바로 알고리즘이 사용하는 자원, 곧 시간, 프로세서, 메모리 등을 추정하는 것이다.

대문자 O 표기법(Big-O notation)은 우리가 측정하는 값-시간, 메모리 등-의 상한을 기술하는 표기법이다. (ex. O(n))

n이 커질수록 가장 큰 차수에 비하면 다른 차수는 무시해도 될 정도이기 때문에,

관습적으로 최상위 차수를 제외한 다른 모든 차수는 제거하며,

상수인 계수도 표기하지 않는다.

사용하는 알고리즘의 차수를 추정하라.
코드를 작성하기 전에 실행 시간이 얼마나 걸릴지 대략이라도 감을 잡아라.

코드의 실행 시간이 얼마나 될지 또는 메모리를 얼마나 사용할지 확실하지 않다면 직접 실행해 보라.

알고리즘의 수학적 분석이 모든 것을 다 알려주지는 않는다.
실제 환경에서 코드의 수행 시간을 측정해 보라.

가장 빠른 알고리즘이 언제나 가장 좋은 알고리즘은 아니다.

'성급한 최적화(premature optimization)'를 조심하라.

언제나 어떤 알고리즘을 개선하느라 여러분의 귀중한 시간을 투자하기 전에

그 알고리즘이 정말로 병목인지 먼저 확인하는 것이 좋다.

• Topic 40. 리팩터링 (p.300)

코드 고쳐쓰기, 다시 작업하기, 다시 아키텍처 만들기는 모두 아울러서 '재구성(restructuring)'이라고 부른다. 그런 활동 중 일부를 따로 떼어 '리팩터링(refactoring)'이라는 이름으로 실천하기도 한다.

무질서하게 대규모로 코드를 다시 쓰는 것이 아니라, 정확한 목적을 가지고 정밀하게 접근하는 활동이다. 그래서 코드를 바꾸기 쉽게 유지하는 것이다.

* 리팩터링은 언제 하는가?

리팩터링은 여러분이 무언가를 알게 되었을 때 한다.

주저하지 말고 변경하라.

일찍 리팩터링하고, 자주 리팩터링하라.

일정에 리팩터링할 시간을 확실히 포함시켜 두도록 하라.

그 코드를 사용하는 사람들이 코드가 조만간 재작성될 것이라는 사실과

재작성이 그들의 코드에 미칠 영향을 인지하도록 해야 한다.

* 리팩터링은 어떻게 하는가?

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

2. 리팩터링을 시작하기 전 든든한 테스트가 있는지 먼저 확인하라.

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

다음에 여러분이 기대하는 수준에 못 미치는 코드를 발견하면, 고쳐라.

지금은 고통스러울지라도 앞으로 더욱 고통스러워질 것 같으면 지금 고치는 편이 낫다.

• Topic 41. 테스트로 코딩하기 (p.307)

테스트는 버그를 찾기 위한 것이 아니다.
테스트는 여러분의 코드를 보는 한 관점이다.
코드의 설계, API, 결합에 대한 피드백을 준다.

테스트에 대해 생각함으로써 코드의 결합도는 낮추고 유연성은 올릴 수 있다.

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

다른 코드와 긴밀하게 결합된 함수나 메서드는 테스트하기 힘들다.

무언가를 테스트하려면 그것을 이해해야만 한다.

* TDD(test-driven development): 목표가 어디인지 알아야 한다.

전체 문제를 완전히 파악하기 힘들 때 한 번에 테스트 하나씩 작은 단계들을 밟아라.

소프트웨어를 만들 때 맨 처음부터 테스트가 가능하도록 만들고,

코드들을 서로 연결하기 전에 코드를 하나하나 철저하게 테스트해야만 한다.

다양한 종류의 테스트 케이스와 경계 조건에서도 모듈이 약속한 대로 기능을 잘 수행하는지 테스트 해보자. 계약을 잘 지키는지 확인하는 테스트를 강조함으로써 프로젝트에서 이후에 벌어질지 모를 재앙을 피하려고 노력하자.

여러분의 소프트웨어를 테스트하라. 그러지 않으면 사용자가 테스트하게 된다.

• Topic 42. 속성 기반 테스트 (p.321)

코드를 작성하고 직접 테스트를 작성한다면 잘못된 가정이 둘 다에 들어갈 수도 있지 않을까?

자기 자신의 생각에 비추어 보면 제대로 동작하므로 코드는 테스트를 통과한다.

>> 대안은 컴퓨터에게 테스트를 맡기는 것이다. 컴퓨터는 여러분과 달리 선입견이 없다.

코드에 존재하는 계약과 불변식을 뭉뚱그려서 '속성(porperty)'이라고 부른다.

코드에서 속성을 찾아내서 테스트 자동화에 사용할 수 있는데,

이것을 '속성 기반 테스트(property-based testing)'라 한다.

속성 기반 테스트가 강력한 까닭은 그저 입력을 생성하는 규칙과 출력을 검증하는 단정문만 설정한 채 제멋대로 작동하도록 놔두기 때문이다.

속성 기반 테스트는 임의의 값을 생성하여 사용하기 때문에 다음번에 실행했을 때 똑같은 값을 테스트 함수에 넘긴다는 보장이 없다. 위와 같이 단위 테스트를 만들어 두면 버그가 완전히 해결되었음을 보장할 수 있다.

속성 기반 테스트는 여러분이 코드를 불변식과 계약이라는 관점으로 바라보게 한다.

여러분은 무엇이 변하지 않아야 하고, 어떤 조건을 만족해야 하는지 생각하게 된다.

• Topic 43. 바깥에서는 안전에 주의하라 (p.331)

우리는 지나칠 정도로 의심을 해야 한다. 매일.

근래 발생하는 보안 관련 사건, 사고들은 모두 개발자가 부주의한 탓이다.

* 기본 보안 원칙

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

2. 최소 권한 원칙.

3. 안전한 기본값.

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

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

외부의 인증 서비스를 사용하라.

여러분의 조직 내에서 운영하는 인증 서비스를 함께 사용할 수도 있고,

외부 클라우드가 제공하는 것을 사용할 수도 있다.

• Topic 44. 이름 짓기 (p.341)

이름이란게 무슨 의미가 있나?? 프로그래밍에서는 이름이 "모든 것!!"이다.

이름을 지을 때 왜 만드는지 생각하는 것은 아주 효과적이다.

여러분이 문제 풀이 사고방식에서 벗어나 더 큰 그림을 보도록 하기 때문이다.

이름 짓기에서의 관습은 각 프로그래밍 언어나 환경의 문화에 달린 것이다.

예를 들어 한글자 변수명,, 관습이 없는 환경이라면 당연히 한 글자 변수명을 사용하면 안된다.

그 분야의 문화를 존중하라.

반드시 팀의 모든 사람이 각 단어의 뜻을 알고 일관성 있게 사용해야 한다.

아무리 좋은 이름을 짓기 위해 노력하더라도 모든 것은 변한다.

부지런히 이름을 계속 바꾸지 않으면 악몽 같은 상황에 빠지게 된다.

문제를 발견했으면 고쳐라.

당장 바로 그 자리에서.

읽는 사람에게 의도를 표현할 수 있는 이름을 붙이고, 의도가 변하자마자 이름을 바꿔라.

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

• 이번 장은 지난 다른 장들과 비교해서 양이 상당히 많았네요. 정리하고 싶은 내용이 정말 많았는데 제가 간단하게 정리하는 것을 잘 못해서 내용도 그만큼 길어지게 되었어요..

• 우연, 테스트, 보안 등 여러 키워드 내용들에서 제 경험을 떠올리며 공부했네요.

• 단순히 반복 테스트만을 하는 업무에서 개발/테스트 환경 구축/프로세스 개선 업무를 어느 정도 경험해본 관점에서 생각을 많이 했어요.

• 현재 개발 일정에서 코딩에만 쏟아도 시간이 부족하다고 해도, 어떻게든 테스트를 위한 시간을 남겨야 겠어요. 이전에 테스트/품질관리 업무를 담당할때 개발자가 테스트 행위를 쉽게 보는듯 했던 말과 행동을 저도 똑같이 하고 싶지는 않거든요...

• 작업 중에 집중이 안되고 뭔가 잘 안된다는 느낌을 쌔하게 받을 때가 있어요. 그럴때 저는 일단 작업을 멈추고 잠시 휴식한 다음 처음부터 다시 되돌아보는 시간을 가지곤 하거든요. 대부분의 작업에서 도움이 되었어요.

• 근래 작업중인 소형 프로젝트에서 팀원간 변수명에 대한 사전 논의를 하지 못해서 불필요한 작업을 할때가 많았어요. 카멜케이스를 사용할지 스네이크케이스를 사용할지,,PK가 될 컬럼명이나 모델들에 idx,id,no 등 어떤 이름을 붙일지, 동사+명사를 사용할지, 명사+동사를 사용할지, 어떻게 사용할지 등등 작업을 하면서 많은 생각을 하게 만들더라구요.

• 마지막으로..! 보안은 팀원 모두가 신경을 써야 한다고 생각해요. 권한에 대해서는 서로 이해도 많이 필요하구요. 확실히 서로 논의할 시간을 가지는 것이 중요하다고 생각해요. 나는 XX 담당이고 리눅스 서버나 권한 그런거 잘 모르니 알아서 좀 다 잘되게 처리 해달라는 그런식의 통보 말고,,서로 공부도 좀 많이 해서 의견을 공유 할필요가 있겠다고 생각했어요.

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

• 왜 우리나라(한국)는 아직도 테스트에 대한 인식이 부족한걸까요?? 많이 좋아졌다고는 하지만, 아직도 많은 기업에서는 테스트는 그냥 input->output이 개발자가 예상한대로, 기획자가 기획한대로 나오면 끝이라고만 생각 하더라구요. 해외에서도 비슷한가요?!

오늘 읽은 다른사람의 TIL

• ysyoo님의 TIL (https://nomadcoders.co/community/thread/4148)