• 테스트를 작성하기 가장 좋은 시점은 프로그래밍을 시작하기 전이다. 나는 기능을 추가해야 할 때 테스트부터 작성한다. 얼핏 순서가 뒤바뀐 듯 들리지만, 전혀 그렇지 않다. 테스트를 작성하다 보면 원하는 기능을 추가하기 위해 무엇이 필요한지 고민하게 된다. 구현보다 인터페이스에 집중하게 된다는 장점도 있다(무조건 …

  • 냄새 나면 당장 갈아라. — 켄트 백 할머니의 육아 원칙
  • 이 장은 켄트와 내가 함께 집필했다는 점을 강조하기 위해 ‘나’가 아닌 ‘우리’란 표현을 사용한다. 어느 부분을 누가 쓴 것인지는 쉽게 구분할 수 있다. 웃긴 농담은 필자가 쓴 것이고 나머지는 켄트가 쓴 것이다.
  • 우리는 주석을 달아야 할 만한 부분은 무조건 …

  • 리팩터링: [명사] 소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법
  • 리팩터링(하다): [동사] 소프트웨어의 겉보기 동작은 그대로 유지한 채, 여러 가지 리팩터링 기법을 적용해서 소프트웨어를 재구성하다.
  • 리팩터링은 결국 동작을 보존하는 작은 단계들을 거쳐 코드 …

리팩터링 2판

  • 리팩터링이란
    리팩터링은 겉으로 드러나는 코드의 기능(겉보기 동작)은 바꾸지 않으면서 내부 구조를 개선하는 방식으로 소프트웨어 시스템을 수정하는 과정이다.

Chapter 01

  • 리팩터링의 첫 단계는 항상 똑같다. 리팩터링할 코드 영역을 꼼꼼하게 검새하줄 테스트 코드들부터 마련해야 한다.

리팩터링하기 전에 제대로 …


[실용주의 프로그래머] 에서 소통에 대한 부분 중 WISDOM 에 대한 소개가 나온다.
다음과 같다.

무엇(What)을 배우길 원하는가?
말하려는 것에서 그들이 관심(interest) 있어 하는 건 무엇인가?
얼마나 소양(sophisticated)이 있는가?
어느 정도의 구체적인(detail) 내용을 원하는가?
누가 정보를 소유(owe)하길 원하는가?
그들이 경청하도록 동기(motive)를 주려면 어떻게 해야 할까?

여기서 인상깊었던 것은 마지막 ‘동기’ 에 대한 부분이다.
경청할 수 있도록 동기를 줘야한다는 것.
생각해보면 당연한 것 같은데 막상 대화를 할 때는 잊곤 하는 부분인 듯 하다.

아마 WISDOM 의 다른 요소들을 신경쓰고 갖춤으로써 동기 역시 자연스레 생기는 게 아닐까 하는 생각을 하기 쉬운 것 같은데, 그건 그저 기대에 가깝다는 생각이 든다.

대화를 할 때, 그들에게 들을 동기를 주고 있는지, 어떤것이 동기가 될 수 있을지 생각해보면 좋겠다는 생각을 한다.


알고리즘은 애증인 것 같다. 알고리즘을 공부한지는 꽤 되었는데 여지껏 알고리즘에 자신이 있다고는 못하고 있다.

알고리즘 테스트에 대해 여러 의견이 있지만 나는 알고리즘을 잘 못하긴 하지만 알고리즘을 공부한 것이 개발에 도움이 되기는 한다는 입장이다. 물론 이것은 나의 수준에 맞춘 판단인데, 예를 들면 어떤 구조에서 …


최근 회사에서 A/B 테스트를 진행하게 되어서 실험을 만들고, 실행하고, 분석하는 과정에 참여할 수 있었다.

그러면서 데이터를 보고 판단하는게 어렵다는 생각을 막연히 하다가 [데이터 분석가의 숫자유감]이라는 책을 보기 시작했다.

맨 첫 챕터가 상관관계와 인과관계에 대한 이야기이다.

일단, 책을 읽기 잘했다는 생각이 들었다.

다음으로는 그래서 이걸 어떻게 정확하게 분석하고 판단할 수 있을까 하는 생각이 든다.

위에서 말한 회사에서 진행한 A/B 테스트는 진행하고, 나름대로의 결과를 도출해냈다. 그런데 그것을 아주 면밀히 검증하고 깨끗하게 판단했다고 말하기는 좀 주저되긴 한다.

그리고 또 한편으로는 그렇게 정확하고 깨끗하게 분석하는게 가능하기는 한것일까 싶기도 하다.

그건 책을 더 읽어봐야하겠지.

아무튼 막연하게 뭔가를 더 해야하지 않을까, 이게 정확한것일까 하던 부분들을 살펴볼 수 있지 않을까 싶다.

첫 챕터부터 재밌다~!


전 프로젝트에서 리딩을 해주셨던 백엔드 개발자(음 이렇게 말하니 굉장히 거리가 느껴지는 군. 그렇지는 않습니다.) 분께서 같이 슬랙앱을 만들어보지 않겠냐는 이야기를 하셨다.

시작은 회사 직원분께서 스프레드 시트에 정리한 맛집 리스트였다.

회사 근처의 맛집들을 스프레드 시트에 정리해 놓으셨는데 그것을 데이터 베이스 삼아 …


기술책은 딱딱하다는 편견일까?

기술이니 정확해야하고.. !@#$ 하는 생각들이 의례히 떠오르긴 하지만

가끔씩은 그 안에서도 유머를 빛내는 분들이 있다.

지금 보고 있는 책 ‘한 권으로 끝내는 Node & Express(2판)’(이선 브라운 저한선용 역) 도 그러한데, 예를 들면 아래와 같은 부분들이다.

‘일반적으로 쿼리스트링을 사용할 때는 GET 요청을, 요청 바디를 사용할 때는 POST 요청을 사용합니다. HTTP 프로토콜에서 이러헥 하라고 강제하는 것은 아니지만 다른 방법을 쓸 이유도 없습니다. 표준을 따르는 것이 가장 좋습니다.

POST는 안전하고 GET은 안전하지 않다는 오해가 널리 퍼져 있지만, 그렇지 않습니다. HTTPS를 사용하면 둘 다 안전하고, 사용하지 않으면 둘 다 안전하지 않습니다.’

은근하게 재미있다.

글을 쓸 때도 이렇게 은근하게 스며들어 있는 웃음기를 좋아하는데

그걸 Node 책을 보다가 발견하니 기분이 좋다.


MIT 알고리즘 강의 중에서

MIT의 알고리즘 강의 중 교수의 이야기이다.

효율이 중요하다는 것은 물론 알고 있다.

그렇지만 브루트 포스의 방식이 마음에 드는 것은 위와 같은 이유려나 싶다

물론 정확하고 효율적으로 만들면 좋겠지만.. 아무튼

정확과 효율의 범위를 넓혀나가야 하겠지

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store