Community

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

← Go back
TIL 7장. 코딩하는 동안
#pragmatic
2년 전
694

오늘 TIL 3줄 요약

  • 우연에 기대지 말자.

  • 항상 리팩터링하고, 테스트를 적극 활용하자.

  • 보안 이슈가 발생하지 않도록 신경 쓰고, 의미가 잘 드러나도록 이름을 짓자.

TIL (Today I Learned) 날짜

2022.04.02

오늘 읽은 범위

7장. 코딩하는 동안

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

  • 코딩할 때는 매 순간 결정을 내려야 하는데, 프로그램이 정확하게 생산적으로 작동하면서 천수를 누리도록 하려면 사려 깊은 생각과 판단으로 결정을 내려야 한다. - 273p

  • 프로그래머로서 경험이 늘어 갈수록 여러분의 뇌에는 암묵적인 지식이 켜켜이 쌓인다. 잘 되는 방법, 잘 안되는 방법, 오류 형태별로 가능한 원인 등 일하는 동안 보고 듣고 느끼는 모든 것이 쌓인다. - 276p

  • 일단, 하고 있는 일을 멈춰라. 여러분의 뇌가 정리를 좀 할 수 있도록 약간의 시간과 공간을 확보하라. 코드에 대해 생각하지 말고 키보드에서 떨어져서 잠깐 머리를 비운 채로 할 수 있는 일을 하라. 언젠가는 다시 생각이 의식의 영역으로 올라와서 ‘아하!’하는 순간이 찾아올 것이다. 이 방법이 잘 안되면 문제를 표면으로 끄집어내 보라. 작성하는 코드에 대한 그림을 그려 보라. 동료에게 설명해 보라. -279p

  • 우리는 우연에 맡기는 프로그래밍, 곧 행운과 우연한 성공에 의존하는 프로그래밍을 하지 않아야 한다. 대신 ‘의도적으로 프로그래밍’해야 한다. ...(중략)... 우연에 기대다 보면 결국 문서화되지 않은 에러나 예외적인 경우의 동작에 의존하게 되고 만다. - 283p

  • 인간은 언제나 패턴과 인과 관계를 찾으려고 한다. 그저 우연에 불과한 것들 속에서도 그렇다. ...(중략)... 가정하지 말라. 증명하라. - 286p

  • 자신도 잘 모르는 코드를 만들지 말라. 완전히 파악하지 못한 애플리케이션을 빌드하거나, 이해하지 못한 기술을 사용하면 우연의 함정에 빠질 가능성이 높다. 이것이 왜 동작하는지 잘 모른다면 왜 실패하는지도 알 리가 없다. - 288p

  • 기존 코드가 앞으로 짤 코드를 지배하도록 놓아 두지 말라. 더는 적절한 코드가 아니다 싶으면 어떤 코드라도 교체할 수 있다. 한 프로그램 안에서도 예전에 한 일이 앞으로 할 일을 제약하지 못 하도록 하라. - 289p

  • O() 표기법은 우리가 측정하는 값의 상한을 기술하는 표기법이다. ...(중략)... 대문자 O 표기법은 수행 시간이든 메모리든, 아니면 다른 무엇을 나타내든 실제 숫자를 알려주지 않는다. 그저 입력의 크기가 바뀜에 따라 이 값이 어떻게 바뀔지를 알려줄 뿐이다. - 293p

  • 언제나 어떤 알고리즘을 개선하느라 여러분의 귀중한 시간을 투자하기 전에 그 알고리즘이 정말 로 병목인지 먼저 확인하는 것이 좋다. - 298p

  • 마틴 파울러는 ‘리팩터링’을 다음과 같이 정의한다. 이 정의에서 핵심적인 부분은 다음 두 가지다. 1)

    이 활동은 체계적이다. 아무렇게나 하는 것이 아니다. 2) 밖으로 드러나는 동작은 바뀌지 않는다. 기능을 추가하는 작업이 아니다. - 302p

  • 지금 리팩터링을 하지 않으면 일이 더 진척되었을 때, 즉 신경 써야 할 의존성이 더 많아졌을 때 문제를 고쳐야 하고, 따라서 훨씬 더 많은 시간을 투자해야 한다. - 304p

  • 탄탄한 회귀 테스트를 유지하는 것이야말로 안전한 리팩터링의 비결이라는 것이다. - 306p

  • 다른 코드와 긴밀하게 결합된 함수나 메서드는 테스트하기 힘들다. 즉, 무언가를 테스트하기 좋게 만들면 결합도도 낮아진다. 게다가 무언가를 테스트하려면 그것을 이해해야만 한다. ...(중략)... 코드에 테스트의 빛을 비추면 모든 것이 명확해진다. 코딩을 시작하기 전에 경계 조건의 테스트와 경계 조건에서 어떻게 동작해야 하는지를 먼저 생각해 본다면, 아마 함수를 단순하게 만드는 코드 패턴을 찾을 수 있을 것이다. - 310p

  • 명백히 테스트는 개발을 이끌어 나가는 데 도움이 된다. 하지만 나아갈 때

    마다 목적지를 떠올리지 않으면 계속 같은 자리만 빙빙 돌게 될 수도 있다. - 314p

  • 여러분이나 여러분의 팀이 테스트하지 않으면 결과적으로 사용자들이 테스트하게 된다. 그러니 소프트웨어를 철저하게 테스트할 계획을 세우는 것이 좋다. - 319p

  • 코드에 존재하는 계약과 불변식을 뭉뚱그려서 ‘속성’이라고 부른다. 코드에서 속성을 찾아내서 테스트 자동화에 사용할 수 있는데, 이것을 ‘속성 기반 테스트’라 한다. - 322p

  • 속성 기반 테스트는 여러분이 코드를 불변식과 계약이라는 관점으로 바라보게 한다. 여러분은 무엇이 변하지 않아야 하고, 어떤 조건을 만족해야 하는지 생각하게 된다. - 329p

  • 복잡한 코드는 예상 외의 부작용이 일어날 확률을 높이고, 결과적으로 공격 표면을 넓힌다. - 333p

  • 최소한의 권한만을 꼭 필요한 시간만큼만 제일 짧게 부여하라는 게 또다른 핵심 원칙이다. - 335p

  • 인위적인 제약을 걸면 무작위도를 낮추고 나쁜 비밀번호 습관을 부추겨서 사용자 계정 탈취를 도와주는 꼴이 될 뿐이다. - 339p

  • 암호화에 있어서 첫 번째 규칙이자 가장 중요한 규칙은 절대 직접 만들지 말라는 것이다. - 340p

  • 이름은 아주아

    주 중요하다. 이름은 여러분의 의도와 믿음을 잔뜩 드러내기 때문이다. 우리는 코드에서 하는 역할에 따라 이름을 지어야 한다고 믿는다. 이 말은 무언가를 만들 때마다 잠시 멈춰서 ‘내가 이것을 왜 만드는 거지?’하고 생각

    해야 한다는 뜻이다. - 341p

  • 반드시 팀의 모든 사람이 각 단어의 뜻을 알고 일관성 있게 사용해야 한다. 한 가지 방법은 많은 의사소통을 장려하는 것이다. - 346p

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

  • 어떤 문제가 발생했을 때 가장 해결이 쉬운 상황은 그 문제 혹은 비슷한 문제를 마주했던 적이 있을 때라고 생각한다. 결국, 문제를 잘 해결하려면 많은 문제를 마주해보고, 그 문제를 해결하는 경험을 쌓아야 한다. 이것저것 시도해보면서 어떤 해결방법이 가장 좋은지, 문제를 어떻게 접근하는 것이 좋은지와 같은 것들은 절대 공부해서 얻을 수 있는 것이 아니다. 경험에서 얻는 것이다. 경험의 축적, 체화. 이런 것들이 업계에서 자신을 가장 특별하게 만들어주는 요소라 생각한다. 계속 시행착오를 겪으면서 나를 발전시키기 위해 노력하자.

  • 자신의 본능, 무의식에 귀기울이기 위해 일단 하고 있는 일을 멈추고, 그래도 안 된다면 문제를 표면으로 끌어내라는 부분이 공감이 많이 되었다. 유튜브를 보다가 '창의적인 아이디어는 일에 몰두하다가 휴식을 취할 때 많이 떠오른다.'는 말을 들었는데, 너무 인상적이었다. 돌이켜보면, 정말 작업에 계속 몰두할 때는 떠오르지 않던 아이디어가 쉴 때 갑자기 생각나기도 하고, 한없이 복잡해보였던 문제가 쉬고 나면 단순해지는 경우가 있다. 또한, 문제나 아이디어를 그냥 생각하는 것보다, 직접 써보거나, 그려보거나, 말로 하면 더 잘 정리되는 경우가 많다.

  • 클린코드를 읽으면서도 얻었던 교훈인데, 항상 코드를 개선하기 위해 노력하자. 즉, 리팩터링을 일상화하자. 책에서 이야기한 것처럼, 지금 마주한 문제를 뒤로 미루면 더 큰 문제가 되어 나타난다. 생각났을 때마다, 마주했을 때마다 코드를 더 좋은 방향으로 수정하기 위해 노력하자.

  • 보안에 관해 이야기하는 부분이 인상 깊었다. switch cost 때문에 고객들은 웬만하면 다른 플랫폼으로 옮겨가지 않는다. 하지만 긴 기간 동안 쌓은 고객들의 신뢰를 한 번에 무너뜨리는 문제가 있다. 바로 보안 이슈다. 책에서 언급한 팁들을 마음에 새겨야겠다. 특히, 복잡한 코드가 보안을 더 취약하게 만든다는 부분이 눈에 띄었는데, 유지보수를 위해서든, 보안을 위해서든 코드를 단순하게 만들기 위해 노력하자.

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

  • P-NP 문제 : P는 결정론적 알고리즘(Deterministic Algorithm)으로 다항 시간에 해결할 수 있는 문제들의 집합, NP는 비결정론적 알고리즘(Nondeterministic Algorithm)으로 다항 시간에 해결할 수 있는 문제들의 집합. (참고 : https://gazelle-and-cs.tistory.com/64) + NP-완전에 관한 글 : https://gazelle-and-cs.tistory.com/74

  • 스레싱(thrashing) : 프로세스가 집중적으로 사용하는 페이지들의 집합이 메모리에 한꺼번에 적재되지 못해 page fault가 많이 발생하게 되고, 그로 인해 CPU 이용률이 급격히 떨어지는 현상 (참고 : https://zangzangs.tistory.com/144)

오늘 읽은 다른사람의 TIL